軟件測(cè)試管理及其應(yīng)用重點(diǎn)_第1頁(yè)
軟件測(cè)試管理及其應(yīng)用重點(diǎn)_第2頁(yè)
軟件測(cè)試管理及其應(yīng)用重點(diǎn)_第3頁(yè)
已閱讀5頁(yè),還剩3頁(yè)未讀, 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說(shuō)明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請(qǐng)進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡(jiǎn)介

1、第一章 明確為什么不能測(cè)試所有可能性 :1) 可能進(jìn)行測(cè)試的數(shù)目是無(wú)限的2) 真正能執(zhí)行的測(cè)試只是代表性的案例3) 很難確定理想的可能測(cè)試的數(shù)目4) 用較少的測(cè)試資源獲取更多的信息1) 可用測(cè)試資源2使用適當(dāng)?shù)臏y(cè)試技術(shù)和方法3明確具體軟件測(cè)試任務(wù)測(cè)試準(zhǔn)備 單元測(cè)試集成測(cè)試系統(tǒng)測(cè)試內(nèi)部驗(yàn)收1. 制定測(cè)試策略1.單元測(cè)試方案1.集成測(cè)試方案2.明確測(cè)試用例3.執(zhí)行單元測(cè)試4.缺陷分析交付成果:?jiǎn)卧獪y(cè)試方案集成測(cè)試方案系統(tǒng)測(cè)試方案內(nèi)部驗(yàn)收?qǐng)?bào)告單元測(cè)試用例集成測(cè)試用例系統(tǒng)測(cè)試用例單元測(cè)試 bug 記錄表集成測(cè)試 bug 記錄表系統(tǒng)測(cè)試 bug 記錄表單元測(cè)試報(bào)告集成測(cè)試報(bào)告系統(tǒng)測(cè)試報(bào)告4.軟件測(cè)試管理

2、定義:就是對(duì)每一種具體測(cè)試任務(wù)、流程、體系、結(jié)果、工具等進(jìn)行具體監(jiān)督和管理5. 常見的實(shí)踐是可以把軟件測(cè)試管理分為8 類:1軟件測(cè)試需求管理2軟件測(cè)試質(zhì)量管理3軟件測(cè)試團(tuán)隊(duì)管理4軟件測(cè)試文檔管理5軟件測(cè)試缺陷管理6軟件測(cè)試環(huán)境管理7軟件測(cè)試流程管理8軟件測(cè)試執(zhí)行管理6. 單元測(cè)試的考慮:1模塊接口2算法和邏輯3數(shù)據(jù)結(jié)構(gòu)全局和局部4邊界條件5獨(dú)立的路徑6錯(cuò)誤處理7.1敏捷開發(fā)迭代流程圖:=輸入需求 -設(shè)計(jì) -開發(fā)-測(cè)試需求 方案 -設(shè)計(jì)-執(zhí)行 - -發(fā)布輸出 =2敏捷方法 中迭代周期短,測(cè)試人員盡早開始測(cè)試,包括及時(shí)對(duì)需求、開發(fā)設(shè)計(jì)進(jìn)行評(píng)審,更重要的是能夠及 時(shí)、 持續(xù)地對(duì)軟件產(chǎn)品質(zhì)量進(jìn)行反應(yīng)。

3、 簡(jiǎn)單地說(shuō), 敏捷測(cè)試管理 要特別注意的就是持續(xù)地對(duì)軟件質(zhì)量問題進(jìn)行及 時(shí)反應(yīng)。有 HP Agile Manager 和微軟的 Visual Studio 2022,包括 TFS 2022、Scrum 模板、Test Manager 2022、Coded UI Test 是確保軟件測(cè)試在軟件質(zhì)量保證中發(fā)揮應(yīng)有的關(guān)鍵作用。 特別表達(dá)在以下 5 個(gè)方面: 1對(duì)軟件產(chǎn)品的評(píng)估和測(cè)量2對(duì)軟件產(chǎn)品的缺陷識(shí)別和控制3產(chǎn)品設(shè)計(jì)和開發(fā)的驗(yàn)證4軟件過(guò)程的監(jiān)視和測(cè)量5有流程和標(biāo)準(zhǔn)指導(dǎo)10.ISO 9000 質(zhì)量管理體系的 8 大原那么原那么 1::以用戶為關(guān)注焦點(diǎn)原那么 2:領(lǐng)導(dǎo)作用原那么 3:全員參與原那么 4

