如何做好軟件系統(tǒng)自動化測試

測試分類

系統(tǒng)級測試一般指對交付的系統(tǒng)進(jìn)行端到端的測試拾酝，驗證系統(tǒng)是否滿足所有功能和非功能需求。

一般而言卡者，系統(tǒng)測試是整個測試實踐最重要的蒿囤，但也是成本最大的測試。為了讓系統(tǒng)測試能夠有效并且低成本崇决，我們先來看看系統(tǒng)測試在整個測試象限中的位置和分類材诽。

如上在敏捷測試四象限，將所有測試實踐分為四大類恒傻。上圖中橫軸從支持團(tuán)隊變化到評價產(chǎn)品脸侥，縱軸從面向技術(shù)變化到面向業(yè)務(wù)。

Q1：面向技術(shù)和支持團(tuán)隊盈厘；這一象限中主要包含單元測試和組件測試睁枕。該象限中的測試幫助團(tuán)隊獲得代碼級別的快速反饋，一般借助xUnit測試框架，要求完全自動化外遇。
O2：面向業(yè)務(wù)和支持團(tuán)隊注簿；這一象限中包含功能測試，原型測試和仿真測試等跳仿。該象限中的測試大多也可以自動化诡渴，但是需要借助面向領(lǐng)域?qū)ｉT的測試工具。一般是否自動化菲语，取決于是否有低成本的系統(tǒng)級別自動化功能測試工具妄辩。
Q3：面向業(yè)務(wù)和評價產(chǎn)品；這一象限中包含探索性測試山上、可用性測試等等恩袱。探索性測試指靠測試人員的主觀發(fā)揮去探索系統(tǒng)潛在的故障，該象限中其它的則測試偏重于客戶主觀感受胶哲，所以以手工測試為主。
Q4：面向技術(shù)和評價產(chǎn)品潭辈；該象限一般包括非功能測試鸯屿，例如性能測試、壓力測試等把敢。非功能測試一般需要依靠專門的測試工具寄摆，能否自動化取決于性能工具天生是否對自動化有效的支持。

從上面的分類可見修赞，系統(tǒng)級別測試包含上圖中的Q2婶恼、Q3、Q4象限中的所有測試柏副。還可以將系統(tǒng)級別測試按如下維度劃分：

測試類型

功能測試：對系統(tǒng)功能進(jìn)行驗收的測試勾邦，包括用戶驗收測試、探索測試割择、A/B測試等眷篇；主要分布在Q2、Q3象限荔泳。
性能測試：指非功能性測試蕉饼，包含性能測試、壓力測試等玛歌；主要分布在Q4象限昧港。

測試方式

自動化測試：包含Q2中容易自動化的功能測試，以及Q4中測試工具支持自動化運(yùn)行的非功能性測試部分支子。
手工測試：主要針對Q3中的探索性測試创肥，以及以客戶主觀感受進(jìn)行對比和驗收的測試用例。

測試策略

經(jīng)過了前面對系統(tǒng)級測試的分類，我們看到有些測試是必須手動測試的瓤的，這些測試是自動化測試替代不了的休弃。

對于可以進(jìn)行自動化的測試，我們需要利用自動化的優(yōu)勢來降低測試成本圈膏，加快反饋周期塔猾。

對于一些依靠專有工具進(jìn)行測試的，我們期望可以改造工具稽坤，逐漸將其自動化丈甸。

如下我們按照功能測試和非功能測試的分類，分別談一下其中可以實施自動化部分的測試策略尿褪。

功能測試

功能測試原則上需要針對系統(tǒng)要完成的功能點逐一進(jìn)行遍歷測試睦擂，一般我們稱其為驗收測試。當(dāng)代碼發(fā)生修改杖玲，功能驗收測試需要做回歸顿仇，以確保修改的代碼沒有破壞系統(tǒng)功能。

