qileilove

　　1、歷史與三重迷霧

　　在“認識軟件測試中黑天鵝”一文中，我描述了什么是軟件測試中的黑天鵝及其特點，本文將探討測試中的黑天鵝發生之前、之后、以及正在發生之中的故事。

　　《黑天鵝》一書的作者Nassim指出“歷史是模糊的。你看到了結果，但看不到導致歷史事件發生的幕后原因。”其實，測試何嘗不是這樣，假如把測試看成一個盒子，這個盒子也是模糊的，你看不到盒子里面是什么，整個機制是如何運行的。

　　書中描述：“對待歷史問題，人類思維會犯三個毛病，我稱之為三重迷霧。他們是：

　　1）假想的理解，也就是人們都以為自己知道在一個超出他們認知的更為復雜（或更具隨機性）的世界中正在發生什么。

　　2）反省的偏差，也就是我們只能在事后評價事務，就像只能從后視鏡里看東西（歷史在歷史書中比在經驗現實中顯得更加清晰和有調理）。

　　3）高估事實性信息的價值，同時權威和飽學之士本身有缺陷，尤其是在他們進行分類的時候，也就是進行‘柏拉圖化’的時候。”

　　我很容易聯想到，這三重迷霧分別對應測試中的黑天鵝發生之前、之后、以及黑天鵝形成之中的故事，即：發生之前的“盲目預測”、發生之后的“假想解釋”、以及黑天鵝形成之中的“柏拉圖化”。

　　2、黑天鵝發生之前的“盲目預測”

　　“第一重迷霧就是我們以為我們生活的這個世界比它實際上更加可理解、可解釋、可預測”。打開收音機或電視機，你就會聽到或看到，每天都有無數的人在信心滿滿地預測著各種各樣的事情：股市的走勢、房價的走勢、戰爭是否會爆發、疾病是否會流行。。。

　 　正向Nassim指出的那樣，“幾乎所有關心事態發展的人似乎都確信自己明白正在發生什么。每一天都發生著完全出乎他們預料的事情，但他們就是認識不到 自己沒有預測到這些事。很多發生過的事情本來應該被認為是完全瘋狂的，但在事情發生之后，看上去就沒有那么瘋狂。這種事后合理性在表面上降低了事件的稀有 性，并使事件看上去具有可理解性。”就拿我所生活的這座城市-上海來說，近來的許多事件都在證實著這點：黃浦江上打撈出數千頭病死豬、H7N9的流行，昨 天突然看到一條“上海自來水中添加了XX”的微博更是令人觸目驚心，我們內心都預測這些事情不應該發生，可是實際上卻發生了。

　　這種黑天鵝發生之前的“盲目預測”讓我想到軟件測試中版本發布之前的“測試評估（test evaluation）”。一個產品經過測試團隊的集中測試后，發布到用戶那里，誰能準確預測是否會出現“黑天鵝”呢？在你的團隊，在版本對外發布之前，是否需要測試團隊填寫一個關于產品質量的測試評估表？下圖是測試評估表的一個樣例。

　 　這里的特性指的是“測試特性（test feature）”。根據各團隊上下文的不同，這個測試特性可能與開發特性直接對應，也可能不與開發特性一一對應，每個測試特性對應一條到多條需求（用戶 需求或系統設計需求）。我最常看見的質量評估說明是“XX特性基本功能正常。”有些人會在后面附上所發現的比較嚴重的bug。這樣的描述顯然并不令人滿 意。

　　問題是：

　　每個特性質量的A/B/C/D的結論是否準確？ 所有特性的A/B/C/D的結論加一起又如何判別整個系統的質量？是否所有特性的質量都是A或B，版本就可以對外發布，并且發布以后不會出現令人意想不到 的“黑天鵝”現象？測試人員給出的A/B/C/D有多大成分是基于一種feeling給出的？

　　對于任何一條 需求，開發人員的任務就是實現它，無論是由一個項目組實現，還是多個項目組配合實現。但是，對于測試人員，考慮的事情就復雜一些。我們除了要驗證這條需求 本身的功能實現是否正確，還要驗證該需求和其它功能之間的交互，還要考慮客戶可能使用的各種場景（Scenario），包括各種組網場景、各種參數的配置 等。如果把測試場景和測試特性交互起來，測試就無窮無盡了，并且也沒有必要在每一種測試場景下，都驗證被測特性的基本功能、異常功能、與其它功能的交互、 非功能屬性等各方面。如何設計更有效的、有限數目的用例盡量做到最大的測試覆蓋，這屬于另外一個話題，本文不做探討。

　　毫無疑問，盡管測試設計人員和測試執行人員精疲力盡的試圖覆蓋該特性的所有可能的場景，測試人員仍然只覆蓋了一小部分的場景下的該特性的部分測試用例，如果沒有Fatal的遺留問題，是否該特性的質量就可以評價為A或B，并且認為可以對外發布了呢？這種測試評估工作， 與其說是讓測試人員對被測對象的質量進行測試評價，不如說是讓測試人員對被測對象進行質量預測，因為測試人員所了解的只是部分信息，而不是全部。 Nassim說“在這些錯誤的預測和盲目的希望中，有一些愿望的成分，但也有知識的問題。”我更愿意相信，測試人員對產品質量的預測主要是“知識的問 題”，畢竟完整測試是不可能的。

