資源描述：
《軟件測試需求評審與需求分析》由會員上傳分享，免費在線閱讀，更多相關(guān)內(nèi)容在教育資源-天天文庫。
1、軟件測試理論第七章：需求評審與需求分析課程回顧項目管理的內(nèi)容是什么？編寫軟件測試計劃應該注意哪些方面？軟件測試計劃設計工具有哪些？軟件測試計劃主要內(nèi)容有哪些？什么是軟件測試方案？軟件測試方案與計劃的主要區(qū)別有哪些？軟件測試過程中，主要的風險有哪些？本章內(nèi)容軟件需求軟件需求的重要性什么是需求規(guī)格說明需求分類需求規(guī)格說明書示例測試需求什么是測試需求測試需求挖掘需求評審需求階段評審的角色和職責軟件需求規(guī)格說明書中的評審要點軟件需求評審輸出組織需求評審原則測試大綱軟件需求軟件需求的重要性調(diào)查數(shù)據(jù)美國權(quán)威的第三方機構(gòu)StandishGr
2、oup對350家公司的8000個軟件項目作過一次調(diào)查，項目失敗的原因是：與產(chǎn)品需求有關(guān)的(1,2,4和6項)占了44.1%。這些數(shù)據(jù)突出地顯示了軟件產(chǎn)品需求在軟件開發(fā)中的重要性。軟件需求需求規(guī)格說明書的概念軟件需求規(guī)格說明書，簡稱SRS,指在特定環(huán)境下要完成一定功能的軟件產(chǎn)品、程序或一組程序的說明描述需求規(guī)格需求規(guī)格說明書軟件需求需求分類原始需求產(chǎn)品需求軟件需求測試需求客戶的原始需求，客戶一般不懂得開發(fā)技術(shù)，所提出來的需求是沒有辦法直接用于開發(fā)產(chǎn)品設計人員根據(jù)原始需求、結(jié)合軟件實現(xiàn)形成的需求軟件開發(fā)人員將產(chǎn)品需求進一步詳細化，
3、合理化。原則上軟件需求技術(shù)上是完全可以實現(xiàn)了軟件需求的進一步詳細化。按照外部接口、設計約束等進行全方位考慮軟件需求需求規(guī)格說明書項目名稱第三波書店產(chǎn)品版本2.0功能名稱搜索查詢書籍文檔版本1.0本功能的意義方便用戶直接便捷的查詢需要購買的書籍名稱搜索入口如圖所示功能簡要描述添加該功能后，用戶可以直接輸入他需要的書籍全稱或書籍的部分字符，點擊搜索或者點擊GO圖標。然后可以顯示搜索到的數(shù)據(jù)。功能核心邏輯接受用戶輸入的書籍全稱或書籍全稱里的部分字符，不支持多個字符串的聯(lián)合查詢搜索結(jié)果顯示在頁面的下半部分，需要按照出版日期升序排序搜索
4、結(jié)果每頁最多顯示10條記錄，如果超過兩頁，需要進行分頁顯示點擊搜索結(jié)果中的書籍名稱鏈接，在新開啟的瀏覽器窗口中顯示書籍信息關(guān)鍵指標在100人同時在線搜索時，搜索時間不超過0.04秒第三波書店搜索功能需求文檔測試需求什么是測試需求？測試需求指可直接形成測試大綱，設計測試用例的需求測試需求測試需求挖掘功能需求—輸入方面輸入來源是什么？輸入數(shù)據(jù)數(shù)量是幾個？如果有錯誤輸入，響應是什么？什么是非法輸入？什么是無效輸入？第三波書店搜索功能在輸入方面的需求挖掘測試需求測試需求挖掘功能需求—處理方面輸入數(shù)據(jù)的有效性檢測的流程是什么？操作的確切
5、次序，包括各事件的時序是什么？對異常情況的回應是什么？例如：溢出、通信失敗、錯誤處理第三波書店搜索功能在處理方面的需求挖掘測試需求測試需求挖掘功能需求—結(jié)果輸出方面輸出到何處（如瀏覽器，打印機，文件）？輸出的數(shù)量是多少？輸出的時序是什么樣的？對非法值的處理是什么樣的？第三波書店搜索功能在結(jié)果輸出方面的需求挖掘測試需求測試需求挖掘功能需求—性能需求方面靜態(tài)量化可能包含：支持的終端數(shù)目，支持的同時使用的用戶數(shù)，處理的文件和記錄的數(shù)目，表和文件的大小動態(tài)量化可能包含：在正?；蚍逯倒ぷ髁壳闆r下一個特定時間段處理事務或任務的數(shù)目及數(shù)據(jù)量
6、。在正?；蚍逯倒ぷ髁壳闆r下處理某個事務或任務所占用系統(tǒng)資源的數(shù)量第三波書店搜索功能在性能需求方面的需求挖掘測試需求測試需求挖掘功能需求—用戶接口方面系統(tǒng)用戶顯示時要求的屏幕格式頁面規(guī)劃及報告或菜單的內(nèi)容輸入和輸出的相關(guān)時序一些組合功能鍵的用法第三波書店搜索功能在用戶接口方面的需求挖掘測試需求測試需求挖掘功能需求—硬件接口方面描述軟件產(chǎn)品和系統(tǒng)硬件組件之間接口的邏輯特征該功能運行支持哪些設備？怎樣支持這些設備和協(xié)議呢？需求評審需求評審角色和職責產(chǎn)品需求評審測試需求評審角色職責軟件開發(fā)項目經(jīng)理帶領(lǐng)項目組與系統(tǒng)工程師進行需求交流并進
7、行分析和文檔化組織SRS文檔評審軟件開發(fā)工程師參加需求評審如果是完成SRS作者，則是需求評審發(fā)起人根據(jù)需求評審專家意見，修改SRS文檔參加系統(tǒng)測試計劃的評審質(zhì)量保證人員（QA）監(jiān)督項目組遵循需求管理流程參加相關(guān)文檔評審保證相關(guān)組參加文檔評審軟件測試項目經(jīng)理參與開發(fā)人員的軟件需求分析，提出可測試性需求組織人員參與SRS的評審工作軟件系統(tǒng)測試計劃寫作需求變更跟蹤軟件測試工程師參與需求評審工作協(xié)助軟件測試項目經(jīng)理完成軟件系統(tǒng)測試計劃將需求轉(zhuǎn)化為測試需求需求評審評審要點是否所有的原始需求都在SRS中體現(xiàn)了？在SRS中定義需求時，是否避
8、免使用那些會引起歧義的術(shù)語？是否在SRS中清楚地描述了軟件要做什么及不做什么？是否在SRS中描述了軟件使用的目標環(huán)境每個需要是否切實可行、可測試、彼此不沖突？是否在SRS中說明了對每個輸入的驗證措施，并描述了每個輸入的屬性。是否在SRS中說明了對每個輸入的處理？是否在SRS中