由于功能驗收測試需要頻繁的運(yùn)行和回歸摆马，所以這類測試需要盡快通過自動化來降低測試成本臼闻。取代人工回歸測試的自動化測試可以釋放人力，讓測試人員把主要精力放在非機(jī)械性的需要創(chuàng)造性的探索性測試上囤采。

由于越偏向業(yè)務(wù)述呐，測試的獨特性就越強(qiáng)，所以自動化功能測試工具一般需要自行開發(fā)蕉毯。

好的消息是對于功能測試來說乓搬，測試用例編寫、調(diào)度代虾、報表生成的部分基本是通用的进肯，所以可以找到不少開源的功能測試框架。但是這類測試框架一般不面向任何領(lǐng)域褐着，只是完成通用的功能并且為擴(kuò)展留好了接口坷澡，由使用者根據(jù)自己的領(lǐng)域?qū)ぞ哌M(jìn)行擴(kuò)展。

常用的功能驗收測試框架有Cucumber和Robot Framework含蓉。這兩款工具對比如下：

	Cucumber	Robot Framework
功能	? 使用自然語言频敛，更易讀 ? 支持表格參數(shù) ? 支持多種格式的 ? 支持多種語言 ? 支持四種狀態(tài)的測試步驟：Passed、Failed馅扣、Skipped斟赚、Pending ? 支持使用變形器消除重復(fù)	? 使用關(guān)鍵字的機(jī)制，更容易上手 ? 提供了RIDE差油，對于不熟悉編碼的人來說比較友好 ? 能夠精細(xì)的控制關(guān)鍵字的scope ? Log和Report非常好 ? 使用變量文件的機(jī)制來描述不同的環(huán)境 ? 豐富的關(guān)鍵字庫 ? 內(nèi)置變量
擴(kuò)展語言	ruby	python拗军、java
不足	用例風(fēng)格單一任洞，只支持BDD風(fēng)格	沒有cucumber輕量
Jenkins支持	支持	支持
開發(fā)效率	可集成IDE開發(fā)，效率高	可集成IDE開發(fā)发侵，效率高
社區(qū)支持	廣泛	廣泛

如上交掏，兩款常用的功能驗收測試框架使用都很廣泛。Robot Framework相比較重量一些刃鳄，但是支持的擴(kuò)展方式多盅弛，而且測試用例風(fēng)格不局限于BDD（行為驅(qū)動測試）風(fēng)格，對傳統(tǒng)測試人員比較友好叔锐。而大量的新的web應(yīng)用開發(fā)者則更鐘情于Cucumber挪鹏，具體需要根據(jù)自己項目的實際情況進(jìn)行選擇。

無論是選擇上述哪種測試框架愉烙，針對領(lǐng)域進(jìn)行擴(kuò)展是避免不了的讨盒。

如上圖，從測試框架到被測系統(tǒng)之間步责，需要使用者去編寫測試支撐庫返顺。這些支撐庫和使用者的測試具體特征有關(guān)。例如對需要通過收發(fā)消息來測試的系統(tǒng)蔓肯，就要根據(jù)消息協(xié)議開發(fā)具體的測試支撐庫创南，以支持訪問被測系統(tǒng)。對于常用的功能省核，都可以直接找到別人開發(fā)好的測試支撐庫。例如Robot Framework就已經(jīng)自帶了常用的telnet昆码，ssh气忠，xml等庫，而使用者特殊的產(chǎn)品功能一般都需要自行開發(fā)支撐庫赋咽。

另外為了讓測試用例容易編寫可讀性強(qiáng)旧噪，還需要編寫支撐測試用例編寫的庫∨洌框架在這方面會提供一些基本的支撐機(jī)制淘钟。例如Robot Framework支持關(guān)鍵字驅(qū)動的測試用例編寫，框架已經(jīng)提供了常用的關(guān)鍵字陪毡，但是和使用者領(lǐng)域相關(guān)的關(guān)鍵字還需要自行開發(fā)米母。

