摘要 隨著測試走向規(guī)范化管理，測試計(jì)劃成為測試經(jīng)理必須完成的重要任務(wù)之一，本文根據(jù)實(shí)踐經(jīng)驗(yàn)結(jié)合理論，探討如何制定軟件項(xiàng)目測試計(jì)劃。

　　關(guān)鍵字 測試計(jì)劃 變更

　　正文

　　軟件測試計(jì)劃作為軟件項(xiàng)目計(jì)劃的子計(jì)劃，在項(xiàng)目啟動(dòng)初期是必須規(guī)劃的。在越來越多公司的軟件開發(fā)中，軟件質(zhì)量日益受到重視，測試過程也從一個(gè)相對(duì)獨(dú)立的步驟越來越緊密嵌套在軟件整個(gè)生命周期中，這樣，如何規(guī)劃整個(gè)項(xiàng)目周期的測試工作;如何將測試工作上升到測試管理的高度都依賴于測試計(jì)劃的制定。測試計(jì)劃因此也成為測試工作的賴于展開的基礎(chǔ)。

　　一個(gè)好的測試計(jì)劃可以起到如下作用

　　1. 避免測試的“事件驅(qū)動(dòng)”

　　2. 使測試工作和整個(gè)開發(fā)工作融合起來

　　3. 資源和變更事先作為一個(gè)可控制的風(fēng)險(xiǎn)

　　測試計(jì)劃的模板在各個(gè)公司中都大同小異，在個(gè)人實(shí)踐中發(fā)現(xiàn)，測試計(jì)劃制定中存在的問題具有相似性，下面重點(diǎn)就這些相似的問題談?wù)勅绾沃贫ㄜ浖?xiàng)目測試計(jì)劃。

　　問題一：測試階段劃分

　　就通常軟件項(xiàng)目而言，基本上采用“瀑布型”開發(fā)方式，這種開發(fā)方式下，各個(gè)項(xiàng)目主要活動(dòng)比較清晰，易于操作。整個(gè)項(xiàng)目生命周期為“需求-設(shè)計(jì)-編碼-測試-發(fā)布-實(shí)施-維護(hù)”。然而，在制定測試計(jì)劃時(shí)候，有些測試經(jīng)理對(duì)測試的階段劃分還不是十分明晰，經(jīng)常性遇到的問題是把測試單純理解成系統(tǒng)測試，或者把把各類型測試設(shè)計(jì)(測試用例的編寫和測試數(shù)據(jù)準(zhǔn)備)全部放入生命周期的“測試階段”，這樣造成的問題是浪費(fèi)了開發(fā)階段可以并行的項(xiàng)目日程，另一方面造成測試不足。

　　合理的測試階段應(yīng)遵循下面劃分方法：

　　照上圖所述，相應(yīng)階段可以同步進(jìn)行相應(yīng)的測試計(jì)劃編制，而測試設(shè)計(jì)也可以結(jié)合在開發(fā)過程中實(shí)現(xiàn)并行，測試的實(shí)施即執(zhí)行測試的活動(dòng)即可連貫在開發(fā)之后。值得注意的是：單元測試和集成測試往往由開發(fā)人員承擔(dān)，因此這部分的階段劃分可能會(huì)安排在開發(fā)計(jì)劃而不是測試計(jì)劃中。

　　問題二：系統(tǒng)測試階段日程安排

　　劃分階段清楚了，隨之而來的問題是測試執(zhí)行需要多長的時(shí)間?標(biāo)準(zhǔn)的工程方法或CMM方式是對(duì)工作量進(jìn)行估算，然后得出具體的估算值。但是這種方法過于復(fù)雜，可以另辟專題討論。一個(gè)可操作的簡單方法是：根據(jù)測試執(zhí)行上一階段的活動(dòng)時(shí)間進(jìn)行換算，換算方法是與上一階段活動(dòng)時(shí)間1：1。1~1。5左右。舉個(gè)例子，對(duì)測試經(jīng)理來說，因?yàn)殚_發(fā)計(jì)劃可能包含了單元測試和集成測試，系統(tǒng)測試的時(shí)間大概是編碼階段(包含單元測試和集成測試)1到1。5倍。這種方法的優(yōu)點(diǎn)是簡單，依賴于項(xiàng)目計(jì)劃的日程安排，缺點(diǎn)是水分太多，難于量化。那么，可以采用的另一個(gè)簡單方法是經(jīng)驗(yàn)評(píng)估。評(píng)估方法如下：

　　1. 計(jì)算需求文檔的頁數(shù)，得出系統(tǒng)測試用例的頁數(shù)

