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/