4、:過(guò)程方法原那么 5:管理的系統(tǒng)方法原那么 6:持續(xù)改進(jìn)原那么 7:基于事實(shí)的決策方法原那么 8:互利的供方關(guān)系11. TMM 軟件測(cè)試能力成熟度 5 級(jí)TL1 初始級(jí)TL2 階段定義級(jí)TL3 集成級(jí)TL4 管理和測(cè)試級(jí)TL5 優(yōu)化級(jí)12. 測(cè)試管理體系的架構(gòu):制定測(cè)試需求設(shè)計(jì)測(cè)試用例生成測(cè)試執(zhí)行用例執(zhí)行單元測(cè)試執(zhí)行集成測(cè)試執(zhí)行系統(tǒng)測(cè)試分析測(cè)試結(jié)果制定測(cè)試策略定義測(cè)試過(guò)程建立測(cè)試腳本建立測(cè)試結(jié)果記錄測(cè)試結(jié)果記錄測(cè)試結(jié)果提出變更請(qǐng)求明確資源進(jìn)度定義測(cè)試環(huán)境回歸測(cè)試回歸測(cè)試回歸測(cè)試分析測(cè)試情況評(píng)審測(cè)試方案生成測(cè)試報(bào)告制定測(cè)試方案 - 測(cè)試方案 測(cè)試執(zhí)行 - 單元測(cè)試 - 集成測(cè)試 - 系統(tǒng)測(cè)試 評(píng)

5、估測(cè)試13. 軟件測(cè)試的 5個(gè)要素 /測(cè)試管理的 5 要素: 質(zhì)量、人員、技術(shù)、資源、流程14. 測(cè)試管理金字塔和關(guān)系實(shí)例圖: 一個(gè)中心 -1 人以人為本 -2 個(gè)目標(biāo) 關(guān)注點(diǎn):測(cè)試覆蓋率、測(cè)試效率 -3 個(gè)支撐人員、流程、 技術(shù) -5 要素或 5 個(gè)工作面 -8 關(guān)系 13 原那么21 關(guān)鍵域 -34 個(gè)方法5 個(gè)工作面:1質(zhì)量 - 人員 - 技術(shù)2質(zhì)量 -人員 -資源3質(zhì)量 -技術(shù) -流程4質(zhì)量 -流程 -資源5人員 -技術(shù) -流程 -資源15. 為什么要進(jìn)行軟件測(cè)試管理? 1軟件測(cè)試的工作量要占整個(gè)軟件開發(fā)工作量的40以上,對(duì)于高可靠、高平安的軟件來(lái)說(shuō),這一比例可能會(huì)到達(dá)60%70%。因

6、此,軟件測(cè)試是軟件開發(fā)過(guò)程中的一項(xiàng)重要工作,必須對(duì)其進(jìn)行科學(xué)有效的管理。 2一項(xiàng)軟件測(cè)試工作涉及到技術(shù)、方案、質(zhì)量、工具、人員等各個(gè)方面,是一項(xiàng)復(fù)雜的工作,因此需要對(duì)其 進(jìn)行管理。3任何軟件測(cè)試工作都是在一定的約束條件下進(jìn)行的,要做到完全徹底的測(cè)試是不可能的。 4只有系統(tǒng)化、 標(biāo)準(zhǔn)化的軟件測(cè)試才能有效地發(fā)現(xiàn)軟件缺陷,才能對(duì)發(fā)現(xiàn)的軟件缺陷實(shí)施有效的追蹤和管理,才能在軟件缺陷修改后進(jìn)行有效的回歸測(cè)試。第二章1. 軟件需求的定義 :1正在構(gòu)建的系統(tǒng)必須符合的條件或具備的功能 2一種獲取,組織并記錄系統(tǒng)需求的系統(tǒng)優(yōu)化方案,以及一個(gè)使客戶與工程團(tuán)隊(duì)對(duì)不斷變更的系統(tǒng)需求達(dá)成并 保持一致的過(guò)程2. 測(cè)試需求