　　既然測試無法做到完整覆蓋，不如在有限的時間和資源內，盡可能覆蓋典型的場 景，測試評估中針對已經覆蓋到的典型場景進行評估，具體地，James Bach和Michael Bolton在RST（Rapid Software Testing）課程里提出的三步法可以供參考：

　　● 測試中發現了哪些問題；

　　● 做了哪些測試活動發現了這些問題；

　　● 測試活動本身的有效性如何，哪些地方可以改善。

　　那么對于典型場景之外的其他場景又如何評估呢，這與測試評價之前的那些測試活動息息相關，也就是與黑天鵝正在形成之中的那些故事有關，我們在后面第四部分再探討。

　　不管怎樣，那些你認為不應該發生的“黑天鵝”經常如期而至。很多組織要求缺陷發生后開展缺陷根因分析（RCA）（我總是在盡力避免使用“缺陷回 溯”這個詞）。尤其對黑天鵝這樣的重要的bug，更要仔細開展缺陷根因分析了。對黑天鵝開展RCA的目的是利用這個黑天鵝，挖掘它帶給我們的信息，從而盡 可能在以后的測試中發現更多類似的缺陷，對開發而言則是在以后盡可能避免引入此類的bug。

　　RCA的目的是做到基于缺陷的過程改進，而不是解釋黑天鵝的發生這個動作本身。不要試圖去解釋所有的黑天鵝，尤其是那些在實驗室很難重現的黑天 鵝。我看到有些測試團隊，當黑天鵝發生了很緊張，又是一個嚴重的bug漏測了，趕緊組織人力調查分析，盡快寫出一個看起來像樣的缺陷分析報告。而閱讀這個 RCA報告，很難從中找出真正有力的措施可以有效避免今后這類bug不再漏測。舉幾個現實中的“RCA現象”：RCA報告中，錯誤的原因有“人為錯誤”、 “溝通不暢”、“缺乏相應的測試用例”等；避免漏測的措施有“加強代碼走讀”、“加強白盒測試”、“提高測試設計能力”、“加強與開發人員的溝通”等。 Nassim發現，“我們的頭腦是非常了不起的解釋機器，能夠從幾乎所有事物中分析出道理，能夠對各種各樣的現象羅列出各種解釋，并且通常不能接受某件事 是不可預測的想法。”

　　我曾對多個團隊進行T-RCA（我提出的一個缺陷根因分析的方法）引導，發現一個有趣的現象，盡管各個團隊所測試的產品是不同的，但是他們 RCA分析的結論卻是驚人的相似，很多團隊都存在我上述所列的“RCA現象”。我分析原因大致有二，一是沒有找到有效開展RCA的方法，沒有找到缺陷發生 的根本原因；二是很多團隊使用了比較“細致”的RCA模板，模板里對每一項可能的情況進行了細致的分類，比如該缺陷所處的測試級別、涉及的測試活動、所屬 的測試類型、可能的原因分類等等。缺陷根因分析工作仿佛變成了測試人員只要對照模板逐一打鉤去篩選就可以了，但實際上RCA是個高度探索性的過程，需要與 缺陷相關的各干系人去溝通，需要從紛繁復雜的種種因素中創造性地找到改進的措施。面對著電腦，填寫那些RCA模板中的空白項不是最主要的工作。實際上，某 種程度上講，過細的RCA模板簡化了缺陷分析過程，掩蓋了缺陷根因分析過程的復雜性，也比較容易導致分析結果的雷同。《黑天鵝》里的這句話也許可以給我們 更多啟示：“我們對周圍世界的任何簡化都可能產生爆炸性后果，因為它不考慮不確定性的來源，它使我們錯誤地理解世界的構成。”

　　4、黑天鵝形成之中的“柏拉圖化”

　　既然，測試中的黑天鵝的發生是個經常性的事件，那么測試的過程不也正處于黑天鵝形成的過程嗎？想象一下，當前我們正在測試一個產品，我們了解黑天鵝理論，我們知道這個產品發布給用戶后極有可能會冒出“黑天鵝”來，那么我們當前可以采取什么措施呢？

　　我在“認識軟件測試中黑天鵝”一文中解釋了什么是“測試的柏拉圖化”：只注重外在的形式、尤其是針對具體明確的事情進行簡單分類的時候，犯“柏 拉圖化”錯誤的人容易高估他們已經掌握的事實性信息的價值，而對大量的他們還不知曉的并且非常重要的信息視而不見。我是在2006年發現這個“我所不知道 的大量信息的”，也同時發現了之前我所犯的“測試的柏拉圖化”的錯誤，即特別重視諸如“測試用例設計個數、測試用例執行個數、發現的bug數”等這些數 據，也許在這些明確的、外在的形式之外，有更多值得我們思考的東西。

