敏捷開(kāi)發(fā)的軟件測(cè)試過(guò)程概述

李嫚

摘 要：近年來(lái)，敏捷化開(kāi)發(fā)方式的流行，使得敏捷測(cè)試應(yīng)運(yùn)而生。它應(yīng)用新的測(cè)試流程、方法和實(shí)踐，精剪并改進(jìn)傳統(tǒng)的測(cè)試流程，如減少測(cè)試用例設(shè)計(jì)，增加與產(chǎn)品設(shè)計(jì)人員的交流。本文根據(jù)在敏捷化開(kāi)發(fā)項(xiàng)目組做測(cè)試工作的經(jīng)歷，介紹在敏捷開(kāi)發(fā)過(guò)程中的對(duì)于測(cè)試的一些體會(huì)和經(jīng)驗(yàn)。

關(guān)鍵詞：敏捷測(cè)試；軟件測(cè)試；測(cè)試執(zhí)行

1 敏捷測(cè)試人員的定位

敏捷化開(kāi)發(fā)近年來(lái)逐漸引起廣泛關(guān)注，它是一種遞增式的，持續(xù)迭代和不斷調(diào)整的開(kāi)發(fā)模式，它可以應(yīng)對(duì)快速變化的需求。通過(guò)不斷增量開(kāi)發(fā)和持續(xù)集成我們逐漸建立起軟件系統(tǒng)，可以看到系統(tǒng)的成長(zhǎng)。敏捷測(cè)試是適應(yīng)敏捷開(kāi)發(fā)方法而采用的新的測(cè)試流程。在敏捷開(kāi)發(fā)模式中，迭代周期短，需求變化快，敏捷測(cè)試總概括起來(lái)可以說(shuō)是對(duì)原有功能的回歸測(cè)試和對(duì)新功能的驗(yàn)收測(cè)試，根據(jù)系統(tǒng)的持續(xù)集成持續(xù)地對(duì)軟件質(zhì)量信息進(jìn)行反饋。

敏捷中測(cè)試人員又叫QA（質(zhì)量保證）。因此，從項(xiàng)目一開(kāi)始就需要讓全員達(dá)成一致：關(guān)注質(zhì)量，隨時(shí)構(gòu)建質(zhì)量，形成零缺陷文化。從用戶(hù)角度出發(fā)關(guān)注用戶(hù)使用，引導(dǎo)開(kāi)發(fā)人員能夠從用戶(hù)的角度去思考、設(shè)計(jì)和實(shí)現(xiàn)軟件，測(cè)試人員可以通過(guò)架構(gòu)預(yù)演等方式，從整體上把握產(chǎn)品，及時(shí)提出架構(gòu)上的問(wèn)題，以及一些組件化開(kāi)發(fā)的共享。測(cè)試人員需要對(duì)用戶(hù)故事及時(shí)反饋，以便團(tuán)隊(duì)的及時(shí)改進(jìn)以及持續(xù)改進(jìn)，與開(kāi)發(fā)緊密合作，形成技能互補(bǔ)，避免開(kāi)發(fā)老是測(cè)試不出問(wèn)題現(xiàn)象，以及測(cè)試不充分的情況。

2 敏捷測(cè)試的各個(gè)階段

針對(duì)敏捷開(kāi)發(fā)方法的敏捷測(cè)試不同于以往針對(duì)傳統(tǒng)開(kāi)發(fā)模式的測(cè)試，在敏捷團(tuán)隊(duì)中，測(cè)試是整個(gè)項(xiàng)目組的指向，它告訴大家現(xiàn)在到哪了，正在往哪個(gè)方向走，使得項(xiàng)目組基于這些可靠的信息作出正確的決定。不僅是測(cè)試員要保證質(zhì)量，而是整個(gè)項(xiàng)目組的每一個(gè)人都要對(duì)質(zhì)量負(fù)責(zé)。測(cè)試員不跟開(kāi)發(fā)人員糾纏錯(cuò)誤，而是幫助他們找到目標(biāo)，共同為達(dá)到項(xiàng)目的最終目標(biāo)而努力。敏捷測(cè)試也需要高度迭代工作、頻繁得到客戶(hù)的反饋，需要?jiǎng)討B(tài)調(diào)整測(cè)試計(jì)劃、測(cè)試的執(zhí)行，并且，敏捷測(cè)試人員參與到了更多的敏捷開(kāi)發(fā)活動(dòng)中，積極的影響了團(tuán)隊(duì)做出的決定和計(jì)劃。

2.1 驗(yàn)證需求和設(shè)計(jì)

