劉方

摘 要：為了在實際項目測試工作中更好地適應(yīng)敏捷開發(fā)模式，探索一種新型軟件測試模型。通過梳理傳統(tǒng)的幾種常用軟件測試模型，比較分析各個模型的優(yōu)缺點，吸取前人的優(yōu)點并結(jié)合實際項目經(jīng)驗和現(xiàn)實需求，設(shè)計了一種以需求為驅(qū)動、以測試為核心的新型軟件測試模型—“車輪”模型。該模型適用于目前最流行的敏捷開發(fā)模式，強調(diào)全過程測試，能有效提高軟件質(zhì)量和開發(fā)效率。

關(guān)鍵詞：敏捷開發(fā)；軟件測試；“車輪”模型；需求驅(qū)動；全過程測試

DOI：10.11907/rjdk.172747

中圖分類號：TP319

文獻標(biāo)識碼：A 文章編號：1672-7800（2018）005-0142-04

Abstract：In order to adapt to agile development mode better in the actual project testing，this paper explores a new kind of software test model. First， this paper has combed the traditional software test models； then， it compares the advantages and disadvantages of every model； finally， the author designs a new software test model， “wheel” model， which is driven by the demand and tested as the core by drawing on the advantages of predecessors and combining actual project experience and real demands. This model is applicable to the most popular agile development mode， and emphasizes the whole process test， which can effectively improve the software quality and development efficiency.

Key Words：agile development；software testing； “wheel” model； demand-driven； whole process test

0 引言

高效的測試工作是保障高質(zhì)量產(chǎn)品盡快上線的關(guān)鍵。建立一個好的軟件測試模型可以極大提高測試效率、減少不必要的工作量、增加測試精準(zhǔn)度。本文首先分析常用的軟件測試模型，然后結(jié)合數(shù)年的工作經(jīng)驗，重點討論一種適應(yīng)目前最為流行的敏捷開發(fā)模式的新型軟件測試模型，即需求驅(qū)動的軟件測試模型——“車輪”模型。

敏捷開發(fā)是一種適應(yīng)性、增量式的開發(fā)模式[1]，目前被大多數(shù)企業(yè)采用。其產(chǎn)生的原因是市場的需求瞬息萬變，很難實現(xiàn)產(chǎn)品需求的明確、完整收集。在整個敏捷開發(fā)過程中需求是不斷新增并改進的，需求變更推動整個開發(fā)過程的行進。而在敏捷開發(fā)中，測試的目的在于驗證：第一、需求理解和表達的正確性；第二、設(shè)計和表達的正確性；第三、實現(xiàn)的正確性；第四、運行的正確性[2]。這4個階段中的正確性都以需求為判斷基準(zhǔn)，測試也以需求為依據(jù)，所以需求是整個開發(fā)過程的驅(qū)動力。

1 常用軟件測試模型分析

1.1 V模型

V模型是最早被提出[3]、最具有代表性，也是最為人熟知的一種測試模型，如圖1所示。

圖1中由左至右描述了開發(fā)過程和測試階段之間的對應(yīng)關(guān)系。V模型的意義在于，它最早提出測試不是開發(fā)的事后彌補行為，而是與開發(fā)同等重要的過程[4]。但V模型的缺點也很明顯，它將測試階段和設(shè)計階段完全分開[5]，認為測試是編碼完成后才開始的階段[6]，這種思想無法體現(xiàn)“盡早測試”的原則。于是，需求分析和產(chǎn)品設(shè)計階段產(chǎn)生的錯誤就只能到最終的測試階段才能被發(fā)現(xiàn)，大大增加了修復(fù)錯誤的代價，延長了開發(fā)周期。并且，V模型中各個階段之間沒有交互，一個階段完成才到下一個階段，無法循環(huán)互動，這和敏捷開發(fā)及時溝通響應(yīng)的要求背道而馳。

1.2 W模型

鑒于V模型的不足，W模型將兩個V模型合并，強調(diào)測試應(yīng)該伴隨開發(fā)的全部過程[4]，需求、功能、設(shè)計、程序都是測試對象[2]，并且測試和開發(fā)同步進行，如圖2所示。

W模型對V模型的改進，不僅擴大了測試范圍，更有利于盡早發(fā)現(xiàn)問題，避免了在驗收階段才最終發(fā)現(xiàn)需求實現(xiàn)錯誤或需求不滿足的嚴(yán)重錯誤。但W模型也有其局限性，如仍然將需求、設(shè)計、編碼視為串行，并且測試和開發(fā)活動也保持線性的先后關(guān)系，當(dāng)上一階段完全結(jié)束才能進入下一階段工作[7]。這樣，缺少了關(guān)鍵的回歸測試階段，也無法支持敏捷開發(fā)過程的迭代模型。

1.3 X模型

