背景
本頁說明使用者可能用於自動化效能測試的各種用途。
說明這些用途的其中一個原因，是記錄 Fuchsia 工具提供這類功能的成效。在上述使用案例中，某些使用案例更適合 Fuchsia 目前的工具。
說明這些用途的廣義原因，是協助我們傳達測試的相關資訊。其中一個人員進行測試的用途可能與其他人意識到的用途不同。
如果某個人員在編寫測試時具有某些用途，在將測試傳送給審查者進行程式碼審查，或請求協助時，明確說明用途是不錯的做法。
測試的使用案例與我們如何處理結果中的迴歸有關，進而影響我們用於偵測迴歸和改善的統計測試效能和限制。
例如，大量測試對比較案例 (請見下文) 很有用，可能會因統計資料中多次比較問題而產生高迴歸警告的速率。因此，這組測試對於偵測迴歸而言可能不是很實用。我們發現只有大型迴歸可以採取行動，而小型迴歸警告通常非常困難，且可忽略。
此處說明的某些用途會重疊，因此並非互斥。
用途
在修訂後或修訂前「偵測迴歸」：我們大多使用 Chromeperf 和標記搜尋工具執行這項修訂作業。修訂版本偵測只能透過 perfcompare 選擇選用，根據預設不會套用。
- 偵測逐步迴歸 (creep)，這是透過許多變更累積的影響。我們目前還沒有任何自動化工具來執行這項作業。Chromeperf 的偵測演算法只會尋找單一修訂版本或單一時間點帶來的迴歸。
測試潛在改善項目：也就是測試嘗試改善效能的變更效果。方法是使用 perfcompare。
比較案例：也就是比較相關測試案例的相對效能。
這可能是我們想要修正這些情況，因此可能會用於尋找相較於其他情況，成效不佳的情況。舉例來說，FIDL 編碼和解碼的效能測試就做為用途。
這也可用來在不使用剖析功能的情況下評估作業或子系統的成本。例如，IPC 來回 Microbenchmark 會使用各種不同的核心和使用者陸地 IPC 運算，測量執行緒或程序之間的往返時間。透過不論是否使用 FIDL 進行測試，我們都能估計 FIDL 和其他使用者土地程式庫在核心 IPC 基元上增加的負擔。同樣地，藉由測試程序內的程序與執行緒之間的處理序間通訊 (IPC) 功能，我們可以估算在位址空間之間切換的情境切換所產生的費用。
提供其他迴歸相關的線索：指標 A 中的迴歸可能不是我們所關注的問題，但或許有助於針對指標 B 中發生迴歸的原因提供線索。這個用途與剖析類似，但較為一般。
舉例來說，如果「每秒影格數」指標發生迴歸，我們可查看「影格建構時間」指標，看看是否也已變更。
剖析：也就是分析測試中時間或記憶體用量的細目。
雖然 Linux 有 perf 和 OProfile 等工具，可對 CPU 作業時間進行統計資料剖析，但 Fuchsia 目前並沒有對等的工具。
無論是自動化測試或手動測試，使用 Fuchsia 的追蹤系統來檢查時間的詳細資料。(為此，自動化測試優於手動測試，優點在於比較可重現、執行的工作更少)。但是，Fuchsia 的追蹤系統與效能剖析工具 (例如 Perf 和 OProfile) 之間有兩項差異：
- 「追蹤記錄」功能只會針對已加註產生追蹤事件的程式碼記錄使用時間。
- 追蹤記錄的常見用途是手動檢查，或是從一組固定的指標 (例如「每秒影格數」和「影格建構時間」) 中擷取追蹤記錄。我們目前沒有工具，因此無法產生較開放且由剖析工具產生的種類統計資料。
請注意，
fuchsiaperf檔案周圍的基礎架構不適合記錄剖析資料。因此，最好記錄大量描述時間或記憶體用量的指標。制定設計決策：子系統的效能特性會影響我們使用其方式。如果子系統速度緩慢，我們可能會避免該子系統，或建構資料層 (例如快取)，或以其他方式加以處理。
其中一個應用範例是「每個程式設計人員都應該知道的延遲數字」表格。請參閱這個近期版本的資料表。
這個資料表的早期版本會顯示在 Jeff Dean 的對話 (史丹佛大學 CS295 課堂授課，2007 年春季, 2007 年) 中。他提議撰寫微基準測試，建構有關效能的構想並做為預估效能的基礎。這個資料表有多種更新版本，詳情請參閱這個 Stack Exchange 問題。