　　需求頁數(shù)：系統(tǒng)測試用例頁數(shù) ≈ 1：1

　　2. 由系統(tǒng)測試用例頁數(shù)計(jì)算編寫系統(tǒng)測試用例時(shí)間

　　編寫系統(tǒng)測試用例時(shí)間 ≈ 系統(tǒng)測試用例頁數(shù)×1小時(shí)

　　3. 計(jì)算執(zhí)行系統(tǒng)測試用例時(shí)間

　　編寫系統(tǒng)用例用時(shí)：執(zhí)行系統(tǒng)測試用時(shí) ≈ 1：2

　　4. 計(jì)算回歸測試包含的時(shí)間

　　系統(tǒng)測試用時(shí)：回歸測試用時(shí)≈ 2：1

　　注：以上比值是個(gè)人工程經(jīng)驗(yàn)值，需要更正比值的測試經(jīng)理可以在具體實(shí)踐中收集數(shù)據(jù)。

　　基于以上方法優(yōu)點(diǎn)是需求為已知的，可以利用已知來推算未知，適用于需求是已知且相對(duì)穩(wěn)定的情況下;缺點(diǎn)是處于研發(fā)狀態(tài)的項(xiàng)目，需求不清晰的時(shí)候比較難計(jì)算?，F(xiàn)套用一個(gè)例子加于說明：需求文檔頁數(shù)為500，系統(tǒng)測試用例頁數(shù)推算為500，則編寫系統(tǒng)測試用例時(shí)間為500小時(shí)，執(zhí)行系統(tǒng)測試用例時(shí)間為1000小時(shí)，回歸測試需要500小時(shí)，加起來總共為2000小時(shí)，按一天8小時(shí)計(jì)算，共計(jì)250個(gè)工作日/人;假如一個(gè)月為22個(gè)工作日，則共計(jì)約11人/月，即投入4個(gè)人需要3個(gè)月左右時(shí)間工作量完成。當(dāng)然，這是系統(tǒng)測試需要的全部時(shí)間。根據(jù)測試階段劃分原則，設(shè)計(jì)用例時(shí)間可以和開發(fā)同步進(jìn)行，只需在測試階段中安排的時(shí)間為1500小時(shí)即4人2個(gè)月工作量。

　　(測試經(jīng)理在編寫測試計(jì)劃時(shí)候，測試進(jìn)度中的計(jì)劃開始/結(jié)束時(shí)間往往用如20050101-20051201的具體時(shí)間劃分方式，這樣引起的問題是當(dāng)項(xiàng)目計(jì)劃進(jìn)行變更的時(shí)候，測試計(jì)劃時(shí)間不得不隨時(shí)調(diào)整，這種變更可能是頻繁而瑣碎的，可以替代的辦法是取消這種方式，采用30工作日/2人或者2人月這種工作量記錄方式，這樣一來，只需在項(xiàng)目計(jì)劃中跟蹤階段的具體開始時(shí)間即可，不必反復(fù)修改測試計(jì)劃。)

　　值得注意的是：國內(nèi)大多數(shù)公司的測試時(shí)間都是不足的，不可能按照這樣的理想比例進(jìn)行運(yùn)作，因?yàn)闇y試執(zhí)行的時(shí)間實(shí)際上不可能占據(jù)整個(gè)項(xiàng)目周期的1/2，甚至要短于其中任何一個(gè)項(xiàng)目階段時(shí)間。即使是微軟的測試結(jié)束原則也并不是完成所有必需的測試，而是測試在按計(jì)劃結(jié)束的那一天結(jié)束!在測試時(shí)間不足的情況下，可參考下面項(xiàng)目計(jì)劃變更時(shí)的做法，因?yàn)橛?jì)劃變更也涉及到測試時(shí)間不足的情況。

　　問題三：變更的控制

　　測試計(jì)劃改變了已往根據(jù)任務(wù)進(jìn)行測試的方式，因此，為使測試計(jì)劃得到貫徹和落實(shí)，測試組人員必須及時(shí)跟蹤軟件開發(fā)的過程，對(duì)產(chǎn)品提交測試做準(zhǔn)備，測試計(jì)劃的目的，本身就是強(qiáng)調(diào)按規(guī)劃的測試戰(zhàn)略進(jìn)行測試，淘汰以往以任務(wù)為主的臨時(shí)性。在這種情況下，測試計(jì)劃中強(qiáng)調(diào)對(duì)變更的控制顯得尤為重要。

　　變更來源于以下幾個(gè)方面

　　1. 項(xiàng)目計(jì)劃的變更

　　2. 需求的變更