圖3是X模型示意圖。X 模型是對V模型的一種改進，圖左描述的是針對單獨程序片段所進行的相互分離的編碼和測試，此后通過頻繁重復(fù)的集成最終成為可執(zhí)行的程序，然后再對這些可執(zhí)行程序進行測試。已通過集成測試的成品可以進行封裝并提交給用戶，也可作為更大規(guī)模和范圍內(nèi)集成的一部分。圖右多根并行的曲線表示變更可以在各個部分發(fā)生，同時還定義了探索性測試，這是不進行事先計劃的特殊類型測試，該方式往往能幫助有經(jīng)驗的測試人員在測試計劃之外發(fā)現(xiàn)更多的軟件錯誤[8]。但這種探索性測試可能造成人力、物力和財力浪費，對測試員的熟練程度要求比較高[6]。但X模型仍存在一些缺陷：①提出測試設(shè)計卻沒有指明在測試的各個階段都需要進行測試設(shè)計；②沒有提及關(guān)于需求的確認；③過于關(guān)注程序級別的測試，沒有抽象成一個系統(tǒng)模型[9]。

1.3 H模型

圖4的H模型僅僅演示了整個產(chǎn)品生命周期中的某一次測試“微循環(huán)”。圖中的“其它流程”可以是任意流程，如：需求分析流程、設(shè)計流程、編碼流程，甚至是測試流程自身。向上的箭頭代表一個測試就緒點，表示“其它流程”在該點處達到了測試條件，此時只要測試準(zhǔn)備活動完成，就可以執(zhí)行測試。概括來說，H模型將軟件測試獨立于其它流程并貫穿于整個產(chǎn)品生命周期，與其它流程并發(fā)的進行，當(dāng)某個測試時間點就緒時，軟件測試即從測試準(zhǔn)備階段進入測試執(zhí)行階段[10]。H模型雖然有很強的靈活性，但它并沒有提出具體的應(yīng)用模型[11]，其實際運用的指導(dǎo)意義不強。

2 需求驅(qū)動軟件測試模型——“車輪”模型

2.1 模型設(shè)計

為使軟件測試能夠適應(yīng)敏捷開發(fā)模式，達到測試目的，本文綜合上述幾種常用測試模型的優(yōu)點，并結(jié)合實踐經(jīng)驗和實際需求，設(shè)計了一種新型的軟件測試模型——“車輪”模型。如圖5所示。

“車輪”模型是一種以用戶需求和用戶反饋為驅(qū)動，以測試為核心、用于迭代開發(fā)模式的測試模型。由于用戶需求和用戶反饋是增量式的遞交，所以產(chǎn)品開發(fā)過程是不斷重復(fù)循環(huán)的。測試滲透在產(chǎn)品開發(fā)的全過程中，跟蹤每一個環(huán)節(jié)的輸入和輸出。在“車輪”模型中，測試直接對需求負責(zé)，保證產(chǎn)品在各個階段都是符合需求的，測試對象是產(chǎn)品生命周期全過程。

“車輪”模型中的測試是一個獨立的流程，其中包括：測試管理和測試執(zhí)行。測試管理是指，對測試計劃、測試說明、測試資源、源程序、測試用例、測試環(huán)境、測試腳本、測試報告、缺陷單等進行管理，同時對測試人員進行合理分工。測試執(zhí)行是指，測試人員在分配到任務(wù)后，對測試對象進行相應(yīng)的測試，包括：接口測試、功能測試、集成測試、系統(tǒng)測試、回歸測試等。

由于測試在“車輪”模型中處于核心位置，跟蹤產(chǎn)品生命周期的全過程，所以對測試人員的要求也較高。測試人員除了能熟練執(zhí)行接口測試、功能測試、集成測試、系統(tǒng)測試、回歸測試等基礎(chǔ)測試，還需要具備需求分析、文案編輯能力，同時還需要有一定的編碼能力，能理解程序的實現(xiàn)算法。

2.2 模型詳述

圖5模型中無法詳細說明在開發(fā)的各個階段測試對應(yīng)的具體工作內(nèi)容，但實際在開發(fā)與測試的每一個交互箭頭上都包含了許多工作，以下是詳細介紹。

（1）需求分析階段：

①測試需求文檔，提出需求缺陷，跟蹤缺陷修改情況；

②參加需求評審， 協(xié)助制定驗收標(biāo)準(zhǔn)；

③根據(jù)最終確定的需求文檔編寫測試計劃；

④根據(jù)需求文檔、業(yè)務(wù)流程， 設(shè)計測試流程。

（2）產(chǎn)品設(shè)計階段：

①對原型進行測試，提出原型缺陷，跟蹤缺陷修改情況；

②根據(jù)需求文檔、業(yè)務(wù)流程和原型， 設(shè)計功能測試用例。

