主要結(jié)論
　　1.測試自動(dòng)化是一種妥善記錄并具備清晰定義的方法，借此可以反復(fù)運(yùn)行同一套測試腳本。然而與此同時(shí)，這種測試自動(dòng)化腳本還可進(jìn)一步實(shí)現(xiàn)其他更有創(chuàng)意的應(yīng)用。
　　2.雖然自動(dòng)化的分析思維很難實(shí)現(xiàn)，但我們的腳本中無疑可以具備一定的隨機(jī)性。
　　3.測試中“隨機(jī)性”的具體程度各異：從隨機(jī)輸入和參數(shù)，再到全面的隨機(jī)測試用例，情況不一而足。
　　4.很難將隨機(jī)步驟與相應(yīng)的驗(yàn)證措施匹配起來，但我們可以使用不同的驗(yàn)證策略確保應(yīng)用程序能夠按照預(yù)期工作。
　　5.隨機(jī)測試無法取代主觀或傳統(tǒng)測試技術(shù)，但可在回歸測試過程中讓我們對應(yīng)用程序質(zhì)量更為自信。
　　正如Cem Kaner在他的一片教程中所說，探索式測試是一種強(qiáng)調(diào)個(gè)人自由度和個(gè)體測試人員責(zé)任的軟件測試方式，可通過將與測試有關(guān)的學(xué)習(xí)、測試設(shè)計(jì)、測試執(zhí)行，以及測試結(jié)果的理解視作一系列彼此提攜，在項(xiàng)目完整過程中并行執(zhí)行的活動(dòng)，借此對測試工作的成果進(jìn)行持續(xù)不斷的優(yōu)化。
　　簡而言之，按照他的定義，眾所周知的“軟件質(zhì)量和消費(fèi)者（Software Quality and Consumer）”主張為測試人員提供了在項(xiàng)目中按照自己認(rèn)為合適的方式進(jìn)行測試的自由和責(zé)任。循序漸進(jìn)地記錄所有規(guī)范，這種做法已經(jīng)不再是必須，原因也很簡單，創(chuàng)意過程基本式無法記錄的，對吧！在他在TestBash 3大會(huì)上有關(guān)測試中決策工作的演講中，Mark Tomlinson對系統(tǒng)的主觀理解這一想法表示支持。如果將其作為探索式的，基于風(fēng)險(xiǎn)和基于會(huì)話的測試技術(shù)（可將其稱之為主觀技術(shù)）的核心，測試者將能主觀地確定應(yīng)用程序中可能導(dǎo)致失敗的重要環(huán)節(jié)。
　　可以參看這張旋轉(zhuǎn)舞者的動(dòng)力學(xué)錯(cuò)覺示意圖：不同時(shí)刻內(nèi)，我們的大腦或判斷舞者以一個(gè)特定的順序旋轉(zhuǎn)：向左或向右。測試工作也會(huì)面臨類似情況：我們可能考慮使用不同流程實(shí)現(xiàn)相同結(jié)果，或相同流程導(dǎo)致雖不同但符合預(yù)期的結(jié)果，或者，嗯……任何其他結(jié)果。
　　整個(gè)測試執(zhí)行過程所用的主觀技術(shù)可以通過各種成熟的分析思維和“隨機(jī)性”的優(yōu)勢加以引導(dǎo)。其中后者是一個(gè)更重要的要素，本文，將揭露自動(dòng)化測試中“隨機(jī)化”的神秘面紗。
　　明確起見，測試自動(dòng)化并不是一種創(chuàng)作活動(dòng)，而是一種妥善記錄且清晰定義的方法，借此可以讓同一套測試腳本反復(fù)運(yùn)行使用。問題在于，我們該如何使用這些測試自動(dòng)化腳本，同時(shí)更更具創(chuàng)意？
　　產(chǎn)品質(zhì)量隨時(shí)間而變
　　產(chǎn)品質(zhì)量模型和所記錄的測試場景可通過特定的狀態(tài)機(jī)以及外部特性加以概括。這一點(diǎn)正是測試自動(dòng)化所熱愛的。測試自動(dòng)化所關(guān)注的正是根據(jù)一些非常具體的測試需求集編寫測試腳本。
　　這種做法很適合功能性回歸測試：清理、打磨、全新發(fā)布，隨后由開發(fā)大師創(chuàng)建。姑且將其稱之為Shiny吧。

　　但經(jīng)過一段冗長、精疲力竭的開發(fā)時(shí)間線后（伴隨著多次發(fā)布，長達(dá)數(shù)年的支持，數(shù)百個(gè)Bug的修復(fù)和功能請求等），系統(tǒng)會(huì)變成什么樣？

　　確實(shí)，從用戶接口的角度來看，可能非常類似于那種雖然老舊但依然工作良好的系統(tǒng)，但表面之下，這種情況通常被稱之為“大泥球”。
　　對于這樣的系統(tǒng)，算使用自動(dòng)化腳本，具體功能的哪些部分依然能獲得和初生產(chǎn)發(fā)布時(shí)同等程度的測試？也許只有30%-80%的部分可以吧。那么其他功能呢？不知道。
　　當(dāng)然，此時(shí)簡單的辦法可能是審查所有現(xiàn)有的質(zhì)量文檔，改良原有的場景，（即時(shí)）引入新的場景等。但考慮到業(yè)內(nèi)的經(jīng)驗(yàn)，隨著遺留系統(tǒng)的規(guī)則測試文檔逐漸過時(shí)，雖然更新工作依然重要，但這種做法并非總是可行。
　　為測試自動(dòng)化解決方案打造妥善定義的架構(gòu)
　　下圖是一個(gè)精簡的測試自動(dòng)化解決方案的范例圖，其中包含三層（類似于基于UI、業(yè)務(wù)邏輯和數(shù)據(jù)庫實(shí)現(xiàn)業(yè)務(wù)應(yīng)用程序的方法）：UI/API映射、業(yè)務(wù)裸機(jī)，以及測試腳本。

　　1.UI/API映射代表該解決方案的技術(shù)端：UI自動(dòng)化工具程度與自動(dòng)化系統(tǒng)的UI高度綁定，這一層所用的方法可能類似于focus()、type_text()、click_button()。
　　2.業(yè)務(wù)邏輯是一種由來自業(yè)務(wù)操作的關(guān)鍵字組成的庫。業(yè)務(wù)操作是指可以在應(yīng)用程序中執(zhí)行的某個(gè)步驟（如login()、create_user()、validate_user_created()）。
　　3.測試腳本負(fù)責(zé)執(zhí)行一系列鏈再一起的業(yè)務(wù)步驟。
　　深入了解獨(dú)立測試（Separate Test）
　　考慮這樣一種簡單的記錄測試用例：執(zhí)行這個(gè) – 驗(yàn)證這個(gè)，執(zhí)行那個(gè) – 驗(yàn)證那個(gè)，執(zhí)行某某 – 驗(yàn)證某某。合格的自動(dòng)化開發(fā)者會(huì)創(chuàng)建一系列類似下面這樣的方法：
　　do_that()， verify_that()， do_this()， verify_this()， do_bla().
　　測試腳本會(huì)按照某種特定的順序調(diào)用這樣的方法：
　　mySpecifiedCase_1(){
　　do_that();
　　verify_that();
　　do_this();
　　verify_this();
　　do_bla();
　　verify_that();
　　verify_this();
　　}