　　3. 測試產(chǎn)品版本的變更

　　4. 測試資源的變更

　　測試階段的風(fēng)險(xiǎn)主要是對(duì)上述變更所造成的不確定性，有效的應(yīng)對(duì)這些變更就能降低風(fēng)險(xiǎn)發(fā)生的幾率。要想計(jì)劃本身不成為空談和空白無用的紙質(zhì)文檔，對(duì)不確定因素的預(yù)見和事先防范必須做到心中有數(shù)。

　　對(duì)于項(xiàng)目計(jì)劃的變更，除了測試人員及時(shí)跟進(jìn)項(xiàng)目以外，項(xiàng)目經(jīng)理必須認(rèn)識(shí)到測試組也是項(xiàng)目成員，因此必須把這些變更信息及時(shí)通知到項(xiàng)目組，使得整個(gè)項(xiàng)目得到順延。項(xiàng)目計(jì)劃變更一般涉及都是日程變更，令人遺憾的是，往往為了進(jìn)度的原因，交付期限是既定的，項(xiàng)目經(jīng)理不得不減少測試的時(shí)間，這樣，執(zhí)行測試的時(shí)間就被壓縮了。在這種情況下，測試經(jīng)理常常固執(zhí)的認(rèn)為進(jìn)度縮減的唯一的方法就是向上級(jí)通報(bào)并主觀認(rèn)為產(chǎn)品質(zhì)量一定會(huì)下降，這種做法和想法不一定是正確的。由于時(shí)間不足，不能“完美”的執(zhí)行所有測試，為了保證質(zhì)量，第一種辦法是調(diào)整測試計(jì)劃中的測試策略和測試范圍，實(shí)踐中測試經(jīng)理常常忽略測試計(jì)劃的這個(gè)章節(jié)。調(diào)整的目的是重新檢查不重要的測試部分，調(diào)換測試的次序和減少測試規(guī)模，對(duì)測試類型重新組合擇優(yōu)，力求在限定時(shí)間內(nèi)做最重要部分的測試，可以把忽略部分留給確認(rèn)測試或現(xiàn)場測試。其他應(yīng)對(duì)辦法包括減少進(jìn)入測試的阻力，例如降低測試計(jì)劃中系統(tǒng)測試準(zhǔn)入準(zhǔn)則;分步提交測試，例如改成迭代方式增量測試;減少回歸測試的要求，例如開發(fā)人員實(shí)時(shí)修改，在測試計(jì)劃中對(duì)缺陷修復(fù)響應(yīng)時(shí)間和過程進(jìn)行約定;和公司QA商量進(jìn)行簡化配置管理，跳過正式發(fā)布環(huán)節(jié);缺陷進(jìn)行局部回歸而不是重新全部測試等等。

　　第二：項(xiàng)目進(jìn)行過程中最不可避免的就是需求的變更。那么，測試計(jì)劃中就不能進(jìn)行控制和約束的嗎?答案是未必。當(dāng)制定計(jì)劃時(shí)，如果項(xiàng)目需求處于動(dòng)態(tài)變化時(shí)，在測試用例章節(jié)就要進(jìn)行說明。許多測試經(jīng)理在編制測試用例時(shí)往往沒有把測試用例和測試數(shù)據(jù)進(jìn)行區(qū)分，因此，造成的問題是當(dāng)需求變化時(shí)辛辛苦苦設(shè)計(jì)的數(shù)據(jù)就作廢了。在這時(shí)，假使面臨一個(gè)需求動(dòng)態(tài)的項(xiàng)目，必須在計(jì)劃中對(duì)需求變更造成的測試(設(shè)計(jì))方式變化進(jìn)行說明，例如采用用例和數(shù)據(jù)分離、流程和界面分離、字典項(xiàng)和數(shù)據(jù)元素分離的設(shè)計(jì)方式，然后等到最終需求確定后細(xì)化測試設(shè)計(jì);另一個(gè)方面是最好制定一個(gè)變更周期的約定――尤其在執(zhí)行測試階段發(fā)現(xiàn)需求的變更――定義變更的最大頻度和重新測試的界限，計(jì)劃從一定程度上能夠降低不可預(yù)期需求變化造成的投入損失。值得注意的是：需求發(fā)生變更時(shí)測試經(jīng)理額外的工作是記住要在需求跟蹤矩陣上做記錄。

