如何有效地報告性能測試結果？一文告訴你

前言

報告功能測試的結果相對簡單，因為這些測試有明確的通過或失敗結果。

報告性能測試的結果就要微妙得多，而且顯示這些值的方法有很多——但是作者認為這些方法都沒有特別有效。他提出了一種報告方法，使性能測試結果更易于閱讀和理解。

有效地報告測試結果

有效地報告測試結果是我們職業的圣杯之一。如果做的好，它能提高項目的質量，并幫助我們專注于真正的問題；但如果做得不好，就會增加混亂，降低測試人員帶來的價值。

報告功能測試的結果相對簡單，因為這些測試有明確的通過或失敗結果，報告性能測試的結果就要微妙得多。

讓我們從一個定義開始：為了本文的目的，我使用了一個術語——性能試驗，指任何執行度量的測試，其數值范圍都被認為是可接受的結果。

它可以是電能消耗的測量、網站并行服務的用戶數、從磁盤讀取數據的速度等等，可以是對非功能需求的任何測量。

性能測試需求

性能測試的第一個挑戰是決定什么是“通過”。在需求定義階段，這常常被忽略。

我看過許多需求，比如“從數據庫中提取數據的時間應該小于10毫秒”，或者“視頻文件的處理速度至少應該是每秒鐘100幀(Fps)”。

這些要求是不完整的，因為它們不包括我們想要達到的實際目標。我們批準該產品，就意味著我們同意容忍最壞的結果。這里有兩個問題：

首先，假設我運行了一個測試，并發現視頻文件處理的速度為101 fps（回想一下需求是“至少100 fps”）?？雌饋聿诲e對吧？但這是否意味著我們已經接近邊緣（也就是說，產品很難滿足要求），還是一切都很好？

如果需求被很好地定義，它將同時包含目標和最小值——例如，目標：120 fps；最低目標：100 fps。有了這樣的要求，101 fps的結果清楚地表明該產品很難滿足要求。

第二，當測試輕微失?。ɡ?9 fps）時，產品經理面臨著“靈活”和接受現有產品的壓力。

我們多久聽到一次，“確實，我們在最低限度以下，但我們幾乎通過，所以我們可以決定它是好的”？如果有完整的需求（目標：120 fps），那么就可以清楚地知道結果離目標有多遠，并且產品有一個真正的問題。

性能測試報告方法

為了完整起見，我要提到的是，非功能需求不僅必須指定目標和最小值，還必須指定測試方法，因為測試方法會影響結果。

例如，在測量CPU利用率時，結果將因我們執行測量的方式而有很大差異。我們測量記錄的最大值嗎？間隔多久測一次？我們記錄測量的平均值了嗎？每秒測量多少次？在CPU上與我們的測試并行運行的還有什么？

性能測試報告結果

理論上，報告性能測試結果不應該是一個問題，只需顯示結果并指出通過或失敗。但是，我們不僅想知道結果，我們還想知道結果與目標之間的關系。所以編制一份不太復雜但仍能提供完整狀態圖的報告是一種平衡之舉。

我們可以用一個表舉例：

但是，由于大多數產品都有許多性能要求，我們最終會得到一個滿是數字的大表。很難快速看出哪里有問題。我們可以用不同的背景顏色來提高可讀性：

但這帶來了更多的問題。幀處理速度和CPU利用率得到相同的顏色碼有意義嗎？其中一個幾乎失敗，而另一個則在可接受的范圍內。那么也許是紅色的彩色幀處理呢？但是，對于失敗，我們會用什么顏色呢？在結果變成黃色之前，我們要考慮多長時間綠色呢？更別提有些人色盲可能造成的困難了。

當我的醫生讓我做年度血液檢查時，我正在考慮上面提到的這個問題，我每三年都會仔細體檢一次。而且，實驗室的結果包括一個以下面這種格式顯示的帶幾十個數字的列表：

即使我不是醫生，我也能馬上判斷出哪些結果是好的，哪些是邊際的，哪些是我應該和我的醫生討論的。

我突然有一個想法：為什么不用這種方法來報告性能測試呢？我選取了一些數據點，并用PowerPoint進行了試驗：

請注意，我不僅使用顏色標注，還用軸線解釋了顏色的代表的意義，并以獨立于顏色的方式標注了哪個顏色越高越好，哪里越低越好，讀者可以清楚地看到每個測量在允許的范圍內的位置。

顏色主要用來提示比較麻煩的地方，創建這樣的報告需要一些時間，但可以自動完成。

我還沒有看到這個想法在一個真正的項目中得到實現——我還在研究這個問題，但如果你真的使用這個想法，我很樂意了解你的經驗和貴組織的反饋。

最后：在我的V ：atstudy-js，可以免費領取一份10G軟件測試工程師面試寶典文檔資料。以及相對應的視頻學習教程免費分享！其中包括了有基礎知識、Linux必備、Shell、互聯網程序原理、Mysql數據庫、抓包工具專題、接口測試工具、測試進階-Python編程、Web自動化測試、APP自動化測試、接口自動化測試、測試高級持續集成、測試架構開發測試框架、性能測試、安全測試等。