探索性測試的18個總結

1）探索性測試放在測試執行，而指令碼化測試則更關注測試設計；2）前者更強調測試活動的並行和相互反饋（學習、設計、執行與結果分析等），而後者的測試活動是相對序列的。

2）指令碼化測試的主要優點是：1）盡早發現缺陷；2）不同利益相關者參與評審；3）可重用性；4）測試覆蓋率評估。

3）指令碼化測試強調測試的盡早介入，如盡早設計測試用例。但是測試人員越早設計測試用例，對測試物件的了解越少，對風險的了解也越少。測試人員對測試物件的了解是乙個逐步的過程，指令碼化測試需要更多的工作量以應對這個過程（需求的細化和變更等）。

4）提供測試物件的質量資訊是測試的乙個主要目的。但是不同的人對質量的理解是不一樣的，指令碼化測試能預先定義所有利益相關者的質量要求嗎？指令碼化測試能預先定義不同缺陷的**嗎？回答是不能。而這正是探索性測試引入的乙個初衷。

5）測試物件的需求是不斷變更的、不同開發人員會犯不同的錯誤、測試環境與組合也是不斷變化的，通過指令碼化測試很難及時跟蹤這些問題，即使能也需要考慮時間與成本。探索性測試的及時反饋與不斷修正是乙個解決之道。

6）「復現缺陷，並確定復現的具體步驟」、「下棋」、「刑偵現場」、「拼圖遊戲」等，其中的思維應該是探索性，還是指令碼化？哪個效率更高？

7）組織內引入探索性測試，需要測試人員掌握各種技術與方法、知識、技能與實踐，並以此為支撐，不是每天喊著這個概念就可以成功實施的。這個理念也同樣適用於敏捷開發與測試。車是好車，但是我們的路修好了嗎？

8）不管是文件化還是存在於測試人員的頭腦中，好的測試設計是什麼？好的測試設計應該是隨著測試環境不斷變化的（例如測試組合、測試環境），以不斷擴大測試覆蓋率，並將關注點放在高風險的區域。

9）不同的測試物件和測試目標，需要不同的測試策略和測試技術，而這將得到不同的測試用例、不同的測試文件與不同的測試結果。

10）探索性測試沒有指令碼化特點，並代表它是不做準備的，它也不是隨機的，而是提供更多的選擇。探索性測試同樣需要設計各種支撐性的內容：測試資料、失效模式、模型等。沒有測試計畫文件，也不代表探索性測試是沒有計畫的。

11）探索性測試如下象棋，其規則很簡單。但是我們在欣賞象棋比賽的時候，不會說：「啊，下象棋的規則真精彩！」相反，我們關注的是隱含在這些規則下選手選擇下一步如何走的技巧與技能，它的技術含量也不在其規則，而在選手的技巧與技能。規則簡單，技巧複雜。

12）探索性測試的學習、設計、執行與結果分析等測試活動是相對並行並且是相互支撐的，了解這個並不代表測試人員掌握了探索性測試。正如嬰兒學會了爬，並不代表就懂得了走、跑與跳等運動技能。

13）探索性測試過程中的乙個重要挑戰是如何設計測試用例（儘管不一定是指令碼化的，也可能是在測試執行的時候進行測試設計），例如：從測試技術到測試用例、從失效模式到測試用例、從風險列表到測試用例、從測試思想到測試用例。

14）從使用者現場反饋了乙個問題：他們在配置某個功能的時候，介面上列印了一些奇怪的資訊，然後系統就重啟了。此時測試人員更傾向於採用探索性測試，而面臨的首要挑戰就是「如何從失效模式設計測試用例」，以復現該問題。

15）探索性測試本身不是一種技術，而是一種測試方式或者思維。那麼，指令碼化測試應該是什麼呢？是技術？不是方式或者思維？

16）什麼使得測試活動具有探索性測試特點呢？答案在於測試人員的認知投入：測試人員如何應對持續變化的情況。

17）探索性測試不一定會有測試用例文件的輸出，這並不代表它沒有測試設計。探索性測試的設計不是為了控制，而是為了指導你的測試。

18）探索性測試更強調個人和互動，而不是過程和工具；更強調應對變化而不是遵循計畫；更強調可工作的軟體而不是可理解的文件；更強調相互合作而不是合同談判；從這個層面而言，探索性測試是敏捷的。

***********************************=分割線******************************==