敏捷測試在軟件項(xiàng)目中的研究與應(yīng)用

王 倩，唐蘭文，趙明芝

（中汽數(shù)據(jù)（天津）有限公司，天津 300180）

1.引言

隨著現(xiàn)代化硬件與軟件結(jié)合的高速發(fā)展，科技創(chuàng)新型人才不斷涌現(xiàn)，社會(huì)對(duì)科學(xué)技術(shù)和方法的要求越來越高。尤其是軟件業(yè)務(wù)行業(yè)，對(duì)于快速變化的用戶需求，有技術(shù)性和方法性的高效率實(shí)現(xiàn)的開發(fā)與測試能力也越來越受歡迎。而大多軟件公司，仍在普遍推行傳統(tǒng)的開發(fā)測試流程。在瀑布模型下的一個(gè)項(xiàng)目周期短則三個(gè)月，長則兩三年。現(xiàn)假設(shè)項(xiàng)目過于龐大，整個(gè)軟件生命周期估算需要兩三年，那項(xiàng)目風(fēng)險(xiǎn)與人力資源、時(shí)間成本的龐大可想而知。而且目前很多項(xiàng)目狀況是因需求的頻繁變更，且沒有完善的測試流程來規(guī)定，開發(fā)和測試每天都在推翻自己前一天的勞動(dòng)成果，這種現(xiàn)象無形地不斷提升相關(guān)人員重復(fù)開發(fā)和重復(fù)測試這個(gè)項(xiàng)目模塊的厭煩感和無力感，并快速降低了技術(shù)人員的成就感。傳統(tǒng)的瀑布模型測試流程，主要特點(diǎn)便是靈活性差、測試耗時(shí)長，不適用于現(xiàn)今項(xiàng)目狀況。為“擁抱變化”，增加項(xiàng)目靈活性，適應(yīng)新的項(xiàng)目狀況需求，推行采用快速迭代、循序漸進(jìn)的方法進(jìn)行敏捷測試開發(fā)測試勢在必行。本文嘗試對(duì)敏捷測試在軟件項(xiàng)目中的研究與應(yīng)用進(jìn)行概述。

2.敏捷開發(fā)中的敏捷測試

傳統(tǒng)的瀑布模型的測試流程是，業(yè)務(wù)從客戶處不斷地收集需求內(nèi)容，提供至需求人員進(jìn)行編寫和細(xì)化，再將其產(chǎn)出需求文檔發(fā)至開發(fā)和測試人員后，開發(fā)人員和測試人員基于此文檔進(jìn)行需求分析，并組織業(yè)務(wù)、開發(fā)、測試人員三方評(píng)審需求。需求評(píng)審?fù)ㄟ^后，開發(fā)人員基于定版的需求文檔進(jìn)行代碼開發(fā)，同時(shí)測試人員開始編寫測試用例。在測試執(zhí)行啟動(dòng)之前，三方再次進(jìn)行一次用例評(píng)審，測試人員在評(píng)審會(huì)上講述自己編寫的測試功能點(diǎn)，業(yè)務(wù)人員和開發(fā)人員一起檢查并指出問題。用例評(píng)審?fù)ㄟ^后，才正式進(jìn)入測試。測試人員接收開發(fā)人員提供的部署包，項(xiàng)目部署好后，測試人員進(jìn)行冒煙測試和首輪測試，結(jié)束一輪后將測試結(jié)果一并發(fā)至開發(fā)進(jìn)行代碼修復(fù)，再次開啟新一輪的測試，直至達(dá)到上線標(biāo)準(zhǔn)，測試人員產(chǎn)出測試結(jié)項(xiàng)報(bào)告，項(xiàng)目測試結(jié)束。與傳統(tǒng)的瀑布模型測試模式不同，敏捷測試是“擁抱”敏捷開發(fā)。在這種模式下，測試與開發(fā)成為一個(gè)完整團(tuán)體，測試隨著開發(fā)而動(dòng)，貫穿于項(xiàng)目生命周期，而且整個(gè)項(xiàng)目周期中開發(fā)與測試過程靈活可變。

3.敏捷測試在項(xiàng)目中的應(yīng)用

3.1 敏捷測試的流程和方法

因?yàn)槊艚轀y試是把一個(gè)大項(xiàng)目分為若干個(gè)相互聯(lián)系又可獨(dú)立運(yùn)行的小項(xiàng)目，并分別完成。所以敏捷測試流程其實(shí)是以瀑布模式流程為基礎(chǔ)，在此增加改進(jìn)而得。敏捷測試流程圖如圖1：

圖 1 敏捷測試流程

3.1.1 項(xiàng)目立項(xiàng)

項(xiàng)目立項(xiàng)過程包括項(xiàng)目建設(shè)單位向上級(jí)主管部門提交項(xiàng)目建議書，然后投入前對(duì)項(xiàng)目進(jìn)行可行性研究，之后對(duì)項(xiàng)目進(jìn)行評(píng)估與論證，最后項(xiàng)目招標(biāo)與投標(biāo)，投標(biāo)人與招標(biāo)人簽訂合同。

