2024年7月19日， CrowdStrike公司的更新引發的全球微軟Windows大規模當機事件，這起事件不僅讓採用他們家產品的各家企業哀號、也引發了業界對軟體開發流程、軟體測試或品質保證(QA)機制以及自動化測試等諸多議題的深入討論。我們今天來探討這個事件，大家看到了什麼。

簡單回顧一下

2024年7月19日，CrowdStrike公司發布一次更新。然而，這次更新卻意外導致了全球範圍內大量使用Windows操作系統的電腦出現藍屏死機、系統崩潰等問題。受影響的用戶數量巨大，涵蓋了個人用戶、企業用戶，甚至包括一些關鍵基礎設施。這場大規模系統的影響無法估量。

網路上在討論什麼？

在事件發生後，全球各大科技論壇和社交媒體上掀起了熱烈的討論。我這幾天深入觀察了國外主要論壇和一些知名科技博客，發現討論的焦點主要集中在以下幾個方面:

1. 開發者的軟體測試思維

許多討論者認為，即使公司沒有專門的軟體測試團隊，開發者也應該具備基本的軟體測試思維。他們覺得，開發者不能僅僅關注功能的實現，還應該時刻考慮到可能出現的各種異常情況和邊界條件，在開發時就要注意，或是自己要進行相關的測試，或許就能避免這場災難。

這種觀點邏輯正確且合理，對應到現代軟體開發中，其實就是「左移測試」(Shift-Left Testing)，這類概念越來越受到重視，但執行的方式千奇百怪。但萬法不離其宗，就是想辦法把測試活動盡可能提前到開發周期的早期階段，而不是等到開發完成後才進行測試，我見過比較誇張的就是開發第一天的Daily Build就要求測試團隊手動跑大型回歸，而且每天的版本都要跑。

無論如何，我們都知道，要求開發者完全承擔軟體測試的職責會有很多問題，這一點我們稍後會詳細討論。

2. 分階段上線策略的缺失

另一個被廣泛討論的問題是，為什麼CrowdStrike沒有採用分階段上線的策略，就像是Android上版時可以選擇要發布給多少百分比的人。CrowdStrike如果採用了灰度發布或者金絲雀發布等策略，即便出現了問題，影響範圍也會被限制在一個較小的用戶群體中，而不是造成全球範圍的系統崩潰。

分階段上線確實是一種行之有效的風險控制策略，而且在很多維運團隊都有採用，大多數的雲服務也都有類似的設定可以做，例如K8S可以導流到特定的機器做新版本實驗。這類策略也允許開發團隊在小範圍內測試新功能或更新，及時發現和解決問題，然後再逐步擴大發布範圍。這種方法能夠大大降低大規模故障的風險。然而，實務上，如果「每一件事」都如此進行，時間一久，都會有人出來質疑必要性，然後就出現了一些特例規則，導致這類流程變成虛設了。如果你們公司還存有這類流程而且貫徹執行，千萬要好好把握。

3. 軟體測試的必要性與局限性

在討論中，一個有趣的爭論點是關於軟體測試的作用和局限性。有人提出質疑:

即使有了軟體測試，真的能保證這種事故不會發生嗎?畢竟軟體測試不可能測試到所有可能的情況，既然這樣，為什麼還需要軟體測試？而大家都一直在討論軟體測試的事情？必要性在哪裡？

這種觀點確實道出了軟體測試工作的一個本質性挑戰:在複雜的軟體系統中，可能的情況組合是無限的，不可能通過測試覆蓋所有情況。然而，這種論點也存在明顯的謬誤。認為軟體測試無法保證100%的安全就否定軟體測試的必要性，這是一種「完美主義謬誤」(因為這個做法不完美，所以這做法是沒用的，不該使用它)。這說法過分強調了軟體測試的局限性，而忽視了軟體測試在提高軟體品質、降低風險方面的重要作用。這就像是認為沒有100%的純粹真愛，所以不願意談戀愛或結婚，完全排除了一件事情的好的那一面而全盤接受的壞的那一面。

事實上，軟體測試的價值不僅在於發現具體的錯誤，更在於建立一種品質文化和風險意識。一個健全的軟體測試流程可以幫助團隊:

• 系統性地思考可能的失敗情景

• 建立全面的測試策略

• 改善開發流程

• 提高整個團隊的品質意識

即使軟體測試無法保證100%避免問題，它仍然是軟體開發過程中不可或缺的一環。我相信大部分的企業沒辦法接受沒測試就上線，至少研發人員或PM自己都要過一手對吧？所以沒軟體測試團隊的配置，不代表不需要測試，它只反映了一間公司對測試的重視度和投資度。這也引發了下一種討論。

4. 敏捷開發與軟體測試的關係

在討論中，有人指出許多推崇敏捷開發的公司實際上並沒有專門的軟體測試團隊。這引發了關於敏捷開發模式下如何保證軟體品質的討論。

在某些敏捷團隊中，開發者被期望承擔更多的測試責任。這種做法的初衷是為了提高開發效率，縮短循環，甚至還提出了測試驅動開發的方法。然而，這種做法也帶來了一些潛在的風險:

• 角色衝突:

  • 開發和測試是兩種不同的思維模式。要求開發者同時扮演這兩種角色可能會導致某一方面被忽視，甚至是受企業文化的影響而偏頗。

