題記：今晚一個(gè)人跑到杭州窩在賓館無(wú)所事事，也睡不著，就把這幾天來(lái)關(guān)于自動(dòng)化測(cè)試的探討記錄下來(lái)，也給自己一個(gè)機(jī)會(huì)，逼著自己好好反思這一年多來(lái)關(guān)于自動(dòng)化測(cè)試的點(diǎn)滴。其實(shí)，我也只是接觸過(guò)兩套自動(dòng)化框架，一是項(xiàng)目組開(kāi)發(fā)、設(shè)計(jì)出來(lái)的，在這個(gè)從無(wú)到有的過(guò)程中，我學(xué)到了很多。其二便是學(xué)習(xí)的Robot Framework，它告訴我一個(gè)優(yōu)秀的自動(dòng)化框架應(yīng)該具備些什么。
都講自動(dòng)化測(cè)試開(kāi)發(fā)，當(dāng)然要把開(kāi)發(fā)自動(dòng)化測(cè)試框架也當(dāng)做一個(gè)項(xiàng)目來(lái)做。這時(shí)候，就需要考慮應(yīng)該選擇何種類(lèi)型的自動(dòng)化測(cè)試框架：數(shù)據(jù)驅(qū)動(dòng)、關(guān)鍵字驅(qū)動(dòng)、還是Junit，TestNG ？ 抑或直接利用現(xiàn)有的開(kāi)源自動(dòng)化測(cè)試框架，如Robot Framework 。無(wú)法講這幾種類(lèi)型的框架，孰優(yōu)孰劣，關(guān)鍵是認(rèn)清項(xiàng)目實(shí)際，選擇最適合的。講一些題外話(huà)，就Java學(xué)習(xí)者而言，Junit3.x的源碼是再好不過(guò)的教材了，JUnit框架運(yùn)用到了大量的設(shè)計(jì)模式，反射機(jī)制。
在決定了選用何種自動(dòng)化框架類(lèi)型后，下面你需要抉擇的就是：應(yīng)該選擇何種編程語(yǔ)言呢？編程語(yǔ)言的選擇和開(kāi)發(fā)者的技術(shù)背景有很大關(guān)系，一般都會(huì)選擇自己熟悉的編程語(yǔ)言，但這也往往是個(gè)局限。另一方面，也受到SUT的影響。一般而言，很少見(jiàn)有選擇C，C++作為自動(dòng)化框架開(kāi)發(fā)語(yǔ)言的，雖然這兩種語(yǔ)言的執(zhí)行效率要高，但開(kāi)發(fā)效率要低一些。我們項(xiàng)目的自動(dòng)化框架是Java語(yǔ)言編寫(xiě)的，關(guān)鍵字也是由Java實(shí)現(xiàn)的。關(guān)鍵字的實(shí)現(xiàn)選擇Java，是由于SUT - 即Domino服務(wù)器提供的API是有Java ，C++。所以自然選擇了Java。而自動(dòng)化框架開(kāi)發(fā)語(yǔ)言的選擇，其實(shí)可以有別的選擇，如腳本語(yǔ)言Python ，Perl。腳本語(yǔ)言Python，或Perl，作為超高級(jí)開(kāi)發(fā)語(yǔ)言，解釋執(zhí)行的特性，在開(kāi)發(fā)效率上可能會(huì)高一點(diǎn)。
下面就是關(guān)鍵字實(shí)現(xiàn)方式的選擇了。關(guān)鍵字就相當(dāng)于手動(dòng)執(zhí)行測(cè)試用例當(dāng)中的一個(gè)步驟，比如現(xiàn)在的項(xiàng)目，即一個(gè)關(guān)鍵字就是修改產(chǎn)品的一個(gè)配置選項(xiàng)，也可以是發(fā)一封帶有特定附件的郵件。就我們的產(chǎn)品而言，Domino提供的操作數(shù)據(jù)庫(kù)的方式有三種，即DIIOP、Web Services和本地調(diào)用。剛開(kāi)始選擇的是DIIOP，這種方式實(shí)現(xiàn)起來(lái)比較簡(jiǎn)單，后來(lái)發(fā)現(xiàn)通過(guò)這種方式實(shí)現(xiàn)的自動(dòng)化腳本，即包含十幾個(gè)關(guān)鍵字腳本，其執(zhí)行時(shí)間大概要35s – 40s。而Web Services的執(zhí)行時(shí)間就要效率就要高得多，差不多一個(gè)自動(dòng)化腳本的執(zhí)行時(shí)間可以縮短10s， 但其實(shí)現(xiàn)需要分為服務(wù)器端Web Service的發(fā)布，和客戶(hù)端的調(diào)用，通過(guò)這種方式實(shí)現(xiàn)，測(cè)試環(huán)境的部署也要復(fù)雜些。講這些，主要是告訴我們，一開(kāi)始就需要對(duì)這些做出評(píng)估，選擇合適的方案，不然中途改變，影響是很大的。
自動(dòng)化框架，說(shuō)白了就是流程的封裝啦。那么一個(gè)自動(dòng)化框架應(yīng)該包括哪些流程呢？來(lái)看看下面這兩幅框架圖吧。
第一幅圖講解了一套自動(dòng)化測(cè)試是由自動(dòng)化框架，自動(dòng)化腳本，關(guān)鍵字組成的。第二幅圖描述了自動(dòng)化框架的流程：根據(jù)配置挑選要執(zhí)行的測(cè)試用例，解析自動(dòng)化執(zhí)行腳本，將自動(dòng)化執(zhí)行腳本送給自動(dòng)化執(zhí)行引擎，生成Log文件，最后生成Report。
對(duì)比Robot Framework框架，這套簡(jiǎn)單的自動(dòng)化框架有哪些地方可以提高呢？第一個(gè)，基于Test Suit的setup和teardown。一個(gè)自動(dòng)化腳本的組成是這樣的：清理、初始化測(cè)試環(huán)境（如，建立一些測(cè)試腳本需要用到的數(shù)據(jù)庫(kù)）， 執(zhí)行自動(dòng)化腳本，生成執(zhí)行結(jié)果，最后清空環(huán)境。這些步驟我們的自動(dòng)化腳本中也實(shí)現(xiàn)的，但如果想在執(zhí)行一批測(cè)試用例之前，做一些動(dòng)作，執(zhí)行完以后，在清空，我們用得方式就是把這些自動(dòng)化腳本的名字在要執(zhí)行的一批測(cè)試腳本之前，我們的腳本是按字母排序的，這樣確保的。其實(shí)應(yīng)該有更好的方式。第二個(gè)，自動(dòng)化腳本中有關(guān)鍵字Fail了，是否還需要接著執(zhí)行下面的關(guān)鍵字呢。我們框架式會(huì)繼續(xù)執(zhí)行，但Robot Framework做到了可配置，它是通過(guò)listern來(lái)實(shí)現(xiàn)的。可以好好學(xué)習(xí)下。
自動(dòng)化框架、關(guān)鍵字的開(kāi)發(fā)周期怎么安排，怎么預(yù)估effort ？項(xiàng)目自動(dòng)化測(cè)試框架，自動(dòng)化腳本開(kāi)發(fā)也分成了兩Iteration。 第一個(gè)迭代期間，完成自動(dòng)化框架主要流程，完成主要關(guān)鍵字，構(gòu)建SMOKE部分的自動(dòng)化腳本。第二次迭代，進(jìn)一步完善自動(dòng)化框架，接著添加關(guān)鍵字，完成Regression部分自動(dòng)化腳本。剛開(kāi)始，effort的估計(jì)沒(méi)有把握，因?yàn)橛行╆P(guān)鍵字的實(shí)現(xiàn)可能比較困難，這時(shí)候需要及時(shí)sync風(fēng)險(xiǎn)。第二個(gè)階段，effort的估計(jì)就有底了。
如何協(xié)同開(kāi)發(fā)？自然是加入版本控制。現(xiàn)在的自動(dòng)化框架用的版本控制是Git，這個(gè)比較火哦！多人協(xié)同開(kāi)發(fā)，提交代碼，肯定會(huì)有conflict。我們的做法是這樣的，除了master分支，每個(gè)人在自己本地建個(gè)開(kāi)發(fā)分支，每次提交代碼前，先從Git Server上checkout最新代碼到master分支，然后，在本地的開(kāi)發(fā)分支和master分支merge，最后commit代碼。
自動(dòng)化腳本如何命名？我們的自動(dòng)化腳本都是從手動(dòng)測(cè)試用例挑選出來(lái)的，我們希望做到自動(dòng)化腳本和手動(dòng)腳本之間有個(gè)關(guān)聯(lián)，但同時(shí)又要做到，只要看到這個(gè)自動(dòng)化腳本的Title，就能知道這個(gè)自動(dòng)化腳本的大概的測(cè)試意圖。我們是這樣做的，ModuleName_FilterName+ID， 這個(gè)ID便是手動(dòng)測(cè)試用例的Define ID。
Keyword的粒度怎么把握？關(guān)鍵字相當(dāng)于手動(dòng)執(zhí)行的一個(gè)執(zhí)行步驟，我們是這樣做的，首先Review手動(dòng)執(zhí)行的測(cè)試用例，抽取出通用的步驟，實(shí)現(xiàn)關(guān)鍵字。但如果關(guān)鍵字的粒度做得太細(xì)，那么關(guān)鍵字的數(shù)量會(huì)比較龐大，但粗了的話(huà)，關(guān)鍵字參數(shù)的形式就會(huì)比較復(fù)雜，對(duì)于構(gòu)造自動(dòng)化腳本的同事來(lái)說(shuō)，就需要學(xué)習(xí)。這個(gè)粒度需要把握好，同時(shí)，對(duì)于自動(dòng)化關(guān)鍵字參數(shù)，需要有詳盡注釋?zhuān)褂酶袷椒独?/p>
自動(dòng)化腳本中的變量如何維護(hù)？一般會(huì)把自動(dòng)化腳本中的一些跟執(zhí)行環(huán)境相關(guān)的參數(shù)以變量的形式抽取出來(lái)，存放在配置文件里，這樣一來(lái)，在部署自動(dòng)化測(cè)試環(huán)境的時(shí)候，就只需要修改這些跟環(huán)境相關(guān)的配置文件即可以。但這個(gè)配置文件會(huì)隨著自動(dòng)化測(cè)試用例的增加，而變得臃腫。
自動(dòng)化腳本中運(yùn)行結(jié)果如何判斷？自動(dòng)化測(cè)試腳本，如同手動(dòng)執(zhí)行測(cè)試用例一般，也有預(yù)期結(jié)果，實(shí)際結(jié)果的比對(duì)，如果兩則不一致，則認(rèn)為這個(gè)自動(dòng)化腳本Fail。剛開(kāi)始我們是這樣做的，將預(yù)期結(jié)果一參數(shù)的形式傳給一個(gè)關(guān)鍵字，這個(gè)關(guān)鍵字在后臺(tái)會(huì)比較實(shí)際結(jié)果，如果不一致fail。剛開(kāi)始也覺(jué)得沒(méi)問(wèn)題，后來(lái)發(fā)現(xiàn)，因?yàn)榄h(huán)境因素，一些預(yù)期結(jié)果是會(huì)發(fā)生變化的，這時(shí)候，我們必須修改自動(dòng)化腳本。后來(lái)的做法是這樣的，先dump出一份預(yù)期結(jié)果，存放在本地，執(zhí)行自動(dòng)化自動(dòng)化腳本的時(shí)候，再Dump出一份實(shí)際結(jié)果，然后比對(duì)這二者。這樣就避免了頻繁改動(dòng)自動(dòng)化執(zhí)行腳本了。
執(zhí)行結(jié)果的容錯(cuò)性？如何確保執(zhí)行結(jié)果是可靠的，在自動(dòng)化關(guān)鍵字的實(shí)現(xiàn)過(guò)程中，會(huì)加入一些容錯(cuò)機(jī)制。舉個(gè)簡(jiǎn)單的例子，發(fā)一封帶特性附件的郵件，命中了一個(gè)策略。這時(shí)候，會(huì)在log數(shù)據(jù)庫(kù)中產(chǎn)生一條記錄。在實(shí)現(xiàn)自動(dòng)化關(guān)鍵字的時(shí)候，可能會(huì)遇到這樣的情況，當(dāng)你去檢查log數(shù)據(jù)庫(kù)的時(shí)候，很有可能那條log記錄還沒(méi)生成好，這時(shí)候如果直接判斷，自然會(huì)fail。我們是怎么提高容錯(cuò)性的呢？很簡(jiǎn)單的方法，就是加入了一定時(shí)間的延時(shí)，比如循環(huán)檢查多少次，每次delay一秒等方法，這就帶來(lái)了另一問(wèn)題，在執(zhí)行時(shí)間會(huì)延長(zhǎng)。
及時(shí)獲取RD幫助。在實(shí)現(xiàn)DLP功能時(shí)，發(fā)現(xiàn)程序重新載入配置會(huì)比較耗時(shí)，如果自動(dòng)化腳本不能重新載入完成，就發(fā)郵件的話(huà)，是無(wú)法命中你的配置策略的。這時(shí)候，需要尋求RD幫助，他們?cè)诤笈_(tái)提供了hidden key。當(dāng)enable這個(gè)hidden key后，重新載入完成后，程序會(huì)在console上打印出提示信息，這時(shí)候，我們的自動(dòng)化腳本只需要去檢查這些提示信息有沒(méi)有生成，就可以判斷是否重載完成，再發(fā)郵件。
在自動(dòng)化測(cè)試開(kāi)發(fā)，維護(hù)過(guò)程中，成本最大的是什么？覺(jué)得一方面是測(cè)試數(shù)據(jù)的維護(hù)。另一方是因?yàn)楫a(chǎn)品功能方面的變動(dòng)引入的自動(dòng)化腳本需要修改方面的成本。
自動(dòng)化測(cè)試的應(yīng)用場(chǎng)景？對(duì)于項(xiàng)目而言，最大的價(jià)值是什么？就我們項(xiàng)目而言，主要還是把手動(dòng)測(cè)試用例變?yōu)樽詣?dòng)化測(cè)試用例，也就是所謂的黑盒、功能性自動(dòng)化實(shí)施。當(dāng)初定位的時(shí)候，也是想做成自動(dòng)化回歸測(cè)試的，縮短回歸測(cè)試時(shí)間，提高回歸測(cè)試效率，確保代碼優(yōu)化、及新引進(jìn)的代碼不會(huì)影響舊有功能。也沒(méi)指望自動(dòng)化測(cè)試能發(fā)現(xiàn)手動(dòng)測(cè)試發(fā)現(xiàn)不了的問(wèn)題。理想的狀態(tài)時(shí)這樣的，自動(dòng)化測(cè)試和CI系統(tǒng)集成，當(dāng)出了一個(gè)新的build，自動(dòng)化框架能夠自動(dòng)安裝新build，執(zhí)行自動(dòng)化腳本，完了以后將執(zhí)行結(jié)果通過(guò)郵件發(fā)布出來(lái)。
有沒(méi)有方法把關(guān)鍵字的實(shí)現(xiàn)提前？而不是等到功能穩(wěn)定后，再開(kāi)始做自動(dòng)化。看過(guò)Junit中的mock的概念，但具體怎么做，還不清楚，下階段學(xué)習(xí)下！
現(xiàn)在看來(lái)，一套自動(dòng)化測(cè)試的開(kāi)發(fā)也涉及到：項(xiàng)目本身需求分析、hight-level 設(shè)計(jì)、框架開(kāi)發(fā)、自動(dòng)化腳本實(shí)現(xiàn)、各種規(guī)則制定、多方面協(xié)作等，所以需要把自動(dòng)化測(cè)試開(kāi)發(fā)當(dāng)做項(xiàng)目來(lái)做哦！