　　對(duì)于測試產(chǎn)品版本的變更，除了部分是由于需求變更造成之外，很有可能是由于修改缺陷引發(fā)的問題或配置管理不嚴(yán)格造成。眾所周知，測試必須是基于一個(gè)穩(wěn)定的“基線”進(jìn)行，否則，因反復(fù)修改造成測試資源和開發(fā)資源的浪費(fèi)是可觀的。合理的測試計(jì)劃在章節(jié)中應(yīng)增加一個(gè)測試更新管理的章節(jié)，在此章節(jié)明確更新周期和暫停測試的原則。例如，小版本的產(chǎn)品更新不能大于每天三次，一個(gè)相對(duì)大的版本不能每周大于1次，規(guī)定緊急發(fā)布產(chǎn)品僅限于何種類型的修改或變更，由誰負(fù)責(zé)統(tǒng)一維護(hù)和同步更新測試環(huán)境。測試計(jì)劃通常制定了準(zhǔn)入和準(zhǔn)出準(zhǔn)則，這是不夠的，要考慮測試暫停的時(shí)候，產(chǎn)品錯(cuò)誤發(fā)布或者服務(wù)器數(shù)據(jù)更新就是一個(gè)例子，暫停的時(shí)候如果測試經(jīng)理不進(jìn)行跟蹤，可能發(fā)生測試組等待測試而沒人通知繼續(xù)測試的情況，所以，增加更新周期和暫停測試原則是很有必要的。

　　最后，測試資源的變更是源自測試組內(nèi)部的風(fēng)險(xiǎn)而非開發(fā)組風(fēng)險(xiǎn)，當(dāng)測試資源不足或者沖突，測試部門不可能安排如此多的人手和足夠時(shí)間參與測試時(shí)，在測試計(jì)劃中的控制方法與測試時(shí)間不足相類似。沒有測試經(jīng)理愿意承擔(dān)資源不足的測試工作，只能說公司本身是否具備以質(zhì)量為主的體系或者項(xiàng)目經(jīng)理對(duì)產(chǎn)品質(zhì)量的重視程度如何決定了對(duì)測試資源投入的大小，最終產(chǎn)品質(zhì)量取決因素不僅僅在于測試經(jīng)理。為了排除這種風(fēng)險(xiǎn)，除了象時(shí)間不足、測試計(jì)劃變更時(shí)那樣縮減測試規(guī)模等等方法以外，測試經(jīng)理必須在人力資源和測試環(huán)境一欄標(biāo)出明確需要保證的資源，否則，必須將這個(gè)問題作為風(fēng)險(xiǎn)記錄。規(guī)避風(fēng)險(xiǎn)的辦法可能有：一，項(xiàng)目組的需求和實(shí)施人員參與系統(tǒng)測試;二，抽調(diào)不同模塊開發(fā)者進(jìn)行交叉系統(tǒng)測試或借用其他項(xiàng)目開發(fā)人員;三，組織客戶方進(jìn)行確認(rèn)測試或發(fā)布β版本。

　　盡管上面盡可能的描述了測試計(jì)劃如何制定才能“完美”，但是還存在的問題是對(duì)測試計(jì)劃的管理和監(jiān)控。一份計(jì)劃投入再多的時(shí)間去做也不能保證按照這份計(jì)劃進(jìn)行實(shí)施。好的測試計(jì)劃是成功的一半，另一半是對(duì)測試計(jì)劃的執(zhí)行。對(duì)小項(xiàng)目而言，一份更易于操作的測試計(jì)劃更為實(shí)用，對(duì)中型乃至大型項(xiàng)目來看，測試經(jīng)理的測試管理能力就顯得格外重要，要確保計(jì)劃不折不扣的執(zhí)行下去，測試經(jīng)理的人際諧調(diào)能力，項(xiàng)目測試的操作經(jīng)驗(yàn)、公司的質(zhì)量現(xiàn)狀都能夠?qū)?xiàng)目測試產(chǎn)生足夠的影響。另外，計(jì)劃也是“動(dòng)態(tài)的”!不必要把所有的因素都可能囊括進(jìn)去，也不必要針對(duì)這種變化額外制定“計(jì)劃的計(jì)劃”，測試計(jì)劃制定不能在項(xiàng)目開始后束之高閣，而是緊追項(xiàng)目的變化，實(shí)時(shí)進(jìn)行思考和貫徹，根據(jù)現(xiàn)實(shí)修改，然后成功實(shí)施，這才能實(shí)現(xiàn)測試計(jì)劃的最終目標(biāo)――保證項(xiàng)目最終產(chǎn)品的質(zhì)量!

　　參考文獻(xiàn)

　　[1].《實(shí)用軟件測試方法與應(yīng)用》 飛思科技產(chǎn)品研發(fā)中心 編者

　　[2].《有效軟件測試》 [美]Elfriede Dustin 著 新語 譯