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

王 倩，唐蘭文，趙明芝

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

1.引言

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

2.敏捷開(kāi)發(fā)中的敏捷測(cè)試

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

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

3.1 敏捷測(cè)試的流程和方法

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

圖 1 敏捷測(cè)試流程

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

項(xiàng)目立項(xiàng)過(guò)程包括項(xiàng)目建設(shè)單位向上級(jí)主管部門(mén)提交項(xiàng)目建議書(shū)，然后投入前對(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ù)方通過(guò)各種渠道收集到用戶需求后，快速整理并向項(xiàng)目成員發(fā)布。業(yè)務(wù)、開(kāi)發(fā)、測(cè)試三方召開(kāi)需求評(píng)審會(huì)對(duì)需求文檔進(jìn)行分析，探討功能實(shí)現(xiàn)的可行性與是否足夠細(xì)致作為測(cè)試依據(jù)。

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

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

3.1.4 編寫(xiě)/修訂測(cè)試用例

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

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

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

3.1.6 執(zhí)行測(cè)試

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

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

自動(dòng)化最適合于軟件開(kāi)發(fā)中那些單調(diào)、重復(fù)的工作和需要持續(xù)集成、構(gòu)建與部署的項(xiàng)目。敏捷測(cè)試中的“一次構(gòu)建、多次部署”便可用自動(dòng)化來(lái)實(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分鐘。而瀑布模型下的測(cè)試，部署時(shí)可能會(huì)因開(kāi)發(fā)人員提供的部署文檔描述不清或測(cè)試人員對(duì)Tomcat甚至對(duì)Linux語(yǔ)句不熟等原因，要耗時(shí)1-2天。

測(cè)試有時(shí)會(huì)需要大批量建基礎(chǔ)數(shù)據(jù)，而人為手動(dòng)新增過(guò)于枯燥與大工程量，這里我們可使 用 Selenium IDE 錄 制后生成腳本后實(shí)現(xiàn)自動(dòng)化新增。比如下方語(yǔ)句，一個(gè)自動(dòng)添加數(shù)據(jù)的簡(jiǎn)單案例，我們優(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)，而使用開(kāi)源工具Jmeter接口實(shí)現(xiàn)新增，便大不相同了。比如我曾測(cè)過(guò)的一個(gè)情況，頁(yè)面中沒(méi)有新增、編輯按鈕，所以每次添加數(shù)據(jù)都需要聯(lián)系開(kāi)發(fā)人員后臺(tái)處理，為避免麻煩，我們可使用Jmeter實(shí)現(xiàn)新增。從開(kāi)發(fā)人員處獲取到此頁(yè)面的接口后，在Jmeter的Dody Data中輸入以下語(yǔ)句：

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

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

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

4.結(jié)語(yǔ)

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