單元二任務一將軟件需求轉化為測試需求(文件)
【正文】 要求的各信息后執(zhí)行保存 ，檢查保存是否成功 ； 功能測試 2 檢查每個輸入項的數(shù)據長度是否遵循數(shù)據字典的要求； 功能測試、完整性測試 3 檢查每個輸入項的數(shù)據類型是否遵循數(shù)據字典的要求； 功能測試、完整性測試 4 檢查“培訓費用”是否滿足規(guī)定的精度要求； 功能測試 5 檢查在培訓的起止時間早晚于截止時間時，所增 加的記錄是否保存成功； 功能測試 基本信息管理 增 加 員工信息 一條完整的培訓信息包括培訓的主題、證書、內容、起止時間、費用、地點、機 構，其中培訓的主題、內容、起止時間、費用、機構為必填項。 功能測試 8 針對頁面中文字、表單、圖片、表格等元素，檢查每個頁面各元素的位置是否協(xié)調，各元素的顏色是否協(xié)調，各元素的大小比例是協(xié)調； 用戶界面測試 9 頁面信息內容顯示是否完整； 用戶界面測試 10 檢查是否有功能標識，功能標識是否準確、清晰； 用戶界面測試、功能測試 基本信息管理 增 加 員工信息 一條完整的培訓信息包括培訓的主題、證書、內容、起止時間、費用、地點、機 構，其中培訓的主題、內容、起止時間、費用、機構為必填項。 用戶界面測試 增加 培訓 信息 ? 評審的內容： ? 完整性審查：應保證測試需求能充分覆蓋軟件需求的各種特征，重點關注功能要求、數(shù)據定義、接口定義、性能要求、安全性要求、可靠性要求、系統(tǒng)約束等方面，同時還應關注是否覆蓋開發(fā)人員遺漏的、系統(tǒng)隱含的需求； ? 準確性審查：應保證所描述的內容能夠得到相關各方的一致理解，各項測試需求之間沒有矛盾和沖突，各項測試需求在詳盡程度上保持一致，每一項測試需求都可以作為測試用例設計的依據。作者將需要評審的內容發(fā)送給各位評審員，并收集他們的反饋意見。 ? 小組評審：通過正式的小組會議完成評審工作，是有計劃的和結構化的評審方式。 ? 評審員需要精心挑選，保證不同類型的人員都要參與進行來，通常包括開發(fā)經理、項目經理、測試經理、系統(tǒng)分析人員、相關開發(fā)人員和測試人員等。 ? 評審的形式 ? 審查：審查和小組評審很相似，但更為嚴格，是最系統(tǒng)化、最嚴密的評審形式，包含了制定計劃、準備和組織會議、跟蹤和分析審查結果等。希望參與評審的其他同事可以發(fā)現(xiàn)其中的錯誤，并能進行現(xiàn)場討論。相互評審是最不正式的一種評審形式，但應用方便、有效。每一個輸入項的數(shù)據規(guī)格應遵循數(shù)據字典的要求。每一個輸入項的數(shù)據規(guī)格應遵循數(shù)據字典的要求。 ? 通過測試需求跟蹤矩陣的方式對需求變更實施管理。 易 用性 / 易操作性 用戶界面測試 ? 建立測試需求跟蹤矩陣，對測試需求進行管理。 功能性 / 適合性 功能測試 8 針對頁面中文字、表單、圖片、表格等元素，檢查每個頁面各元素的位置是否協(xié)調，各元素的顏色是否協(xié)調，各元素的大小比例是協(xié)調； 易用性 / 易操作性 用戶界面測試 9 頁面信息內容顯示是否完整； 易用性 / 易操作性 用戶界面測試 10 檢查是否有功能標識，功能標識是否準確、清晰； 易用性 / 易理解性 用戶界面測試、功能測試 一條完整的培訓信息包括培訓的主題、證書、內容、起止時間、費用、地點、機構，其中培訓的主題、內容、起止時間、費用、機構為必填項。 質量特性對應表 原始需求描述 標識 測試要點 質量特性 測試類型
環(huán)評公示相關推薦
鄂ICP備17016276號-1