為什麼通過率不是一個 Release Signal

什麼才是「足以出貨」的？ 實際上意味著 ——以及為什麼at 您目前的指標 不 告訴ING 您的回饋。

通過率並非發布訊號。 這裡的 什麼 是。 

現在是星期四下午。 Release 定於週五上午進行。 

你打開控制面板。通過率94%。失敗的測試都是你以前見過的——時好時壞，通常重運行後會顯示綠色。你重新運行這些測試。綠色。你簽字確認。 

星期六早上，你的手機響了。 

用戶報告稱會話隨機註銷。工程團隊正在緊急諮詢。根本原因是：身分驗證令牌刷新過程中存在競態條件。先前，一個不穩定的測試已經連續四個迭代周期都發現了同樣的問題——而團隊卻只能反覆測試直到通過為止，然後繼續推進。 

訊號一直都在，只是你沒注意到而已。 

人人都在關注的指標，但它卻無法回答的問題。 

通過率是行動端品質保證中最常用的指標，但它也是最不適合用於制定發布決策的指標之一。 

847 次測試通過，23 次測試失敗，這樣的統計數據並不能提供管理階層任何關於風險的資訊。它既沒有揭示這 23 次失敗是否涉及關鍵的支付流程，也沒有說明失敗是否會影響某個隱藏的設定頁面。它也沒有顯示失敗次數是隨著版本迭代而呈現上升趨勢，還是只是個別退步事件。1] 

94%的通過率並非發布訊號，它只是一個計數。而脫離上下文的計數無法回答每次發布前真正重要的問題： 該架構的風險集中在哪些方面？ 

支付確認流程中的一次失敗與極少使用的邊緣案例中的一次失敗風險並不相同。但通過率卻將它們視為相同。2] 

如果這還不能讓你想起什麼，那麼這些將會… 

開頭的這個故事只是眾多類似模式中的一種，幾乎在每個移動團隊中都會以不同的形式上演。細節有所不同，但根本原因卻始終如一：訊號一直存在，但卻沒有人擁有解讀它的系統。 

以下還有兩種情況你可能也經歷過。 

由於數字看起來正常，所以沒人注意到這個故障。 

第六次測試。一項涵蓋支付確認畫面的測試開始失敗。 847 次測試中只有 1 次失敗——通過率高達 99.8%。這看起來像是噪音。測試結果正常發布。 

三天後，用戶反映收不到訂單確認郵件。下游整合出現故障，而唯一一次針對此故障的測試卻因為整體資料看起來正常而被大家忽略了。 

問題不在於缺少一次考試，而是及格率將高風險的失敗案例平均化為一個令人安心的數字，從而掩蓋了失敗的後果。1] 

緩慢的漂移，無人察覺。 

經過四個迭代週期，通過率從 97% 降至 96%，再降至 94%，最後降至 93%。每次下降看起來都像是正常的波動。沒有閾值，沒有趨勢線，也沒有警報——它只是每週報告中一個無人問津的數字，沒有人會將其與上個迭代周期的數據進行比較。 

當故障率達到 93% 時，出現了 11 個新的重複性故障，分佈在三個功能區域。單一故障本身並不令人擔憂，但它們共同表明系統性問題正在惡化。 

這種現象的危險之處在於它並非突然下跌，而是一種緩慢的漂移，只有透過長期趨勢分析才能發現——不能將其視為一個快照。4] 

這些情景的共同點是什麼？ 

這些都不是測試失敗。測試運作正常，測試套件執行完畢，資料也都存在。 

這些都是洞察力不足導致的失誤。團隊明明掌握了訊號，卻沒有對應的解讀系統。 

接下來發生的事情是可以預見的：開發人員不再仔細閱讀故障日誌。 QA負責人不再對每個失敗的建置版本進行分類。真正的故障和那些不穩定的故障一樣被忽略了。這並非疏忽──這是對一個噪音過多、有效資訊過少的系統的一種理性反應。當每個故障看起來都一樣時，團隊就不會再仔細檢查任何一個故障了。3] 

