《測試執(zhí)行及測試報告》

1、測試執(zhí)行,Chapter 1 測試執(zhí)行,Chapter 2 軟件缺陷,課程目錄,Chapter 3 測試報告,Chapter 1 測試執(zhí)行,,1.1 什么是執(zhí)行測試用例1.2 測試執(zhí)行過程注意事項,什么是執(zhí)行測試用例,根據(jù)已有的測試用例，按照里面的步驟一步一步的執(zhí)行，查看預期結果與實際結果是否一致。,明確要在被測軟件的哪個版本上執(zhí)行？確認要驗證的測試點，在被測版本上已經(jīng)實現(xiàn)了。按照測試用例的預置條件、步驟進行執(zhí)行按照測試用例的預

2、期結果進行結果判斷如果結果失敗，說明找到了缺陷,測試用例的執(zhí)行,當用例還尚未被執(zhí)行時，是No Test未執(zhí)行狀態(tài)當執(zhí)行結果與預期結果相符時，是Pass通過狀態(tài)當執(zhí)行結果與預期結果不符時，是Fail失敗狀態(tài)當因為軟件有缺陷而妨礙了用例步驟的執(zhí)行，且該缺陷并不是我們的測試點，則用例是Block阻礙狀態(tài)。當用例正在執(zhí)行中，但是需要耗較多時間去觀察其結果，是Investigate觀察中狀態(tài)。,用例執(zhí)行結果,測試執(zhí)行過程注意事項,搭建測

3、試環(huán)境事項注意前提條件和特殊說明測試用例要全部執(zhí)行不要忽視任何偶然現(xiàn)象加強測試過程記錄詳細預期與實際的不一致提交缺陷時與開發(fā)的關系處理提交一份優(yōu)秀的問題報告單及時更新測試用例,Chapter 2 軟件缺陷,,2.1 缺陷的理論基礎2.2 缺陷的生命周期2.3 缺陷的流程2.4 缺陷的狀態(tài)2.5 缺陷的等級2.6 缺陷實例與練習,缺陷理論基礎,,2.1.1 缺陷的定義2.1.2 缺陷的原因2.1.3 缺陷的修

4、復成本2.1.4 缺陷的分布特征2.1.5 缺陷的抗藥性2.1.6 并非所有缺陷都要修改,缺陷的定義,軟件未實現(xiàn)需求和規(guī)格要求的功能軟件出現(xiàn)了需求和規(guī)格指明不該出現(xiàn)的錯誤軟件實現(xiàn)了需求和規(guī)格未提及的功能軟件未實現(xiàn)需求和規(guī)格未明確提及但應該實現(xiàn)的內(nèi)容軟件難以理解，不易使用，運行緩慢，或者最終用戶(估計會)認為不好。測試用例執(zhí)行中發(fā)現(xiàn)的與預期結果不符的現(xiàn)象 缺陷又名為BUG（臭蟲）,缺陷的原因,缺陷的修復成本,缺

5、陷的分布特征,集結（二八定理） 缺陷往往喜歡扎堆，一個模塊已經(jīng)發(fā)現(xiàn)的缺陷比別的模塊多，通常不是代表這個模塊已經(jīng)把缺陷暴露完了，而是意味著這個模塊還存在有同樣多的缺陷尚未被發(fā)現(xiàn)。這就是著名的二八定理：80%的缺陷出現(xiàn)在 20%的模塊。,并非所有的缺陷都需要修復,有一些原因，使得有些缺陷我們不修復：沒有足夠的時間不算真正的軟件缺陷修復的風險太大不值得修復,缺陷的生命周期,缺陷的流程,缺陷生命周期—狀態(tài),

6、缺陷的等級,缺陷單的編寫,一個好的缺陷單，是你提交之后就再也沒人聯(lián)系你，然后過了一段時間已經(jīng)被完美地修復，轉回到你手上進行驗證測試這樣的一個單子要做到這樣，你應該怎么做呢 1、提供足夠的錯誤環(huán)境信息，使得開發(fā)人員既能夠明確如何重現(xiàn)故障現(xiàn)象，又有足夠的信息定位到問題的根源 2、書寫良好的重現(xiàn)步驟； 3、上傳附件，例如軟件運行日志，抓圖，網(wǎng)絡抓包，聲音，視頻等。 4、使用特殊的顏色對重點詞

7、語進行標記； 5、使用關鍵詞進行強調(diào) 6、特殊標記,一個缺陷的基本要素,缺陷ID 缺陷復現(xiàn)步驟缺陷標題 期望結果 測試環(huán)境 實際結果缺陷發(fā)現(xiàn)的日期和時間

