測試先知和啟發式方法

測試人員拿到測試任務時，需要考察兩類基本情況。第一類是測試人員的情況：

n  測試人員的測試經驗怎么樣，豐富還是欠缺？

n  測試人員對被測產品的行業經驗怎么樣，熟悉還是了解？

n  測試人員對被測產品的需求了解怎么樣，熟悉還是了解？

第二類是被測產品的情況：

n  產品開發目前處于什么階段？

n  產品是否經過了測試，使用了哪些類型的測試，覆蓋了哪些功能和屬性？

n  產品目前的風險或潛在問題有哪些？

測試人員應該仔細分析和理解這些情況。在時間壓力和業務質量壓力下，測試人員需要根據正確的信息來驅動測試活動，這樣才會取得較好的效果。

首先測試人員需要非常清楚自己的情況，也就是自己所擁有的知識（Knowledge），包括產品知識、行業知識、測試技術、開發技術和計算機基礎等。

檢查這些知識是為了在測試時能夠快速和有效地確定所發現的問題是否是差評缺陷。即測試人員需要綜合各種知識以構造一組測試先知，從而高效地識別產品缺陷。一種構造測試先知的可行方法是參考HICCUPPS（F）啟發式規則[Bolton05]，它們通過一致性檢查來識別產品缺陷。

n  歷史（History）：目前所做的產品的版本是否與過去的版本相一致。

n  愿景（Image）：產品是否與開發組織的愿景相一致。

n  相似產品（Comparable Products）：產品是否與類似的產品相一致。

n  聲明（Claims）：產品是否與重要人物的聲明相一致。

n  用戶期望（User’s Expectations）：產品是否與用戶期望相一致。

n  產品自身（Product）：產品中可比較的各個功能是否一致。

n  目的（Purpose）：產品是否與其（明確的或隱含的）目的相一致。

n  法規（Statutes）：產品是否與適用的法律相一致。

n  常識（Familiarity）：產品是否與常識相一致。

盡管我們有很多方式去豐富測試先知，但不支付足夠的時間成本很難達到非常完美的程度（所有預期輸出都在測試之前明確下來是需要很多時間成本投入的），因此我們在探索式測試過程中往往會遇到以下問題：

n  沒有測試先知可以使測試人員提前確定所觀察到的系統行為必定是正確或錯誤的。

n  沒有一個單獨的測試先知可以說明某個功能在任何時間或任何情況下都是正確工作的。

n  有些功能看上去是正常工作的，但在某些情況下會失敗，且會影響其他測試先知的正確性和適用性。

可見，測試人員構造測試先知時，肯定會遇到很多困難，那么該如何解決呢？以下是三個可能的思路。

n  忽略這個問題（也許這個信息的價值從成本角度考慮不值得）。

n  簡單化這個問題（改善可測試性以獲得更多的信息、分析需求、規約和代碼，從而獲得更簡單的檢查規則）。

n  轉移這個問題（考慮問題的相關性，從類似問題下手）。

在測試設計過程中，測試人員還可以使用啟發式方法（Heuristics）來產生更多更好的測試思路，例如[Bach21]：

n  引導詞啟發法（Guideword Heuristics）：一些詞語或標簽能引導測試人員發掘自身的知識和經驗，產生新的測試思路。。

n  觸發器啟發法（Trigger Heuristics）：一些存在于事件或條件中的想法，能提醒測試人員采用另外一種方式來進行試驗，就像思維的鬧鐘一樣。

n  副標題啟發法（Subtitle Heuristics）：能幫助測試人員重構測試想法并獲得更多的選擇點。

n  啟發式模型（Heuristics Model）：一組系統性的想法能幫助測試人員控制、管理和挖掘更多的想法。

實際上，人們在日常生活中也經常使用啟發式方法，例如，我們常用如下簡單的規則處理復雜的現實問題：

n  酒后駕駛非常危險。

n  一鳥在手要強于二鳥在林。

n  不入虎穴，焉得虎子。

n  人們有時在計算機旁邊隱藏自己的密碼，嘗試從那里尋找。

n  假期商店一般較晚開門。

n  如果你的計算機出現了莫名其妙的行為，重啟。如果還是有問題，重裝操作系統。

n  如果這是個真正重要的任務，你的老板會跟蹤它，否則，你可以忽略它。

由這些例子可知，啟發式方法是一種經驗方法，它針對復雜的問題提出了一種簡單的、較可能成功的解決思路。使用啟發式方法，人們可以快速地采取行動，在實踐中去探索答案，從而避免陷于無止境的問題分析，毫無進展。然而，啟發式方法只是一種“捷徑”，它不保證提供了“最佳答案”，也不能確保總是提供“正確答案”。因此，明智的測試人員不會依賴特定的、單一的啟發式方法，他會綜合運用多個啟發式方法，并根據實踐結果調整測試方法和測試先知。

本文節選自《探索式測試實踐之路》一書

史亮，高翔著

電子工業出版社出版