以上是我在知乎提出的問題，感謝梧桐同學的回答，quote中的文字是我的描述有乙個現象是很奇怪的，在這行業6年到現在為止，我嘗試弄清楚各種效能測試的概念，但是至今貌似沒有乙個統一的標準，因此大夥理解的某個效能測試方法和我所理解的可能完全相反。有人可以為效能測試定義3種方法、也有7種的、甚至更多，但是無論多少種，都是一種方法總有它對應的需求，而效能需求就是干係人的需求，這種需求實在不容易分類。以下是我針對自己的理解進行的一些回答：在做系統的過程中會遇到需要對整個系統做測試的情況，包括一些基準測試，容量測試，壓力測試等。如何做乙份精緻的效能報告書，在測試過程中有哪些量化指標是需要重點考慮的？
題主已經列舉出了基準測試、容量測試、壓力測試，相信對這些測試也已經有一定的了解，但如果題主再進一步了解一定會發現，其實，這些測試並不是所有專案干係人都會關心的。
答主在這裡說到了專案中不同的人所關心的測試的不同維度譬如作為系統終端使用者來說，根本不可能去關心系統的效能基準，終端使用者往往關心的是系統能夠帶給他的實際效能體驗，好比你去秒殺搶購，你只關心你要到達的付款頁面有多快響應，根本不會管系統效能基準在哪乙個水平、系統效能容量如何、如何通過裝置的擴充套件為效能帶來伸縮。
但是，這些恰恰問題又是系統的運維人員關心的，運維人員還關心「配置測試」，通過對被測系統軟硬體環境的調整，了解各種不同環境/不同引數對效能測試影響的程度，從而找到各項資源的最優分配原則、還有可靠性測試、失效恢復測試，即某一裝置出現故障以後系統是否仍然能夠提供正常的響應服務，對於開發人員來說，他們關心的是鎖、是記憶體洩漏諸如此類的設計和實現問題。
我所理解的、精製的效能測試報告：是乙份能夠通俗的顯示使用者實際獲得效能體驗的的測試報告、或者是乙份能夠告知系統運維人員系統所面臨實際效能風險的效能測試報告、又或者是乙份能夠告訴開發人員系統設計實現上所存在的效能缺陷報告，就這些問題來說，往往都不會出現在同乙份的報告當中。所以，請先弄清楚報告面對的專案干係人是誰、他所關係的究竟是什麼。從使用者角度來說，平均響應時間能夠很好的衡量使用者整體所獲得的效能體驗，但前提是同一請求響應時間整體分布上必須呈現的是正態分佈，否則平均響應時間除了誤導你，什麼用都沒有。
所以，乙個更有參考價值，但是可能會為測試人員和開發人員帶來不必要麻煩的指標是響應時間的90百分位，也就是90%請求響應時間所處於的範圍，這是乙個對系統比較苛刻的指標，但是非常靠譜。
相應時間區間來作為速度衡量指標除了平均響應時間和響應時間90百分位值，還有響應時間的「標準差」也是作為衡量整體使用者所能獲得實際效能體驗是否穩定的指標，在「相對穩定」的效能體驗中，標準差（經驗來說）往往是平均值的一半。
相應時間標準差作為穩定指標訪問應用服務時在頻寬上每秒的吞吐表面上是一種網路資源開銷，但系統對頻寬的占用實際上影響著使用者的效能體驗。
從運維與開發角度來說，一定也有著他們自己的效能指標閾值標準、或他們所關心的效能風險，例如cpu的佔用率、記憶體、硬碟效能計數器、jvm記憶體、gc頻率與暫停時間等等。
運維和開發以硬體消耗率作為指標總結
對於專案/產品經理來說，在報告中要著重說明不同的業務場景、場景中不同的負載級別下，使用者所能獲得的實際效能體驗是什麼；對於運維人員來說，在報告中要著重說明系統在資源開銷上的風險、裝置資源上擴充、配置的變更產生的影響；對於開發人員來說，在報告中著重說明設計上的缺陷，鎖、記憶體洩漏、資源開銷與釋放等。
原 如何做乙份精緻的效能測試報告？
以上是我在知乎提出的問題，感謝梧桐同學的回答，quote中的文字是我的描述 在做系統的過程中會遇到需要對整個系統做測試的情況，包括一些基準測試，容量測試，壓力測試等。如何做乙份精緻的效能報告書，在測試過程中有哪些量化指標是需要重點考慮的？有乙個現象是很奇怪的，在這行業6年到現在為止，我嘗試弄清楚各種...
如何做乙份會辦事的人
在這個人才濟濟的時代，社會根本就沒有功夫和耐心慢慢培養你。你不行？你不願意？你不喜歡？沒關係，換人吧！這就是現實 一天到晚只會抱怨的人，必定是不成熟的人。當你知道自己應該如何去面對社會，如何快速地適應社會後，你就沒有時間去抱怨了。因為那個時候，你把時間都用來學習 工作和拓展人際網路了 對於已過了20...
乙份完善的軟體測試報告該怎麼寫？
一 什麼是測試報告？測試報告是指把測試的過程和結果寫成文件，對發現的問題和缺陷進行分析，為糾正軟體的存在的質量問題提供依據，同時為軟體驗收和交付打下基礎。二 測試執行和結束的準則 1.測試執行的結束原因 1 測試達到預期目的後，按計畫結束 2 受時間進度 資源的限制，測試被迫結束 測試執行結束準則 ...