時(shí)至今日，進(jìn)項(xiàng)目組已經(jīng)半年了，對(duì)自動(dòng)化測(cè)試也有了更深刻的認(rèn)識(shí)和理解。

為什么要進(jìn)行自動(dòng)化測(cè)試？要回答這個(gè)問(wèn)題，先了解一下測(cè)試背景。我們項(xiàng)目所使用的軟件開(kāi)發(fā)模型是agile，agile開(kāi)發(fā)的scrum模型，整個(gè)大項(xiàng)目分成一個(gè)個(gè)小team，每個(gè)team都有一個(gè)scrum master。Scrum master 根據(jù)每個(gè)人的情況安排任務(wù)，制定sprint plan。我們的測(cè)試有兩條線(xiàn)，一條是main line ，一條是branch line，平均每個(gè)sprint是一個(gè)月（22個(gè)工作日），差不多每周要出2個(gè)build，每個(gè)sprint大概4-7個(gè)build。版本迭代非常快，周期短；對(duì)于QA,每個(gè)人要負(fù)責(zé)至少一個(gè)component，每個(gè)component有200-400個(gè)case，每個(gè)case如果手工測(cè)需要2分鐘左右，再加上整理test summary,將測(cè)試結(jié)果上傳到ALM，時(shí)間往往不夠用。因此單純的依靠手工測(cè)試，workload 非常大，占用時(shí)間非常多，顯而易見(jiàn)；另外的一個(gè)問(wèn)題是regression，有很多情況下新發(fā)布的版本并未修改你所測(cè)component的code。當(dāng)然，除了workload的另外一個(gè)因素就是沒(méi)玩沒(méi)了的meeting，stand up meeting,各種on line meeting，無(wú)形中會(huì)影響一個(gè)人的工作進(jìn)度。這時(shí)候矛盾就凸顯出來(lái)，在人員有限，工作量很大的情況下，測(cè)試風(fēng)險(xiǎn)極大的情況下，急需一種解決方案—就是自動(dòng)化測(cè)試。

自動(dòng)化測(cè)試有什么好處：

a)        節(jié)省人力，只要代碼維護(hù)的好，不需要那么多人就可完成測(cè)試

b)        節(jié)省時(shí)間，測(cè)試腳本可以晚上或者是周末跑測(cè)試腳本

c)         優(yōu)化資源分配，在運(yùn)行測(cè)試腳本的同時(shí)，QA可以做其他事，比如設(shè)計(jì)新測(cè)試用例

d)        方便regression，極大提高效率

e)        增加軟件的可信度，測(cè)試是機(jī)器執(zhí)行的，排除了手工測(cè)試時(shí)因人為情緒而發(fā)生的隨意性或疏忽性，測(cè)試結(jié)果更可信

f)         能完成手工不易控制的工作，比如采集系統(tǒng)cpu占有率信息，手工計(jì)算很復(fù)雜，還要進(jìn)行數(shù)據(jù)比對(duì)，使用腳本更簡(jiǎn)單，更方便。

自動(dòng)化測(cè)試的缺點(diǎn)：

a)        腳本維護(hù)成本高，尤其是版本變動(dòng)比較大，對(duì)項(xiàng)目來(lái)說(shuō)，是潛在的風(fēng)險(xiǎn)

使用什么自動(dòng)化測(cè)試工具，對(duì)于client端的同學(xué)來(lái)說(shuō)，一般是QTP，而對(duì)于server端的，我們使用的是perl和shell寫(xiě)的自動(dòng)化測(cè)試框架。

原文鏈接：http://www.cnblogs.com/tobecrazy/archive/2012/12/18/2824248.html