Ch15-報告所發(fā)現(xiàn)的缺陷-STMTPPT課件

1、1,軟件測試方法和技術(shù) 第2版第15章 測試用例的設(shè)計,Zhu.K,朱少民 Kerry Zhu,Zhu.K,2,第15章 報告所發(fā)現(xiàn)的缺陷,15.l 軟件缺陷的描述 15.2 軟件缺陷相關(guān)的信息 15.3 軟件缺陷跟蹤和分析 15.4 軟件缺陷跟蹤系統(tǒng),Zhu.K,3,15.l 軟件缺陷的描述,15.1.1 軟件缺陷的生命周期 15.1.2 嚴(yán)重性和優(yōu)先級 15.1.3 缺陷的其它屬性 15.1.4 完整的缺陷信息 15.1.5 缺陷描述的基本要求 15.1.6 缺陷報告的示例,Zhu.K,4,軟件缺陷生命周期指的是一個軟件缺陷被發(fā)現(xiàn)、報告到這個缺陷被修復(fù)、驗(yàn)證直至最后關(guān)閉的完整過程 缺陷生命

2、周期是各類開發(fā)人員一起參與、協(xié)同測試的過程。 軟件缺陷一旦發(fā)現(xiàn)，便進(jìn)入嚴(yán)密監(jiān)控之中，直至軟件缺陷生命周期終結(jié)，這樣即可保證在較短的時間內(nèi)高效率地關(guān)閉所有的缺陷，縮短軟件測試的進(jìn)程，提高軟件質(zhì)量，同時減少開發(fā)、測試和維護(hù)成本,15.1.1 軟件缺陷的生命周期,Zhu.K,5,基本的缺陷生命周期,發(fā)現(xiàn)-打開：測試人員找到軟件缺陷并將軟件缺陷提交給開發(fā)人員。 打開-修復(fù)：開發(fā)人員再現(xiàn)、修復(fù)缺陷，然后提交給測試人員去驗(yàn)證。 修復(fù)-關(guān)閉：測試人員驗(yàn)證修復(fù)過的軟件，關(guān)閉已不存在的缺陷,Zhu.K,6,常見的軟件缺陷生命周期,Zhu.K,7,15.1.2 嚴(yán)重性和優(yōu)先級,嚴(yán)重性（severity）衡量缺陷對

3、客戶滿意度的影響程度 致命的（fatal）、嚴(yán)重的（critical）、一般的（major）、微小的（minor） 優(yōu)先級(Priority)：指缺陷被修復(fù)的緊急程度,Zhu.K,8,15.1.3 缺陷的其它屬性,缺陷標(biāo)識（ID） 缺陷類型（type） 缺陷產(chǎn)生可能性（frequency） 缺陷來源（source） 缺陷原因（root cause,見 P.327328 諸表,Zhu.K,9,15.1.4 完整的缺陷信息,前提 操作步驟 期望結(jié)果 實(shí)際結(jié)果 上述的各種缺陷屬性,見 P.328 表15-7,Zhu.K,10,軟件缺陷的詳細(xì)描述,步驟”提供了如何重復(fù)當(dāng)前缺陷的準(zhǔn)確描述，應(yīng)簡明而完備、

4、清楚而準(zhǔn)確。這些信息對開發(fā)人員是關(guān)鍵的，視為修復(fù)缺陷的向?qū)?“期望結(jié)果”與測試用例標(biāo)準(zhǔn)或設(shè)計規(guī)格說明書或用戶需求等一致，達(dá)到軟件預(yù)期的功能。是驗(yàn)證缺陷的依據(jù)。 “實(shí)際結(jié)果”實(shí)際執(zhí)行測試的結(jié)果，不同于期望結(jié)果，從而確認(rèn)缺陷的存在,Zhu.K,11,15.1.5 缺陷描述的基本要求,單一準(zhǔn)確 可以再現(xiàn) 完整統(tǒng)一 短小簡練 特定條件 補(bǔ)充完善 不做評價,Zhu.K,12,15.1.6 示例,見 P.330,優(yōu)秀的缺陷報告 重現(xiàn)步驟 : 打開一個編輯文字的軟件并且創(chuàng)建一個新的文檔（這個文件可以錄入文字） 在這個文件里隨意錄入一兩行文字 選中一兩行文字，通過選擇Font 菜單然后選擇Arial字體格式

5、一兩行文字變成了無意義的亂字符 期望結(jié)果：當(dāng)用戶選擇已錄入的文字并改變文字格式的時候，文本應(yīng)該顯示正確的文字格式不會出現(xiàn)亂字符顯示。 實(shí)際結(jié)果:它是字體格式的問題，如果改變文字格式成Arial之前，你保存文件，缺陷不會出現(xiàn)。缺陷僅僅發(fā)生在Windows98并且改變文字格式成其它的字體格式，文字是顯示正常的。 見所附的圖片,Zhu.K,13,散漫的缺陷報告的示例,重現(xiàn)步驟： 在Window98上打開一個編輯文字的軟件并且編輯存在文件 文件字體顯示正常 我添加了圖片，這些圖片顯示正常 在此之后，我創(chuàng)建了一個新的文檔 在這個文檔中我隨意錄入了大量的文字 在我錄入這些文字之后，選擇幾行文字.并且通過選

