軟件測試的組織與管理計劃

作為軟件的重要環(huán)節(jié)，軟件測試越來越受到人們的重視。隨著軟件開發(fā)規(guī)模的增大、復雜程度的增加，以尋找軟件中的錯誤為目的的測試工作就顯得更加困難。然而，為了盡可能多地找出中的錯誤，生產(chǎn)出高的軟件產(chǎn)品，加強對測試工作的組織和管理就顯得尤為重要。從軟件的生存周期看，測試往往指對程序的測試，這樣做的優(yōu)點是被測對象明確，測試的可*作*相對較強。但是，由于測試的依據(jù)是規(guī)格說明書、文檔和使用說明書，如果設計有錯誤，測試的質(zhì)量就難以保證。即使測試后發(fā)現(xiàn)是設計的錯誤，這時，修改的代價是相當昂貴的。因此，較理想的做法應該是對軟件的開發(fā)過程，按軟件工程各階段形成的結果，分別進行嚴格的審查。軟件的生命周期可用圖1的表示。為了確保軟件的質(zhì)量，對圖1的過程應進行嚴格的管理。雖然測試是在實現(xiàn)且證后進行的，實際上，測試的準備工作在分析和設計階段就開始了。軟件測試計劃作為軟件項目計劃的子計劃，在項目啟動初期是必須規(guī)劃的。在越來越多公司的軟件開發(fā)中，軟件質(zhì)量日益受到重視，測試過程也從一個相對獨立的步驟越來越緊密嵌套在軟件整個生命周期中，這樣，如何規(guī)劃整個項目周期的測試工作;如何將測試工作上升到測試管理的高度都依賴于測試計劃的制定。測試計劃因此也成為測試工作的賴于展開的基礎。一個好的測試計劃可以起到如下作用1.避免測試的“事件驅(qū)動”2.使測試工作和整個開發(fā)工作融合起來3.資源和變更事先作為一個可控制的風險測試計劃的模板在各個公司中都大同小異，在個人實踐中發(fā)現(xiàn)，測試計劃制定中存在的問題具有相似*，下面重點就這些相似的問題談談如何制定軟件項目測試計劃。問題一：測試階段劃分就通常軟件項目而言，基本上采用“瀑布型”開發(fā)方式，這種開發(fā)方式下，各個項目主要活動比較清晰，易于*作。整個項目生命周期為“需求-設計-編*-測試-發(fā)布-實施-維護”。然而，在制定測試計劃時候，有些測試經(jīng)理對測試的階段劃分還不是十分明晰，經(jīng)常*遇到的問題是把測試單純理解成系統(tǒng)測試，或者把把各類型測試設計(測試用例的編寫和測試數(shù)據(jù)準備)全部放入生命周期的“測試階段”，這樣造成的問題是浪費了開發(fā)階段可以并行的項目日程，另一方面造成測試不足。相應階段可以同步進行相應的測試計劃編制，而測試設計也可以結合在開發(fā)過程中實現(xiàn)并行，測試的實施即執(zhí)行測試的活動即可連貫在開發(fā)之后。值得注意的是：單元測試和集成測試往往由開發(fā)人員承擔，因此這部分的階段劃分可能會安排在開發(fā)計劃而不是測試計劃中。問題二：系統(tǒng)測試階段日程安排劃分階段清楚了，隨之而來的問題是測試執(zhí)行需要多長的時間?標準的工程方法或CMM方式是對工作量進行估算，然后得出具體的估算值。但是這種方法過于復雜，可以另辟專題討論。一個可*作的簡單方法是：根據(jù)測試執(zhí)行上一階段的活動時間進行換算，換算方法是與上一階段活動時間1：1。1~1。5左右。舉個例子，對測試經(jīng)理來說，因為開發(fā)計劃可能包含了單元測試和集成測試，系統(tǒng)測試的時間大概是編*階段(包含單元測試和集成測試)1到1。5倍。這種方法的優(yōu)點是簡單，依賴于項目計劃的日程安排，缺點是水分太多，難于量化。那么，可以采用的另一個簡單方法是經(jīng)驗評估。評估方法如下：1.計算需求文檔的頁數(shù)，得出系統(tǒng)測試用例的頁數(shù)需求頁數(shù)：系統(tǒng)測試用例頁數(shù)≈1：12.由系統(tǒng)測試用例頁數(shù)計算編寫系統(tǒng)測試用例時間編寫系統(tǒng)測試用例時間≈系統(tǒng)測試用例頁數(shù)×1小時3.計算執(zhí)行系統(tǒng)測試用例時間編寫系統(tǒng)用例用時：執(zhí)行系統(tǒng)測試用時≈1：24.計算回歸測試包含的時間系統(tǒng)測試用時：回歸測試用時≈2：1注：以上比值是個人工程經(jīng)驗值，需要更正比值的測試經(jīng)理可以在具體實踐中收集數(shù)據(jù)基于以上方法優(yōu)點是需求為已知的，可以利用已知來推算未知，適用于需求是已知且相對穩(wěn)定的情況下;缺點是處于研發(fā)狀態(tài)的項目，需求不清晰的時候比較難計算?，F(xiàn)套用一個例子加于說明：需求文檔頁數(shù)為500，系統(tǒng)測試用例頁數(shù)推算為500，則編寫系統(tǒng)測試用例時間為500小時，執(zhí)行系統(tǒng)測試用例時間為1000小時，回歸測試需要500小時，加起來總共為2000小時，按一天8小時計算，共計250個工作日/人;假如一個月為22個工作日，則共計約11人/月，即投入4個人需要3個月左右時間工作量完成。當然，這是系統(tǒng)測試需要的全部時間。根據(jù)測試階段劃分原則，設計用例時間可以和開發(fā)同步進行，只需在測試階段中安排的時間為1500小時即4人2個月工作量。(測試經(jīng)理在編寫測試計劃時候，測試進度中的計劃開始/結束時間往往用如20050101-20051201的具體時間劃分方式，這樣引起的問題是當項目計劃進行變更的時候，測試計劃時間不得不隨時調(diào)整，這種變更可能是頻繁而瑣碎的，可以替代的辦法是取消這種方式，采用30工作日/2人或者2人月這種工作量記錄方式，這樣一來，只需在項目計劃中跟蹤階段的具體開始時間即可，不必反復修改測試計劃。)值得注意的是：國內(nèi)大多數(shù)公司的測試時間都是不足的，不可能按照這樣的理想比例進行運作，因為測試執(zhí)行的時間實際上不可能占據(jù)整個項目周期的1/2，甚至要短于其中任何一個項目階段時間。即使是微軟的測試結束原則也并不是完成所有必需的測試，而是測試在按計劃結束的那一天結束!在測試時間不足的情況下，可參考下面項目計劃變更時的做法，因為計劃變更也涉及到測試時間不足的情況。問題三：變更的控制測試計劃改變了已往根據(jù)任務進行測試的方式，因此，為使測試計劃得到貫徹和落實，測試組人員必須及時跟蹤軟件開發(fā)的過程，對產(chǎn)品提交測試做準備，測試計劃的目的，本身就是強調(diào)按規(guī)劃的測試戰(zhàn)略進行測試，淘汰以往以任務為主的臨時*。在這種情況下，測試計劃中強調(diào)對變更的控制顯得尤為重要。變更來源于以下幾個方面1.項目計劃的變更2.需求的變更3.測試產(chǎn)品版本的變更4.測試資源的變更測試階段的風險主要是對上述變更所造成的不確定*，有效的應對這些變更就能降低風險發(fā)生的幾率。要想計劃本身不成為空談和空白無用的紙質(zhì)文檔，對不確定因素的預見和事先防范必須做到心中有數(shù)。對于項目計劃的變更，除了測試人員及時跟進項目以外，項目經(jīng)理必須認識到測試組也是項目成員，因此必須把這些變更信息及時通知到項目組，使得整個項目得到順延。項目計劃變更一般涉及都是日程變更，令人遺憾的是，往往為了進度的原因，交付期限是既定的，項目經(jīng)理不得不減少測試的時間，這樣，執(zhí)行測試的時間就被壓縮了。在這種情況下，測試經(jīng)理常常固執(zhí)的認為進度縮減的唯一的方法就是向上級通報并主觀認為產(chǎn)品質(zhì)量一定會下降，這種做法和想法不一定是正確的。由于時間不足，不能“完美”的執(zhí)行所有測試，為了保證質(zhì)量，第一種辦法是調(diào)整測試計劃中的測試策略和測試范圍，實踐中測試經(jīng)理常常忽略測試計劃的這個章節(jié)。調(diào)整的目的是重新檢查不重要的測試部分，調(diào)換測試的次序和減少測試規(guī)模，對測試類型重新組合擇優(yōu)，力求在限定時間內(nèi)做最重要部分的測試，可以把忽略部分留給確認測試或現(xiàn)場測試。其他應對辦法包括減少進入測試的阻力，例如降低測試計劃中系統(tǒng)測試準入準則;分步提交測試，例如改成迭代方式增量測試;減少回歸測試的要求，例如開發(fā)人員實時修改，在測試計劃中對缺陷修復響應時間和過程進行約定;和公司QA商量進行簡化配置管理，跳過正式發(fā)布環(huán)節(jié);缺陷進行局部回歸而不是重新全部測試等等。第二：項目進行過程中最不可避免的就是需求的變更。那么，測試計劃中就不能進行控制和約束的嗎?答案是未必。當制定計劃時，如果項目需求處于動態(tài)變化時，在測試用例章節(jié)就要進行說明。許多測試經(jīng)理在編制測試用例時往往沒有把測試用例和測試數(shù)據(jù)進行區(qū)分，因此，造成的問題是當需求變化時辛辛苦苦設計的數(shù)據(jù)就作廢了。在這時，假使面臨一個需求動態(tài)的項目，必須在計劃中對需求變更造成的測試(設計)方式變化進行說明，例如采用用例和數(shù)據(jù)分離、流程和界面分離、字典項和數(shù)據(jù)元素分離的設計方式，然后等到最終需求確定后細化測試設計;另一個方面是最好制定一個變更周期的約定――尤其在執(zhí)行測試階段發(fā)現(xiàn)需求的變更――定義變更的最大頻度和重新測試的界限，計劃從一定程度上能夠降低不可預期需求變化造成的投入損失。值得注意的是：需求發(fā)生變更時測試經(jīng)理額外的工作是記住要在需求跟蹤矩陣上做記錄。對于測試產(chǎn)品版本的變更，除了部分是由于需求變更造成之外，很有可能是由于修改缺陷引發(fā)的問題或配置管理不嚴格造成。眾所周知，測試必須是基于一個穩(wěn)定的“基線”進行，否則，因反復修改造成測試資源和開發(fā)資源的浪費是可觀的。合理的測試計劃在章節(jié)中應增加一個測試更新管理的章節(jié)，在此章節(jié)明確更新周期和暫停測試的原則。例如，小版本的產(chǎn)品更新不能大于每天三次，一個相對大的版本不能每周大于1次，規(guī)定緊急發(fā)布產(chǎn)品僅限于何種類型的修改或變更，由誰負責統(tǒng)一維護和同步更新測試環(huán)境。測試計劃通常制定了準入和準出準則，這是不夠的，要考慮測試暫停的時候，產(chǎn)品錯誤發(fā)布或者服務器數(shù)據(jù)更新就是一個例子，暫停的時候如果測試經(jīng)理不進行跟蹤，可能發(fā)生測試組等待測試而沒人通知繼續(xù)測試的情況，所以，增加更新周期和暫停測試原則是很有必要的。最后，測試資源的變更是源自測試組內(nèi)部的風險而非開發(fā)組風險，當測試資源不足或者沖突，測試部門不可能安排如此多的人手和足夠時間參與測試時，在測試計劃中的控制方法與測試時間不足相類似。沒有測試經(jīng)理愿意承擔資源不足的測試工作，只能說公司本身是否具備以質(zhì)量為主的體系或者項目經(jīng)理對產(chǎn)品質(zhì)量的重視程度如何決定了對測試資源投入的大小，最終產(chǎn)品質(zhì)量取決因素不僅僅在于測試經(jīng)理。為了排除這種風險，除了象時間不足、測試計劃變更時那樣縮減測試規(guī)模等等方法以外，測試經(jīng)理必須在人力資源和測試環(huán)境一欄標出明確需要保證的資源，否則，必須將這個問題作為風險記錄。規(guī)避風險的辦法可能有：一，項目組的需求和實施人員參與系統(tǒng)測試;二，抽調(diào)不同模塊開發(fā)者進行交叉系統(tǒng)測試或借用其他項目開發(fā)人員;三，組織客戶方進行確認測試或發(fā)布β版本。盡管上面盡可能的描述了測試計劃如何制定才能“完美”，但是還存在的問題是對測試計劃的管理和監(jiān)控。一份計劃投入再多的時間去做也不能保證按照這份計劃進行實施。好的測試計劃是成功的一半，另一半是對測試計劃的執(zhí)行。對小項目而言，一份更易于*作的測試計劃更為實用，對中型乃