軟件自動(dòng)化測試的推動(dòng)力

　　做過一個(gè)單元測試自動(dòng)化，我們開發(fā)了近百行的測試代碼去測試一個(gè)代碼行為10行的函數(shù);在UI測試自動(dòng)化，則調(diào)用了IE的COM接口去驅(qū)動(dòng)IE application，以模擬在界面上的兩個(gè)動(dòng)作，輸入“測所”和點(diǎn)擊“搜索”按鈕，總共9行代碼(如果考慮自動(dòng)化健壯性的話，還要增加錯(cuò)誤處理代碼)。

　　觀察到這些，我們暫且不考慮自動(dòng)化測試開發(fā)之后的維護(hù)，至少可以有一個(gè)直觀的認(rèn)識：從手工測試向自動(dòng)化測試的轉(zhuǎn)變是要付出的成本的，而且這個(gè)投入要遠(yuǎn)比做一次手工測試的代價(jià)要高，比如，一個(gè)有經(jīng)驗(yàn)的自動(dòng)化測試開發(fā)人員完成一段健壯的100行左右的測試腳本大概需要左右的時(shí)間，而手工完成這個(gè)功能點(diǎn)的測試則只需要10分鐘。 VS十分鐘，按理說，這是一個(gè)賠本的買賣，但為什么還有這么多的軟件企業(yè)對測試自動(dòng)化情有獨(dú)鐘呢?排除一些盲目跟風(fēng)，試圖提高測試技術(shù)含金量的情感因素，至少有以下幾個(gè)理性的現(xiàn)實(shí)驅(qū)動(dòng)力。

　　1. 測試自動(dòng)化主要是做長線投資，而非一時(shí)之計(jì)

　　顯而易見地，開發(fā)一個(gè)程序，只為了運(yùn)行一次自動(dòng)化測試是非常不劃算的。那么要想能收回開發(fā)自動(dòng)化測試的投資，要盡可能多地運(yùn)行測試程序，每多運(yùn)行一次，會(huì)多節(jié)省一份手工測試工作量。這個(gè)簡單的道理可以說明為什么如今測試自動(dòng)化應(yīng)用多的是回歸測試階段。由于回歸測試往往是驗(yàn)證軟件bug的fix或者軟件補(bǔ)丁的有效性，理論上，每一次bug的修復(fù)，都需要進(jìn)行一次全面回歸測試。如下圖所示。

　　這樣在軟件測試流程里，回歸測試包括在測試分支(Test Branch)上進(jìn)行的bug驗(yàn)證測試，還有在發(fā)布分支(Release Branch)上進(jìn)行的補(bǔ)丁更新測試(在實(shí)際的企業(yè)實(shí)踐中，發(fā)布分支的更新遠(yuǎn)遠(yuǎn)比圖中頻繁)，這樣回歸測試的重復(fù)性非常高，而且持續(xù)時(shí)間長，直到軟件在市場上的退出才結(jié)束。這對于手工測試人員來說，可以說是一個(gè)對耐心和毅力的巨大考驗(yàn)，再美好有趣的事情如果天天重復(fù)去做，而不做任何變化，終也會(huì)成為枯燥乏味的代名詞。所以手工測試人員是有愿望通過自動(dòng)化測試來改變現(xiàn)狀的。這為回歸測試自動(dòng)化的實(shí)施同時(shí)提供了主觀的動(dòng)機(jī)和客觀需求。

　　【案例】：

　　一些有經(jīng)驗(yàn)的軟件測試團(tuán)隊(duì)通常會(huì)采用一些激勵(lì)或游戲規(guī)則來增加回歸測試的趣味性，我曾看過一個(gè)TOP500的軟件企業(yè)里的測試部門，每隔一段時(shí)間會(huì)由高層發(fā)起一個(gè)“蟲子打獵”(Bug hunting)的活動(dòng)，通常在一個(gè)不太繁忙的周五午后，通知郵件一發(fā)出，全體部門立即行動(dòng)，不論職務(wù)高低，不分經(jīng)理，工程師，紛紛赤膊上陣。為了找到獵物，每人都各顯神通，盡可能地設(shè)計(jì)一些平時(shí)想不到的測試場景去尋找軟件里的bug，但有一個(gè)前提條件，是他不能測試自己本來負(fù)責(zé)的系統(tǒng)模塊，必須去測試別人的而且他不熟悉的的模塊。比如小張是負(fù)責(zé)測Email的，那他在這次活動(dòng)中，偏偏要去測試Messenger;測試messenger的小李這次又要去測試calendar，這完全是一個(gè)網(wǎng)狀交叉的測試。打獵活動(dòng)結(jié)束后，高層還要召開“慶功會(huì)”，評定出“好的bug”，“有創(chuàng)意的bug”等等稱號，雖然沒有獎(jiǎng)金，但是每個(gè)獲得榮譽(yù)的人都會(huì)倍感自豪。而且，對于團(tuán)隊(duì)來說，打獵活動(dòng)收到成效也是顯著的，是一舉三得的好事情。

