主要結論
1.測試自動化是一種妥善記錄并具備清晰定義的方法，借此可以反復運行同一套測試腳本。然而與此同時，這種測試自動化腳本還可進一步實現其他更有創意的應用。
2.雖然自動化的分析思維很難實現，但我們的腳本中無疑可以具備一定的隨機性。
3.測試中“隨機性”的具體程度各異：從隨機輸入和參數，再到全面的隨機測試用例，情況不一而足。
4.很難將隨機步驟與相應的驗證措施匹配起來，但我們可以使用不同的驗證策略確保應用程序能夠按照預期工作。
5.隨機測試無法取代主觀或傳統測試技術，但可在回歸測試過程中讓我們對應用程序質量更為自信。
正如Cem Kaner在他的一片教程中所說，探索式測試是一種強調個人自由度和個體測試人員責任的軟件測試方式，可通過將與測試有關的學習、測試設計、測試執行，以及測試結果的理解視作一系列彼此提攜，在項目完整過程中并行執行的活動，借此對測試工作的成果進行持續不斷的優化。
簡而言之，按照他的定義，眾所周知的“軟件質量和消費者（Software Quality and Consumer）”主張為測試人員提供了在項目中按照自己認為合適的方式進行測試的自由和責任。循序漸進地記錄所有規范，這種做法已經不再是必須，原因也很簡單，創意過程基本式無法記錄的，對吧！在他在TestBash 3大會上有關測試中決策工作的演講中，Mark Tomlinson對系統的主觀理解這一想法表示支持。如果將其作為探索式的，基于風險和基于會話的測試技術（可將其稱之為主觀技術）的核心，測試者將能主觀地確定應用程序中可能導致失敗的重要環節。
可以參看這張旋轉舞者的動力學錯覺示意圖：不同時刻內，我們的大腦或判斷舞者以一個特定的順序旋轉：向左或向右。測試工作也會面臨類似情況：我們可能考慮使用不同流程實現相同結果，或相同流程導致雖不同但符合預期的結果，或者，嗯……任何其他結果。
整個測試執行過程所用的主觀技術可以通過各種成熟的分析思維和“隨機性”的優勢加以引導。其中后者是一個更重要的要素，本文，將揭露自動化測試中“隨機化”的神秘面紗。
明確起見，測試自動化并不是一種創作活動，而是一種妥善記錄且清晰定義的方法，借此可以讓同一套測試腳本反復運行使用。問題在于，我們該如何使用這些測試自動化腳本，同時更更具創意？
產品質量隨時間而變
產品質量模型和所記錄的測試場景可通過特定的狀態機以及外部特性加以概括。這一點正是測試自動化所熱愛的。測試自動化所關注的正是根據一些非常具體的測試需求集編寫測試腳本。
這種做法很適合功能性回歸測試：清理、打磨、全新發布，隨后由開發大師創建。姑且將其稱之為Shiny吧。
但經過一段冗長、精疲力竭的開發時間線后（伴隨著多次發布，長達數年的支持，數百個Bug的修復和功能請求等），系統會變成什么樣？
確實，從用戶接口的角度來看，可能非常類似于那種雖然老舊但依然工作良好的系統，但表面之下，這種情況通常被稱之為“大泥球”。
對于這樣的系統，算使用自動化腳本，具體功能的哪些部分依然能獲得和初生產發布時同等程度的測試？也許只有30%-80%的部分可以吧。那么其他功能呢？不知道。
當然，此時簡單的辦法可能是審查所有現有的質量文檔，改良原有的場景，（即時）引入新的場景等。但考慮到業內的經驗，隨著遺留系統的規則測試文檔逐漸過時，雖然更新工作依然重要，但這種做法并非總是可行。
為測試自動化解決方案打造妥善定義的架構
下圖是一個精簡的測試自動化解決方案的范例圖，其中包含三層（類似于基于UI、業務邏輯和數據庫實現業務應用程序的方法）：UI/API映射、業務裸機，以及測試腳本。
1.UI/API映射代表該解決方案的技術端：UI自動化工具程度與自動化系統的UI高度綁定，這一層所用的方法可能類似于focus()、type_text()、click_button()。
2.業務邏輯是一種由來自業務操作的關鍵字組成的庫。業務操作是指可以在應用程序中執行的某個步驟（如login()、create_user()、validate_user_created()）。
3.測試腳本負責執行一系列鏈再一起的業務步驟。
深入了解獨立測試（Separate Test）
考慮這樣一種簡單的記錄測試用例：執行這個 – 驗證這個，執行那個 – 驗證那個，執行某某 – 驗證某某。合格的自動化開發者會創建一系列類似下面這樣的方法：
do_that()， verify_that()， do_this()， verify_this()， do_bla().
測試腳本會按照某種特定的順序調用這樣的方法：
mySpecifiedCase_1(){
do_that();
verify_that();
do_this();
verify_this();
do_bla();
verify_that();
verify_this();
}
