[原]如何做一份精緻的效能測試報告？

標籤：class   類   問題   表   時間   應用   

如何做一份精緻的效能測試報告？

以上是我在知乎提出的問題，感謝梧桐同學的回答，Quote中的文字是我的描述
在做系統的過程中會遇到需要對整個系統做測試的情況，包括一些基準測試，容量測試，壓力測試等。如何做一份精緻的效能報告書，在測試過程中有哪些量化指標是需要重點考慮的？

有一個現象是很奇怪的，在這行業6年到現在為止，我嘗試弄清楚各種效能測試的概念，但是至今貌似沒有一個統一的標準，因此大夥理解的某個效能測試方法和我所理解的可能完全相反。有人可以為效能測試定義3種方法、也有7種的、甚至更多，但是無論多少種，都是一種方法總有它對應的需求，而效能需求就是干係人的需求，這種需求實在不容易分類。以下是我針對自己的理解進行的一些回答：

“如何做一份精緻的效能測試報告？”

題主已經列舉出了基準測試、容量測試、壓力測試，相信對這些測試也已經有一定的瞭解，但如果題主再進一步瞭解一定會發現，其實，這些測試並不是所有項目干係人都會關心的。

答主在這裡說到了項目中不同的人所關心的測試的不同維度

譬如作為系統終端使用者來說，根本不可能去關心系統的效能基準，終端使用者往往關心的是系統能夠帶給他的實際效能體驗，好比你去秒殺搶購，你只關心你要到達的付款頁面有多快響應，根本不會管系統效能基準在哪一個水平、系統效能容量如何、如何通過裝置的擴充為效能帶來伸縮。

但是，這些恰恰問題又是系統的營運人員關心的，營運人員還關心“配置測試”，通過對被測系統軟硬體環境的調整，瞭解各種不同環境/不同參數對效能測試影響的程度，從而找到各項資源的最優分配原則、還有可靠性測試、失效恢複測試，即某一裝置出現故障以後系統是否仍然能夠提供正常的響應服務，對於開發人員來說，他們關心的是鎖、是記憶體流失諸如此類的設計和實現問題。

• 使用者: 實際體驗效能
• 營運: 最佳化，可用，恢複
• 開發: BUG，效能

我所理解的、精製的效能測試報告：是一份能夠通俗的顯示使用者實際獲得效能體驗的的測試報告、或者是一份能夠告知系統營運人員系統所面臨實際效能風險的效能測試報告、又或者是一份能夠告訴開發人員系統設計實現上所存在的效能缺陷報告，就這些問題來說，往往都不會出現在同一份的報告當中。所以，請先弄清楚報告面對的項目干係人是誰、他所關係的究竟是什麼。

在測試過程中有哪些量化指標是需要重點考慮的？

從使用者角度來說，平均回應時間能夠很好的衡量使用者整體所獲得的效能體驗，但前提是同一請求回應時間整體分布上必須呈現的是常態分佈，否則平均回應時間除了誤導你，什麼用都沒有。

所以，一個更有參考價值，但是可能會為測試人員和開發人員帶來不必要麻煩的指標是回應時間的90百分位，也就是90%請求回應時間所處於的範圍，這是一個對系統比較苛刻的指標，但是非常靠譜。

相應時間區間來作為速度衡量指標

除了平均回應時間和回應時間90百分位值，還有回應時間的“標準差”也是作為衡量整體使用者所能獲得實際效能體驗是否穩定的指標，在“相對穩定”的效能體驗中，標準差（經驗來說）往往是平均值的一半。

相應時間標準差作為穩定指標

訪問應用服務時在頻寬上每秒的吞吐表面上是一種網路資源開銷，但系統對頻寬的佔用實際上影響著使用者的效能體驗。

從營運與開發角度來說，一定也有著他們自己的效能指標閾值標準、或他們所關心的效能風險，例如CPU的佔用率、記憶體、硬碟效能計數器、JVM記憶體、GC頻率與暫停時間等等。

營運和開發以硬體消耗率作為指標

總結

對於項目/產品經理來說，在報告中要著重說明不同的業務情境、情境中不同的負載層級下，使用者所能獲得的實際效能體驗是什麼；對於營運人員來說，在報告中要著重說明系統在資源開銷上的風險、裝置資源上擴充、配置的變更產生的影響；對於開發人員來說，在報告中著重說明設計上的缺陷，鎖、記憶體流失、資源開銷與釋放等。