如上可見，系統(tǒng)級別的自動化功能測試是需要花一些精力的毡琉。但是以作者的經(jīng)驗铁瞒，一旦在這方面取得突破，整個組織的敏捷性會提高一大步桅滋，這些付出還是值得的慧耍。

非功能測試

通過前面的介紹我們看到身辨，非功能測試一般是需要借助專門的工具進(jìn)行。例如性能測試芍碧，一般需要由專門的工具來制造負(fù)荷和壓力煌珊。對于成熟常見的領(lǐng)域，一般可以找到免費(fèi)的工具使用泌豆。例如對于互聯(lián)網(wǎng)web服務(wù)器的性能和壓力測試定庵，可以找到一些免費(fèi)工具。而對于專門的領(lǐng)域践美，則很難找到免費(fèi)的工具洗贰，大多需要自行開發(fā)或者購買專門的儀表進(jìn)行測試。

如果購買專門的性能測試工具的話陨倡，對自動化的支撐只能看工具本身的能力了敛滋。但是通過封裝也能把一些測試過程自動化掉，但是由于專有工具的使用成本兴革，一般自動化的意義未必很大绎晃。

對于性能測試，除去對系統(tǒng)做端到端的測試外杂曲，對代碼級別進(jìn)行profiling（性能打點統(tǒng)計）也是有價值的庶艾。一般出現(xiàn)性能問題后，需要找到代碼的性能瓶頸進(jìn)行代碼修改擎勘，這時如果直接有數(shù)據(jù)指出哪里是可能的性能瓶頸咱揍，可以有效的指導(dǎo)代碼修改。

代碼級別的profile工具開源免費(fèi)的比較多棚饵，例如Gprof和Valgrind都能對代碼做精確到語句的性能分析煤裙。但是這兩款工具都需要在運(yùn)行時對代碼進(jìn)行打點，所以如果能結(jié)合自動化的xUnit測試框架來編寫供profiling用的測試用例噪漾，那么可以有效的加快反饋速度硼砰，降低成本。

作者曾經(jīng)為某企業(yè)開發(fā)過一款性能CI工具欣硼，在開發(fā)人員提交代碼的時候由持續(xù)集成工具觸發(fā)對代碼進(jìn)行profiling题翰，一旦出現(xiàn)性能異常惡化，則阻止代碼入庫并通知開發(fā)人員進(jìn)行分析诈胜。該工具可以防患于未然豹障，盡早地讓開發(fā)人員去關(guān)注性能。

其它

自動化測試不能取代人工測試焦匈，事實上兩種測試的定位是不同的沼填。自動化測試是為了回歸，而人工測試是為了探索括授。一旦探索測試中的一部分開始變得常規(guī)化坞笙，則可以將其編寫成自動化測試用例后續(xù)自動執(zhí)行回歸岩饼，而讓測試人員重新投入更有創(chuàng)造性的測試工作。

另外薛夜，自動化的系統(tǒng)測試也不能取代自動化的單元測試籍茧。從前面的四象限可以看到，系統(tǒng)測試是幫助產(chǎn)品的梯澜，而單元測試為了幫助開發(fā)團(tuán)隊的寞冯，兩者的定位和價值方向不同。

借用下圖說明一個健康的測試用例分布模式：

健康的測試用例分布應(yīng)該如同上面的金字塔晚伙，由頂部少量的手工測試和系統(tǒng)測試吮龄，中間適度的集成測試和底層大量的單元測試用例組成。測試金字塔越往上更接近真實業(yè)務(wù)咆疗，但是成本越大也越慢漓帚，反饋周期長。金字塔越往下越靠近技術(shù)午磁，遠(yuǎn)離業(yè)務(wù)尝抖，但是好處是運(yùn)行速度塊成本低，可以加快反饋速度迅皇。所以如果能夠搭配如上圖昧辽，在整體上可以獲得很好的成本收益比。