　　第一，交叉測試會(huì)找到以往被忽略的bug。

　　第二，熟悉不同模塊，測試人員將來可以在工作中互為備份。

　　第三，增強(qiáng)了團(tuán)隊(duì)凝聚力，并激發(fā)對測試工作的熱情。

　　2. 測試自動(dòng)化可以隨時(shí)觸發(fā)運(yùn)行

　　測試自動(dòng)化一旦開發(fā)完成，可以在任何時(shí)間被觸發(fā)運(yùn)行，而沒有下班或的概念，測試人員完全可以在下班之前觸發(fā)某個(gè)自動(dòng)化開關(guān)，把測試任務(wù)移交給自動(dòng)化腳本，然后經(jīng)過一夜的運(yùn)行，第二天早上上班來查看自動(dòng)化測試報(bào)告，這是自動(dòng)化的獨(dú)特優(yōu)勢所在。從這個(gè)意義上講，測試自動(dòng)化延伸了手工測試的工作時(shí)間和范圍。

　　3. 測試自動(dòng)化有助于知識的存儲和移交

　　這是一個(gè)潛在的事實(shí)，在以前的手工測試一統(tǒng)天下的時(shí)候，測試人員的知識主要是靠文檔存儲，比如測試計(jì)劃，測試案例說明書，bug數(shù)據(jù)庫等等。因此，我們看到，當(dāng)一個(gè)測試工程師離職的時(shí)候，他會(huì)把他的知識以文檔的方式留給原來的團(tuán)隊(duì)。而隨著自動(dòng)化測試的發(fā)展，這種測試知識的形式也在發(fā)生變化，測試人員的技術(shù)可以通過測試程序保留下來。對整個(gè)測試團(tuán)隊(duì)來說，能夠量化共享的知識越多，團(tuán)隊(duì)越穩(wěn)定，受到個(gè)體測試人員的影響越少。這是老板愿意看到的場面，因此，從這個(gè)角度來說，測試經(jīng)理比測試工程師更有動(dòng)力去推動(dòng)軟件測試自動(dòng)化。

　　4. 第三方自動(dòng)化測試工具的使用提高了自動(dòng)化測試開發(fā)的效率

　　如果說前三點(diǎn)已經(jīng)講清了自動(dòng)化測試的合理性動(dòng)機(jī)，那么自動(dòng)化測試工具的應(yīng)用則為自動(dòng)化測試實(shí)施提供了保障，使得做自動(dòng)化測試不在那么困難和復(fù)雜，而變得簡單和有效率。

　　使用Junit來完成案例一

　　import junit.framework.TestCase;

　　public class funTest extends TestCase {

　　protected void setUp() throws Exception {

　　super.setUp();

　　}

　　protected void tearDown() throws Exception {

　　super.tearDown();

　　}

　　public void testFun() throws Throwable {

　　//調(diào)用被測函數(shù)

　　int i = Fun(2);

　　//使用junit提供的assert斷言語句比較結(jié)果

　　assertTrue(1，i);

　　}

　　}

　　在以上代碼中， funTest類，以及funTest類的setup函數(shù)和teardown函數(shù)(環(huán)境回收工作)是由Junit自動(dòng)生成的，我們寫的測試程序只有2條語句，其中斷言語句assertTrue會(huì)通過比較，給出pass還是fail的結(jié)果報(bào)告。可以看出，使用Junit工具幫我們減少了自動(dòng)化測試開發(fā)的工作量。

　　使用QTP來完成案例二，如下：

　　使用QTP錄制同樣的google搜索操作，只有兩條語句生成：

　　Browser(”Google”).Page(”Google”).WebEdit(”q”).Set “測所”

　　Browser(”Google”).Page(”Google”).WebButton(”Google 搜索”).Click

　　其中Browser，page，webEdit，webbutton都是QTP提供的對象，操作起來非常直觀方便。