王 倩，唐蘭文，趙明芝

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

1.引言

隨著現(xiàn)代化硬件與軟件結(jié)合的高速發(fā)展，科技創(chuàng)新型人才不斷涌現(xiàn)，社會對科學(xué)技術(shù)和方法的要求越來越高。尤其是軟件業(yè)務(wù)行業(yè)，對于快速變化的用戶需求，有技術(shù)性和方法性的高效率實現(xiàn)的開發(fā)與測試能力也越來越受歡迎。而大多軟件公司，仍在普遍推行傳統(tǒng)的開發(fā)測試流程。在瀑布模型下的一個項目周期短則三個月，長則兩三年?，F(xiàn)假設(shè)項目過于龐大，整個軟件生命周期估算需要兩三年，那項目風(fēng)險與人力資源、時間成本的龐大可想而知。而且目前很多項目狀況是因需求的頻繁變更，且沒有完善的測試流程來規(guī)定，開發(fā)和測試每天都在推翻自己前一天的勞動成果，這種現(xiàn)象無形地不斷提升相關(guān)人員重復(fù)開發(fā)和重復(fù)測試這個項目模塊的厭煩感和無力感，并快速降低了技術(shù)人員的成就感。傳統(tǒng)的瀑布模型測試流程，主要特點便是靈活性差、測試耗時長，不適用于現(xiàn)今項目狀況。為“擁抱變化”，增加項目靈活性，適應(yīng)新的項目狀況需求，推行采用快速迭代、循序漸進(jìn)的方法進(jìn)行敏捷測試開發(fā)測試勢在必行。本文嘗試對敏捷測試在軟件項目中的研究與應(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ā)、測試人員三方評審需求。需求評審?fù)ㄟ^后，開發(fā)人員基于定版的需求文檔進(jìn)行代碼開發(fā)，同時測試人員開始編寫測試用例。在測試執(zhí)行啟動之前，三方再次進(jìn)行一次用例評審，測試人員在評審會上講述自己編寫的測試功能點，業(yè)務(wù)人員和開發(fā)人員一起檢查并指出問題。用例評審?fù)ㄟ^后，才正式進(jìn)入測試。測試人員接收開發(fā)人員提供的部署包，項目部署好后，測試人員進(jìn)行冒煙測試和首輪測試，結(jié)束一輪后將測試結(jié)果一并發(fā)至開發(fā)進(jìn)行代碼修復(fù)，再次開啟新一輪的測試，直至達(dá)到上線標(biāo)準(zhǔn)，測試人員產(chǎn)出測試結(jié)項報告，項目測試結(jié)束。與傳統(tǒng)的瀑布模型測試模式不同，敏捷測試是“擁抱”敏捷開發(fā)。在這種模式下，測試與開發(fā)成為一個完整團(tuán)體，測試隨著開發(fā)而動，貫穿于項目生命周期，而且整個項目周期中開發(fā)與測試過程靈活可變。

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

3.1 敏捷測試的流程和方法

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

圖 1 敏捷測試流程

3.1.1 項目立項

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

3.1.2 階段需求分析

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

3.1.3 編寫/修訂迭代測試計劃

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

3.1.4 編寫/修訂測試用例

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

3.1.5 三方用例評審

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

3.1.6 執(zhí)行測試

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

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

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

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

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

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

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

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

4.結(jié)語

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