7、和測(cè)試設(shè)計(jì)的區(qū)別: 1測(cè)試需求并不等同于簡(jiǎn)單的測(cè)試范圍,也不是測(cè)試方案。因此也有專家定義測(cè)試需求不是對(duì)測(cè)試提出的要求 的總和,而是根據(jù)程序文件和質(zhì)量目標(biāo)對(duì)軟件測(cè)試活動(dòng)所提的要求。2測(cè)試需求不同于測(cè)試設(shè)計(jì)。按照IEEE 標(biāo)準(zhǔn),測(cè)試設(shè)計(jì)的目的是:細(xì)化測(cè)試方案中描述的測(cè)試途徑,確定要包含的特性和測(cè)試,確定完成測(cè)試所用到的測(cè)試用例和測(cè)試規(guī)程,最后給出測(cè)試失效和通過(guò)的標(biāo)準(zhǔn)。就是對(duì)軟件測(cè)定要解決的問題進(jìn)行詳細(xì)分析4. 測(cè)試需求分析主要有兩個(gè)任務(wù): 1通過(guò)對(duì)測(cè)試活動(dòng)需要解決問題及環(huán)境的理解、分析和綜合,建立分析模型; 2在完全弄清所有測(cè)試活動(dòng)干系人對(duì)測(cè)試確實(shí)切要求的根底上,用“軟件測(cè)試需求規(guī)格說(shuō)明書把測(cè)試需

8、求以 正式書面形式確定下來(lái)軟件測(cè)試需求分析環(huán)節(jié):建立軟件測(cè)試需求模型 編寫測(cè)試需求說(shuō)明書5. 軟件測(cè)試需求分析的最通用的方法:通過(guò) 軟件需求推導(dǎo)軟件測(cè)試需求6. 軟件測(cè)試需求分析步驟:1根據(jù)軟件開發(fā)需求說(shuō)明書逐條列出軟件開發(fā)需求,并判斷其可測(cè)試性,如果不具備可測(cè)試性,那么需要提交申 請(qǐng)對(duì)軟件開發(fā)需求說(shuō)明書進(jìn)行變更,任何軟件開發(fā)需求都應(yīng)具備可測(cè)試性。通常來(lái)說(shuō),對(duì)軟件開發(fā)需求說(shuō)明書 的可測(cè)試性檢查應(yīng)該在軟件開發(fā)需求說(shuō)明書的評(píng)審過(guò)程中提出并解決。2對(duì)步驟 1中列出的每一條開發(fā)需求,形成可測(cè)試性的描述。針對(duì)這條開發(fā)需求需要進(jìn)行測(cè)試范圍的界定。開發(fā)需求和需要進(jìn)行測(cè)試的范圍不是1:1的關(guān)系,可能是1: n

9、或n: 1,必要情況下,需要對(duì)開發(fā)需求進(jìn)行分解和合并。3對(duì)步驟 2中形成的每一條測(cè)試范圍,根據(jù)質(zhì)量標(biāo)準(zhǔn),逐條制定質(zhì)量需求,即測(cè)試通過(guò)標(biāo)準(zhǔn),用以判斷測(cè)試 成功和失敗。4對(duì)步驟 3確定的質(zhì)量需求,分析測(cè)試執(zhí)行時(shí)需要實(shí)施的測(cè)試類型,至此形成專業(yè)的測(cè)試需求。 5建立測(cè)試需求跟蹤矩陣,輸入測(cè)試需求管理系統(tǒng),對(duì)測(cè)試需求實(shí)施嚴(yán)格有效的管理。7. 軟件測(cè)試需求分析過(guò)程中還有許多其他重要的環(huán)節(jié):軟件測(cè)試需求分析干系人分析、測(cè)試需求的收集與分析/整理、測(cè)試需求的優(yōu)先級(jí)排序和評(píng)審測(cè)試需求8. 評(píng)審的內(nèi)容 包括 完整性檢查和準(zhǔn)確性檢查 評(píng)審的形式,有以下常用幾種:1 相互評(píng)審、交叉評(píng)審2輪查3走查4小組評(píng)審9. 軟件

