如何做一份精致的性能測試報告？

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

---

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

“如何做一份精致的性能測試報告？”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

運維和開發以硬件消耗率作為指標

總結

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

轉載于:https://www.cnblogs.com/Bozh/p/3806155.html

總結

以上是生活随笔為你收集整理的[原]如何做一份精致的性能测试报告？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。