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