10、測(cè)試需求管理的內(nèi)容:1 定義測(cè)試需求2確認(rèn)測(cè)試需求3建立測(cè)試需求狀態(tài)4測(cè)試需求評(píng)審5測(cè)試需求責(zé)任制6測(cè)試需求跟蹤10. 為什么變更?變更的原因 ;1) 客戶的需求2市場(chǎng)的需求3技術(shù)或非技術(shù)的其他原因11軟件測(cè)試需求變更的主要任務(wù):1提出變更2分析變更的必要性和合理性,確定是否實(shí)施變更3記錄變更信息,填寫變更控制單,提交變更申請(qǐng)4做出更改,并交上級(jí)審查5修改相應(yīng)的軟件測(cè)試工作,如更新測(cè)試用例等,確定新的版本6評(píng)審后,正式發(fā)布新版本的軟件測(cè)試需求說(shuō)明書12. 測(cè)試需求狀態(tài)轉(zhuǎn) 換:1Open2Analyzed3Reviewed4Resolved5 Passed6Un resolved7Closed8

11、 Cancle9FailedUnresolved缺陷多種原因:1測(cè)試問題2需求分析問題13. 軟件測(cè)試需求跟蹤是指跟蹤軟件測(cè)試需求使用期限的全過(guò)程。需求跟蹤包含的正向跟蹤和逆向跟蹤合稱為雙 向跟蹤。軟件開發(fā)需求到測(cè)試需求從測(cè)試需求回溯軟件測(cè)試需求到測(cè)試用例從測(cè)試用例回溯測(cè)試用例正向跟蹤逆向跟蹤14. 惠普應(yīng)用生命周期管理流程 報(bào)告和分析 指定版本-指定需求-方案測(cè)試-執(zhí)行測(cè)試-追蹤缺陷第三章1. 測(cè)試團(tuán)隊(duì)角色:1測(cè)試經(jīng)理:他們負(fù)責(zé)測(cè)試方案和測(cè)試統(tǒng)籌安排,具備軟件測(cè)試、質(zhì)量管理、工程管理和人員管理等領(lǐng)域的知識(shí)和經(jīng)驗(yàn),能指導(dǎo)和管理其他測(cè)試人員的工作2測(cè)試設(shè)計(jì)人員:他們需要掌握測(cè)試方法、流程和測(cè)試規(guī)

12、格說(shuō)明等,具備測(cè)試設(shè)計(jì)、測(cè)試分析以及軟件工程等領(lǐng)域的知識(shí)和經(jīng)驗(yàn)3測(cè)試自動(dòng)化人員:測(cè)試自動(dòng)化人員不但具備測(cè)試的根底知識(shí),還有編程經(jīng)驗(yàn)以及豐富的測(cè)試工具和腳本語(yǔ)言知識(shí)。4測(cè)試環(huán)境管理員:負(fù)責(zé)測(cè)試環(huán)境的技術(shù)人員。一般是安裝和操作測(cè)試環(huán)境方面的專家,具備系統(tǒng)管理員知識(shí)。建立、維護(hù)和支持測(cè)試環(huán)境, 需要經(jīng)常與系統(tǒng)管理員和網(wǎng)絡(luò)管理員進(jìn)行協(xié)調(diào)。他們也幫助一般測(cè)試工程師和開發(fā)工程師搭建測(cè)試環(huán)境。5測(cè)試執(zhí)行人員:他們執(zhí)行測(cè)試并編寫缺陷報(bào)告,具備IT根底知識(shí)、測(cè)試根底知識(shí),能應(yīng)用測(cè)試工具,熟悉被測(cè)試對(duì)象。2. 測(cè)試團(tuán)隊(duì)與開發(fā)團(tuán)隊(duì)的比例測(cè)試比例不是唯一確定的1質(zhì)量風(fēng)險(xiǎn)2測(cè)試意識(shí)3發(fā)布流程4測(cè)試效率5合理估計(jì)工程的開

