反應測試（反應測試_humanbenchmark反應測試「建議收藏」）

反應測試_humanbenchmark反應測試「建議收藏」-反應測試human

反應測試_humanbenchmark反應測試「建議收藏」這兩天在重溫RexBlack寫的《軟件測試實踐》這本書，對其中反應測試方法有點體會，分享一下。這里借用了不少書中的術語。反應測試（reactivetest）是一種動態的測試方法，能夠發現邊界值、等價類和正交表等靜態測試方法可能遺漏的缺陷。做反應測試比較難的是這種測試方法會依賴于測試者的技能和直覺，來自相似應用的經驗，以及來自相似技術的經驗。在反應測試開始前，沒有預先進行高度細節化的設計，也就是說沒有具體的測試用例，這些測試用例都是在測試之中進行具體化的。說到這里，一

這兩天在重溫Rex Black 寫的《軟件測試實踐》這本書，對其中反應測試方法有點體會，分享一下。這里借用了不少書中的術語。

反應測試（reactive test）是一種動態的測試方法，能夠發現邊界值、等價類和正交表等靜態測試方法可能遺漏的缺陷。做反應測試比較難的是這種測試方法會依賴于測試者的技能和直覺，來自相似應用的經驗，以及來自相似技術的經驗。在反應測試開始前，沒有預先進行高度細節化的設計，也就是說沒有具體的測試用例，這些測試用例都是在測試之中進行具體化的。

說到這里，一定會有人認為反應測試就是探索測試或者隨機測試。但是不然，反應測試中的確包含了探索測試，但絕對不是隨機測試或者說是毫無計劃的即興測試。反應測試通常會使用到以下的方法：缺陷歸類法（bug taxonomy），一個常見的系統弱點或過去成功的攻擊的列表，一個缺陷圍獵方法（bug hunting）、一套測試章程（test charter）和一個清單（checklist）。

對反應測試的兩個挑戰是工作量和工作時間的估計和對測試覆蓋率的跟蹤。對于挑戰一，可以使用固定時間的方法，就是先初步的預估一個時間，按照這個時間去執行，然后根據執行的情況再去確定剩下的時間。例如安排了2個小時去測試一個功能點，在測試兩個小時后，根據發現的缺陷的數量來決定還需要多久的測試。這里先不討論挑戰二，因為下面的一些方法會解答這個問題。

還是需要說明的一點，反應測試不是隨機測試，它是有的放矢的，那么第一個方法就是缺陷歸類。通過測試者的經驗和對系統的熟悉，猜測可能會出現的缺陷，把這些缺陷在一個列表上記錄下來，那么攻擊（James Whittaker 《如何攻破軟件》中提出）就是對猜想的嘗試。如果以前有成功的攻擊列表當然也是可以借鑒的。

第二個方法就是缺陷圍獵。這個方法是建立第一步的基礎之上的，因為做完第一步，第二步才是有魚可捕，有鳥可獵。這個時候，你對缺陷的敏感可能會指引你從一個缺陷找到另外一個缺陷，就像聰明的獵人總是能從一只鳥找到一群鳥一樣。

第三個方法就是探索性測試。我個人覺得這是對第二個方法的具體的實施，探索式測試做起來可要比說起來難多了。因為探索性測試很容易讓測試者偏離測試的方向。

第四個方法就是清單。把你所做的反應測試用清單列出來，這樣就不至于陷入到為了找缺陷而找缺陷的陷阱中。測試不是為了找缺陷，而是幫助項目管理風險。所以可以把反應測試和預先設計，編寫好的測試用例結合執行。

最后打一個小小的比方，純屬杜撰。如果把測試方法比作一個幫派的武功的話，那邊界值和等價類就像是少林和武當的羅漢拳和八卦掌，那反應測試就像是楊過的黯然銷魂掌。