• 時間壓力:

  • 如果沒有給開發者分配額外的時間來進行充分的測試，那麼測試品質很可能會受到影響。

• 專業性不足:

  • 專業的軟體測試人員通常擁有系統的測試方法論和豐富的經驗，這是一般開發者所不具備的，也有不少研發人員被要求做測試工作憤而離職的。

因此，即使在敏捷開發模式下，也不應完全刪除軟體測試角色。更合理的做法是讓軟體測試更好地融入敏捷流程，例如:

• 讓軟體測試參與需求分析和設計討論，早期識別潛在風險

• 在每個迭代中安排充足的測試時間

• 鼓勵開發者和軟體測試密切合作，共同制定測試策略

• 相信軟體測試的專業

5. 自動化測試的爭議

另一個引發熱議的話題是自動化測試的可靠性。有人質疑，如果過度依賴自動化測試，很多測試案例都被忽略，甚至是自動化腳本本身的問題導致測試無效。

自動化測試確實有其優勢，如快速、可重複執行、成本效益高等。然而，它也存在一些固有的局限性，甚至大家都知道自動化不能取代手動測試:

• 難以模擬所有真實世界的情況，特別是一些複雜的交互場景，網路每個環節的問題。

• 可能存在「假陽性，誤報」(false positive)和「假陰性，漏報」(false negative)的問題，腳本是照本宣科的執行，不如人具有人性，可以根據經驗法則做出異常判斷。

• 難以發現用戶體驗方面的問題，畢竟腳本只照腳本做事，其餘的一概不管。

因此，一個正確的測試策略應該結合自動化測試和手動測試。自動化測試覆蓋大部分基本功能和常見場景，而手動測試則關注更複雜的情況和用戶體驗。而我認爲更重要的，是在一些自動化測試無法被馬上開發出來的時候，手動測試能夠及早介入一些測試場景，尤其是冒煙測試。以這次CrowdStrike狀況來說，這種一上線就掛掉的狀況讓人匪夷所思啊，難怪會讓人覺得沒測試就上線。

此外，自動化測試的本身的品質也至關重要。僅僅有大量的單元測試並不足夠，還需要確保這些測試用例的設計是合理的，能夠真正反映系統的關鍵功能和潛在風險點，甚至整合測試與單元測試的概念是不同的，不該完全的依賴單元測試。

6. 根本原因在流程！而不是測試！

綜合各方討論，我們可以看到，雖然表面上這次事件看起來像是一個測試不足的問題，但實際上它反映了更深層次的流程問題。以下幾個方面值得我們重點關注:

a) 發布時機:

選擇在週五發布重要更新是一個有爭議的做法。週五發布意味著如果出現問題，可能需要工作人員在週末加班處理，這不僅影響員工生活品質，也可能因為人員不足而延遲問題解決。可以試著想想看，有些問題可能不是馬上發生，等到了週六週日，大家都在玩，出問題了誰來解決呢？我個人是非常不推崇週五發布版本的，即使在做了萬全測試，或是超級科技大公司，我都會這樣建議，逃避不可恥，也很有用。

b) 驗證流程:

是否有一個嚴格的驗證流程來確保每次更新都經過充分測試?這個流程是否包括了各種可能的使用場景和環境配置?我們無從得知CrowdStrike的內部流程，但至少看起來，如果是有經過驗證的，那這個版本的驗證出現了嚴重問題。

c) 審核機制:

重大更新是否經過了多層次的審核?例如，Code Review，主管確認，風險評估等。

d) 應急預案:

當出現問題時，是否有一個明確的退版機制和應急預案?能否快速識別問題並做出反應?而什麼樣的維運指標叫做出問題？

e) 冒煙測試:

在全面發布之前，是否進行了冒煙測試(smoke testing)來驗證基本功能?這次一上線就掛，最為人所詬病。

f) 內部測試環境的真實性:

大多數公司不會建置一套跟正式環境相同的環境用做測試，以前我加入17LIVE後，與SRE主管推動建置了Pre-Production模擬了正式環境的所有架構和機器大小(可縮放)，並且模擬資料量來取得接近真實的查詢速度和機器壓力，這個環境之後就作為正規發版前的壓力測試環境。

以上問題指向了軟體開發和發布流程中的關鍵環節。一個健全的流程應該能夠在多個層面上預防和快速應對潛在問題。

CrowdStrike事件付出慘痛代價，股價狂跌啊！不僅對該公司本身，也對整個軟體行業都是如此，至少微軟也跟著跌了。然而，從積極的角度來看，這次事件提供了很多的討論內容，引發熱烈的話題，軟體測試的話題被推上檯面。它提醒我們，在追求創新和效率的同時，不能忽視基本的品質保證和風險管理原則，測試的角色是不能夠被忽略的。

軟體開發永遠是一個不斷學習和改進的過程。即使有軟體測試工程師的存在，不意味著你有個王牌守門員幫你擋下所有的問題，即使是王牌守門員，也是有強大的團隊跟經年累月的訓練的。

更重要的是，即使是最成熟、最龐大、最領頭的公司也可能犯錯，接受每一間公司都會犯錯、接受自己的團隊會犯錯，關鍵在於如何從錯誤中學習並不斷進步。才能在這個快速迭代的環境中不斷前進，為用戶提供更好、更安全的產品和服務。

KEENLITY隆重推出第二門線上課程

軟體測試思維課 – 年薪三百萬的測試工程師獨門心法