（3）詳細設(shè)計階段：

①測試詳細設(shè)計文檔，提出設(shè)計缺陷，跟蹤缺陷修改情況；

②根據(jù)詳細設(shè)計文檔編寫接口測試計劃，設(shè)計接口測試用例和測試腳本；

③根據(jù)詳細設(shè)計文檔、數(shù)據(jù)字典搭建測試環(huán)境，準(zhǔn)備測試數(shù)據(jù)。

（4）編碼實現(xiàn)階段：

①對已完成編碼的接口進行接口測試；

②集成通過接口測試的接口進行模塊測試；

③根據(jù)需要選擇進行壓力測試、性能測試、穩(wěn)定性測試、兼容性測試、安全性測試、自動化測試；

④跟蹤缺陷，不斷進行回歸測試。

（5）系統(tǒng)集成階段：

①集成全部模塊進行系統(tǒng)測試；

②完成測試報告；

③編寫用戶手冊；

④收集β測試中的用戶反饋，對用戶反饋進行核查篩選確定系統(tǒng)缺陷，跟蹤缺陷修改情況；

⑤協(xié)助實施人員完成系統(tǒng)部署和產(chǎn)品上線。

2.3 模型優(yōu)勢

和常用測試模型相比，“車輪”模型有如下優(yōu)點：

（1）強調(diào)測試對象不是代碼而是整個產(chǎn)品生命周期，每一個可交付的中間件都需要通過適當(dāng)?shù)姆绞竭M行測試，真正實現(xiàn)了“全過程”測試， 提高了軟件測試質(zhì)量[12]。

（2）由于測試在項目啟動初期就參與其中，保證了測試和開發(fā)過程的密切銜接，確保能在第一時間發(fā)現(xiàn)錯誤。

（3）現(xiàn)實中的開發(fā)不是一種串行的活動，在大多數(shù)情況下是交叉進行的，那么相應(yīng)的測試也不存在嚴(yán)格的先后關(guān)系。“車輪”模型適應(yīng)了這一現(xiàn)實狀況，讓各階段的測試（如：接口測試、集成測試、系統(tǒng)測試、回歸測試等）跟隨開發(fā)進度反復(fù)觸發(fā)、循環(huán)迭代。

（4）將測試活動完全獨立出來，同時采取敏捷方法，及時響應(yīng)并全程跟蹤，完全實現(xiàn)了測試和開發(fā)的同步。

（5）體現(xiàn)了客戶、產(chǎn)品經(jīng)理、開發(fā)人員以及測試人員之間的交互，當(dāng)需求發(fā)生變更時能夠及時調(diào)整方案。并且測試結(jié)果實時反饋，也保證了測試質(zhì)量。

2.4 模型應(yīng)用實施

將“車輪”模型應(yīng)用到一個社會治理網(wǎng)格化微信公眾號的開發(fā)項目中，該項目包括公眾號前臺開發(fā)和后臺管理平臺開發(fā)。其中的志愿者模塊完全依照“車輪”模型進行全程測試。首先，產(chǎn)品經(jīng)理與客戶溝通需求并完成需求文檔后，將需求文檔交付給測試人員和開發(fā)人員進行評估。在此階段測試人員會對需求的可行性、合理性及完整性進行測試，并將需求缺陷提交給產(chǎn)品經(jīng)理。之后產(chǎn)品經(jīng)理會根據(jù)測試提交的缺陷以及開發(fā)反饋的意見重新補充并修改需求文檔。需求文檔定稿后，產(chǎn)品經(jīng)理、開發(fā)人員和測試人員共同參與需求評審會議，制定產(chǎn)品驗收標(biāo)準(zhǔn)。

接下來，產(chǎn)品經(jīng)理根據(jù)需求文檔完成產(chǎn)品原型的設(shè)計后，將原型交付給開發(fā)人員和測試人員。在此階段對原型進行測試，主要包括：界面是否美觀；配色是否合理；交互是否友好；操作步驟是否簡單；功能是否齊全；使用場景是否全覆蓋；邏輯是否合理；操作流程是否順暢等。測試人員將原型缺陷提交給產(chǎn)品經(jīng)理后，產(chǎn)品經(jīng)理會根據(jù)測試缺陷以及開發(fā)意見對原型進行修改，最終確定原型。

開發(fā)人員根據(jù)原型進行詳細設(shè)計階段，測試人員同時設(shè)計編寫測試用例。對于需要進行接口測試的部分，測試人員依據(jù)開發(fā)人員提供的接口說明書設(shè)計編寫接口測試腳本。在此階段測試人員還要搭建測試環(huán)境，準(zhǔn)備測試數(shù)據(jù)。