需求和設(shè)計(jì)具體來(lái)說(shuō)一般包括：（1）由項(xiàng)目經(jīng)理根據(jù)需求文檔而編寫(xiě)的功能設(shè)計(jì)文檔；（2）由開(kāi)發(fā)人員根據(jù)功能文檔而編寫(xiě)設(shè)計(jì)文檔。作為測(cè)試人員，審核重點(diǎn)是檢查文檔對(duì)用戶(hù)需求定義的完整性、嚴(yán)密性和功能設(shè)計(jì)的可測(cè)性。

在測(cè)試初期，測(cè)試人員要學(xué)會(huì)做靜態(tài)測(cè)試，做好需求分析，做好對(duì)設(shè)計(jì)邏輯的分析。測(cè)試人員要更多的思考需求的可實(shí)現(xiàn)性，將自身作為第一用戶(hù)積極參與項(xiàng)目和系統(tǒng)的需求分析，設(shè)計(jì)和開(kāi)發(fā)。積極地參與前期工作，并迅速反饋給設(shè)計(jì)和開(kāi)發(fā)其靜態(tài)測(cè)試結(jié)果。要盡早的開(kāi)始測(cè)試，不要等待到功能完全做好才開(kāi)始測(cè)試。

2.2 測(cè)試計(jì)劃和測(cè)試用例

在敏捷開(kāi)發(fā)的過(guò)程中由于是根據(jù)每個(gè)用戶(hù)故事來(lái)估算時(shí)間的。開(kāi)發(fā)人員將對(duì)本次迭代所需要的完成的用戶(hù)故事進(jìn)行評(píng)估。開(kāi)發(fā)人員可以和客戶(hù)直接溝通，來(lái)確定每個(gè)用戶(hù)故事的優(yōu)先級(jí)。測(cè)試人員根據(jù)已審核通過(guò)的需求和設(shè)計(jì)編制測(cè)試計(jì)劃，設(shè)計(jì)測(cè)試用例。在前面提到的三種文檔中，功能設(shè)計(jì)文檔是主要依據(jù)。測(cè)試的這兩個(gè)文檔也要被項(xiàng)目經(jīng)理和開(kāi)發(fā)人員審核。

為使開(kāi)發(fā)人員能參與到測(cè)試用例的審閱中來(lái)并讓開(kāi)發(fā)人員迅速地了解測(cè)試的重點(diǎn)并給出相應(yīng)的意見(jiàn)和建議，以保證測(cè)試用例的質(zhì)量和可行性，確保測(cè)試工作的順利進(jìn)行，測(cè)試人員在出測(cè)試用例的同時(shí)，應(yīng)出一份測(cè)試用例映射，其中注明測(cè)試用例已覆蓋了哪些產(chǎn)品功能，具體每個(gè)產(chǎn)品功能對(duì)應(yīng)的測(cè)試用例編號(hào)，這樣在對(duì)測(cè)試用例進(jìn)行審閱的時(shí)候，能夠?qū)y(cè)試用例的覆蓋率一目了然，對(duì)覆蓋率不足的地方能夠及時(shí)給出意見(jiàn)。

2.3 測(cè)試執(zhí)行

在敏捷方法中，測(cè)試有兩種：?jiǎn)卧獪y(cè)試和接收測(cè)試。單元測(cè)試是由開(kāi)發(fā)人員來(lái)完成的，接收測(cè)試是由客戶(hù)代表來(lái)完成。由于我們客戶(hù)無(wú)法在現(xiàn)場(chǎng)，我們采取了，開(kāi)發(fā)人員做單元測(cè)試，測(cè)試人員做驗(yàn)證測(cè)試，最后由客戶(hù)進(jìn)行接收測(cè)試。在每個(gè)版本發(fā)布給客戶(hù)之前必須由測(cè)試人員進(jìn)行測(cè)試，發(fā)布版本之后由客戶(hù)做接收測(cè)試，提出需要修改的地方。需要修改的地方將在下一個(gè)發(fā)布完成。

為方便衡量項(xiàng)目的進(jìn)度，測(cè)試可每天測(cè)試完畢后提供測(cè)試的Bug趨勢(shì)，即將每天新生成的Bug數(shù)和每天被解決的Bug數(shù)標(biāo)成一個(gè)趨勢(shì)圖表。一般在項(xiàng)目的開(kāi)始階段新生Bug數(shù)曲線會(huì)呈上升趨勢(shì)，到項(xiàng)目中后期被解決Bug數(shù)曲線會(huì)趨于上升，而新生Bug數(shù)曲線應(yīng)下降，到項(xiàng)目最后，兩條曲線都趨向于零。