13、發(fā)測(cè)試比例的方法 1.看工程的性質(zhì),遇到問題影響范圍是100%的核心任務(wù),投入開發(fā)與測(cè)試比例至少為1:12. 遇到缺陷影響范圍可控或有替代方式的業(yè)務(wù),上線步驟是遞進(jìn)的,開發(fā)和測(cè)試之比2:1 或更高3. 有些工程對(duì)質(zhì)量要求不是很高的,只需做簡(jiǎn)單驗(yàn)證性測(cè)試即可發(fā)布,只需設(shè)立一到兩名測(cè)試人員即可 6手工測(cè)試工程師和自動(dòng)化測(cè)試工程師的比例第四章1.測(cè) 試過(guò)程實(shí)施所必備的核心測(cè)試文檔包括: 測(cè)試方案、測(cè)試標(biāo)準(zhǔn)、測(cè)試用例和軟件測(cè)試報(bào)告2.測(cè)試文檔的必要性 ;1) 提高工程測(cè)試過(guò)程的透明度2) 文檔化能標(biāo)準(zhǔn)測(cè)試,能提高測(cè)試效率3) 便于團(tuán)隊(duì)成員之間的交流與合作4) 測(cè)試文檔的重要性還表現(xiàn)在對(duì)于工程“傳承的重

14、要性5) 測(cè)試文檔是測(cè)試人員經(jīng)驗(yàn)提升的最正確途徑6) 有利于工程測(cè)試的監(jiān)控作用3. 工程測(cè)試文檔 是用來(lái)記錄、描述、展示測(cè)試過(guò)程中一系列測(cè)試信息的處理過(guò)程,通過(guò)書面或圖示的形式對(duì)工程 測(cè)試活動(dòng)過(guò)程或結(jié)果進(jìn)行描述、定義及報(bào)告4. 測(cè)試方案 :描述測(cè)試活動(dòng)的范圍、 方法、資源和進(jìn)度。它規(guī)定被測(cè)試的項(xiàng)、 被測(cè)試的特征、 應(yīng)完成的測(cè)試任務(wù)、 負(fù)責(zé)每項(xiàng)工作的人員以及與本方案有關(guān)的風(fēng)險(xiǎn)等。5. 測(cè)試說(shuō)明包括三類文檔:1測(cè)試設(shè)計(jì)說(shuō)明2測(cè)試用例說(shuō)明3測(cè)試規(guī)程說(shuō)明6.測(cè)試報(bào)告包括 4 類文檔:1測(cè)試項(xiàng)傳遞報(bào)告2) 測(cè)試日志3) 測(cè)試事件報(bào)告4) 測(cè)試總結(jié)報(bào)告7. 國(guó)際 IEEE 829 標(biāo)準(zhǔn):1測(cè)試方案2測(cè)試設(shè)

15、計(jì)規(guī)格3測(cè)試用例規(guī)格4) 測(cè)試過(guò)程規(guī)格5) 測(cè)試記錄6) 測(cè)試附加報(bào)告7) 測(cè)試摘要報(bào)告8. 測(cè)試策略和測(cè)試方案的區(qū)別:測(cè)試策略定義 :在一定的軟件測(cè)試標(biāo)準(zhǔn)、 測(cè)試標(biāo)準(zhǔn)的指導(dǎo)下, 依據(jù)測(cè)試工程的特定環(huán)境約束而規(guī)定的軟件測(cè)試的 原那么、方式、方法的集合。通俗地講, 測(cè)試策略描述了要進(jìn)行哪些種類的測(cè)試和如何測(cè)試的問題。測(cè)試方案: 5W1H what where when who why how9. 簡(jiǎn)述制定軟件測(cè)試策略的過(guò)程1首先要明確制定軟件測(cè)試策略的輸入 2其次要明確軟件測(cè)試策略的輸出 1.確定測(cè)試的需求 2.評(píng)估風(fēng)險(xiǎn)并確定測(cè)試優(yōu)先級(jí)3.確定測(cè)試策略10. 測(cè)試方案定義 ; 一個(gè)表達(dá)了預(yù)定的測(cè)