3.1.2 階段需求分析

對(duì)接客戶的業(yè)務(wù)方通過各種渠道收集到用戶需求后，快速整理并向項(xiàng)目成員發(fā)布。業(yè)務(wù)、開發(fā)、測試三方召開需求評(píng)審會(huì)對(duì)需求文檔進(jìn)行分析，探討功能實(shí)現(xiàn)的可行性與是否足夠細(xì)致作為測試依據(jù)。

3.1.3 編寫/修訂迭代測試計(jì)劃

通過三方需求評(píng)審后，測試部門要編寫/修訂迭代測試計(jì)劃，具體內(nèi)容包括各模塊的計(jì)劃開始時(shí)間、計(jì)劃結(jié)束時(shí)間、對(duì)應(yīng)測試工程師、預(yù)計(jì)人天等。隨后測試人員將完善的計(jì)劃發(fā)給業(yè)務(wù)方查看，審核無誤，便可實(shí)行。

3.1.4 編寫/修訂測試用例

測試部發(fā)送至業(yè)務(wù)方測試計(jì)劃審核通過后，便可正式進(jìn)入測試流程。測試工程師基于定版的需求文檔編寫測試用例。測試用例主要包括三內(nèi)容：用例標(biāo)題、步驟和預(yù)期。

3.1.5 三方用例評(píng)審

測試人員組織業(yè)務(wù)、開發(fā)進(jìn)行三方用例評(píng)審，評(píng)審會(huì)上測試人員講述自己每條用例對(duì)應(yīng)的需求功能點(diǎn)。業(yè)務(wù)和開發(fā)檢查是否有功能遺漏和步驟預(yù)期正確性。如有問題，測試人員將有問題的用例在會(huì)后及時(shí)修改，并再次發(fā)送至業(yè)務(wù)方審核。多次確認(rèn)無誤后，測試用例存檔。

3.1.6 執(zhí)行測試

此處的執(zhí)行測試，便是瀑布模型與迭代模型的主要差異所在。一種情況是，開發(fā)人員將這一階段的開發(fā)版本提交給測試部進(jìn)行測試，即可進(jìn)行下一階段的開發(fā)，測試人員在測試過程中若遇到核心問題，及時(shí)聯(lián)系開發(fā)解決，以便不會(huì)堵塞后面的功能測試，若是一般問題，測試人員將bug記錄好，以便開發(fā)人員對(duì)該階段的下一版本及時(shí)修改和提交。另一種情況是，開發(fā)人員并行工作，同時(shí)進(jìn)行著下一階段的開發(fā)與這一階段的bug修復(fù)工作。這種情況的實(shí)現(xiàn)必須要開發(fā)人員和測試人員的高度配合。測試版本可能一天一次甚至一天內(nèi)隨時(shí)更新部署。尤其是為縮短頻繁部署時(shí)間，開發(fā)人員使用Jenkins和Git實(shí)現(xiàn)自動(dòng)化部署，每次部署最多僅需1分鐘。最理想情況下，測試人員邊提bug邊得到修復(fù)，進(jìn)度大大加快，縮短了項(xiàng)目周期。執(zhí)行測試中最重要一點(diǎn)是每日站會(huì)。由測試人員負(fù)責(zé)主持，站會(huì)上開發(fā)人員要講述自己前一天對(duì)哪些部分代碼進(jìn)行了改動(dòng)，測試人員匯報(bào)測試進(jìn)度，以便團(tuán)隊(duì)人員可以清楚項(xiàng)目情況，同時(shí)會(huì)上大家可以提出項(xiàng)目推進(jìn)過程中遇到的問題，做到早反饋早解決。

3.2 敏捷測試中的自動(dòng)化和接口應(yīng)用

自動(dòng)化最適合于軟件開發(fā)中那些單調(diào)、重復(fù)的工作和需要持續(xù)集成、構(gòu)建與部署的項(xiàng)目。敏捷測試中的“一次構(gòu)建、多次部署”便可用自動(dòng)化來實(shí)現(xiàn)。比如環(huán)境部署可以用項(xiàng)目版本管理工具GIT和持續(xù)集成工具Jenkins合作搭建，創(chuàng)建一個(gè)觸發(fā)構(gòu)建的項(xiàng)目后，后續(xù)代碼如果有改動(dòng)，只要push到github或者gitlab等上，在jenkins界面中再次執(zhí)行構(gòu)建任務(wù)就可以了，耗時(shí)最多1分鐘。而瀑布模型下的測試，部署時(shí)可能會(huì)因開發(fā)人員提供的部署文檔描述不清或測試人員對(duì)Tomcat甚至對(duì)Linux語句不熟等原因，要耗時(shí)1-2天。

