昨天滴滴又㕛叒崩潰瞭！！！！

早上，正是一個人們出行的高峰季。結果，出現滴滴打車APP崩潰

至於，背後導致不崩潰的原因，就無從得知。

53a6c334ba01493429514a8c3c694ac2

當然，也隻有滴滴公司自己才知道到底是什麼原因導致的，

為此，刀哥專門也找瞭畢業之後，進入滴滴公司的學生。

但是，學生說不在那個出瞭事的部門，因此，刀哥也不敢瞎猜測瞭。

ba892bf795d56645d14594f768e83e88

刀哥今天想說的不是滴滴崩潰的原因，而是我想通過這件事告訴大傢，在軟件公司有一個重要的職業，叫軟件測試。

在沒有發生這件事之前呢，我們一提到軟件呢，都會和軟件開發工程師劃對等。其實還有一個和他同等重要的職業，那就是軟件測試工程師。

我們來以軟件測試的角度來分析如何避免這次事件的發生，當然刀哥的意思不是滴滴公司的測試工程師有多水，畢竟一個復雜的系統，崩潰的原因有可能有千萬種可能性都有可能導致問題。

這一點刀哥還是知道的，很多人還是很厲害的，我也認識很多滴滴裡面的測試骨幹，很多人的技術沉淀是很豐富的。

不廢話，作為一個軟件尤其是這種牽扯到大用戶量使用的軟件，我們該如何避免這種災難性的bug出現的概率。

首先，出現上面的問題，第一種情況就是有新版本上線。

那麼，如何保證新版本上線的質量。

需求評審

測試用例的編寫

測試用例評審

下來就是執行測試用例。

執行測試呢，基本上沿用我前面文章裡面闡述的。

文中也給出瞭在一般互聯這種迭代開發和測試的流程。

第二種，就是大用戶量的湧入導致服務器癱瘓。

就像每年淘寶雙十一，京東618，會有大量的用戶並發，但是這些都是比較寬泛的場景

但是這次事故因為大並發導致的問題可能性還是較低的。

畢竟，作為滴滴這樣的企業，在上線之前應該會做過各種並發場景的驗證，比如：主要業務功能的壓測，甚至對於這樣的大型企業，會有全鏈路的壓測技術以及相應的流量回放機制作為上線前性能的保證。

對於上線的過程中，滴滴也有一套完整的保障措施，比如：

新功能在上線的過程中會采取如下的一些措施

功能的定向投放

87ce209092f41a271e8121eefc48ed03

灰度發佈

當然，在滴滴這樣的大型互聯網公司，灰度發佈的規則也不會像傳統企業那樣簡單，有可能采取根據用戶和地域等分佈的情況進行逐級發佈，最後由小及大,最終達到一個全流量發佈

AB測試

當然，對於互聯網公司的一個最大的特質就是思想open，經常會有不同的方案產生，很多方案不知道那個更優化，帶來的轉化率，PV，UV等指標更優化的提升，這時候往往采取的AB測試。

以上，先介紹到這裡，由於篇幅有限，每個公司都有自己特有的產品研發測試流程，所以還得根據公司實際的情況，靈活的去選取對應的方案。