6、擇Font 菜單然后選擇Arial字體格式改變文字的字體。 有三次我重現(xiàn)了這個缺陷 我在Solaris操作系統(tǒng)運(yùn)行這些步驟，沒有任何問題。 我在Mac操作系統(tǒng)運(yùn)行這些步驟，沒有任何問題。 期望結(jié)果：當(dāng)用戶選擇已錄入的文字并改變文字格式的時候，文本應(yīng)該顯示正確的文字格式不會出現(xiàn)亂字符顯示。 實(shí)際結(jié)果：我試著選擇少量的不同的字體格式，但是只有Arial字體格式有軟件缺陷，不論如何，它可能會出現(xiàn)在我沒有測試的其它的字體格式,Zhu.K,14,15.2 軟件缺陷的相關(guān)信息,15.2.1 軟件缺陷的圖片信息 15.2.2 使用WinDBG記錄軟件缺陷信息 15.2.3 使用Soft-ICE記錄軟件缺陷信

7、息 15.2.4 分離和再現(xiàn)軟件缺陷,Zhu.K,15,15.2.1 軟件缺陷的圖片信息,軟件缺陷相關(guān)的信息包括軟件缺陷的圖片、記錄信息和如何再現(xiàn)和分離軟件缺陷，使開發(fā)人員和其他的測試人員更容易分離和重現(xiàn)它。 一些涉及用戶界面(User Interface)的軟件缺陷可能很難用文字清楚地描述，因此軟件測試人員通過附上圖片比較直觀地表示缺陷發(fā)生在產(chǎn)品界面什么位置、有什么問題等,Zhu.K,16,15.2.2 使用WinDBG記錄軟件缺陷信息,WinDbg是微軟發(fā)布的源碼級調(diào)試工具，用于Kernel模式調(diào)試和用戶模式調(diào)試，可用于調(diào)試軟件崩潰后形成Dump文件，包括操作系統(tǒng)的信息、進(jìn)程運(yùn)行的狀態(tài)、時

8、間和環(huán)境變量、匯編指令、調(diào)用堆棧等 安裝、使用的具體操作方法，如提供了圖形界面和命令行兩種運(yùn)行方式 調(diào)試方式：遠(yuǎn)程調(diào)試、Dump調(diào)試、本地進(jìn)程調(diào)試 windbg remote npipe:server=SERVER_NAME,pipe=PIPE_NAME windbg z DUMP_FILE_NAME Windbg p “process id” 常用命令,Zhu.K,17,15.2.3 使用Soft-ICE記錄軟件缺陷信息,stack u eip-80 如果數(shù)據(jù)窗口是開啟的狀態(tài)，可以輸入”wd”來關(guān)閉該窗口，然后再輸入 “dd esp-20”命令。stack 、dd esp-20是為了標(biāo)注跟蹤

9、信息。 通過輸入x，退出 Soft-ICE的窗口；如果還是無法退出Soft-ICE，需要輸入faults off，然后輸入x。 打開Soft-ICE應(yīng)用程序，立即保存日志文件。一旦再次打開Soft-ICE，請輸入faults on,Zhu.K,18,15.2.4 分離和再現(xiàn)軟件缺陷,確保所有的步驟都被記錄。 特定條件和時間。 壓力和負(fù)荷、內(nèi)存和數(shù)據(jù)溢出相關(guān)的邊界條件。 考慮資源依賴性包括內(nèi)存、網(wǎng)絡(luò)和硬件共享的相互作用等。 不能忽視硬件。與軟件不同，硬件不按預(yù)定方式工作。 和開發(fā)人員緊密合作,理解分離和調(diào)試軟件缺陷之間的區(qū)別,Zhu.K,19,分離和調(diào)試軟件缺陷之間的區(qū)別,再現(xiàn)缺陷現(xiàn)象所需的最少

10、步驟有哪些？這些步驟成功再現(xiàn)的可能性多大？ 缺陷是否成立存在？測試結(jié)果是否可能起源于測試因素或者測試人員自身的錯誤，還是影響顧客需求的、系統(tǒng)真正的故障？ 哪些外部因素產(chǎn)生軟件缺陷？ 哪些內(nèi)部因素，是代碼、網(wǎng)絡(luò)、還是環(huán)境引起的軟件缺陷？ 怎樣在不產(chǎn)生新的缺陷的條件下使這個軟件缺陷得到修復(fù)？ 這種修復(fù)是否經(jīng)過調(diào)試，單元是否經(jīng)過測試？ 問題解決了嗎？它是否通過了確認(rèn)和回歸測試，確定系統(tǒng)的其余部分仍工作正常,Zhu.K,20,15.3 軟件缺陷跟蹤和分析,15.3.1 軟件缺陷處理技巧 15.3.2 缺陷趨勢分析 15.3.3 缺陷分布分析 15.3.4 缺陷跟蹤方法,Zhu.K,21,軟件缺陷的處理

