敏捷測試在軟件項目中的研究與應用

王 倩，唐蘭文，趙明芝

（中汽數據（天津）有限公司，天津 300180）

1.引言

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

2.敏捷開發中的敏捷測試

傳統的瀑布模型的測試流程是，業務從客戶處不斷地收集需求內容，提供至需求人員進行編寫和細化，再將其產出需求文檔發至開發和測試人員后，開發人員和測試人員基于此文檔進行需求分析，并組織業務、開發、測試人員三方評審需求。需求評審通過后，開發人員基于定版的需求文檔進行代碼開發，同時測試人員開始編寫測試用例。在測試執行啟動之前，三方再次進行一次用例評審，測試人員在評審會上講述自己編寫的測試功能點，業務人員和開發人員一起檢查并指出問題。用例評審通過后，才正式進入測試。測試人員接收開發人員提供的部署包，項目部署好后，測試人員進行冒煙測試和首輪測試，結束一輪后將測試結果一并發至開發進行代碼修復，再次開啟新一輪的測試，直至達到上線標準，測試人員產出測試結項報告，項目測試結束。與傳統的瀑布模型測試模式不同，敏捷測試是“擁抱”敏捷開發。在這種模式下，測試與開發成為一個完整團體，測試隨著開發而動，貫穿于項目生命周期，而且整個項目周期中開發與測試過程靈活可變。

3.敏捷測試在項目中的應用

3.1 敏捷測試的流程和方法

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

圖 1 敏捷測試流程

3.1.1 項目立項

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

3.1.2 階段需求分析

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

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

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

3.1.4 編寫/修訂測試用例

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

3.1.5 三方用例評審

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

3.1.6 執行測試

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

3.2 敏捷測試中的自動化和接口應用

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

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

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

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

3.3 敏捷測試在項目中應用感想

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

4.結語

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