16、試活動(dòng)的范圍、途徑、資源及進(jìn)度安排的文檔。它確認(rèn)了測(cè)試項(xiàng)、被測(cè)特征、測(cè)試任務(wù)、人 員安排以及任何偶發(fā)事件的風(fēng)險(xiǎn)。 軟件測(cè)試方案是指導(dǎo)測(cè)試過(guò)程的綱領(lǐng)性文件, 是測(cè)試文檔中的重中之重。 它包 含了產(chǎn)品概述、 測(cè)試策略、測(cè)試方法、測(cè)試區(qū)域、 測(cè)試配置、測(cè)試周期、 測(cè)試資源、 測(cè)試交流、風(fēng)險(xiǎn)分析等內(nèi)容。 根本要素:1編號(hào)2) 標(biāo)題3) 重要級(jí)4) 測(cè)試輸入5) 操作步驟6) 預(yù)期結(jié)果12. 編寫缺陷報(bào)告的5c準(zhǔn)那么;1Correct(準(zhǔn)確)2Clear清晰3Concise簡(jiǎn)潔4Complete完整5 Consistent 一致 缺陷報(bào)告生命周期提交缺陷報(bào)告 -分配缺陷報(bào)告 -處理缺陷報(bào)告 -反測(cè)報(bào)告

17、-反測(cè)通過(guò) 關(guān)閉缺陷報(bào)告 反測(cè)未通過(guò)處理缺陷報(bào)告13. 對(duì)測(cè)試方案的可行性、全面性以及正確性等進(jìn)行評(píng)審1 4 .評(píng)審的內(nèi)容:1 用例設(shè)計(jì)的結(jié)構(gòu)安排是否清晰、合理,是否利于高效地對(duì)需求進(jìn)行覆蓋 2優(yōu)先級(jí)安排是否合理3是否覆蓋測(cè)試需求的所有功能點(diǎn) 4用例是否具有很好可執(zhí)行性5是否刪除冗余的用例 6是否包含充分的的負(fù)面測(cè)試用例7是否從用戶層面來(lái)設(shè)計(jì)用戶使用場(chǎng)景和使用流程的測(cè)試用例 8是否簡(jiǎn)潔,是否便于重復(fù)使用15. 使用 ALM 進(jìn)行測(cè)試管理包括 4 個(gè)步驟:1 明確條件2測(cè)試方案3執(zhí)行測(cè)試4跟蹤缺陷16. 最正確測(cè)試用例的設(shè)計(jì)原那么:1 依據(jù)原那么2全覆蓋原那么3標(biāo)準(zhǔn)原那么4全面原那么17. 最正

18、確測(cè)試用例的特點(diǎn):1 完整性2準(zhǔn)確性3簡(jiǎn)潔性4清晰性5可維護(hù)性6適當(dāng)性7可復(fù)用性8其他18. 測(cè)試用例的粒度: 是指一個(gè)測(cè)試用例覆蓋軟件功能點(diǎn)的范圍,覆蓋面廣被稱為力度粗大,覆蓋面窄被稱為力度細(xì)小19. 設(shè)計(jì)測(cè)試用例時(shí)應(yīng)考慮以下因素:1工程的進(jìn)度2軟件工程師的情況3客戶需求4工程是否具有延續(xù)性20. 測(cè)試用例生命周期:確定測(cè)試需求 -測(cè)試用例設(shè)計(jì) - 測(cè)試用例執(zhí)行 -測(cè)試用例管理21. 測(cè)試用例管理:包括測(cè)試用例組織、測(cè)試用例跟蹤和測(cè)試用例維護(hù)22. 幾大測(cè)試文檔有哪些?具體內(nèi)容是什么?測(cè)試需求文檔:測(cè)試執(zhí)行方案:測(cè)試方案: 一個(gè)表達(dá)了預(yù)定的測(cè)試活動(dòng)的范圍、途徑、資源及進(jìn)度安排的文檔 。它確認(rèn)

