每項效能測試都應包含英語測試測量結果的英文說明，通常在單一句子中說明。
例如：「使用 Zircon 管道測量不同程序之間的 IPC 來回行程時間」。
唯一的例外是，基本測試 (主要是單行) 的程式碼不需要總結功能。若是非常類似的測試，只需要一個說明。
建議您說明測試的預期用途，也是很實用的做法。請參閱效能測試的潛在用途清單。
Rationale
相較於正確性測試 (通過/失敗測試)，提供測試說明更重要，因為相較於通過/通過/失敗的結果，測試說明的解讀方式更小。
舉例來說，如果您的 CL 破壞了正確性測試，使得測試一直失敗，您必須找出方法來確保測試通過，或是移除測試。相對地，如果 CL 測試速度較慢 10%，就會明顯降低這項測試的重要性。如果有一項變更低了 1% 的測試速度 50%，就比較無法判定該變更是否重要。
此外，相較於正確性測試的通過或失敗結果，程式碼集中更多的項目可能會影響效能測試的結果。更準確地說，有許多方式可以變更程式碼集，這不會影響正確性，但會影響效能。
這可能表示，比起通過特定測試成功或失敗的結果，會有更多人需要解讀效能結果。舉例來說，如果對元件 A 所做的變更會導致元件 B 的效能測試發生迴歸現象，這些效能測試的意義可能需要由元件 A 的維護人員和元件 B 的維護人員解讀，也可能由其他使用者三分分類後的效能迴歸問題。
因此，記錄效能測試的門檻應比正確性測試更高。
測試測量項目的說明通常會比測試程式碼短許多，因此提供說明可能會讓開發人員省下許多花在閱讀程式碼的時間判讀評估目的。
位置
您可以把效能測試的說明放在測試程式碼或附近的 Markdown 檔案註解中。
我們目前沒有可供瀏覽的效能測試清單及其說明清單，也沒有方法從程式碼中擷取測試說明，但我們可能會在日後加入其中一項方法。
範例
Fuchsia Microbenchmark 範例：
「使用 Zircon 管道測試 IPC 來回行程，其中用戶端和伺服器都會使用 Zircon 通訊埠等候等待。」
(資料來源：IPC 來回行程時間的 microbenchmark，src/tests/microbenchmarks/round_trips.cc)
「測量將 Zircon 管道中的訊息排入佇列，然後在單一執行緒上解除佇列所需的時間。這不涉及任何跨執行緒喚醒。」
(資料來源：管道的 microbenchmark，src/tests/microbenchmarks/channels.cc)。
儲存空間效能測試的範例：
「在不明確同步處理或清除的情況下，測量將 8KiB 大小的區塊寫入新檔案所需的時間。產生的指標是指每個區塊寫入作業傳回的時間。」
(來源：舊版 garnet/bin/odu/README.md，目前說明的時間較長)