《軟件開發沉思錄》之實用主義性能測試

 

學習了《軟件開發沉思錄》中的實用主義性能測試，對重點內容作下記錄：

性能測試應該囊括確保產品性能符合要求所需的一切行動。這裏有四個關鍵點:需求、產品性能數據、溝通和流程。

1.需求採集

需求採集中的幾個重要問題:要度量什麼?如何知道咱們須要什麼?以及如何獲得確實有用(而非幫倒忙)的數據?

@要度量什麼

最重要的性能度量點有兩個,最大吞吐量以及給定吞吐量下的響應時間。一個好的作法是:分別度量幾種不一樣吞吐量下的響應時間,從中分析負載對響應時間的影響。

須要經過度量找出兩項數據:當響應時間剛好能夠接受時的吞吐量,以及達到預期吞吐量時的響應時間。伸縮性度量的關鍵則在於:隨着數據規模、用戶數量或者運行系統的硬件變化,起初獲得的性能度量數據會發生怎樣的變化。

可靠性的關鍵度量點是:當負載量高得超乎尋常,或者連續運行了很長時間之後,系統是否仍然正常工做。

@如何設定目標

要想知道系統須要達到怎樣的吞吐量,你首先須要知道有多少用戶會使用這個系統,以及他們的使用模式。用戶會多頻繁地使用某個功能?這個功能須要多快完成?

須要有一個可靠的溝通流程與機制來得到所需的信息,及時獲知支撐業務需求所需的性能指標。

總之：需求採集是爲了讓全部人都清楚最終交付的產品須要有怎樣的性能才能支撐業務目標。之因此要讓客戶參與,是由於他們最瞭解本身的業務,這樣才能確保採集到的需求足夠準確。並且經過討論也能幫助客戶清晰本身對性能的需求,從而有效管理他們對系統的指望。

2.運行測試

@運行哪些測試

單場景和混合場景：全部頻繁進行的用戶操做都應該有對應的測試。這些測試應該記錄吞吐量、錯誤率和響應時間的統計數據。而後你還應該複用這些測試,從而構建更復雜的測試。全部這些測試應該一塊兒執行,儘量地模擬真實狀況,這樣你就能從中獲悉產品的性能情況。

考慮伸縮性：在不一樣的用戶量、不一樣的數據規模下運行它們,觀察性能數據的伸縮狀況。若是可能的話,還應該在不一樣的機器數量下進行測試,從而瞭解增長硬件能給性能帶來多大提高。從這幾方面,你就能獲知產品的伸縮能力。

超負荷以及穩定性測試

@何處運行測試

若是可能的話,應該儘可能讓性能測試環境模擬真實的生產環境。若是生產環境太過龐大而沒法總體模擬,那麼就應該讓性能測試環境模擬生產環境的一個部分,而後將真實的性能需求等比壓縮到性能測試環境的水平。(包括軟硬件環境)

@應該用多大規模的數據庫來作性能測試

應該先與關注性能的客戶交流,爭取拿到一份生產數據庫的副本,這樣就能夠針對它來進行測試。儘可能模擬線上環境(包括數據量，索引等等)。另外，還應該與客戶探討數據規模發生變化的可能性。

@如何處理第三方接口

若是系統用到不少第三方接口,性能測試最好不要直接去使用這些第三方系統。緣由有兩點:首先,第三方系統可能並不適合成爲性能測試的一部分;其次,即使第三方系統提供了測試環境,依賴你沒法控制的第三方系統會下降測試的可靠性。最好的辦法是用一個單獨的測試來獲知第三方系統的平均響應時間,而後爲它寫一個 mock或者 stub,直接等待那麼長的一段時間而後返回一個固定的響應。

@屢次度量響應時間和吞吐量

須要獲得系統最大吞吐量，最佳響應時間、當響應時間正好符合要求時的負載量以及負載達到事先測量的最大吞吐量的 80%和 90%時的響應時間等信息

@有必要測試全部功能嗎

對系統的全部功能進行測試基本上是不現實的。重點在於要覆蓋最經常使用的功能。 因此你須要識別出系統的主要使用場景,並針對這些場景建立不一樣的測試。 

好比說,在線購物網站最主要的使用模式應該是「瀏覽」和「購買」。來購物的人不全會瀏覽不少頁面,瀏覽的時間一般也不都會太長。因此 你須要建立一個「瀏覽」的測試腳本和一個「購買」的測試腳本。爲了讓測試腳本更貼近真實 ,你須要知道用戶瀏覽商品的平均數量、每次購買的平均商品數以及正常狀況下一天時間內被瀏覽過的商品數佔商品總數的百分比。

3.溝通

須要作的就測試結果進行溝通。

根據討論出的性能需求和目前的性能水平來解讀測試結果。

@指出系統性能與目標的接近程度(與目標的差距有多少,或是超出目標多少)

@說明產品的性能是否發生了重大變化。

@各個關鍵點時各類系統資源的使用狀況

不一樣的人會對不一樣的信息感興趣（客戶，項目經理，開發者）。建議用一個網站向全部人展現最新的性能測試結果。

4.流程

性能測試常常被放在項目結束前進行,這種安排嚴重影響了性能測試的效果。性能測試中最重要的事就是要按期地進行測試。若是直到項目最後幾周才作性能測試,那麼你將有不少事要幹,而時間卻很是緊迫。大部分時間會被用於編寫測試腳本,並獲得一些和產品有關的數據。這時你就會處於一種尷尬的境地,你大概知道系統運行得多快,但基本無從知道它是否足夠快,並且也沒有時間作任何改進。

當第一段代碼被編寫出來,性能測試就應該開始了。雖然這時可能尚未任何可供測試的東西,但仍是有不少事能夠去作。你能夠向開發者瞭解他們將要使用的技術,評估合適的工具,找出功能足以測試當前產品的工具。此外還須要識別出關注性能的客戶,而且與他們一塊兒啓動需求採集的流程。

@如何把各類工做鏈接起來

每週循環工做：1.每週開始時開會，討論正在開發的功能的性能需求，介紹測試計劃;2.編寫新功能對應的腳本，維護已有腳本，執行測試；3.每週結束時開會，展現本週成果：腳本，測試結果等並進行討論

@如何確保不拖後腿

1.肯定任務列表；2.肯定優先級；3.時間確實緊張時按照前面2點來減小任務量(高難度，低優先級)或者增長人手

5.總結

這個流程最大的好處在於它能確保你知道本身手上有什麼、須要什麼,並且你能確定系統的每一個部分都有測試覆蓋,從而大大增長了發現問題解決問題的機會。讓性能測試與開發同步,對每一個功能都有測試覆蓋,這樣若是性能出了問題你就有時間應對。有一份性能需求在手上,你就能判斷當前的系統是否須要改變。這份需求是客戶根據業務流程和規模製訂的,因此整個團隊都對它有信心,你們也會樂於花時間來解決性能問題,由於他們知道這是一件有價值的工做。