學習探索式測試的問與答(5)

　　尋找缺陷：發現或收集軟件的缺陷。

　　提煉模式：分析出缺陷的根本原因，編寫一個模式，用它捕獲相似的缺陷。一個模式是一個結構化的攻擊手段，它包含如下內容。

　　何時實施該攻擊?

　　該攻擊會捕獲何種錯誤(Fault)?

　　利用該攻擊如何識別軟件失敗(Failures)?

　　如何實施攻擊?

　　樣例和分析。

　　開發自動化工具：識別出攻擊過程中機械的部分，編寫一個工具去自動化模式的應用。此處的測試自動化不是自動地執行測試用例，而是提供計算機輔助功能，其目的是讓計算機完成高負荷運算，讓人專注于富有智力挑戰的任務。

　　按照James的方法實施軟件測試，測試團隊可以積累一批有益的模式和測試輔助工具。這可以幫助團隊更有效地測試現在和未來的項目。

　　問：探索式測試能用于測試自動化嗎?

　　答：本書第6章將討論探索式測試與測試自動化。這里簡單陳述一下筆者的觀點。

　　測試自動化可以大致分為測試用例自動執行(Automated Test Execution)和計算機輔助測試(Computer-Assisted Testing)。

　　對于測試用例自動執行，探索式測試可以提供一批適合自動執行的測試用例。

　　對于計算機輔助測試，探索式測試要求人盡其才(自由發揮測試者的智能)和物盡其用(充分利用計算機的性能)，利用計算機強大的計算能力去幫助測試人員完成測試使命。

　　許多復雜的測試自動化應該以探索式的風格來構造。對于困難的測試，應該先構建簡單的測試代碼，將其投入測試，利用測試反饋來改進測試代碼。然后，將改進后的測試代碼投入測試實踐，分析測試反饋，再優化測試代碼。所謂探索式測試自動化，就是將學習、設計、實現、評估納入迭代開發，以逐步提高測試自動化和產品的質量。

　　問：探索式測試與敏捷測試有何關系?

　　答：探索式測試在本質上是敏捷的，且可以很好地應用于敏捷項目。

　　2001年，17位軟件專家在美國猶他州雪鳥(Snowbird)城集會，締結敏捷聯盟，并發表敏捷宣言。與會者之一Brian Marick具有深厚的測試背景，因此軟件測試社區對敏捷宣言亦有貢獻。

　　敏捷軟件開發宣言[Agile01]

　　我們一直在實踐中探尋更好的軟件開發方法，身體力行，同時也幫助他人。由此我們建立了如下價值觀：

　　個體和互動高于流程和工具

　　工作的軟件高于詳盡的文檔

　　客戶合作高于合同談判

　　響應變化高于遵循計劃

　　也就是說，盡管右項有其價值，我們更重視左項的價值。

　　語境驅動測試的基本原則“任何實踐的價值都取決于其語境”和“人，在一起工作的人，是項目語境中最重要的部分”，與敏捷宣言的首條價值觀“個體和互動高于流程和工具”不謀而合。高效的探索式測試不但需要優秀的測試人員，也要求測試人員、開發人員、客戶和項目關系人緊密協作、頻繁互動。

　　在思想層面，探索式測試要求測試人員不斷地研究產品，通過應對、激勵、擁抱變化來驅動對問題空間的積極探索。這不但符合敏捷價值觀，也可以應用于其他類型的測試項目。敏捷測試專家Lisa Crispin和Janet Gregory指出：“敏捷測試可以發生在敏捷項目之外。例如探索式測試，無論它是否應用于敏捷項目，其本質是敏捷的。通過測試逐漸學習產品，并讓所學信息指導測試實踐，這無疑符合敏捷價值觀：工作的軟件和響應變化。”[Crispin09]

　　在實踐層面，探索式測試是評價產品的面向業務測試的主要手段[Crispin09]。在用戶故事和測試策略的指導下，測試人員會模擬真實用戶去測試系統。當一部分代碼被簽入，一部分用戶故事被實現后，測試人員就會探索新的區域，并逐步完善測試模型和測試策略。隨著測試人員對產品的了解，探索式測試不但可以彌補自動化測試的不足，還可以揭示出更有效的自動化測試區域，為自動化測試設計添磚加瓦。此外，探索式測試能夠發掘新情景(Scenario)，而這些情景往往會演變成新的用戶故事，從而在需求層面提高產品質量。

　　從術語的歷史看，“探索式測試”(Exploratory Testing，Cem Kaner提出于1983年)的歷史比“敏捷軟件開發”(Agile Software Development，敏捷宣言締結于2001年)更悠久。它們都是在描述已經長期存在但是沒有得到合適命名的思想及實踐：Cem Kaner用“探索式測試”來描述一種已經長期存在的測試思維，敏捷宣言的締造者們用“敏捷”來描述他們對軟件開發的共識。雖然這些思想來自不同的頭腦、實踐和社區，但是它們擁有相似的核心，并可以相互借鑒與補充。

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