問題：能否先簡單談談您在測試領域的工作經驗？和您對此領域的理解？
宗剛：我的工作經驗主要分成三個階段：
第一階段：民企開發Leader
畢業后做程序員，負責開發維護6個產品。解決過多次關鍵性能問題，其中有一次系統跑批2小時后死機，通過我的優化最后只需要15分鐘完成，協助業務部門打了一個大勝戰。06年開始在項目組自下而上推一些敏捷實踐。因為有開發編程以及敏捷工程的基礎，為我后期進行大型系統性能測試、優化、規劃以及提出全生命周期敏捷性能管理體系打下了堅實的基礎。
第二階段：創業公司負責人
和幾位朋友一起創業，負責公司兩個產品的運作，測試、開發、需求、業務、銷售、人力各種工作都干過。雖然結果不太理想，但這個階段磨練我從整體去看一個產品，從開發、測試、產品系統看問題，而不會局限于研發。
第三階段：惠普非功能技術負責人
到惠普后，作為團隊非功能技術負責人，推行敏捷軟件開發，推行安全測試，提出性能測試優化建模整體服務整體解決系統上線過程中的技術難題，提出全生命周期敏捷性能與容量管理體系解決系統整個生命周期的性能與容量難題，提出交維服務系統解決從研發到運維的技術、流程等問題。主要為國內金融、電信、政府核心系統進行非功能服務。曾在創金融領域全球最高TPS（HP開放平臺）的項目擔任性能技術專家。惠普是一個很大的平臺，各種資源都有，性能測試工具、監控工具、刀片、小機、存儲、網絡、操作系統以及各種領域專家，最重要的是有很多大型應用系統的客戶，非常有利于性能技術成長。
對于測試領域的理解：
A、從測試領域職業發展來看，將來的測試有兩條比較好的出路，一條為業務專家，懂得某業務領域知識如金融、電信、建筑等等有行業壁壘的知識；另一條為測試技術專家，會編程是基礎，能夠做技術含量比較高的測試。原來主要點擊幾下鼠標的黑盒測試競爭會越來越激烈，由于知識壁壘有限，大量的高校畢業生輕易進入這個領域，很難出高薪。前幾年是測試領域的原始積累期，很多技術能力不強的人能成為領導、經理，將來這種可能性越來越小。
B、性能測試領域現在還缺少標準，市面上的培訓以及書籍多數以工具為主，沒有系統解決性能問題關注性能測試為主。
問題：能否簡述企業中性能測試現狀？
宗剛：從09年的淘寶雙十一導致多家銀行網銀系統宕機，到12306購票難，再到前不久聚美優品促銷活動剛開始就遭秒殺。根據Google的統計，如果網站打開慢每500毫秒，用戶訪問量將下降20%。根據Amazon統計，每慢100毫秒，交易額下降1%。這些事件和統計數據為大家敲響了警鐘，企業也會越來越重視性能測試。
企業性能測試常見問題：
A、缺少整體性能與容量管理策略，常常臨時抱佛腳，見過用20人年開發的系統上線之后系統性能完全無法瞞住要求，重新開發
B、UAT階段才做測試。為時太晚，很多問題這個階段無法解決或解決成本非常高
C、運維與研發缺乏互動。沒有形成生產與研發的閉環，測試結果脫離實際，見過通過大量性能測試的系統上線之后就宕機
D、缺少性能優化和規劃。只有性能測試報告，定位不了問題，提出不了建議，對于生產系統的容量和性能缺少規劃，不清楚系統的容量，無法支持有效的業務決策。
問題：能否描述一下性能測試人員的現狀？
宗剛：11和12年分別在北京、上海、深圳面試了近100位性能測試人員，主要的特點如下：
A、性能測試人員出身比較復雜，有開發經驗的人員能力和潛力都強于其他。由于性能測試項目比較少，所以不同角色的人遇到這種項目，就成為性能測試人員。由于性能測試對人員要求的技術比較高，相對之下有開發經驗的人員學習速度要快得多。就拿我自己舉例，由于有4年的開發經驗，通過兩個項目的實踐就可以靈活掌握性能測試，1年掌握的東西相當于沒有開發經驗的3年。
B、多數性能測試人員都以工具為主，缺少系統解決性能問題的能力。見過一個項目的性能測試人員只懂通過loadrunner設置場景發起壓力，根本不會性能監控和瓶頸定位，測試的數據壓倒生產庫都不知道。
C、從面試的整體來看北京的技術能力稍強于其它地區，基本上為北京>上海>深圳。
D、很多“資深”性能測試的人員由于停留于幾年以前會loadrunner就是專家的時代，技能沒有提升，陷入“上不去，下不來”的尷尬境地。
E、多數人員習慣于從測試看問題，缺少整體視角解決性能問題。個人建議從產品經理的角度看問題，因為一個產品其實就是一個小型企業，從這個角度看成本、創新、流程、質量就比較有意義，抓住了本質。
F、性能測試領域非常缺人才，缺少精通性能測試，同時熟悉各層性能優化的人才。見過好幾個企業有若干個OS、中間件、DB性能優化專家，但是解決不了性能問題，缺少整體貫通的人員。
問題：你如何理解性能測試在軟件生命周期中的位置？
宗剛：性能測試應該貫穿整個軟件的生命周期，從需求到架構到迭代到上線再到運維都和性能測試息息相關。下圖為借鑒了敏捷性能工程的思路整理出來的一個全生命周期性能管理圖。
主要分成4個大階段：
A、計劃階段：
編寫可測試的性能需求：詳細說明可落地可測試的需求，而不是籠統的寫著一天支持1.5億的交易，支持1億的用戶。
性能測試策略：需要提前考慮怎么進行性能測試，用什么工具？需要哪些培訓等等 在產品代辦列表里增加性能活動：由于性能測試一般實施周期比較長，建議單獨成為一個列表項。
B、架構評估：
在系統架構階段，在實現部分關鍵功能的情況下評估系統性能、容量、安全、可擴展性、穩定性等等是否滿足系統設計的需要，我們常常缺少這個階段的實踐，等系統開發結束才進行，常常為時已晚。在系統規劃時常常在缺少實際測試數據的時候拍腦袋規劃硬件，出現“大馬拉小車”的局面，架構評估的另一個作用是通過架構階段的評估為規劃提供數據支持。
C、迭代階段：
系統不斷的增加新特性、新需求，需要迭代驗證系統的性能與容量
D、運維階段：
研發人員常常覺得系統交給運維就可以了，由于運維人員對應用本身不夠清楚，所以常常是盲人摸象，抓不住根本。見過業務高峰期，運維人員就看著CPU在往上漲，不知道應該怎么辦，不清楚系統的容量點會在哪里出現，系統宕掉一臺服務器會怎么樣？多長時間能夠恢復？到底能夠支持多少的業務量？什么業務比較消耗時間？怎么優雅降級？在研發環境中，獲得這些數據和手段都是比較容易的，運維人員是研發的第一個客戶，應該多為他們考慮。
上面介紹了整個生命周期性能的管理，從廣度角度講。那么從深度角度講，性能管理應該包括：性能測試、性能優化和性能建模容量規劃。
性能測試：驗證系統性能是否滿足需求。
性能優化：優化性能瓶頸，提升系統處理能力，測試和優化會有若干次的迭代。性能建模容量規劃：生產環境可能出現各種場景，應該怎么預測與預防。
如果比喻整個過程為病人看病，那么性能測試就是體檢，性能優化就是對病下藥，性能建模容量規劃就是保健。
由于系統總在變化，新業務、擴容、軟硬件版本升級等等，所以需要不斷的迭代，如下圖：
問題：你如何判斷性能測試在項目或產品中的實際價值？
宗剛：實際價值：
A、業務部門：支持業務決策和促銷，提高客戶滿意度
B、運維部門：清楚系統容量，提升系統可用性、穩定定，降低硬件采購成本，提前預測預防提高響應速度，睡覺可以安心
C、規劃部門：有理有據進行規劃
D、研發部門：減少運維部門給研發部門的壓力
問題：你覺得高級性能測試專家需要什么樣的個人能力和素質？
宗剛：高級性能測試專家需要的能力模型，如下圖所示，成為博學的專家。
精通于性能測試分析建模，熟悉系統各層的監控與優化。同時需要較強的溝通能力，為了實施好項目需要有過程領域的知識如敏捷、CMMI等。性能測試技術發展路線參考如下：
成為一個高級性能測試人員需要掌握的東西非常多，如何學習這些知識。通過多年的實踐歸納，我的一點學習方法和大家分享：
成長=3本書+領域專家+實驗+實戰+持續提升。
3本書：1本基礎書籍+1本全面的理論書籍+1本實戰書籍。所有的書一定要經典書籍，我們常常開始學習知識的時候通過論壇的方法，這種方法入門比較容易，但是很難系統，也會占據非常多的時間。為什么要經典書？讀書的最大成本不是買書的錢，而是讀書的時間，所以看書一定要看最經典的書，怎么找經典書？可以到豆瓣、專業論壇、當當上看看評論。每個領域有每個領域的書籍，學習Oracle優化有oracle的書籍，學習loadrunner有loadrunner的書籍，千萬不要以為做性能測試就學3本性能測試的書籍就夠了。
領域專家：成長過程中如果有領域專家的支持，就會少走不少彎路。當我開始學習Oracle性能調優的時候，剛好認識一位Oracle調優同事，和他溝通請他推薦一些資料，講講實操的技巧。這里需要注意的一點是不要所有毛皮小事都去找專家，人家也有自己的工作。一些問題可以通過google搜索、或專業論壇就可以解決。前段時間有項目需要用informix數據庫，就請一位informix專家給我指導，大多數技術小問題在技術論壇上都有。如果大家不認識專家，那也沒有關系，通過微博、論壇認識他們，大多數人還是愿意幫忙的。
實驗：性能項目不是那么多，所以自己要找一些實驗的內容。技術書籍一般都會有一些實戰的內容，如果不去實際操作一遍往往過一段時間就忘了。當我學習Tuxedo調優的時候，在自己的虛擬機上搭建Tuxedo環境，使用修改后的Demo應用進行壓力測試，設計不同的壓力場景，測試過程不斷去調優應用，這個學習過程成長會很快。我的好多同事為了學習好hp-ux，自己購買退役的小機搭環境，進行實驗調優。很多時候不是技術難，而是沒有機會接觸這樣的環境。有過實驗的經歷，在就職面試的時候也算是經驗啊。
實戰：通過實驗之后，基本有經驗了，如果再通過幾個實戰項目，不斷總結歸納，基本就成為一個中級的性能測試人員了。以戰養戰，沒有一個人開始就會所有的東西，每個項目都會用一些新的技術，所以在不同的項目中需要有很強的學習能力，能夠快速學習新的技術并用于實戰。
持續提升：想成為高級性能測試人員或專家，就需要不斷更新學習新的知識和技術。通過論壇、活動、微博、讀書等方式不斷提升，也要常常和大家一起分享，分享是非常好的學習手段，還可以提高自己的知名度。
問題：如何從業務目標分析得到性能測試需求、性能指標？
宗剛：常見的業務需求如下：日交易量支持1.4億，響應時間小于2秒，支持用戶2億。我們需要把這些指標轉化為可以測試的指標和場景。通過分析歷史交易的波峰波谷，把1.4億的交易量折換為每秒鐘的交易量；響應時間也可以分類，比如本地業務多長時間，跨省業務多長時間，跨行業務多長時間等等；我們常常把支持多少用戶作為衡量指標，這是一個誤區，大量用戶導致產生大量的業務才會消耗系統的利用率，所以關鍵是業務量。這里有個例外，如果要驗證支持多少在線用戶，以及長連接的系統就需要考慮支持的用戶數量更精確的說法應該是支持的Session。從業務需求到性能測試需要一般要經歷這些過程：評估性能風險、確定關鍵用例、選擇關鍵性能場景、建立可測試性能目標。
性能指標一般會有：交易響應時間、交易成功率、資源利用率、每秒鐘的交易量（TPS）。這幾個指標是相互約束的，如果低成功率下的TPS是沒有意義的。多數運維部門對資源利用率都會有一些硬規定，比如CPU不能高于85%，內存不能高于90%等等，所以在測試之前需要清楚這些約束。除了上面的通用指標，各個應用系統會依據技術特點有一些特殊的指標。更全面的指標應該是分層的，從終端用戶的體驗—>業務流程—>中間件數據庫的響應—>基礎架構的利用。
問題：如何進行性能測試建模？在性能測試過程中要建立哪些模型？
宗剛：性能測試過程需要考慮的模型有：業務模型、測試模型、用戶模型TPS模型、數據模型、失效模型、性能模型
業務模型：依據應用系統特點分析出來的不同的業務場景和業務配比。性能測試常常會通過歷史數據分析業務的重要性、交易頻率、易耗資源的交易以及未來的發展趨勢，最后確定一種業務配比。依據這個業務配比設計測試場景。這往往是不夠的，一個線上系統往往有多個業務模型，需要考慮時間驅動的如：白天、晚上、月末、過年過節，事件驅動的如：本拉登去世黃金業務突發變化、業務部門促銷等，第三方驅動：永遠不要相信第三方的內容，所以需要考慮第三方接口的業務突變，延時等等。
測試模型：如何將業務模型的內容轉化為可以測試的內容，就是測試建模需要解決的問題。通過業務建模分析出來的業務需要過濾，剔除一些不易執行的、相互包含的等等業務。最后落地為各種可執行的業務配比，業務配比完成后，需要考慮的是如何和測試工具映射起來，這個就牽涉到用戶模型和TPS模型。用戶模型是指按照業務配比設置發起壓力的用戶比例，這種方法存在一定的局限性，因為不同的交易響應時間是不同的，長交易完成1筆交易，短交易可能是5筆，特別是在較大壓力時，測試結果的業務配比會和真實的業務配比差距很大。所以一般情況下需要考慮TPS模型，這個是和業務模型相同的配比，這個模型的一個劣勢就是需要不斷調整并發用戶數。
數據模型：一個系統的大多數性能問題是數據庫問題，所以墊底數據或參數化數據是否和實際相符將直接影響性能測試的有效性。一般建議性能測試使用清洗后的生產數據，參數化數據盡量采集生產系統一天的交易數據。以前見過一個項目，說有的數據都是通過loadrunner壓進去的，所有數據都集中在一塊，測試結果和實際生產差距巨大，整個測試無效。
失效模型：主要是總結了大量以往生產系統經常出錯的模式，在設計測試案例的時候需要著重考慮。這部分要依據實際情況來定，如果能夠從運維部門獲得更多的事故數據就更有價值。
性能模型：不同的交易對系統的性能要求是不同的，依據測試的數據以及生產環境的數據建立模型，主要解決以下問題：測試環境中測試的數據如何映射到生產環境？生產環境中出現性能問題應該如何預測預防和優雅降級？生產環境應該如何擴容等等。