單元二任務(wù)一將軟件需求轉(zhuǎn)化為測試需求-資料下載頁
2025-05-12 12:59本頁面
【正文】 加的記錄是否保存成功； 功能測試 基本信息管理 增 加 員工信息 一條完整的培訓(xùn)信息包括培訓(xùn)的主題、證書、內(nèi)容、起止時間、費用、地點、機 構(gòu)，其中培訓(xùn)的主題、內(nèi)容、起止時間、費用、機構(gòu)為必填項。培訓(xùn)的起始時間不能晚于截止時間， 培訓(xùn)費用精確到元角分 。每一個輸入項的數(shù)據(jù)規(guī)格應(yīng)遵循數(shù)據(jù)字典的要求。 6 檢查“培訓(xùn)主題”、“培訓(xùn)內(nèi)容”、“起止時間”、“培訓(xùn)費用”、“培訓(xùn)機構(gòu)”是否為必填項； 功能測試 增加 培訓(xùn) 信息 H R M I S 2 . 0 測試需求跟蹤矩陣 軟件需求 測試需求 軟件需求標識 軟件需求描述 測試需求標識 測試要點 測試類型 7 驗證系統(tǒng)對數(shù)據(jù)重復(fù)的檢查。 功能測試 8 針對頁面中文字、表單、圖片、表格等元素，檢查每個頁面各元素的位置是否協(xié)調(diào)，各元素的顏色是否協(xié)調(diào)，各元素的大小比例是協(xié)調(diào)； 用戶界面測試 9 頁面信息內(nèi)容顯示是否完整； 用戶界面測試 10 檢查是否有功能標識，功能標識是否準確、清晰； 用戶界面測試、功能測試 基本信息管理 增 加 員工信息 一條完整的培訓(xùn)信息包括培訓(xùn)的主題、證書、內(nèi)容、起止時間、費用、地點、機 構(gòu)，其中培訓(xùn)的主題、內(nèi)容、起止時間、費用、機構(gòu)為必填項。培訓(xùn)的起始時間不能晚于截止時間， 培訓(xùn)費用精確到元角分 。每一個輸入項的數(shù)據(jù)規(guī)格應(yīng)遵循數(shù)據(jù)字典的要求。 11 最大化、最小化、還 原、切換、移動窗口時是否能正常的顯示頁面。 用戶界面測試 增加 培訓(xùn) 信息 ? 評審的內(nèi)容： ? 完整性審查：應(yīng)保證測試需求能充分覆蓋軟件需求的各種特征，重點關(guān)注功能要求、數(shù)據(jù)定義、接口定義、性能要求、安全性要求、可靠性要求、系統(tǒng)約束等方面，同時還應(yīng)關(guān)注是否覆蓋開發(fā)人員遺漏的、系統(tǒng)隱含的需求； ? 準確性審查：應(yīng)保證所描述的內(nèi)容能夠得到相關(guān)各方的一致理解，各項測試需求之間沒有矛盾和沖突，各項測試需求在詳盡程度上保持一致，每一項測試需求都可以作為測試用例設(shè)計的依據(jù)。 ? 評審的形式 ? 相互評審、交叉評審：甲和乙在一個項目組，處在一個領(lǐng)域，但工作內(nèi)容不同，甲的工作成果交給乙審查，乙的工作成果交給甲審查。相互評審是最不正式的一種評審形式，但應(yīng)用方便、有效。 ? 輪查：又稱分配審查方法，是一種異步評審方式。作者將需要評審的內(nèi)容發(fā)送給各位評審員，并收集他們的反饋意見。 ? 評審的形式 ? 走查：作者將測試需求在現(xiàn)場向一組同事介紹，以收集大家的意見。希望參與評審的其他同事可以發(fā)現(xiàn)其中的錯誤，并能進行現(xiàn)場討論。這種形式介于正式和非正式之間。 ? 小組評審：通過正式的小組會議完成評審工作，是有計劃的和結(jié)構(gòu)化的評審方式。評審定義了評審會議中的各種角色和相應(yīng)的責(zé)任，所有參與者在評審會議的前幾天就拿到了評審材料，并對該材料進行了獨立研究。 ? 評審的形式 ? 審查：審查和小組評審很相似，但更為嚴格，是最系統(tǒng)化、最嚴密的評審形式，包含了制定計劃、準備和組織會議、跟蹤和分析審查結(jié)果等。 ? 評審的人員組成： ? 正式評審小組中，一般存在多種角色，包括協(xié)調(diào)人、作者、評審員等。 ? 評審員需要精心挑選，保證不同類型的人員都要參與進行來，通常包括開發(fā)經(jīng)理、項目經(jīng)理、測試經(jīng)理、系統(tǒng)分析人員、相關(guān)開發(fā)人員和測試人員等。 ? 選擇“大學(xué)學(xué)籍管理系統(tǒng)”的某一功能，按照測試需求分析的 4個步驟，完成對該功能的“測試需求跟蹤矩陣”
環(huán)評公示相關(guān)推薦
鄂ICP備17016276號-1