【正文】 ? 評審的形式 ? 走查：作者將測試需求在現場向一組同事介紹，以收集大家的意見。將上述步驟分析、確定的開發(fā)需求、測試需求、測試類型填入測試跟蹤需求矩陣。 ? 安全性測試：側重于確保測試目標數據只供預訂好的那些參與者訪問。 質量特性對應表 原始需求描述 標識 測試要點 質量特性 1 輸入符合字典要求的各信息后執(zhí)行保存 ，檢查保存是否成功； 功能性 / 適合性 2 檢查每個輸入項的數據長度是否遵循數據字典的要求； 功能性 / 適合性、可靠性 / 容錯性 3 檢查每個輸入項的數據類型是否遵循數據字典的要求； 功能性 / 適合性、可靠性 / 容錯性 4 檢查“培訓費用”是否滿足規(guī)定的精度要求； 功能性 / 準確性 5 檢查在培訓的起止時間早晚于截止時間時，所增加的記錄是否保存成功； 功能性 / 適合性 一條完整的培訓信息包括培訓的主題、證書、內容、起止時間、費用、地點、機構，其中培訓的主題、內容、起止時間、費用、機構為必填項。 ? 需求采集的提取方法： ? 通過列表的形式對軟件開發(fā)需求進行梳理，形成 原始測試需求列表 ，列表的內容包括需求標識、原始測試需求描述、信息來源。 ? 測試需求是衡量測試覆蓋率的重要指標。 ? 可靠性 ? 容錯性：在軟件出現故障或違反其指定接口的情況下，軟件產品維持規(guī)定的性能級別的能力。 ? 完整性測試：側重于評估測試目標的健壯性（防止故障）和語言、語法和資源用途的技術一致性。 易 用性 / 易操作性 用戶界面測試 ? 建立測試需求跟蹤矩陣，對測試需求進行管理。相互評審是最不正式的一種評審形式，但應用方便、有效。 ? 小組評審：通過正式的小組會議完成評審工作，是有計劃的和結構化的評審方式。 H R M I S 2 . 0 測試需求跟蹤矩陣 軟件需求 測試需求 軟件需求標識 軟件需求描述 測試需求標識 測試要點 測試類型 1 輸入符合字典要求的各信息后執(zhí)行保存 ，檢查保存是否成功 ； 功能測試 2 檢查每個輸入項的數據長度是否遵循數據字典的要求； 功能測試、完整性測試 3 檢查每個輸入項的數據類型是否遵循數據字典的要求； 功能測試、完整性測試 4 檢查“培訓費用”是否滿足規(guī)定的精度要求； 功能測試 5 檢查在培訓的起止時間早晚于截止時間時，所增 加的記錄是否保存成功； 功能測試 基本信息管理 增 加 員工信息 一條完整的培訓信息包括培訓的主題、證書、內容、起止時間、費用、地點、機 構，其中培訓的主題、內容、起止時間、費用、機構為必填項。 ? 結構測試：側重于評估測試目標對其設計和形式的遵循性。 6 檢查“培訓主題”、“培訓內 容”、“起止時間”、“培訓費用”、“培訓機構”是否為必填項； 功能性 / 適合性 質量特性對應表 原始需求描述 標識 測試要點 質量特性 7 驗證系統對數據重復的檢查。 ? 軟件需求獲取的來源信息 作為信息來源。即，它們必須有一個可觀察、可評測的結果，無法核實的需求不是測試需求； ? 測試需求應指明滿足需求的正常的前置條件，同時也要指明不滿足需求時的出錯條件； ? 測試需求不涉及具體的測試數據，測試數據設計是測試設計環(huán)節(jié)應解決的內容。 ? 進行細化和分解還需考慮： ? 需求的完整性，經過分解獲得的需求必須能夠充分覆