在執(zhí)行測(cè)試階段中，測(cè)試人員需要對(duì)已有的測(cè)試用例進(jìn)行及時(shí)的維護(hù)。通常以下兩種情況下要新增一些測(cè)試用例：一是對(duì)于當(dāng)初測(cè)試設(shè)計(jì)不周全的領(lǐng)域，二是對(duì)于外部的Bug，比如從客戶(hù)報(bào)告來(lái)的，沒(méi)有被現(xiàn)有測(cè)試用例所覆蓋。當(dāng)產(chǎn)品的功能設(shè)計(jì)出現(xiàn)更改時(shí)，所涉及的測(cè)試用例也要相應(yīng)地修改，使測(cè)試用例保持和現(xiàn)有的功能需求同步。

為更好地保證軟件質(zhì)量，規(guī)避風(fēng)險(xiǎn)，必須加強(qiáng)對(duì)中間版本的控制。例如，客戶(hù)要求或者計(jì)劃周五要提交版本，則周三一定要提交一個(gè)中間過(guò)程的版本進(jìn)行測(cè)試，也就是控制中間版本，避免所有的工作都?jí)旱胶笃谧罹o急的時(shí)候去完成。以前的項(xiàng)目中出現(xiàn)過(guò)項(xiàng)目前期很輕松，到后期Bug越來(lái)越多，開(kāi)發(fā)人員和測(cè)試人員都異常忙碌，經(jīng)常加班的情況。為減少后期工作量，規(guī)避風(fēng)險(xiǎn)，建議開(kāi)發(fā)每天做一個(gè)Build，或者按照完成一個(gè)功能特性就進(jìn)行一次Build，針對(duì)這個(gè)功能特性進(jìn)行測(cè)試，這樣就可以有效避免后期Bug越來(lái)越多的狀況發(fā)生，后期工作量也就會(huì)相應(yīng)減少，項(xiàng)目的質(zhì)量也會(huì)更有保證。在每次發(fā)布版本之前，測(cè)試人員要根據(jù)待發(fā)布的版本情況編寫(xiě)版本說(shuō)明，使客戶(hù)對(duì)發(fā)布的版本情況一目了然。版本說(shuō)明主要包括三方面的內(nèi)容：已經(jīng)修復(fù)的上個(gè)版本中存在的Bug，新的功能，此版本尚存在哪些比較大的問(wèn)題。

在每日立會(huì)上，測(cè)試人員可以簡(jiǎn)潔地講述一下當(dāng)天測(cè)試的重點(diǎn)部分，以及項(xiàng)目中存在哪些嚴(yán)重的Bug，讓開(kāi)發(fā)人員了解當(dāng)天測(cè)試的重點(diǎn)是什么，并提出自己的意見(jiàn)和建議。這樣加強(qiáng)了開(kāi)發(fā)與測(cè)試人員的交流和溝通，使測(cè)試工作能夠更加有效，更加順利地開(kāi)展。

2.4 需求管理

采用敏捷開(kāi)發(fā)模式的項(xiàng)目中，客戶(hù)對(duì)于需求的變更很頻繁。因此，需求管理是十分必要和重要的工作。整個(gè)項(xiàng)目進(jìn)行過(guò)程中，對(duì)不斷變化的需求，一定要作跟蹤，每次的需求變更都要有相應(yīng)的歷史記錄，可將每次的變更整理記錄到需求跟蹤文檔中，并使該文檔始終保持最新更新的狀態(tài)，與需求的變化保持同步，方便后期的管理和維護(hù)工作。

2.5 清理Bug

在項(xiàng)目開(kāi)發(fā)的末期，可以開(kāi)展“Bug大掃除”活動(dòng)。劃出一個(gè)專(zhuān)門(mén)的時(shí)間段，在這期間所有參與項(xiàng)目的人員，集中全部精力，搜尋項(xiàng)目的Bug。注意以下要點(diǎn)：（1）盡管這是一個(gè)測(cè)試活動(dòng)，但參與者并不僅限于測(cè)試人員。項(xiàng)目經(jīng)理，開(kāi)發(fā)人員甚至于高層管理人員都應(yīng)參加。目的是要集思廣益；（2）要鼓勵(lì)各部門(mén)，領(lǐng)域交叉搜索，因?yàn)樾碌乃悸泛鸵暯峭ǔＳ兄诎l(fā)現(xiàn)更多的Bug；（3）為調(diào)動(dòng)積極性，增強(qiáng)趣味性，可以適當(dāng)引入競(jìng)爭(zhēng)機(jī)制，比如當(dāng)活動(dòng)結(jié)束時(shí)，評(píng)出發(fā)現(xiàn)Bug最多，發(fā)現(xiàn)最嚴(yán)重Bug的個(gè)人，給以物質(zhì)和精神獎(jiǎng)勵(lì)。（4）可以分專(zhuān)題展開(kāi)，比如安全性、用戶(hù)界面可用性、國(guó)際化和本地化等等。