測試有時(shí)會(huì)需要大批量建基礎(chǔ)數(shù)據(jù)，而人為手動(dòng)新增過于枯燥與大工程量，這里我們可使 用 Selenium IDE 錄 制后生成腳本后實(shí)現(xiàn)自動(dòng)化新增。比如下方語句，一個(gè)自動(dòng)添加數(shù)據(jù)的簡單案例，我們優(yōu)選將錄制后的腳本轉(zhuǎn)化為Java腳本到Eclipse中運(yùn)行。

其實(shí)Selenium IDE錄制后轉(zhuǎn)化的Java腳本不一定能跑通，所以需要手動(dòng)修改代碼。而且使用Selenium自動(dòng)化要校驗(yàn)的地方太多，維護(hù)腳本成本高，碰到iframe框架也不好實(shí)現(xiàn)，而使用開源工具Jmeter接口實(shí)現(xiàn)新增，便大不相同了。比如我曾測過的一個(gè)情況，頁面中沒有新增、編輯按鈕，所以每次添加數(shù)據(jù)都需要聯(lián)系開發(fā)人員后臺(tái)處理，為避免麻煩，我們可使用Jmeter實(shí)現(xiàn)新增。從開發(fā)人員處獲取到此頁面的接口后，在Jmeter的Dody Data中輸入以下語句：

用Jmeter灌入數(shù)據(jù)，還要注意某些字段要求的必填、唯一性校驗(yàn)，否則點(diǎn)擊Start后運(yùn)行結(jié)果會(huì)顯示程序異常等失敗報(bào)錯(cuò)。這里建議測試人員在實(shí)際項(xiàng)目中根據(jù)自身能力和習(xí)慣來選擇用哪一種工具實(shí)現(xiàn)自動(dòng)化。

3.3 敏捷測試在項(xiàng)目中應(yīng)用感想

經(jīng)過敏捷測試在企業(yè)軟件項(xiàng)目中的實(shí)踐驗(yàn)證，迭代測試團(tuán)隊(duì)專業(yè)素養(yǎng)的基本三要素：一是團(tuán)隊(duì)成員的責(zé)任心要強(qiáng)。俗話說，眾人拾材火焰高。一個(gè)項(xiàng)目的最基本的展示來自UI設(shè)計(jì)工程師、后端工程師、數(shù)據(jù)庫工程師、接口工程師和前端工程師合作產(chǎn)出。如果團(tuán)隊(duì)內(nèi)員工懈怠，團(tuán)隊(duì)?wèi)猩ⅲ瑏y推責(zé)任，即使團(tuán)隊(duì)內(nèi)的員工都是技術(shù)大牛，整合出的項(xiàng)目質(zhì)量也會(huì)差強(qiáng)人意。二是團(tuán)隊(duì)人員穩(wěn)定，避免流動(dòng)性。迭代項(xiàng)目都是分模塊開發(fā)和提測，彼此模塊之間有銜接，而且不停地變更和完善，業(yè)務(wù)人員有可能未來得及完善文檔，往往項(xiàng)目很多細(xì)節(jié)處，其實(shí)只有長期穩(wěn)定在這項(xiàng)目中的人才能發(fā)現(xiàn)，所以迭代必須保證長期跟進(jìn)參與的開發(fā)與測試存在。三是團(tuán)隊(duì)合作默契度要高。迭代測試的迭代周期普遍很短，有可能測試幾天便上線，所以無法避免一天部署多個(gè)版本，提交的bug以小時(shí)為單位迅速解決并回歸，基本上測試人員當(dāng)天提bug，開發(fā)人員當(dāng)天標(biāo)記已解決，又當(dāng)天便回歸了，這個(gè)無縫銜接的合作需要隨時(shí)分配bug的項(xiàng)目管理人調(diào)配和迅速修改bug的開發(fā)人員以及回歸的測試人員的高度配合。

4.結(jié)語

經(jīng)實(shí)踐證明，與傳統(tǒng)的測試模型相比，敏捷測試能更早地發(fā)現(xiàn)并清除軟件bug，在保證了軟件產(chǎn)品質(zhì)量的同時(shí)很大程度上提高了軟件產(chǎn)品的生產(chǎn)效率。如今，“敏捷測試”的概念開始加熱。對(duì)于軟件測試人員，如果想要轉(zhuǎn)型，要以成為敏捷測試領(lǐng)域的先行者和實(shí)踐者為目標(biāo)，必須找到自身定位，加強(qiáng)內(nèi)部學(xué)習(xí)，掌握測試的基礎(chǔ)和理論，再談其他。而對(duì)于企業(yè)，彼此之間競爭激烈，交付項(xiàng)目時(shí)若不滿足客戶要求，便很難獲取同一客戶公司下的第二次競標(biāo)，因此把握住每一次項(xiàng)目，把每次項(xiàng)目都當(dāng)成機(jī)會(huì)，去爭取去實(shí)現(xiàn)，也是每個(gè)參與人員該肩負(fù)的責(zé)任感。