每次發布前都要問的正確問題 

大多數發布前的討論都集中在「測試通過了嗎？」這個問題。而這個問題其實可以預測發布日期。 safety 不同： 該架構的風險集中在哪些方面？ 

回答這個問題需要結合背景訊息，而及格率並不能提供這些資訊。 

故障位置，而不僅僅是故障次數。 關鍵用戶旅程中的故障與極少使用的邊緣案例中的故障截然不同。重要的是哪些故障會發生，它們發生在什麼位置，以及它們是否會影響真實使用者會遇到的路徑。2] 

關注的是長期趨勢，而不僅僅是今天的快照。 如果上個迭代的通過率是 97%，那麼 93% 的通過率與連續六個版本都穩定在 93% 的通過率意義截然不同。版本間的穩定性比任何單次迭代都更能可靠地預測發布準備情況——但這只有在關注趨勢而非僅僅關注數字時才成立。4] 

將不穩定性視為一流訊號，而不是需要抑制的雜訊。 不穩定的測試會削弱人們對自動化的信任。當故障看似隨機發生時，團隊會重新執行測試流程，忽略訊號，從而拖慢發布速度。而那些將不穩定視為結構化資料的團隊——對故障進行分類，按測試區域分析不穩定趨勢，探究測試為何反覆出現故障——才能在競爭條件演變為生產事故之前將其捕獲。 

出貨前需明確故障原因。 一個有意義的發布決定不僅需要知道測試失敗了，還需要知道這些失敗是否有明確的根本原因，它們是本次版本的新問題還是反覆出現的問題，以及它們是否是真實用戶會遇到的問題。 

為什麼行動裝置讓這一切變得更難 

在行動裝置上，訊號雜訊比問題比在網頁上更為嚴重。 

設備碎片化、應用程式商店審核延遲、網路不穩定、後台執行限制以及作業系統特有的行為意味著品質問題經常會在實驗室之外顯現出來。提交前的測試運行良好固然有用，但這還不夠。5] 

一套能在你的實驗室設備上通過的測試套件，幾乎無法告訴你不同硬體、不同作業系統版本和不同網路環境下的使用者會遇到什麼問題。如果不將故障模式與實際重要的環境組合進行對比，通過率不僅會掩蓋風險，還會歪曲風險的真實情況。 

同樣的測試，即使建置版本完全相同，在一台裝置上也可能通過，而在另一台裝置上卻失敗。環境差異——作業系統狀態、語言環境、網路狀況、裝置歷史記錄——意味著相同的測試程式碼會產生不同的結果，而這些結果與你的應用程式本身無關。如果無法了解測試運行期間環境的具體情況，那麼測試套件顯示「綠色」並不能保證測試成功。它只是碰巧猜對了而已。6] 

測試分析應該滿足哪些要求 

目標不僅僅是自動化，而是高可靠性的發布——每次發布都要經過有意義、值得信賴且與用戶在設備上的實際操作相對應的檢查。7] 

要實現這一點，就意味著要將測試數據視為分析問題，而不是簡單的合格/不合格記錄。這意味著要建構——並要求——一些工具，能夠在一個視圖中呈現故障集中度、穩定性趨勢和不穩定模式。 之前 你決定是否要出貨。 

大多數團隊離目標只差一步之遙。資料已經存在，日誌中也蘊含著訊號。所缺少的是一個能夠將執行輸出轉化為發布情報的分析層。 

下一代測試分析工具需要圍繞一個問題構建：不是“測試套件的性能如何？”，而是“我應該擔心此次發布中的哪些方面？” 

At Digital.ai這就是我們正在努力解決的問題。我們認為答案並非在於增加測試次數，而是更聰明的訊號——以及在每次發布前提出更尖銳問題的嚴謹態度。 

Digital.ai 測試XXXXXXX 為移動團隊提供 執行基礎設施 大規模運行測試。 分析層 接下來，我們要建立的就是將這些數據轉化為產品發布的信心。