軟件測試中對于測試計劃有效性問題的分析

但是，唯一有個問題讓一些組織者絞盡腦汁，那就是：如何讓自己的工作能盡量小的偏離自己的預定計劃目標，從而提高自己測試計劃的有效性呢?對于這個問題，我有一點自己的想法，可供參考。

由于測試計劃是一個測試項目必不可少的項目管理性文檔。它或簡單或復雜，其目 的都是為了讓項目能在預先計劃好的軌跡上運作，以盡量減少測試工作的過大投入，從而拉大投入成本與軟件利潤的比差，達到項目的最大收益。除了這個主要原因外，制定測試計劃還有一些附加原因，也就是：

1)讓測試工作盡量的可視化和可控化。

2)為更好的對測試團隊的工作能力有更真實的考核(即，執(zhí)行者在預定的時間和環(huán)境下完成任務的能力和質量)。

3)為測試的過程改進工作提供依據。

4)軟件開發(fā)流程中必要的文檔。

可見測試計劃的必要性。既然他是必要的，而且目的也說的很清楚了。那么我們不能把自己制定的測試計劃當成一紙空文，而應該把他更好的利用起來，以真正的體現(xiàn)它的價值所在。

下面是我對如何提高其利用率的幾點建議：

1、不要過渡的依賴于測試計劃模板。

現(xiàn)狀：

我們在拿到一個測試項目以后，我們一般的做法是：先看文檔;然后根據文檔分析系統(tǒng)功能;然后在要求的時間里就開始寫計劃了。寫測試計劃的過程是邊想邊寫，好像都不知道該寫些什么好。有的人就干脆把其他項目的測試計劃拿來，修改一下進度表和人員表，增刪一些測試方法等就完了事。我們做測試計劃的目的幾乎就成了應付檢查，不在于使用。

建議：

我們通過分析需求和系統(tǒng)功能，我們就應該對如何計劃測試工作胸有成竹了。制定測試計劃，我們必須先要做好以下幾件事情(那是我們制定計劃的時候所必須的東西)：

a)確定測試范圍。

b)根據測試項目的工作強度和難度來組織測試人員。

c)根據項目所提供的各項數(shù)據以及成員能力，評估風險，時間和資源消耗。

d)根據質量保證計劃以及項目所提供的數(shù)據資料，確定可行的測試方案(必要的話，還需對測試方案的可行性和風險性進行審查，使實施的風險可控化。)

e)在預計的測試時間段里，根據制定的測試方案確定時間進度。

f)測試過程中，對測試版本的控制(大型的項目，應該考慮附加《配制計劃》)

當我們把這些事情做好后，我們就可以正式的擬定測試計劃文檔了。在計劃文檔中寫清楚測試的對象、范圍，測試的時間、進度，測試所需要的人力和物力，測試方案說明，測試工作的各項標準定義，測試的風險評估以及預防措施等。

尤其在確定時間的進度時，最好不要把時間剛好排滿，要在時間的后期留有一個緩沖時間段，以應對意外突發(fā)事件。

　　

2、重把測試計劃的審核關。

現(xiàn)狀：

一個測試計劃文檔生成后，還不能算是完成計劃工作了，還必須對計劃進行評審，將其合法化。那么我們公司的評審者到底評審些什么呢?他們拿到要評審的計劃書，就主要關注一下文檔的書寫結構(看目錄)，再看看進度安排和實施方案，但就是不提出該實施方案在這個預定的進度中能否可行，以及風險評估是否合理，可能在他們的評審檢查項里就缺少“對計劃可信性和可行性的檢查”以及“計劃方案實施的風險性”的考慮。

建議：

計劃是拿來實施的，不是拿來當擺設的。計劃是否可行，是否行之有效，實施的風險是否可控制等等問題是我們在檢查的時候必須考慮的。如果我們只是在文檔字面上去檢查那些文字錯誤的東西，是否太不負責任了呢?試問，如果在通過這樣的計劃評審后，在實施中，遇到風險過大等諸多問題，這個責任是誰來擔呢?

所以我們檢查計劃，字面錯誤這種不痛不癢的問題幾乎可以忽略它，這個計劃能不能用才是關鍵。所以，我們應該主要檢查：

1)我們測試的對象是什么?

2)在什么環(huán)境下實施我們的測試工作?

3)我們的測試所要花費的時間、經費和資源(最好還是不要超出預算的為好，不然可能老板不支持我們的工作，反倒是個麻煩了!嘿嘿)?

4)制定的實施方案是否可行性?

5)制定的實施方案所擔當?shù)娘L險系數(shù)有多高?

6)是否還有更好的可降低風險的實施方案?

7)我們的測試工作以什么樣的來衡量我們的工作成績?(甚至是對工作的獎懲辦法等)

8)是否有對于工作風險的控制方案。

9)工作中，任務交代的是否夠清楚?以免讓執(zhí)行者隨意瞎搞，導致對其測試工作不可控。

10)項目成員對這個要測試的對象的理解程度有多深?

　　

11)測試人員的組織和管理方案是否可靠?

3、測試計劃不是一紙空文。

