摘要：匯報功能測試結果相對簡單，因為這些結果有乙個清晰的通過或者失敗的輸出。匯報效能測試的結果更加細緻入微些，而且有很多展示這些值的方法——但是麥可ž斯塔爾感到這些方法沒有特別有效。他建議一種使效能測試結果一眼易讀的匯報方法。
有效的匯報測試結果是我們專業的聖杯之一。如果正確操作，它能改進專案的質量並且幫助我們關注實際的事情。但是如果錯誤操作，它增加了誤解並減少測試帶來的價值。
匯報功能測試結果相對簡單，因為這些測試有乙個個清晰的通過或失敗的輸出。匯報效能測試更有細微差別。
讓我們以乙個定義開始：這篇文章的目的，我使用術語「效能測試」意味著任何測試會執行乙個度量，它以一系列數值型的值都被考慮到可接受的結果。它可能是耗電量的測量，**並行服務的使用者數量，可以從硬碟讀取的資料速度，等等。——任何乙個非功能需求的測量。
第二，當測試最低限度地失敗（比如99幀每秒），產品經理會處於「靈活」且接受產品的壓力中。我們有多經常聽到 「事實上，我們都在最小值以下，但是我們經常通過，所以我們決定它是好的」？假如完整的需求可以被獲取到（目標：120幀每秒），將會更清晰地看到結果離目標有多遠，並且產品會有乙個真正的發行。
為了完整性的好處，我將提起乙個非功能性需求不僅需要特定目標和最小值，而且需要測試方法，因為測試方法影響測試結果。舉個例子，當測量cpu使用率，取決於我們如何執行測量，結果會變化很大。我們是否測量記錄的最大值？一次持續多久？我們算測量的平均值嗎？一秒有多少測量值？我們的測試中還有其它什麼並行執行在cpu上嗎？
從理論上講，匯報效能測試結果根本不應該是乙個問題。只呈現出結果並且指出乙個通過或者失敗。但是再者，我們不僅想要知道結果；我們想要得到結果如何關聯目標的乙個概念。製作乙份報告不會過度複雜，但是仍然要傳送乙個完整的狀態是乙個平衡的做法。
我們可以使用乙個**：
需求目標
最小值結果
120100
101無論如何，因為多數產品有很多效能需求，我們將以乙個充滿數字的大**結束。它將難以快速看出**是乙個問題。我們可以使用顏色去提高可讀性：
需求目標
最小值結果
幀處理速度（幀每秒）
120100
101cpu佔用率（%）710
8.55
效能消耗
1.51.9
1.34
但是這帶來更多問題。它意味著幀處理速度和cpu使用率使用相同的顏色**嗎?乙個幾乎失敗，當另乙個很好地在可接受範圍內。所以可能幀處理速度標成紅色？但是然後我們使用什麼顏色表示失敗呢？而且多久我們考慮乙個結果在它應該變成黃色前而為綠色呢？更不要提到會發生的困難，因為一些人有色盲。
當我的醫生每三年把我的每年血液檢查（我一絲不苟地做這個事）傳送給我時，我正在考慮這個事情。無論如何，從實驗室來的結果包括幾十個數的列表顯示了這個**：
即使雖然我不是物理學家，我可以區分良好結果的合適的方法，哪個是邊界，並且哪個是我應該與醫生討論的一些事。
在我的腦海裡乙個電燈泡繼續前進：為什麼不使用這個方法來報告效能測試呢？我指出一些資料點並且用幻燈片演示：
特性分數
能量消耗
傳輸/公尺每秒
cpu佔用率
記憶體使用
注意那些我仍然使用顏色，但是軸線解釋了顏色的選擇並且暗示**高亮會更好並且哪兒顏色上更暗會更好些——單獨的方法。讀者能清晰地看到在允許範圍內的每個測量的位置；顏色主要服務於關注在有問題的地方。製作這樣乙份報告花費一些時間，但是它可以被自動化。
我還沒有在實際專案看見這個想法的實現——我仍然在研究這個想法——但是假如你確實使用這個想法，我將會高興地了解到你的經驗和你的組織的反應。
獲取hudson持續構建編譯結果的一種方法
很多時候使用hudson結合visualstudio進行持續構建後需要獲取持續構建的編譯結果，通過編譯結果來知道哪些專案失敗了以及對應的編譯錯誤。最初是通過分析hudson的日誌來獲取編譯結果的，後來發現這樣做並不準確，因為很多任務程專案的編譯輸出是混雜在一起的，造成編譯失敗的工程和對應的編譯錯誤無...
壓力測試就是一種破壞性的效能測試
對效能測試 負載測試和強度測試比較混淆。沒錯，這三個概念是比較容易使人糊塗。負載測試和強度測試，都屬於效能測試的子集。下面舉個跑步的例子進行解釋。效能測試，表示在乙個給定的基準下，能執行的最好情況。例如，在沒有負重的情況下，你跑100公尺需要花多少時間 這邊，沒有負重是基準 負載測試，也是效能測試，...
壓力測試就是一種破壞性的效能測試
壓力測試stresstest是在一定的負荷條件下，長時間連續執行系統給系統效能造成的影響。負載測試loadtest 在一定的工作負荷下，給系統造成的負荷及系統響應的時間。壓力測試主要是為了發現在一 任意 定條件下軟體系統的效能的變化情況，通過改變應用程式的輸入以對應用程式施加越來越大的負載 併發，迴...