11、和跟蹤,確保每個被發(fā)現(xiàn)的缺陷都能夠被解決，“解決”的意思不一定是被修正，也可能是其他處理方式（例如，延遲到下一個版本中修正或者由于技術(shù)原因不能被修正），總之，對每個被發(fā)現(xiàn)的BUG的處理方式必須能夠在開發(fā)組織中達(dá)到一致； 收集缺陷數(shù)據(jù)并根據(jù)缺陷趨勢曲線識別測試處于測試過程中的哪個階段； 決定測試過程是否結(jié)束，通過缺陷趨勢曲線來確定測試過程是否結(jié)束是常用并且較為有效的一種方式。 收集缺陷數(shù)據(jù)并在其上進(jìn)行數(shù)據(jù)分析，作為組織過程改進(jìn)的財富,Zhu.K,22,15.3.1 軟件缺陷處理技巧,審閱?？梢杂蓽y試管理員、項(xiàng)目管理員或其他人來進(jìn)行，審閱缺陷報告的質(zhì)量水平； 拒絕。如果審閱者決定需要對一份缺陷報告

12、進(jìn)行重大修改，應(yīng)該和測試人員一起討論，由測試人員糾正缺陷報告，然后再次提交； 完善。完整地描述了問題的特征并將其分離，那么審查者就會肯定這個報告； 分配。分配給適當(dāng)?shù)拈_發(fā)人員，如果不知道具體開發(fā)人員，應(yīng)分配給項(xiàng)目開發(fā)組長，由開發(fā)組長再分配給對應(yīng)的開發(fā)人員,Zhu.K,23,軟件缺陷處理技巧 (2,驗(yàn)證。缺陷的修復(fù)需要得到測試人員的驗(yàn)證，同時還要進(jìn)行回歸測試，檢查這個缺陷的修復(fù)是否會引入新的問題； 重新打開。重新打開一個缺陷，需要加注釋說明、電話溝通等，否則會引起“打開-修復(fù)”多個來回，造成測試人員和開發(fā)人員不必要的矛盾 關(guān)閉。只有測試人員有關(guān)閉缺陷的權(quán)限，開發(fā)人員沒有這個權(quán)限。 暫緩。如果每個

13、人都同意將確實(shí)存在的缺陷移到以后處理，應(yīng)該指定下一個版本號或修改的日期。一旦新的版本開始時，這些暫緩的缺陷應(yīng)該重新被打開,Zhu.K,24,15.3.2 缺陷趨勢分析,監(jiān)控（打開/關(guān)閉/已修正的）缺陷隨時間的變化 產(chǎn)品開發(fā)質(zhì)量情況取決于累積打開/關(guān)閉曲線的趨勢。 項(xiàng)目進(jìn)度取決于累積關(guān)閉/打開曲線起點(diǎn)的時間差。 開發(fā)人員、測試人員的工作進(jìn)度、效率也能得到反映,Zhu.K,25,示例,Zhu.K,26,理想趨勢圖,Zhu.K,27,示例,微軟公司基于缺陷趨勢圖的里程碑定義,Zhu.K,28,15.3.3 缺陷分布分析,缺陷分布報告，缺陷數(shù)量與缺陷屬性的函數(shù)。如測試需求和缺陷狀態(tài)、嚴(yán)重性的分布情況等

14、,Zhu.K,29,示例：根本原因圖表,Zhu.K,30,缺陷報告,Zhu.K,缺陷分布報告，允許將缺陷計數(shù)作為一個或多個缺陷參數(shù)的函數(shù)來顯示，生成缺陷數(shù)量與缺陷屬性的函數(shù)。如測試需求和缺陷狀態(tài)、嚴(yán)重性的分布情況等。 缺陷趨勢報告，按各種狀態(tài)將缺陷計數(shù)作為時間的函數(shù)顯示。趨勢報告可以是累計的，也可以是非累計的； 缺陷年齡報告，顯示缺陷處于活動狀態(tài)的時間，展示一個缺陷處于某種狀態(tài)的時間長短，從而了解處理這些缺陷的進(jìn)度情況。 測試結(jié)果進(jìn)度報告，展示測試過程在被測應(yīng)用的幾個版本中的執(zhí)行結(jié)果以及測試周期,31,15.3.3 缺陷跟蹤方法,當(dāng)前缺陷狀態(tài) Bug Dashboard 項(xiàng)目發(fā)展趨勢: 每天的變化、差異，重點(diǎn)進(jìn)行趨勢分析,Zhu.K,32,軟件缺陷報告,任何一個缺陷跟蹤系統(tǒng)的核心都是“軟件缺陷報告”，一份軟件缺陷報告詳細(xì)信息如表： 軟件缺陷項(xiàng)目列表,Zhu.K,33,軟件缺陷報告,Zhu.