那天 RGT 報告出來，老闆的臉綠了三秒
還記得前幾年，我們為了新產品的可靠度焦頭爛額。那時候為了趕著開案，RGT（Reliability Growth Test）進度一直落後。有次週會，報告出來，一個新的失效模式又冒出來了，我看著老闆的臉，從平常的「嗯嗯」點頭，瞬間僵在那邊。會議室安靜了三秒，空氣凝結。大家都知道，這代表又要延期了。那時候真的想，要是能預先知道什麼時候能達標，或至少知道還有多少坑沒踩到，該有多好？
問題出在哪？不是你測得不夠，是你沒算對
你是不是也跟我一樣，常常覺得可靠度測試就是一直測、一直修、一直測，然後期待哪天突然就「可靠」了？說實話，以前我也這麼想。但後來才發現，這樣搞根本是賭運氣。可靠度成長測試，不是盲測，它背後是有科學方法的。最常用的就是 AMSAA 模型（經國防部認證！）。
這模型說穿了就是一種統計工具，它能幫我們預測，在持續改進設計、修復缺陷的過程中，產品的可靠度會怎麼「成長」。它不只告訴你現在多糟，更能預估你接下來會有多好，或是還要多久才能達到目標。
換句話說，它讓我們從「測到哪算到哪」變成「根據數據預測未來」。這就像你開車，不再是只看後照鏡，而是打開導航，知道目的地還有多遠，還有多少時間會到。
實際上怎麼做？看 Beta 值就對了！
要跑 AMSAA 模型，你需要的是「累積失效次數」和「累積測試時間」這兩組數據。每次測試發現失效，修復後再重新測試，持續紀錄。軟體會幫你算出兩個關鍵參數：Alpha 和 Beta。
- Beta 值： 這個是重中之重！它告訴你可靠度成長的趨勢。
* Beta = 1： 你的可靠度維持「不變」。代表你修的 bug 跟你新增的 bug 差不多，或產品根本沒改善。
* Beta > 1： 糟糕！你的可靠度正在「惡化」。每次修正都搞出更多問題，或新問題層出不窮。坦白講，這時候通常要回去檢討設計或製程，哪裡出大包了。
舉個實際數字，假設我們目標是 MTBF（平均失效間隔時間）達到 5000 小時。如果我們跑出來的 Beta 是 0.8，Alpha 是 12。這就表示，可靠度正在穩定成長，我們可以根據模型預測，大概再測試 2000 小時，並持續修正，就能達到目標。這就比瞎測一通來得有譜多了。
最常見的坑：資料亂七八糟
我碰過最常出包的地方，就是「資料」不乾淨。有時候測試人員為了方便，把好幾個不同的失效模式都歸類成同一個，或是根本沒記錄清楚失效發生的時間。你想想，如果你的輸入數據本身就是錯的，那跑出來的 Beta 值能準嗎？
還有，不要以為跑一次模型就萬事大吉。可靠度成長是一個動態過程，每次有新的設計變更、新的失效發生，都要重新評估。如果你只看第一週的數據，然後就拍胸脯保證，那很有可能會在最後一刻爆掉。
今天能做的一件事
重新檢視你們 RGT 的數據，確保每個失效模式都有被獨立記錄。