BM對測試計劃的評審記錄

IBM對測試計劃的評審記錄

    最近公司做的項目要由IBM監理進行評審才可。呵呵，這也讓我們看到了IBM是怎樣做測試的。呵呵。下面把測試計劃的評審記錄放在這里，希望大家能共同學習一下呀。

1. 會議評審內容。

（1）  測試計劃的名稱不合理，應改為系統集成測試&用戶接收測試測試計劃，如果用以前的測試計劃的名稱則應包括單元測試部分。

（2） 測試計劃文檔的名稱應加上版本1.0，以便以后對文檔版本的管理。

（3） 文檔2.0中用戶接收組應與用戶溝通確定用戶測試組的負責人

（4）  文檔3定義一部分應加入Uat和Sit的定義目標，定義要再清楚的補充一下，詳細資料楊威那有可以借鑒一下

（5）  文檔4參考資料一部分將b、c去掉，同時添加參考資料的版本信息。

（6）  文檔5測試內容部分應添加場景部分、數據部分、回歸部分（哪些需要做回歸、哪些不需要做回歸）。要寫清楚測試的重點是什么，關鍵回歸路徑確定清楚。

不需要測試的地方要寫明白（安裝、備份、維護測試），系統廁所和用戶確認兩個測試階段的測試重點不同，應在此處體現出來。

本次測試共分兩種測試即功能測試和非功能測試，其中功能測試包括業務測試和功能測試，非功能測試為壓力測試。

（7）  文檔6.1部分應寫明了進入系統集成測試和用戶確認測試的準則，即一些量化指標，如程序已經達到了這個量化指標（某些重點功能已經完成），才能進入系統集成測試或用戶確認測試。

（8）  文檔6測試環境準備就緒前建議加一個測試數據的準備，寫清楚系統集成測試采用模擬數據測試，用戶確認測試采用真實數據測試，這一方面還需要會后再具體討論一下。

（9）  文檔7.2測試進度中只有兩個測試人員，比較緊張，要將人員緊張的風險列出來。

SIT和UAT可以并行進行，建議添加UAT執行計劃和SIT執行計劃，也可以將這兩個執行計劃都寫在總計劃中。

回歸主要場景和業務功能在此處應該寫明白。測試中回歸需要幾輪回歸，每輪回歸所執行的場景和功能也要寫明白。關鍵的回歸路經很重要，建議寫出來。也可以采取兩輪迭代的方式回歸測試。建議添加用例規約。

（10）文檔7.3缺陷的等級定義不明確，會后再考慮一下，看IBM是否可以建議一下。

（11）文檔7.4應添加程序更新的工作流程，如幾點更新，由誰來做更新。測試跟蹤匯總建議每天進行一次，每天與項目經理進行一次測試匯總。

（12）文檔7.5與6結合一下，或去掉7.5的準入準出規則

（13）文檔8里面添加人員風險。

（14）文檔9測試環境中應寫明系統集成測試和用戶確認測試的環境是否相同，添加外圍系統接口實現的拓撲圖。

（15）文檔10和文檔11結合起來叫做測試工具，寫明沒有回歸測試工具，并分析其風險。

原文轉自：http://www.kjueaiud.com