19、了測(cè)試項(xiàng)、被測(cè)特征、 測(cè)試任務(wù)、 人員安排以及任何偶發(fā)事件的風(fēng)險(xiǎn)。 軟件測(cè)試方案是指導(dǎo)測(cè)試過(guò)程的綱領(lǐng)性文件, 是測(cè)試文檔中的重 中之重。它包含了產(chǎn)品概述、測(cè)試策略、測(cè)試方法、測(cè)試區(qū)域、測(cè)試配置、測(cè)試周期、測(cè)試資源、測(cè)試交流、風(fēng) 險(xiǎn)分析等內(nèi)容,包含了測(cè)試的背景、人員和內(nèi)容、以及方案要做的測(cè)試。測(cè)試用例 :是對(duì)于方案中要做的測(cè)試內(nèi)容、測(cè)試項(xiàng)生成的用例。測(cè)試結(jié)果報(bào)告 ::包含了用例測(cè)試的結(jié)果和總結(jié),以便將來(lái)維護(hù)時(shí)使用測(cè)試標(biāo)準(zhǔn): 為了一個(gè)特定的測(cè)試目的,對(duì)被測(cè)軟件產(chǎn)品或功能進(jìn)行測(cè)試所需的有關(guān)文件。軟件測(cè)試報(bào)告:測(cè)試策略 :在一定的軟件測(cè)試標(biāo)準(zhǔn)、 測(cè)試標(biāo)準(zhǔn)的指導(dǎo)下, 依據(jù)測(cè)試工程的特定環(huán)境約束而規(guī)定的軟

20、件測(cè)試的原那么、 方式、方法的集合。通俗地講, 測(cè)試策略描述了要進(jìn)行哪些種類的測(cè)試和如何測(cè)試的問題。缺陷報(bào)告: 為便于管理測(cè)試發(fā)現(xiàn)的軟件錯(cuò)誤, 通常要采用軟件缺陷數(shù)據(jù)庫(kù), 將發(fā)現(xiàn)的每一個(gè)錯(cuò)誤輸入到缺陷報(bào)告 中,軟件缺陷數(shù)據(jù)庫(kù)的每一條記錄稱為一個(gè)軟件問題報(bào)告第五章1. 缺陷狀態(tài)New Open Fixed Reopen Closed Rejected Pending Distract Cancelled一個(gè)好的缺陷報(bào)告應(yīng)該包含哪些信息?唯一的缺陷 ID ,精確描述但簡(jiǎn)短的標(biāo)題、缺陷類型、嚴(yán)重級(jí)別、優(yōu)先級(jí)別、報(bào)告人、詳細(xì)準(zhǔn)確的重現(xiàn)步驟包 含位置、操作、現(xiàn)象等三要素 ,UI 截圖、所屬模塊、負(fù)責(zé)人、預(yù)期結(jié)果、實(shí)際結(jié)果,重現(xiàn)環(huán)境、前置條件等等 信息其余可以補(bǔ)充 。事件 / 缺陷 ID:XXX缺陷標(biāo)題: 號(hào)不合法也能注冊(cè)成功報(bào)告者: XXX報(bào)告的日期: 2022/10/20狀態(tài): New嚴(yán)重度:

溫馨提示

  • 1. 本站所有資源如無(wú)特殊說(shuō)明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請(qǐng)下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請(qǐng)聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁(yè)內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫(kù)網(wǎng)僅提供信息存儲(chǔ)空間,僅對(duì)用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對(duì)用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對(duì)任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請(qǐng)與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對(duì)自己和他人造成任何形式的傷害或損失。

評(píng)論

0/150

提交評(píng)論