SAAS技術交流系列（二）
一、 效能測試的概念
效能測試是一項綜合性的工作，致力於暴露效能問題，評估系統性能趨勢。效能測試工作實質上是利用工具去模擬大量使用者操作來驗證系統能夠承受的負載情況，找出潛在的效能問題，分析並解決；找出系統性能變化趨勢，為後續的擴充套件提供參考。
二、 效能測試的價值
隨著網際網路的發展，單機軟體的逐漸減少，系統從單機步入“雲”時代，軟體系統功能和規模也越來越龐大，盜版也越來越難，使用者規模也越來越大，企業盈利隨之爆發式地增長。隨著使用者數量的增多，系統穩定就成為企業的首要技術保障，穩定才能帶來流量，才能賺錢。
三、 軟體測試分類
從圖可以看到效能測試在整個軟體測試環節佔了50%的內容，如測試內容中，負載測試、壓力測試、效能測試、大資料量測試、恢復測試、記憶體洩露測試、競品測試（比較測試）和可靠性測試。一共14個測試內容，效能的測試佔領8個，可想而知效能測試在軟體測試中的重要程度。
軟體業大部分軟體開發之初一般考慮的是軟體功能的市場需求契合度，是否能被市場認可。這個前提成立之後，才會有較大的使用者群體去使用，從而出現效能問題。然而根據金子塔理論，到了後期在進行修改，投入和產出不成比例。一般公司在做出確定可以盈利的產品後，會對產品進行再次開發，來達到這個效能要求。所以第一個產品（試驗）的效能要求和真正的推廣產品（成熟）的效能要求不是一個量級，企業發展到一定程度就得關注效能，重視效能。效能測試的價值就是保障系統的效能，提供良好的使用者體驗；儘可能地找出系統性能薄弱環節，幫助進行效能優化。
四、 效能測試成功與失敗要素
效能測試上手難度比較高，是一門融合測試、開發、運維、需求調研、架構、協調管理等綜合技能的學科，掌握一門效能測試工具對於效能測試來說只是萬里長征的第一步，沒有一定的需求、開發和運維專業能力，往往會吃一些苦頭。
效能測試有幾大難點：
（1）需求分析；
（2）場景設計；
（3）效能診斷調優。
（4）環境搭建和模擬
往往很多效能測試從業者在需求分析方面沒有做到位，不能準確地預估使用者行為；在場景上不能復現使用者操作，無法把需求體現在指令碼和場景設計上，無法模擬真實的系統負載；這種狀態下做出的效能測試往往結果良好，上線出問題，導致整個專案團隊狼狽不堪，整個公司手忙腳亂。
效能診斷調優是一門有效利用和協調硬體軟體的“藝術”，從Oracle Exadata誕生之初在軟體層面的優化就可以有200倍至10000倍之多。但是效能診斷和調優是有時間和經濟成本的，也是需要全面的IT知識體系的專家或者團隊才能比較全面地挖掘出系統的效能問題並給出調優方案。
很多效能測試初學者總覺得效能測試就是寫個指令碼，弄幾臺機器應付，出個報告就行了。通常關注併發多少，響應時間多少，能跑通嗎等問題認為併發越大，響應時間越快，那效能一定就越好，實際上我們需要對系統進行一系列複雜精密的工作才能開始效能測試執行，經過N次迴歸，找到瓶頸的具體原因，優化再驗證。
下面講解效能測試重要關注點。
1． 評估系統，需求分析
對於初次上線的系統，我們需要用同行的系統資料，進行使用者行為分析和商業資料結構的估算為前提，利用效能估演算法推算。得到的負荷和響應時間資料可以被用於驗證所計劃的模型的能力，並幫助作出決策。
對於已經上線的系統，我們可以通過運維人員獲取TPS和時間的比例分佈圖、使用者數和時間的分佈圖、資料庫ER關係圖、容量資料等，直接精確得出目前的系統的使用者行為和業務資料關係，進而得出我們需要的效能需求。
2． 場景設計、用例設計
充足的需求調研與分析之後，我們要在測試場景中儘可能真實地復原系統負載。通過需要我們要決定哪些功能要參與效能執行，如何參與？這就是用例設計。如何有效地組織測試用例就是場景要做的事，按業務分佈、業務量、業務時段、業務角色來綜合分配使用者數、執行時間、執行比例等。看似簡單，實際操作起來還是比較麻煩的。
3． 測試執行、是否通過
模擬不同負載執行測試場景來識別系統弱點：做好各種監控，甄別各種問題；驗證系統的穩定性。下面是我們在執行時常見的需要關注的指標，如下圖所示。
4． 效能診斷優化
效能診斷知識面要求甚廣，系統日益複雜，單打獨鬥的日子已經遠去，依靠團隊力量才能夠高效完成診斷任務。效能測試從業者要具備良好、敏感的效能意識，能夠把遇到的問題初步分類，協助各開發團隊完成問題定位、分析調優。所以首先要是一個好的協調者，還是一個技術面廣的技術人員，具備跨領域知識，如開發、運維、資料庫、快取等。
五、 不同角色看效能
下圖是當前典型的系統性能涉及的方面，需要多個工種（有架構師、開發、系統管理員、DBA、測試等）一起協調才能完成工作，每個環節都可能是瓶頸，造成阻塞。相對於目前國內的IT軟體部門環境，因為需要協調多部門，所以效能測試工作人員必須是一個複合型人才，對於各工作的知識有所瞭解也要求有一定的專案協調能力，來引導大家同心協力地完成此項複合任務，靠單人是不太可能完成如此具有挑戰的工作。
技術部門一般有以下幾種常見的角色，開發、測試、架構師、運維人員-（系統管理員、DBA）等。下面我們看看不同角度對於系統的要求。
1． 黑盒測試的角度
黑盒測試操作應用介面——資料請求經過網路傳送——伺服器前端接收處理——在DB server獲取相關資料——前端處理後返回資料——應用介面收到資料響應下一步。
黑盒測試只關心應用程式的單步響應時間，效能好壞就看應用時間多少，也就是資料流經過伺服器/伺服器叢集經過網路傳輸後往返的時間總和。
2．開發角度
（1）架構合理性（2）資料庫設計合理性（3）程式碼（4）系統裡記憶體的使用方式（5）系統裡執行緒使用方式（6）系統資源是否有惡性，不合理競爭（7）作為一個開發人員，只關注功能的程式碼實現，很少有精力去關注資料庫的設計，框架的設計是否合理，系統裡記憶體的使用方式是否合理、系統裡執行緒使用方式是否合理、系統資源會不會有可能存在不合理競爭。他們通常認為這些是架構師去考慮的問題，但是在我國普遍的中小軟體公司，很少有去考慮這些事情。
3．系統管理員角度
（1）硬體資源利用率（2）JVM（3）DB（4）換哪些硬體能提高系統性能（5）系統能否支援7*24的服務（6）擴充套件性，相容性，最大容量，可能的瓶頸（7）作為運維人員通常關注這套系統所有伺服器是否正常執行，一般關注這些伺服器（資料庫、中介軟體等伺服器）的硬體資源利用率情況，如記憶體是否有可用空間，CPU是否超過70%，網路是否通暢、I/O是否存在瓶頸。這些伺服器和配置是否能支撐幾個月甚至幾年穩定無問題地執行這套系統。除此之外還考慮，隨著公司業務的增大，吞吐量需求加大，是否增加伺服器就可以等比例地提高系統的綜合吞吐量。
4．效能測試的角度
（1）伺服器硬體效能（2）根據需求和歷史資料制定效能目標（3）建立效能通過模型（4）對開發程式碼框架和硬體框架進行效能分析（5）針對開發釋出版本的基準測試（6）執行軟體效能驗收及穩定性測試（7）生產環境的配置和優化（8）制定效能測試的測試用例（9）制定效能測試的場景設計（10）協調各部門配合（11）特定的效能分析
六、 效能測試工具選擇
工欲善其事必先利其器，效能測試時模擬大量負載需要工具幫忙，市面上可供使用的負載工具繁多，如何選擇呢？
首先我們要明白負載工具是幫助我們來模擬負載的，對於效能測試來說，工具並不是核心，分析、評估、找出效能問題才是核心，這些是主觀因素；工具是客戶因素，自然要降低其對結果的影響，所以工具選擇時我們有幾個方面要考慮。
（1）專業、穩定、高效，比如Loadrunner，工業級效能負載工具。
（2）簡單易上手，在測試指令碼上不用花太多時間。
（3）有技術支援，文件完善，不用在疑難問題上花費時間，集中精力在效能分析上。
（4）要考慮投入產出比，比如我們可以選擇免費開源的JMeter。當然有時候自研或者使用開源不一定比商業工具更省錢，因為要做技術上的投資，時間上的投資。
常見效能工具：
（1）HP公司的LoadRunner；
（2）Apache JMeter（開源）；
（3）Grinder（開源）；
（4）CompuWare 公司的QALoad；
（5）Microsoft公司的WAS ；
（6）RadView公司的WebLoad ；
（7）IBM公司的RPT ；
（8）OPENSTA等。
七、 效能測試通過標準
效能測試從需求、設計、準備、執行到分析，最後需要判斷效能測試是否通過，效能測試工程師最終需要考慮很多因素，判斷的標準相應也會有多個維度。
效能測試通過標準包括服務端效能、前端效能和使用者體驗效能，常規通過標準如表所示。
八、參考文獻
全棧效能測試修煉寶典-Jmeter實戰