剛被派遣到諾基亞不久，確切地說是剛剛結束新員工入職培訓的時候，小組長問我對測試自動化是否 感興趣，我覺得好像蠻酷的，而且還可以被派到北京去參加兩天的培訓，英國人授課，何樂而不為呢。這個英國人就是Mark Fewster，《Software Test Automation》的作者，這本書被認為是該領域的開山之作，詳細地描述了測試自動化相關的所有細節、戰略和戰術。于是就這樣我加入了只有兩個人的兼職測試自動化小組，之所以成立這個小組是因為在國外的其他研發中心使用測試自動化的效果非常好，所以要把它引入到杭州的研發中心。
我們很快就接下第一個任務，將一些領域的回歸測試用例實現為自動化腳本，以便節省回歸測試所使用的時間和人力。產品線的測試自動化專家們已經做了一些工作，他們圍繞著我們所使用的測試工具，使用其腳本語言封裝出一個測試自動化框架。這個框架提供了若干庫（Library），使用庫所提供的函數可以快速地創建測試腳本，當有需要時我們也可以自己為庫開發一些新的函數。當然，只是這一點還算不得是框架，它還規定了測試腳本要遵循的格式，以及要使用的日志功能，以便生成格式比較統一的測試結果記錄和報告。甚至于它自己還有設計的測試腳本文件夾結構，通過一個特殊的INI文件及其內容來記錄測試腳本的執行管理。運行這個測試自動化框架，可以看到相應測試腳本庫下的所有測試腳本，并且可以配置要執行哪一些腳本。
跟隨著這個測試框架的，還有一些相應的測試自動化理論知識。我們將測試全過程看做五個部分：前置條件檢查；設置；執行；結果分析；清理及復原。所有的測試用例都是如此：首先，檢查測試用例可以執行的前置條件是否已被滿足，如果沒有，則退出測試不執行，例如系統中存在某個被測板塊；而后根據測試用例所需，將相關的資源或者環境設置到相應的狀態，例如將被測板塊設置到某個狀態或是創建一些資源；而后就是執行測試腳本，并且記錄執行的結果，同時需要對結果進行分析，除了每一個測試步驟要檢查之外，所有相關測試步驟執行完后也要檢查整個測試的結果；最后，在退出當前測試腳本的執行之前，它必須清理在設置階段所改變或增加的資源及其狀態，例如將被測板塊恢復到測試開始前的狀態，這一步非常必要，要做到執行或不執行當前測試腳本，留給后續測試腳本的被測系統環境都是一致的。不然的話，對于后續測試腳本來說，它們得到的測試環境將是不可預知的，運行腳本所得到的測試結果也是無法肯定的，如果腳本出錯了需要調試也會難以定位問題的根源。
多個測試用例會組成一個測試集合，這個五個部分同樣適用于測試集合層面：每一個測試集合都要檢查該集合中所有測試用例都關注的前置條件；也要進行共同都需要的設置，例如創建某個文件，以供測試用例驗證 該文件的各種操作是否正常；而后是執行測試集合，當然也包括對結果的分析以及生成報告；最后在退出測試集合的執行前，將設置階段所做的改變全部復位，以便后續測試集合得到當前測試集合相同的執行前環境。集合的集合，集合的集合的集合，循環往復，一直到整個產品線的所有測試用例集合，都適用這五個部分的模型。
在此過程中，我們的小組不斷地發展壯大，當然，依然是兼職狀態，吸納的都是感興趣的人，以及之前就在回歸測試工作組工作的人。于是我們開始面臨一些技術之外的問題，也即如何確保大家所寫出來的都是統一風格的測試腳本，都能夠知道如何開發出符合框架要求的測試腳本，如何使用框架運行測試腳本以及對測試運行進行管理，等等。同樣的，我們也需要考慮把測試的一些質量管理流程同樣的引入到測試自動化的工作中來，例如如何對測試腳本的開發進行評審和修訂，如何確保測試腳本的質量，如何確保每一個測試腳本自身都是一個原子操作，不會給后續的腳本留下爛攤子。
由于當時產品線整體正在將研發工作的主題轉移到杭州研發中心，這個測試自動化框架的用戶主題也將會變成杭州研發中心，于是管理層決定要在杭州尋找一個關鍵用戶（Key User）來管理這個框架，負責它的維護工作以及持續地開發。對這個框架有著極高熱情的我最終得到了這個機會，于是我也有了機會和足夠的時間可以去研究這個框架自身的設計原理。當然，框架本身也是用那個類C的腳本代碼實現的，而且代碼庫也都是內部公開的，所以即使我不是關鍵用戶，也可以學習它的設計原理，但是作為關鍵用戶還需要協調和處理多人并行開發過程中的很多問題。于是我們開發出了一些相關文檔和教程，幫助大家理解和使用這個框架，把它推廣到測試自動化小組之外的其他測試團隊，把普通的功能測試用例（不屬于回歸測試用例的集合）也納入到這個框架之中，統一地管理起來。由于框架自身的模塊化，功能測試腳本的開發人員可以省去許多重復函數代碼的開發，而且也不用再靠自己去處理信息記錄、結果分析和生成測試報告了。
人多了，就有不同的想法和看法，測試自動化的人員也一樣。測試自動化和開發的關系其實比它和測試的關系近多了，因為兩者都涉及到代碼。每個人寫的腳本代碼風格都不一樣，所以我們也有自己的（測試腳本代碼）編碼規范和命名規則等等一系列的規定。而我們作為測試自動化小組，在審核會議上著重觀察的則是測試腳本代碼，而不是測試用例的邏輯，或是測試計劃、報告之類的東西。
在此過程中，我們還要承擔評估測試自動化工具、框架的工作，除了這個內部自己開發的框架，我們也同時有考慮其他的商用工具，不同的工具各有優勢，例如有的工具集成了類似于實驗室環境管理的功能。但最終，在當時我們選擇了內部開發出來的這個框架，因為大家對它更熟悉，推廣使用它進行新腳本開發的成本相對更低，等等一些原因。
后來這些測試專家推薦給我們一個新的測試自動化框架，由另一個產品線的測試專家們開發出來，也是圍繞著公司的測試工具進行封裝。但他們的實現思路主要是沿著如今流行的DSL路線前進，他們希望將那些所有測試用例都會用到的操作封裝起來，作為一種無關具體實現技術（例如函數代碼）的調用。使用這個框架的測試人員無需去查閱那個類C腳本語言，只需要使用這個框架所提供的操作即可。不過由于種種已記不得的原因，這個框架并未流行開來。
相關鏈接：
我的軟件測試之旅：（1）起點——作為軟件開發人員
我的軟件測試之旅：（2）轉變——作為專職測試人員