瀑布開發(fā)與敏捷開發(fā)中測試與開發(fā)的配合

張 靜，于 琪（南京新聯(lián)電子股份有限公司，210005）

?

瀑布開發(fā)與敏捷開發(fā)中測試與開發(fā)的配合

張 靜，于 琪
（南京新聯(lián)電子股份有限公司，210005）

摘要：傳統(tǒng)的瀑布開發(fā)方式對于如何應(yīng)對頻繁變化的軟件需求有明顯的不足，部分電力行業(yè)或工控行業(yè)的軟件開發(fā)公司正轉(zhuǎn)向使用敏捷開發(fā)方式。而敏捷開發(fā)方式中對測試工作的要求不能從互聯(lián)網(wǎng)企業(yè)的敏捷開發(fā)方式中生搬硬套過來。本文對比了瀑布開發(fā)方式中測試與開發(fā)的配合流程，提出了適用電力或工控等傳統(tǒng)行業(yè)的敏捷開發(fā)方式中測試如何與開發(fā)配合的建議。

關(guān)鍵詞：瀑布開發(fā)；敏捷開發(fā)；測試與開發(fā)配合；測試人員素質(zhì)要求

0　引言

電力或工控等傳統(tǒng)行業(yè)的軟件開發(fā)有其“有明確的國網(wǎng)或行業(yè)標(biāo)準(zhǔn)，需求比較固定、變動不頻繁”等特點(diǎn)，而這些特點(diǎn)正是瀑布式開發(fā)在傳統(tǒng)行業(yè)大行其道的根本原因。

隨著新技術(shù)不斷引入電力或通信等傳統(tǒng)行業(yè)，以及很多地方用戶對軟件功能提出各種變更性建議，很多傳統(tǒng)行業(yè)的軟件開發(fā)公司開始嘗試使用敏捷開發(fā)方式來管理軟件開發(fā)過程。

傳統(tǒng)行業(yè)的軟件對質(zhì)量要求一直遵循“高標(biāo)準(zhǔn)、嚴(yán)要求”的質(zhì)量標(biāo)準(zhǔn)，測試工作作為質(zhì)量保證的一種手段，不能因?yàn)殚_發(fā)方式的變動而被弱化。

因?yàn)槊艚蓍_發(fā)首先是在互聯(lián)網(wǎng)行業(yè)興起并被廣泛使用，所以帶有互聯(lián)網(wǎng)行業(yè)的特點(diǎn)：用戶體驗(yàn)勝于軟件的正確性。而在傳統(tǒng)行業(yè)這種對操作安全性和軟件質(zhì)量要求更加嚴(yán)格的行業(yè)，不能簡單地將互聯(lián)網(wǎng)行業(yè)中的敏捷開發(fā)的測試工作內(nèi)容生搬硬套過來。

由于以上這些情況，本文提出了電力或工控等傳統(tǒng)行業(yè)中使用敏捷開發(fā)方式適用的測試方法和流程。

該測試方法和流程經(jīng)過在公司內(nèi)部一年半的使用過程中，取得了良好的效果：測試工作的壓力從瀑布模型的后期集中爆發(fā)變成均衡地釋放，測試發(fā)現(xiàn)Bug的有效率也有相應(yīng)提高。

1　正文

1.1瀑布式開發(fā)模式中測試與開發(fā)的配合

瀑布式開發(fā)模式中，測試與開發(fā)的配合可以歸結(jié)為一下幾點(diǎn)內(nèi)容：

1）及時介入，了解需求。

測試人員在需求了解進(jìn)度上需要和開發(fā)人員保持一致，為保證后面的測試計(jì)劃編制打下基礎(chǔ)。

2）并行設(shè)計(jì)，相互審查，保證設(shè)計(jì)質(zhì)量（開發(fā)寫設(shè)計(jì)文檔，測試寫測試用例）

需求評審結(jié)束后，開發(fā)人員寫開發(fā)文檔，測試人員可以結(jié)合開發(fā)的設(shè)計(jì)文檔編寫測試用例，編寫的過程也是一個對開發(fā)文檔進(jìn)行評審的過程，同樣，當(dāng)測試人員寫好用例以后，開發(fā)人員也要評審測試用例，以發(fā)現(xiàn)用例不完善之處，經(jīng)過這個環(huán)節(jié)以后，即可以保證開發(fā)的設(shè)計(jì)文檔被測試?yán)斫猓部梢员ＷC測試用例是覆蓋設(shè)計(jì)文檔和需求文檔的。

