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

?

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

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

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

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

0　引言

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

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

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

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

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

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

1　正文

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

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

1）及時(shí)介入，了解需求。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.2.1Functional Sprint

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

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

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

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

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

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

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

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

1.2.2Hardening Sprint

Hardening Sprint的周期要比Functional Sprint周期長(zhǎng)，一般為4~8周。

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

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

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

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

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

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

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

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

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

3　總結(jié)

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

參考文獻(xiàn)

［1］ 曹向志.軟件測(cè)試項(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)目管理與開(kāi)發(fā)［M］. 清華大學(xué)出版社， 2013.

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

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

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

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

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

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

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

［6］ 楊波.一種軟件測(cè)試需求建模及測(cè)試用例生成方法［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

作者簡(jiǎn)介

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

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