三、執(zhí)行測試
輸入:
·已批準的測試文檔(測試計劃、用例、程序)
·如果適用測試工具,自動化測試軟件和編寫好的腳本
·設計的變更(變更請求)
·測試數據
·測試和項目組的可用性(項目人員,測試小組)
·概要和詳細設計文檔(需求,軟件設計)
·通過配置/構建人員能夠完全轉移到測試環(huán)境(單元測試過的代碼)的開發(fā)環(huán)境
·測試就緒文檔
·修訂文檔
輸出:
·代碼的變更(測試修復項)
·作為一種測試的結果(測試文檔問題),測試文檔沒有說明的問題
·設計時發(fā)現的問題,反饋給開發(fā)人員和客戶(需求,設計,代碼問題)
·測試事故的正式記錄(問題跟蹤)
·為向下一級別轉移而準備的基線化包(已測試的源代碼和對象代碼)
·測試結果的日志和總結
·已批準和帶有修訂測試交付項的簽署文檔(已更新的交付項)
過程:
·在執(zhí)行階段中應召開Checkpoint 會議。(如果由需要,)每天應召開Checkpoint 會議處理和討論測試中的問題,狀態(tài)和活動。
·通過采用系統的手段跟進測試文檔來完成測試的執(zhí)行。當執(zhí)行測試程序的每一個包時,為了記錄程序的執(zhí)行和測試程序找出的任何缺陷,應該將問題記錄到測試執(zhí)行日志中。測試程序執(zhí)行后的輸出當作測試結果。
·為了確定是否可以得到預期的結果,測試結果應該由適當的項目組員評估(,適合于測試的所有級別)。記錄并和軟件開發(fā)經理/程序員討論所有差異/異常,為了以后的調查和解決應該將它文檔化(每個客戶可能有不同的記錄日志和報告bug/defect的過程,通過Configuration Management (CM)小組校驗這些過程)。通過/失敗的準則用來確定問題的嚴重級別,結果記錄到測試總結報告中。
·根據客戶的風險評估來定義在系統測試中發(fā)現的問題嚴重級別并記錄到他們選擇的跟蹤工具中。
·基于問題的嚴重級別有目的的修復并提交到測試環(huán)境中。被修改的問題應進行回歸測試并將沒有問題的修復項轉移到新的基線中。在測試完成后,測試組的成員應準備一份總結報告?偨Y報告要由項目經理,客戶,SQA和/或測試組長復審。
·在證實達到一個指定的測試級別后,配置經理應根據配置管理計劃中的要求整理發(fā)布的軟件組件并轉移到下一個測試級別。軟件只有在客戶正式驗收之后才可以轉移到生產環(huán)境中。
·測試小組復審在測試和更新文檔時發(fā)現的測試文檔問題。一些問題可能是由于技術性和功能性之間不一致或修改所造生的。
相關推薦:考試吧策劃:2010年軟件水平考試完全指南北京 | 天津 | 上海 | 江蘇 | 山東 |
安徽 | 浙江 | 江西 | 福建 | 深圳 |
廣東 | 河北 | 湖南 | 廣西 | 河南 |
海南 | 湖北 | 四川 | 重慶 | 云南 |
貴州 | 西藏 | 新疆 | 陜西 | 山西 |
寧夏 | 甘肅 | 青海 | 遼寧 | 吉林 |
黑龍江 | 內蒙古 |