3）持續(xù)集成，回歸測試保證代碼質(zhì)量

在軟件基線版本出來以后，就可以進(jìn)行回歸測試，這樣發(fā)現(xiàn)的Bug及時提交給開發(fā)人員進(jìn)行Bug修復(fù)。在Bug修復(fù)后進(jìn)行新的回歸測試，保證代碼質(zhì)量的穩(wěn)定性。為了將這個迭代過程不斷進(jìn)行下去，開發(fā)和測試都需要將持續(xù)集成服務(wù)器的項(xiàng)目構(gòu)建作為一件重要的事情看待。

瀑布開發(fā)模式中，測試與開發(fā)的配合流程如圖1所示：

1.2敏捷開發(fā)模式中測試與開發(fā)的配合

敏 捷 開 發(fā) 有 很 多 類 型：Lean（精 益 ）、XP（Extreme Programming，極限編程）、Scrum等。

本文以Scrum這種敏捷方式為例。Scrum的每個迭代周期稱為一個Sprint，一般2或3周。每個Sprint中，都會選擇一些功能（Scrum中稱為“用戶故事”）來完成，與瀑布開發(fā)不同的是，這些功能（用戶故事）是包含文檔、開發(fā)、測試等內(nèi)容的一個完整交付。

迭代完成一個個可交付的軟件版本，將設(shè)計(jì)、開發(fā)、測試融入到每個Sprint進(jìn)行迭代；而不是按階段地進(jìn)行項(xiàng)目流程劃分。

圖1　瀑布開發(fā)中測試與開發(fā)的配合流程

這是敏捷開發(fā)與瀑布開發(fā)模式的區(qū)別所在。

敏捷開發(fā)方式可以用圖2來表示：

圖2　敏捷開發(fā)方式示意圖

按照這種開發(fā)方式，傳統(tǒng)軟件工程方法（瀑布式開發(fā)）中的回歸測試、系統(tǒng)測試（功能測試、性能測試、安全性測試）等難以被完整地覆蓋到。如何在使用敏捷開發(fā)方法的同時，又不降低測試質(zhì)量是亟待處理的一個問題。

對于這個問題，本文建議將迭代周期（Sprint）區(qū)分為2中：Functional Sprint與Hardening Sprint。

1.2.1Functional Sprint

一個開發(fā)功能完成，開發(fā)人員進(jìn)行要執(zhí)行單元測試，測試人員進(jìn)行：新增功能的功能測試和可接受性測試（“簡單的回歸測試”），此外，可根據(jù)需要進(jìn)行一些安全性測試、壓力測試。

如果測試人員發(fā)現(xiàn)Bug，可以放入下一個Sprint，配合流程見圖3所示：

圖3　Functional Sprint測試與開發(fā)配合流程

具體的配合方式如圖4所示：

圖4　Functional Sprint測試與開發(fā)配合方式

1）當(dāng)組件基本開發(fā)完畢，開發(fā)人員將任務(wù)單放在自測欄下面。

2）如果準(zhǔn)備將該組件提交測試，開發(fā)人員將任務(wù)單放在測試欄下面。

3）如果組件通過測試，測試人員將任務(wù)單放在完成欄下面。這樣一個組件就走完了整個開發(fā)流程。

1.2.2Hardening Sprint

Hardening Sprint的周期要比Functional Sprint周期長，一般為4~8周。

這個過程中，開發(fā)人員不再開發(fā)新功能，主要是修復(fù)Bug。測試人員進(jìn)行的主要是回歸測試+系統(tǒng)測試。

假設(shè)Hardening Sprint能夠進(jìn)行2次系統(tǒng)測試。在進(jìn)行第一輪系統(tǒng)測試時，封存軟件版本；系統(tǒng)測試結(jié)束后，開發(fā)人員修復(fù)Bug，測試人員進(jìn)行迭代的回歸測試。影響軟件發(fā)布的Bug解決后，測試人員進(jìn)行第二輪系統(tǒng)測試，并封存軟件版本。