8、附件缺陷提交人缺陷的優(yōu)先級缺陷的嚴重等級；測試類型發(fā)現(xiàn)缺陷的軟件版本,例子-excel表,例子-bugfree,如何寫好每部分（1）,標題：創(chuàng)建一個簡短的標題，讓問題看起來更清晰。“應用崩潰”是一個很惱人的標題因為它沒有足夠的信息包括在這份報告里面。取而代之的是標題應該包含錯誤消息和消息碼，或者是結果的名稱以及失敗時你正在做的事情。例如：Error 402:訪問拒絕當點擊“發(fā)送郵件”這個例子就提供了缺陷系統(tǒng)的上下文信息。差：

9、“程序崩潰”，“報錯”，“Bug”好：“從’Kifu’中打印時5C79錯誤”，“’Kifu honors’報表為空”產(chǎn)品：用名稱標識產(chǎn)品，告知你使用的是哪個版本。絕大部分軟件都包含有版本信息。web應用的版本信息通常在頁腳。差：“你的應用”好：”Kifu v1.01″平臺：告訴我們軟件運行在什么平臺。尤其是操作系統(tǒng)的名字及版本和游覽器名稱版本。特別是web應用，這些信息對我們很重要。差：“Windows”好：“Window

10、s7,IE9”是否能重現(xiàn)：有些惱火的Bug是間歇性的出現(xiàn)，我們想預先知道，如果我們正在處理一個靈異事件或者正逢Bug出現(xiàn)時。差：留空白好：“每次”，“偶然”，“不重現(xiàn)”,如何寫好每部分（2）,● 總結：用簡潔的語言概括出Bug出現(xiàn)時你正在做的事情。從上下文開始，在操作應用的哪個部分。聚焦在你做的時候軟件做了什么？差：“系統(tǒng)不能用了”好：在“honor report”頁面單擊“打印按鈕”，但是報表是空的?！?發(fā)生了什么：一步

11、一步描述你做的事情當bug出現(xiàn)時，為什么你認為是錯誤的。事無巨細，打印出菜單的名稱，頁面標題，點擊時的按鈕或者鏈接的名稱。做相同的操作是不是出現(xiàn)一樣的錯誤。差：“空白報表”好：“點擊 ‘File/Save as…’，’Save‘對話空彈出，然后點擊‘OK’按鈕，但是文件沒有保存”● 錯誤時什么：如果錯誤消息出現(xiàn)時，拷貝粘貼整個信息，這樣更有利于我們跟蹤錯誤。差：“有個錯誤，點擊它始終讀不出”好：“Error 403：訪問拒絕”

12、● 復現(xiàn)的步驟：如果你可以讓bug重現(xiàn)，那太好了，這能提供很大的幫助。一步步描述如何重現(xiàn)次bug。差：“打印沒法使用”好：“從‘Honors Report’頁面，點擊‘打印按鈕’”,如何寫好每部分（3）,● 預期結果：描述你預期發(fā)生的結果當bug發(fā)生時，這部分特別有用如果程序沒有按照你期待的結果發(fā)生時，因為它很詭異。差：“我期待能正常工作”好：“我期待能看到‘Honors Reports’的PDF文件”真實結果：當bug發(fā)生

13、時是怎么發(fā)生的，什么錯誤，為什么有錯，或者如果錯誤拋出，拋出什么錯。差：“沒法用”好：“我收到是空的PDF文件，或者’403錯誤，訪問拒絕’” ● 附件：如果你知道怎么截屏，做吧，附上一個簡短的錯誤，截屏可以是錯誤之前或者發(fā)生錯誤之后，我們的開發(fā)者能夠看到究竟發(fā)生了什么。如果應用有崩潰的日志，同樣附上它。,Chapter 3 測試報告,,3.1 測試報告的主要內(nèi)容3.2 測試結果分析3.3 測試總結,測試報告的主要內(nèi)容（掌上

14、書院）,,3.1.1 數(shù)據(jù)統(tǒng)計3.1.2 遺留bug情況3.1.3 測試風險3.1.4 測試對象評估3.1.5 測試結論3.2 測試總結,數(shù)據(jù)統(tǒng)計-人力投入,數(shù)據(jù)統(tǒng)計-用例覆蓋率,數(shù)據(jù)統(tǒng)計-問題單分類統(tǒng)計,遺留bug情況,測試風險,測試對象評估,測試結論,測試結果分析,測試執(zhí)行結束后，測試活動還沒有結束。測試結果分析是必不可少的重要環(huán)節(jié)， “ 編筐編簍，全在收口 ” ，測試結果的分析對下一輪測試工作的開展有很