由于志愿者模塊內(nèi)還細分了多個小模塊，開發(fā)人員會將逐個完成的小模塊提測給測試人員。測試人員對提測的模塊會先進行冒煙測試，確保提測內(nèi)容的主要功能已通，可以進行后續(xù)的全面測試。如在冒煙測試過程中發(fā)現(xiàn)阻塞缺陷立即打回給開發(fā)人員重新編碼。于是整個開發(fā)實現(xiàn)過程是一種邊開發(fā)邊測試的狀態(tài)。當(dāng)所有小模塊全部完成后，開發(fā)人員會集中修復(fù)測試人員提交的缺陷，而測試人員會不斷回歸測試已修復(fù)的缺陷。

最后測試人員還要再整體進行系統(tǒng)測試、兼容性測試以及并發(fā)測試。當(dāng)已知缺陷全部修復(fù)完成后，產(chǎn)品達到驗收條件即可上線并交付給客戶使用。

2.5 模型應(yīng)用效果分析

社會治理網(wǎng)格化微信公眾號項目中還有一個智慧黨建模塊，該模塊未使用“車輪”模型，而是按照傳統(tǒng)測試方法進行測試。與使用“車輪”模型的志愿者模塊相比，由于智慧黨建模塊的測試工作并未在需求制定階段就介入，而是在編碼完成后一次性交付給測試，智慧黨建模塊在測試后又修改了2次需求，同時開發(fā)人員根據(jù)修改的需求重構(gòu)了兩次代碼。而志愿者模塊因為前期對需求及原型都進行了測試，編碼工作一次性完成，大大減少了開發(fā)時間，提高了產(chǎn)品開發(fā)效率。

另外，志愿者模型由于測試全程跟蹤，當(dāng)出現(xiàn)問題時和項目其他人員及時溝通反饋，極大地縮短了處理問題的響應(yīng)時間。而智慧黨建模塊的測試工作仍是一種串行模式，當(dāng)發(fā)現(xiàn)問題后再回退到上一階段，這種問題解決模式浪費了大量時間。

3 結(jié)語

本文結(jié)合軟件測試模型的設(shè)計原則，提出了一個新的軟件測試模型——“車輪”模型。該模型吸取V模型、W模型、X模型、H模型的優(yōu)點，同時彌補這些傳統(tǒng)模型的不足之處，最大化體現(xiàn)了“盡早測試、全面測試”的原則。模型將測試置于產(chǎn)品開發(fā)的核心位置，充分發(fā)揮了測試人員的主觀能動性，以測試推動開發(fā)，有效地減少了軟件缺陷，在保證軟件質(zhì)量的同時也縮短了開發(fā)時間。并且，模型加強了測試人員和客戶、產(chǎn)品經(jīng)理、開發(fā)人員的溝通交流，讓測試人員直接對需求負責(zé)，完全符合當(dāng)前流行的敏捷開發(fā)模式。下一步將不斷優(yōu)化改進模型，提高模型的通用性，以期有新的突破。

參考文獻：

[1] 王科欣.基于敏捷方法的軟件測試模型研究[J].軟件導(dǎo)刊，2009，8（5）：27-28.

[2] 劉超.基于擴展V模型的軟件測試[J].玉林師范學(xué)院學(xué)報：自然科學(xué)版，2006，27（5）：149-152.

[3] 陳靜.軟件測試過程模型和管理理念探討[J].艦船電子對抗，2007，30（4）：99-101，107.

[4] 鄧璐娟，刁海港.軟件測試模型及X模型的改進[J].鄭州輕工業(yè)學(xué)院學(xué)報：自然科學(xué)版，2011，26（1）：91-94.

[5] 周童，方彥軍.一種新的軟件測試過程模型-“跑道”模型[J].計算機測量與控制，2015，23（10）：3347-3349.

[6] 孟祥豐.軟件測試模型及其改進方案[J].電子設(shè)計工程，2012，20（23）：38-40.

[7] 孫文婷.軟件測試模型的應(yīng)用研究及改進[J].電腦知識與技術(shù)，2008，4（4）：1005-1007.

[8] 曾凡晉.淺議軟件測試領(lǐng)域V模型與X模型[J].邢臺職業(yè)技術(shù)學(xué)院學(xué)報，2009，26（1）：72-74.

[9] 陳小勇，尹剛.軟件測試模型分析與研究[J].現(xiàn)代計算機.2008（5）：22-25.

[10] 吳慧韞，李卓群.基于H模型的軟件測試管理應(yīng)用模型研究[J].計算機工程與設(shè)計，2006，27（11）：1993-1995.

[11] 張曉雯，徐東.基于工作流的軟件測試H模型研究[J].軟件導(dǎo)刊，2013，12（2）：24-26.

[12] 耿曉偉，刁文濤.基于改進噴泉模型的軟件測試的研究[J].信息技術(shù)與信息化，2009（3）：35-38.

（責(zé)任編輯：江 艷）