　　那一年，我負責一個特性（大體就是在手機上通過蜂窩小區廣播的形式收看電視）的測試，這個特性是個全新開發的特性，我是第一個、也是當時唯一一 個測試人員，測試任務很緊張，因為這個特性已經定于一、兩個月以后在香港某個運營商網絡里首次商用。像大多數測試人員一樣，我很辛勤地、按照既定方法和策 略測試這個特性，在有限的測試時間里：我熟悉了這個特性、設計了很多測試用例、執行了大量的測試用例、發現了很多bug、對這個特性相關的每一個bug都 了如指掌、通過和開發人員不斷地交涉和定位bug還對該特性當前存在的缺陷非常清楚、熟悉這個特性的代碼和問題定位手段。當我奔赴香港作為測試人員輔助開 通這個特性的商用之前，研發團隊解決了所有嚴重的缺陷，我很有信心應對各種可能的狀況，我幾乎認為我對這個特性的了解已經很完整了。

　　可是，當我抵達用戶那里，看到我們的產品在真實網絡中的運行環境、配置、使用方式，與用戶和當地技術支持人員的各種交流，坐在地鐵里看到身邊的 人員拿著手機正在開啟使用我剛剛參與開通商用的特性，從真實網絡環境中獲取的大量錯誤報告和跟蹤消息和后臺日志。。。短短幾天內，有關這個特性的、以前我 所不知道的、大量的信息沖進了我的大腦，我像突然撿到寶藏一樣地忙著分析日志、記錄bug，生怕遺漏了哪個bug沒有記錄，然后回到實驗室都不知道如何觸 發。

　　我發現了一個重要的事實：這一回，我只用了幾天時間，沒有設計任何測試用例，沒有執行任何測試用例，卻在一個我幾乎認為沒有什么嚴重缺陷的特性 上，“不費吹灰之力”似的又發現了很多嚴重的缺陷。而且這些缺陷不是實驗室觸發的，而是就發生在用戶的身上，有些遭到用戶的投訴，有些用戶還不知曉，換句 話說，這些缺陷都是優先級很高的非常重要的缺陷。

　　從香港回來，我一直在思考，測試團隊如何發現這些重要的缺陷？甚至如何讓平常我們在實驗室中的測試也能這么高效、這么有效？您可能已經猜到了， 這就是后來備受重視的UBT（Usage Based Testing），或者有的行業叫做TiP（Test in Production），也有人稱為Testing-in-the-wild。

　　再回到前面曾提到的一個關于測試評估的問題上：假如平常的測試更關注典型場景的測試，那么對于非典型場景如何測試以及如何評估呢？我想UBT是 個不錯的選擇。既然無法做到全覆蓋的測試，就不去做，不要試圖在現有的測試模式下，測試設計和測試執行都投入很大精力去覆蓋各種場景和交互，因為這樣做收 效甚微，依然達不到目的。平常的功能測試只做最普通、最典型、最重要場景下的功能驗證，保證每個測試特性的基本功能OK。此外，還要開展UBT或TiP， 主要考慮各種配置和場景，用模擬器模擬真實商用組網環境和業務模型，或者直接在用戶使用產品的真實環境中開展測試。

　　假如被測系統如下圖的方框，灰色的小塊就是我們平常的功能測試覆蓋，可能很多測試團隊的做法是試圖盡最大能力增加這些灰色小塊的覆蓋，但依然會 有很多覆蓋不到的地方。而UBT就相當于紅色的范圍，雖然沒有針對性的設計測試用例，但由于模擬了可能使用的商用場景和業務，業務之間交互的測試在這種測 試環境下自動進行，潛在的一般的bug都被自動發現（比較難觸發的異常bug依然發現不了），如果這樣的UBT測試連續執行幾天或數周都沒有問題，此時測 試的評估中就可以很有信心地寫到：在XXX UBT環境下連續運行XX天，沒有發現嚴重問題。 這樣，也大大減少了版本發布后“黑天鵝”出現的幾率。

　　5、結論

　　如果你認同“測試的黑天鵝”就在我們身邊，那么：

　　● 在“測試的黑天鵝”發生之前，不要在信息不完整的情況下對全局做“盲目預測”，因為你只掌握了部分信息，你要做的是更準確地陳述這些“部分信息”；

　　● 在“測試的黑天鵝”發生之后，不要試圖對所有黑天鵝都做“假想解釋”，更重要的是從已經發生的黑天鵝身上挖掘更有價值的信息，以減少更多類似黑天鵝事件的發生；

　　● 在“測試的黑天鵝”形成過程之中，不要犯“測試的柏拉圖化”錯誤，重視你知道的信息，更重視那些你所不知道的大量的更有價值的信息。

　　本文轉載自：http://www.taixiaomei.com/archives/223

相關鏈接：

軟件測試中的黑天鵝（一）：認識軟件測試中的黑天鵝