1、軟體測試中的「黑天鵝」
幾年前，我帶領的乙個測試小組遺漏了乙個嚴重的bug到網上，當使用者反饋這個bug後，我們對它進行了深入的分析和重現，最終所有人一致認為，這個bug能夠發生實在是機緣巧合，因為它需要多個條件同時發生才有可能觸發，比如「xx演算法開關必須開啟、xx演算法開關又必須關閉、xx引數必須取某個特定值、使用者的使用環境必須是xx個場景、硬體必須是使用xx介面板、軟體必須是xx版本、xx的頻寬恰巧又不夠。。。」，在使用者那裡，這些條件有一條不滿足，就不會發生這個bug。
由於這個bug的影響比較嚴重，又是使用者報告的，照例要提交缺陷根因分析報告。其中，報告裡有一項「後續如何發現這類缺陷，確保不遺漏？」我們不知道如何避免這樣的缺陷再次發生，實際上，如果從正向設計的角度，我們無論如何也不會設計乙個滿足上述所有條件的用例，也不會去執行這樣的測試。不過，我們不得不費盡心思地去思考，這個bug的發生是如何有其合理性的、是可以解釋的、因此也是可以預防的，以填補報告裡這一項的空白。
- 稀有性，或意外性，即它通常在預期之外；
- 衝擊性，即它會產生極端影響；
- 事後（而不是事前）可**性，人的本性促使我們在事後為它的發生編織理由，並且或多或少地認為它是可解釋和可**的。
很多重要的線上bug不就是測試中的「黑天鵝」嗎？它們的發生在你的預期之外、產生了極端的影響、事後人們總是認為這些bug是可以避免的。
仔細想一想，你所在的專案中是否有「黑天鵝」？2023年1月31日，亞馬遜主頁癱瘓近1小時，你是否提前預期到了（《黑天鵝》書中寫到，「從對稱的角度講，乙個高度不可能事情的發生，與乙個高度可能事件的不發生是一樣的」）？12306**的癱瘓、高鐵事故、atm取款系統故障。。。，你是否能提前預期到？其實，你可能已經發現，「黑天鵝」離我們並不遙遠，總是有那麼多被認為不應該發生的現象實際發生了。
造成「黑天鵝」現象的可能有很多種原因，從測試的角度講，我們如何來認識軟體測試中的「黑天鵝」 – 那些總是讓人意想不到又產生嚴重後果的bug呢？
2、對「黑天鵝」視而不見
人們習 慣於對「黑天鵝」視而不見。「社會學家一直錯誤地以為他們的理論能夠衡量不確定的事物」。人們相信通過使用趨勢分析工具和複雜的數學公式可以幫助我們很好地****市場的風險、挑選一支好的**，結果大失所望的人不在少數；人們相信複雜的科學儀器和先進的數學、物理學、天文學等理論可以幫助我們很好地****、海嘯、天氣，結果經常有令人意想不到的自然災害發生。
人們習慣於使用確定性的理論去推測那些不確定的事物，在這個處處都充滿了「變數」的時代，「以不變應萬變」的做法已不合適。rbt（基於風險的測試）是個不錯的方法，有些人會按照既定的套路使用rbt：在專案的某個時間點，邀請相關人一起收集風險、分析風險，然後按照風險分析結果開展測試活動。但是風險是時刻變化的、風險是不能確定的，你不可能提前預期所有的風險，你得學會「以動制動」，動態地、持續地應用rbt技術。哪怕如此，你仍然無法避免所有的風險，仍然會有「黑天鵝」發生，因為軟體測試的過程充滿了隨機性。
reqbt（基於需求的測試）是個至少從數學上說很嚴謹的測試技術，它會用因果圖的方法把業務中的每乙個原子邏輯規則都表達出來。reqbt的創始人richard bender認為只要使用了reqbt方法，不會遺漏乙個從黑盒角度講、功能上的、業務邏輯相關的、嚴重的bug。我深知這套方法的妙處，但仍然對如上的陳述有所懷疑，原因無他，測試中的不確定性太多，沒有哪個確定性的理論是銀彈，可以保證沒有某類的「黑天鵝」發生。
但這並不表示這些形式或模式確定類的技術沒有任何用處、只要使用不確定性的技術比如et（探索性測試）、rst（快速軟體測試）等就好了。應該說，這些確定性的方法（rbt、reqbt等）和不確定性的方法（et、rst等）結合起來使用的話，「動靜結合」，會更有效地減少測試中「黑天鵝」的發生。
3、判斷是否是「黑天鵝」
想知道哪些重要的軟體缺陷是「黑天鵝」，哪些不是？只要問一問，這些bug與出現之前所預期的相比較，是否是在預料之中的？
我們會發現，這些重要的bug大體可以分為兩類：一類是可以預期發生的，但是並沒有採取及時的措施去規避；一類是不被預期發生的，認為不應該發生這種缺陷。這就啟發我們在做rca（缺陷根因分析）時，對不同類bug的分析會帶來不同的收穫。
分析可以預期發生的嚴重缺陷，可以很好地幫助我們改進已經在實施的確定類方法或技術中的不足。比如在實施rbt過程中，為什麼沒有識別出某個風險？或者為什麼對風險級別的估計不足？或者為什麼沒有對已知的風險採取風險規避措施？再比如在應用mbt（基於模型的測試技術）過程中，為什麼某乙個因子在建模時被遺漏了？或者為什麼基於模型生成測試條件或測試用例時某個重要的引數被忽略掉了？再比如按照企業既定的流程管理軟體測試的過程中，為什麼在測試策略或測試方案中忽略了這一風險？或者為什麼在測試分析和測試設計中沒有覆蓋這個風險點？或者為什麼在測試執行環節沒有發現這個缺陷？等等。通過這樣對的rca過程，可以更好地幫助我們改善既有的測試方法或流程。
分析不被預期發生的嚴重缺陷，可以為我們開展不確定類測試方法或技術提供更多的輸入和想法。例如本文開篇所舉的那個關於某演算法失效的例子，想通過確定類的測試方法、正向的方式提前設計（也就是預期）相關的測試用例，基本不大可能。相反，我們換乙個角度，也許在et中探索出這個缺陷的機率更大一些，比如適當增加與使用者應用環境相關的各種因子組合的複雜場景測試的session。
《黑天鵝》是一本關於不確定性的書。「有兩種認識現象的方式。第一種排除不正常的現象，只關注正常現象。研究者不理會意外事件，只研究正常案例。第二種方法則認為，為了理解這一現象，人們需要首先考慮極端現象，尤其是當它們有非同尋常的效應累積的時候，比如黑天鵝現象。」對於測試而言，如果希望了解我們的不足，這兩類缺陷（可以被預期的缺陷和不可以被預期的缺陷）都要分析。
4、我們所不知道的更有意義
「黑天鵝的邏輯是，你不知道的事比你知道的事更有意義，因為許多黑天鵝事件正是由於它們不被預期而發生和加劇的。」作者認為現在的世界由不確定性主導，不論這個結論正確與否，單就測試而言，這個結論是非常適用的，軟體測試是由不確定性主導的。測試就是尋找未知的過程，這些未知的事情包括未知的缺陷、未知的被測物件的質量狀況、未知的真實的被測物件是什麼樣的以及所有那些你認為你已經知道的但實際上是你不知道的軟體相關的資訊，這些未知給予測試挑戰的同時也賦予測試很大的意義。
可以這樣說，所有的測試用例都是基於測試人員已知的知識設計出來的，執行這些用例有機會發現那些能夠被預期的缺陷；而測試中的「黑天鵝」- 那些重要的不被預期的缺陷，有多少是由測試用例發現的？
分析每乙隻「黑天鵝」，會幫助我們發現那些原本對於我們是「未知」的東西，每乙隻「黑天鵝」的遺漏，都是由於一些「未知」的因素，或者是未知的知識或資訊、或者是不知道某些資訊的重要程度而加以重視。下一次測試中，就會有意識地盡量拓寬我們的已知領域，減少「黑天鵝」發生的次數。
探索性測試在拓寬「已知領域」方面功不可沒。當我們需要探索時、當我們不知道下一步測試什麼時、當我們想要獲得更多的想法時，我們使用探索性測試，et有助於拓寬我們的測試深度和測試寬度，盡可能擴大已知領域的邊界，縮小我們未知的領域。
5、結論
你看到乙個後果很嚴重的缺陷，正是由於你認為它不應該發生？這是不是很奇怪？不管你採用什麼樣的測試方法、你的測試團隊有多麼強大、你在測試上投入了多少人力物力，測試中的「黑天鵝」總會發生。
作者在《黑天鵝》書中指出人性的乙個弱點：「習慣於學習精確的東西，而不是總體的東西」，並且把「由於只關注那些純粹而有明確定義的『形式』而導致的錯誤」稱為『柏拉圖化』」。測試的柏拉圖化思想會讓你只關注外在的形式，例如測試的流程是否遵守、測試的模板是否應用、測試方法的具體步驟是否實施，而開始忽略其他不那們具體不那麼明確不那麼美好和解釋得清的事務，忽略那些顯得有些混亂和不可琢磨的事務，比如在有些人眼裡，探索性測試不容易管理、不好解釋給別人、步驟不那麼明確、有太多不可琢磨的東西在裡面。
就像敏捷裡承認變化總會存在而去擁抱變化一樣，我們也應該正視測試中「黑天鵝」現象的存在，並盡最大可能地多嘗試以減少「黑天鵝」發生的機會（拓展已知領域、減少未知領域），並且一旦「黑天鵝」發生了盡最大可能地把握黑天鵝機會（分析那些未知點，更好地應用不確定類的方法，尋求測試改進）。
黑天鵝筆記
1.黑天鵝現象，黑天鵝現象具有三個特點 不可預測性。影響重大。事後可解釋。2.我們不斷依據事件發生之後我們認為有道理的邏輯又一次敘述過去的事件。3.避免敘述錯誤的辦法就是強調實驗而非講故事。強調體驗而非歷史，強調客觀知識而非理論。4.那些我們沒有看到的結果可能。不，是通常更具有意義。5.我們冒險通常...
黑天鵝 簡記
黑天鵝 是2010年由達倫 阿倫諾夫斯基執導的美國電影。劇情簡介 圍繞娜塔莉 波曼飾演的妮娜，一位紐約的芭蕾舞演員展開，她與母親 退休的芭蕾舞演員艾麗卡居住在一起，她的生活只有舞蹈以及野心勃勃的職業目標。好機會終於降臨，當導演托馬斯 文森特 卡塞爾 決定為新一季 天鵝湖 挑選新演員時，妮娜成為了第一...
黑天鵝 簡記
黑天鵝 是2010年由達倫 阿倫諾夫斯基執導的美國電影。劇情簡介 圍繞娜塔莉 波曼飾演的妮娜，一位紐約的芭蕾舞演員展開，她與母親 退休的芭蕾舞演員艾麗卡居住在一起，她的生活只有舞蹈以及野心勃勃的職業目標。好機會終於降臨，當導演托馬斯 文森特 卡塞爾 決定為新一季 天鵝湖 挑選新演員時，妮娜成為了第一...