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

如何作一份精緻的性能測試報告？

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

---

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

「如何作一份精緻的性能測試報告？」

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

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

譬如做爲系統最終用戶來講，根本不可能去關心繫統的性能基準，最終用戶每每關心的是系統可以帶給他的實際性能體驗，比如你去秒殺搶購，你只關心你要到達的付款頁面有多快響應，根本不會管系統性能基準在哪個水平、系統性能容量如何、如何經過設備的擴展爲性能帶來伸縮。

可是，這些偏偏問題又是系統的運維人員關心的，運維人員還關心「配置測試」，經過對被測系統軟硬件環境的調整，瞭解各類不一樣環境/不一樣參數對性能測試影響的程度，從而找到各項資源的最優分配原則、還有可靠性測試、失效恢復測試，即某一設備出現故障之後系統是否仍然可以提供正常的響應服務，對於開發人員來講，他們關心的是鎖、是內存泄漏諸如此類的設計和實現問題。

• 用戶: 實際體驗性能
• 運維: 優化，可用，恢復
• 開發: BUG，性能

我所理解的、精製的性能測試報告：是一份可以通俗的顯示用戶實際得到性能體驗的的測試報告、或者是一份可以告知系統運維人員系統所面臨實際性能風險的性能測試報告、又或者是一份可以告訴開發人員系統設計實現上所存在的性能缺陷報告，就這些問題來講，每每都不會出如今同一份的報告當中。因此，請先弄清楚報告面對的項目干係人是誰、他所關係的到底是什麼。

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

從用戶角度來講，平均響應時間可以很好的衡量用戶總體所得到的性能體驗，但前提是同一請求響應時間總體分佈上必須呈現的是正態分佈，不然平均響應時間除了誤導你，什麼用都沒有。

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

相應時間區間來做爲速度衡量指標

除了平均響應時間和響應時間90百分位值，還有響應時間的「標準差」也是做爲衡量總體用戶所能得到實際性能體驗是否穩定的指標，在「相對穩定」的性能體驗中，標準差（經驗來講）每每是平均值的一半。

相應時間標準差做爲穩定指標

訪問應用服務時在帶寬上每秒的吞吐表面上是一種網絡資源開銷，但系統對帶寬的佔用實際上影響着用戶的性能體驗。

從運維與開發角度來講，必定也有着他們本身的性能指標閾值標準、或他們所關心的性能風險，例如CPU的佔用率、內存、硬盤性能計數器、JVM內存、GC頻率與暫停時間等等。

運維和開發以硬件消耗率做爲指標

總結

對於項目/產品經理來講，在報告中要着重說明不一樣的業務場景、場景中不一樣的負載級別下，用戶所能得到的實際性能體驗是什麼；對於運維人員來講，在報告中要着重說明系統在資源開銷上的風險、設備資源上擴充、配置的變動產生的影響；對於開發人員來講，在報告中着重說明設計上的缺陷，鎖、內存泄漏、資源開銷與釋放等。