現(xiàn)狀：

一個很讓人懷疑其可行性的測試計劃通過之后，下一步工作就是把它放到共享服務器上，供項目管理部檢查，最后——結束了。直到項目結項的時候，才把這個都快“發(fā)霉”的計劃文檔翻出來，準備結項工作。而且對于計劃中沒有完成的任務也不怎么提(因為大家都在擔心一個問題：如果提出來，結不了項，怎么辦?)。因為我們似乎都是很盡職的在發(fā)揚“揚長避短”的“優(yōu)良”作風。

建議：

QA人員必須嚴格按制定的計劃進行過程檢查工作。一旦發(fā)現(xiàn)實施的計劃與預定的計劃有出入。應及時通報相關人員，了解其偏離計劃的原因，盡快處理好計劃實施不到位的問題。

4、實行計劃跟蹤。

現(xiàn)狀：

計劃中編寫的時間進度表，在真正的實施中是很少用的。每個時間段里要生成什么工作成果，要評審什么文檔，項目管理部似乎也在關心。但他們似乎只關心成果數(shù)量，而工作成果質量工作似乎被項目管理工作所取代了(QA被項目部同化了)。試問，一個項目真正是想要十幾個甚至更多的沒有實際意義的文檔，還是要一個高質量的可使用的文檔呢?對于這個問題，似乎走入了一個面子工程的地步(過程進行的風風火火，結果是一塌糊涂)。比如：在評審各項工作成果的時候，只檢查字面的東西，而對于這個工作成果到底是不是這個項目的工作成果他們也不怎么懷疑?難怪很多項目文檔描述的東西和實際開發(fā)出來的東西對不上號呢!(如：SRM系統(tǒng))

建議：

對于在計劃中提到的各階段必須生成的工作成果是否存在的問題，項目管理部也必須嚴格監(jiān)督。而最重要的工作成果質量問題，應該由QA人員組織評審人員進行評審。如果工作成果評審未通過，堅決不能啟動下一階段的工作(但如果時間不充裕的話，為了不耽誤下一階段工作的如期進行，可以提前準備下階段的資料)。不能因為時間緊迫，而放寬對工作成果質量的檢查。

5、計劃變更，必須可控(如：變更的風險性審查和變更通知等)。

現(xiàn)狀：

當計劃實施過程中，需要變動計劃的時候，根本不走變更流程，直接由經理修改了事。他們的理由是：走變更流程太麻煩，很浪費時間，怕拖延計劃進度。如果項目順利完成到好，但如果項目出現(xiàn)任何閃失，那就在這個責任問題上，可能會激化各部門之間的矛盾。而且修改過的計劃即不通過評審，也不加以通知報告了，不知情的人還在努力的在原計劃中奮斗工作著呢!有可能導致項目就此失去項目管理部的控制(難怪項目管理部的項目管理控制工作是如此的困難)。

建議：

對計劃中的重大變動問題，必須向項目管理部提出變動申請。項目管理部必須對該申請進行嚴格審核，考慮其變動的風險性問題，而不能一有申請來，就通通的給通過了。通過審核的申請，就可以修改計劃了，計劃在做出相應變動修改之后，必須進行再次評審通過才可生效。再次評審通過后的計劃，必須及時替換原有計劃文件，并通知所有項目成員按新的計劃實施。

6、定期在報告中匯報計劃執(zhí)行情況。

現(xiàn)狀：

在計劃實施過程中，執(zhí)行者們很少有自覺寫工作日志或階段工作報告的習慣。

建議：

在每個階段結束后，應該向管理部門提交一份關于該階段的計劃任務完成情況的報告。管理部應嚴格審查該階段的工作匯報，及時處理工作所遇到的問題，以避免問題在以下的階段中繼續(xù)擴散或延續(xù)。

7、當計劃無法繼續(xù)實施時，及時通報相關人員(不能擅自自定義計劃)。

現(xiàn)狀：

在計劃實施過程中，遇到無法在現(xiàn)有的環(huán)境下繼續(xù)執(zhí)行計劃時，經理開始想辦法另辟蹊徑了，從而放棄原方案，開辟一條新道路給大家走?？赡苤钡浇Y項的那一天，項目管理部才發(fā)現(xiàn)我們實際所做的工作于我們的原計劃上有很大的出入。(難怪項目管理部對我們測試甚至整個項目的計劃實施管理控制上，像個局外人呢!)

建議：

在計劃實施過程中，遇到無法在現(xiàn)有的環(huán)境下繼續(xù)執(zhí)行計劃時，不能擅自調整計劃方案，應該及時通報上級管理部門，以便及時處理計劃方案調整的問題。對于計劃方案的調整，必須通知其他相關人員，做好調整工作。加強各個部門的溝通。以免項目失控。

以上是幾點關于測試計劃的實施有效性問題的微薄見解，希望以此引起相關人員/部門的重視，并做出更好的方案，以完善此方面的問題。而對于其中提到的各項審查的檢查項等問題的定義，在以后的工作中，再繼續(xù)加以完善。也希望公司的每個人都為了以后更好的做好項目而積極努力。