Hardening Sprint測試與開發(fā)的配合流程如圖5所示。

2　兩種開發(fā)模式中對測試人員的素質(zhì)要求

不管是采用瀑布開發(fā)還是敏捷開發(fā)，對測試人員的素質(zhì)要求是一致的。測試人員的素質(zhì)框圖如圖6所示：

測試人員所需要具有的關(guān)鍵素質(zhì)或能力可以概括為：

1）理解軟件測試在整個軟件工程中的流程，軟件測試如何與軟件需求、軟件架構(gòu)設(shè)計(jì)、軟件開發(fā)、軟件驗(yàn)收和發(fā)布等階段進(jìn)行配合。撰寫測試計(jì)劃。

2）對所測試的軟件有較強(qiáng)的業(yè)務(wù)理解：根據(jù)軟件需求和開發(fā)功能的要求，拆分出測試原始需求，能夠根據(jù)“用戶場景分析”和“功能交互分析”進(jìn)一步將測試需求分析為測試項(xiàng)。進(jìn)行測試分析，并撰寫測試方案。

3）熟悉軟件測試的工程方法：能夠利用“功能分解法”、“等價類劃分法”和“邊界值分析法”等工程方法，根據(jù)測試項(xiàng)設(shè)計(jì)出測試用例。

3　總結(jié)

本文分析了瀑布開發(fā)與敏捷開發(fā)中測試人員如何與開發(fā)進(jìn)行工作配合，以及在兩種開發(fā)模式中測試人員的工作內(nèi)容。并對兩種開發(fā)模式中對測試人員的統(tǒng)一素質(zhì)要求進(jìn)行了總結(jié)。

參考文獻(xiàn)

［1］ 曹向志.軟件測試項(xiàng)目實(shí)戰(zhàn)：技術(shù)、流程與管理［M］. 電子工業(yè)出版社， 2010.

Cao Xiang-zhi.Software testing project Combat： technology，process and management［M］.Electronic Industry Publishing House， 2010.

［2］ Mike Cohn.用戶故事與敏捷方法［M］.清華大學(xué)出版社，2010.

Mike Cohn.User Stories Applied：For Agile Software Development ［M］.Tsinghua university press， 2010.

［3］ Andrew Pham.Scrum實(shí)戰(zhàn)——敏捷軟件項(xiàng)目管理與開發(fā)［M］. 清華大學(xué)出版社， 2013.

Andrew Pham. Scrum combat -- agile software project management and development［M］.Tsinghua university press，2013.

［4］ Ken Schwaber. 30天軟件開發(fā)：告別瀑布擁抱敏捷［M］.人民郵電出版社， 2014.

圖5　Hardening Sprint測試與開發(fā)配合流程

圖6　測試人員的素質(zhì)要求

Ken Schwaber.30 days of software development： Farewell waterfall embrace agile［M］.People's Posts and Telecommunications Press，2014.

［5］ Patton，R.軟件測試［M］.機(jī)械工業(yè)出版社，2006.

Patton，R.Software testing.［M］.Machinery Industry Press，2006.

［6］ 楊波.一種軟件測試需求建模及測試用例生成方法［J］. 計(jì)算機(jī)學(xué)報(bào)， 2014/03， 37（3）：522-538.

Yang Bo.An Approach of Modeling Software Testing Requirements［J］.Chinese journal of computers，2014/03，37（3）： 522-538.

Test work combined with development in waterfall development model and agile development model

Zhang Jing，Yu Qi
（Nanjing Xinlian electronic Ltd.，210005）

Abstract：Traditional waterfall development method has obvious shortcomings for how to deal with the frequent software development changes.Some software development companies domain in power system or industry control are turning to the use of agile development.However，the requirements for testing in the agile development mode cannot be copied from agile development mode used in Internet companies.This paper compares the test combined with development process used in the waterfall development method，and puts forward the advice on how test cooperate with development in agile that suitable to traditional area such as power or industry .

Keywords：Waterfall development；Agile development；Test coordinate with development；Quality requirements for testers

作者簡介

張靜（1989-），女，工程師，本科，主要從事電力系統(tǒng)自動化方面的測試工作。

于琪（1984-），男，項(xiàng)目經(jīng)理，碩士，主要從事軟件開發(fā)管理工作