如何捕捉無規律的異常

　　階段：項目進入到第8個月了，等過完春節后還有1周用來清理后續，就宣告結束這場勝仗了。

　　投靠陣營：軟件測試組；
　　內部對立陣營：軟件開發組；
　　外部對立陣營：客戶。

　　場景：就在完成了大量重復操作和回歸測試之后，以為勝利在望的時候，突然發現程序有不穩定現象。征兆為“退出程序時的內存異?！?。有些使用時間長久的WINDOWS操作系統，莫名奇妙就會出現這個懊惱提示。這猶如吃米飯吃到最后一口時，發現里面有石子兒那般破壞快感。由于項目對于程序穩定性沒有特殊要求，2個舊版本中的不穩定概率很低，導致這次的意外沒有被提早發現。無論如何，作為測試人員，既然“吃石子兒”的好運降臨在我的頭上，就不能辜負這次機會。

　　作戰方案：的確，采取純粹的黑盒測試方法，很難捕捉問題的源頭。因此這樣的硬骨頭是很有挑戰意義的。還是這樣，按照換位思考的方法來綜合出一個最合適的解決方案，而非最優秀的解決方法。從客戶角度來思考，在不影響功能的狀態下，不要出現這個嚇唬人的框框就行了；從開發人員的角度思考，在項目末期出現這個故障，是比較頭大的，如果不影響主要功能的穩定，想辦法讓框框消失就可以了，盡量不要大興土木重新來過；因此，作為測試人員，找到問題的大致方向，給開發人員提供思路，即可。不必刨根問底顯示你的“艱苦奮斗”而影響全隊的作戰士氣。

　　第一階段：沒有規律，沒有重現方法。

　　首先我們知道，這個內存錯誤提示框，是WINDOWS為了保護硬件而組織程序駐留在非法內存中拋出的。因此，在這個階段，想要開發人員簡單的屏蔽這個框框是不現實的，也是不負責任的。你肚子痛，醫生叫你隨便吃藥，也不告訴你吃的什么藥，反正你付錢拿藥就行。那還有沒有天理呢，呵呵?！贿^這個階段情緒挺差，組合了很多測試用例和方法，依然沒有找到任何規律，也不能確定如何才能重現。有至少2天，處于這種狀態。

　　第二階段：沒有規律的重現。

　　被動防御了2天，戰局沒有進展，開發人員卻給了一個新的版本。在這個版本中關于這個程序異常，可以說沒有任何實質性的進展。不過似乎在夾縫中有了轉機，這個版本中加強了對最新功能模塊的修改，使得使用并關閉程序之后，WINDOWS報錯的概率大幅度提高。這樣一來，有了2條模糊的思路：1，是否和新功能修改有關；2，是否有內存泄漏。即使如此，出錯的規律依舊沒有找到。就這樣，每天打開內存監視工具，嘗試尋找規律?？赡茚t學上的臨床觀測，也是類似如此吧，哈哈。

　　第三階段：尋找資料，逐步溝通。

　　在網絡上搜索內存泄漏的技術資料，并再次熟悉程序架構：C++編程，新功能中外掛了一個DELPHI開發的DLL。在這兩種語言編寫出來的程序中，前者對于指針的把握問題很普遍，而后者對于程序關閉時的內存回收機制也同樣具有很多先例性問題。有了這些資料作為后盾，我對于內存泄漏的猜測有了更足夠的信心。跑去和開發人員溝通，次日便得到回復：代碼中存在部分導致內存泄漏的錯誤。逐一修改，得到了新版本的程序再測試。臨床檢驗有了初步診斷，但是仍舊沒有擺脫危險。

　　第四階段：水落石出。

　　某一天早晨，開發人員主動過來告之，該新模塊中調用的DLL存在關閉程序時回收機制的問題。（不搜不知道，網絡上一搜索，資料一大堆）在察看了程序代碼之后，可以輕而易舉地找到出錯規律，并能每次重現。開發人員友好地提供了重現方法，為了新版本的測試而提供方案。這樣，我們從第一階段的毫無頭緒到現在的水落石出，終于把癥結給捕捉。石頭從嘴里吐出，漱漱口再吃一顆口香糖吧。

　　總結：冷靜、整理、規劃、溝通、探討、總結。在合作競爭的環境下，共同努力，促進良性循環，完成工作，增進感情。

原文轉自：http://www.anti-gravitydesign.com