1、軟件測試中的“黑天鵝”

　　幾年前，我帶領的一個測試小組遺漏了一個嚴重的bug到網上，當用戶反饋這個bug后，我們對它進行了深入的分析和重現，最終所有人一致認為，這個bug能夠發生實在是機緣巧合，因為它需要多個條件同時發生才有可能觸發，比如“XX算法開關必須打開、XX算法開關又必須關閉、XX參數必須取某個特定值、用戶的使用環境必須是XX個場景、硬件必須是使用XX接口板、軟件必須是XX版本、XX的帶寬恰巧又不夠。。?！?#xff0c;在用戶那里，這些條件有一條不滿足，就不會發生這個bug。

　　由于這個bug的影響比較嚴重，又是用戶報告的，照例要提交缺陷根因分析報告。其中，報告里有一項“后續如何發現這類缺陷，確保不遺漏？”我們不知道如何避免這樣的缺陷再次發生，實際上，如果從正向設計的角度，我們無論如何也不會設計一個滿足上述所有條件的用例，也不會去執行這樣的測試。不過，我們不得不費盡心思地去思考，這個bug的發生是如何有其合理性的、是可以解釋的、因此也是可以預防的，以填補報告里這一項的空白。

　　前不久我閱讀了一本書叫做《黑天鵝》。數千年來，人們認為世界上只有白天鵝，但是發現第一只澳大利亞黑天鵝以后，這種牢不可破的觀念被顛覆了。作者指出“黑天鵝事件”滿足三個特征：

　　- 稀有性，或意外性，即它通常在預期之外；

　　- 沖擊性，即它會產生極端影響；

　　- 事后（而不是事前）可預測性，人的本性促使我們在事后為它的發生編織理由，并且或多或少地認為它是可解釋和可預測的。

　　很多重要的線上bug不就是測試中的“黑天鵝”嗎？它們的發生在你的預期之外、產生了極端的影響、事后人們總是認為這些bug是可以避免的。

　　仔細想一想，你所在的項目中是否有“黑天鵝”？2013年1月31日，亞馬遜主頁癱瘓近1小時，你是否提前預期到了（《黑天鵝》書中寫到，“從對稱的角度講，一個高度不可能事情的發生，與一個高度可能事件的不發生是一樣的”）？12306網站的癱瘓、高鐵事故、ATM取款系統故障。。。，你是否能提前預期到？其實，你可能已經發現，“黑天鵝”離我們并不遙遠，總是有那么多被認為不應該發生的現象實際發生了。

　　造成“黑天鵝”現象的可能有很多種原因，從測試的角度講，我們如何來認識軟件測試中的“黑天鵝” – 那些總是讓人意想不到又產生嚴重后果的bug呢？

　　2、對“黑天鵝”視而不見

　　人們習 慣于對“黑天鵝”視而不見?！吧鐣W家一直錯誤地以為他們的理論能夠衡量不確定的事物”。人們相信通過使用趨勢分析工具和復雜的數學公式可以幫助我們很好地預測股票市場的風險、挑選一支好的股票，結果大失所望的人不在少數；人們相信復雜的科學儀器和先進的數學、物理學、天文學等理論可以幫助我們很好地預測地震、海嘯、天氣，結果經常有令人意想不到的自然災害發生。

　　人們習慣于使用確定性的理論去推測那些不確定的事物，在這個處處都充滿了“變數”的時代，“以不變應萬變”的做法已不合適。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。

　　《黑天鵝》是一本關于不確定性的書?！坝袃煞N認識現象的方式。第一種排除不正常的現象，只關注正常現象。研究者不理會意外事件，只研究正常案例。第二種方法則認為，為了理解這一現象，人們需要首先考慮極端現象，尤其是當它們有非同尋常的效應累積的時候，比如黑天鵝現象?！睂τ跍y試而言，如果希望了解我們的不足，這兩類缺陷（可以被預期的缺陷和不可以被預期的缺陷）都要分析。

　　4、我們所不知道的更有意義

　　“黑天鵝的邏輯是，你不知道的事比你知道的事更有意義，因為許多黑天鵝事件正是由于它們不被預期而發生和加劇的?！弊髡哒J為現在的世界由不確定性主導，不論這個結論正確與否，單就測試而言，這個結論是非常適用的，軟件測試是由不確定性主導的。測試就是尋找未知的過程，這些未知的事情包括未知的缺陷、未知的被測對象的質量狀況、未知的真實的被測對象是什么樣的以及所有那些你認為你已經知道的但實際上是你不知道的軟件相關的信息，這些未知給予測試挑戰的同時也賦予測試很大的意義。

　　可以這樣說，所有的測試用例都是基于測試人員已知的知識設計出來的，執行這些用例有機會發現那些能夠被預期的缺陷；而測試中的“黑天鵝”- 那些重要的不被預期的缺陷，有多少是由測試用例發現的？

　　分析每一只“黑天鵝”，會幫助我們發現那些原本對于我們是“未知”的東西，每一只“黑天鵝”的遺漏，都是由于一些“未知”的因素，或者是未知的知識或信息、或者是不知道某些信息的重要程度而加以重視。下一次測試中，就會有意識地盡量拓寬我們的已知領域，減少“黑天鵝”發生的次數。

　　探索性測試在拓寬“已知領域”方面功不可沒。當我們需要探索時、當我們不知道下一步測試什么時、當我們想要獲得更多的想法時，我們使用探索性測試，ET有助于拓寬我們的測試深度和測試寬度，盡可能擴大已知領域的邊界，縮小我們未知的領域。

　　5、結論

　　你看到一個后果很嚴重的缺陷，正是由于你認為它不應該發生？這是不是很奇怪？不管你采用什么樣的測試方法、你的測試團隊有多么強大、你在測試上投入了多少人力物力，測試中的“黑天鵝”總會發生。

　　作者在《黑天鵝》書中指出人性的一個弱點：“習慣于學習精確的東西，而不是總體的東西”，并且把“由于只關注那些純粹而有明確定義的‘形式’而導致的錯誤”稱為‘柏拉圖化’”。測試的柏拉圖化思想會讓你只關注外在的形式，例如測試的流程是否遵守、測試的模板是否應用、測試方法的具體步驟是否實施，而開始忽略其他不那們具體不那么明確不那么美好和解釋得清的事務，忽略那些顯得有些混亂和不可琢磨的事務，比如在有些人眼里，探索性測試不容易管理、不好解釋給別人、步驟不那么明確、有太多不可琢磨的東西在里面。

　　就像敏捷里承認變化總會存在而去擁抱變化一樣，我們也應該正視測試中“黑天鵝”現象的存在，并盡最大可能地多嘗試以減少“黑天鵝”發生的機會（拓展已知領域、減少未知領域），并且一旦“黑天鵝”發生了盡最大可能地把握黑天鵝機會（分析那些未知點，更好地應用不確定類的方法，尋求測試改進）。

轉載于:https://www.cnblogs.com/Kung/archive/2013/03/22/Test.html

總結

以上是生活随笔為你收集整理的测试中的黑天鹅的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。