軟件缺陷報告_第1頁
軟件缺陷報告_第2頁
軟件缺陷報告_第3頁
軟件缺陷報告_第4頁
軟件缺陷報告_第5頁
已閱讀5頁,還剩18頁未讀 繼續(xù)免費閱讀

下載本文檔

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

文檔簡介

1、軟件缺陷報告分享目錄1.軟件缺陷軟件缺陷1.1軟件缺陷的含義1.2軟件缺陷的屬性1.3軟件缺陷產(chǎn)生的原因1.4軟件缺陷的分布1.5如何確認缺陷1.6軟件缺陷的讀者1.6.1讀者希望從軟件缺陷報告中得到的內(nèi)容2.軟件缺陷報告軟件缺陷報告2.1衡量缺陷報告質(zhì)量的標準2.2軟件缺陷的寫作準則2.3怎樣有效記錄缺陷2.4缺陷報告的產(chǎn)生過程2.5缺陷報告寫作過程中注意事項1.軟件缺陷軟件缺陷1.1軟件缺陷的含義 什么是軟件缺陷? 不滿足用戶確定需求 簡單的說就是存在于軟件(文檔、數(shù)據(jù)、程序)之中的那些不希望,或不可接受的偏差,而導致軟件產(chǎn)生的質(zhì)量問題。按照一般的定義,只要符合下面5個規(guī)則中的一個,就叫做

2、軟件缺陷。可稱之為軟件缺陷的五個規(guī)則:軟件未達到產(chǎn)品說明書標明的功能軟件出現(xiàn)了產(chǎn)品說明書指明不會出現(xiàn)的錯誤軟件功能超出產(chǎn)品說明書指明范圍軟件未達到產(chǎn)品說明書雖未指出但應(yīng)達到的目標軟件測試員認為軟件難以理解、不易使用、運行速度緩慢,或者最終用戶認為不好屬性名稱描述缺陷標識(identifier) 缺陷標識是標記某個缺陷的一組符號。每個缺陷必須有一個唯一的標識缺陷類型 (type) 缺陷類型是根據(jù)缺陷的自然屬性劃分的缺陷種類。缺陷嚴重程度 (severity)缺陷嚴重程度是指因缺陷引起的故障對軟件產(chǎn)品的影響程度。缺陷優(yōu)先級(priority) 缺陷的優(yōu)先級指缺陷必須被修復的緊急程度。缺陷狀態(tài)(st

3、atus) 缺陷狀態(tài)指缺陷通過一個跟蹤修復過程的進展情況。缺陷起源(origin) 缺陷來源指缺陷引起的故障或事件第一次被檢測到的階段。缺陷來源(source)缺陷來源指引起缺陷的起因缺陷根源(root cause)缺陷根源指發(fā)生錯誤的根本因素1.2軟件缺陷的屬性1.3軟件缺陷產(chǎn)生的原因 工期短,任務(wù)大; 程序設(shè)計錯誤; 文檔不完善; 需求不斷變化; 溝通交流不夠; 軟硬件環(huán)境不完善; 軟件的復雜性1.4軟件缺陷的分布(主要在于產(chǎn)品的描述及說明書)1.5如何確認缺陷判斷發(fā)現(xiàn)的問題是否是缺陷的方法 通過參考文檔來確認缺陷 通過了解軟件產(chǎn)品的行業(yè)背景(或參考同類典型軟件)來發(fā)現(xiàn)缺陷 通過溝通來確認

4、和識別缺陷1.6缺陷報告的讀者在書寫軟件缺陷報告之前,需要明白誰是缺陷報告的讀者對象,知道讀者最希望從缺陷報告中獲得什么信息。通常,缺陷報告的直接讀者是軟件開發(fā)人員和質(zhì)量管理人員;來自市場和技術(shù)支持等部門的人員讀者希望從軟件缺陷報告中得到的內(nèi)容易于搜索軟件測試報告的缺陷;報告的軟件缺陷進行了必要的隔離,報告的缺陷信息具體、準確;軟件開發(fā)人員希望獲得缺陷的本質(zhì)特征和復現(xiàn)步驟;市場和技術(shù)支持等部門希望獲得缺陷類型分布以及對市場和用戶的影響程度。2.軟件缺陷報告軟件缺陷報告2.1衡量缺陷報告質(zhì)量的標準對管理層來說,是清晰明了的,特別是在概要這一級;對于開發(fā)部門是有用的,主要是給出能夠讓開發(fā)人員高效地

5、調(diào)試問題的相關(guān)信息可以使測試人員很快的將bug從“opened”狀態(tài)轉(zhuǎn)變成“closed”狀態(tài),減少從開發(fā)人員打回的差的bug report并導致測試人員返工的時間。2.2軟件缺陷報告的準則correct(準確):每個組成部分的描述準確,不會引起誤解; clear(清晰):每個組成部分的描述清晰,易于理解; concise(簡潔):只包含必不可少的信息,不包括任何多余的內(nèi)容; complete(完整):包含復現(xiàn)該缺陷的完整步驟和其他本質(zhì)信息; consistent(一致):按照一致的格式書寫全部缺陷報告。2.3怎樣有效記錄缺陷保證缺陷重現(xiàn)分析故障使用最少步驟復現(xiàn)故障包含所有重現(xiàn)缺陷的必要步驟方

6、便閱讀盡量簡單一個缺陷一個報告注意自己的語氣報告隨機缺陷不夸大缺陷報告小缺陷及時報告缺陷引用別人報告不要擅自修改缺陷報告中注明姓名和日期2.4缺陷報告的產(chǎn)生過程 組織-重現(xiàn)-隔離-歸納-對比-總結(jié)-精簡-消除歧義-中立-檢查組織組織structure:測試人員應(yīng)該采用深思熟慮的,小心謹慎的方法執(zhí)行測試,并且做詳盡的記錄。這樣可以促使他們對測試下的系統(tǒng)有很好的認識。當錯誤發(fā)生的時候,一個有組織的測試人員能夠知道最早出現(xiàn)問題的地方在哪;重現(xiàn)重現(xiàn)reproduce:測試人員在編寫bug report之前必須在檢查問題是否可重現(xiàn)。如果錯誤不可再重現(xiàn),仍然應(yīng)該寫下來,但是必須說明問題的偶然性。一個好的處

7、理原則就是在編寫bug report之前反復嘗試3次;隔離隔離isolate:在嘗試編寫bug report之前,必須試著隔離錯誤。可以采用改變一些變量的方法,如系統(tǒng)的配置,它可能會改變錯誤的癥狀。這些信息可以為開發(fā)人員著手調(diào)試提供思路;歸納歸納generalize:在測試人員發(fā)現(xiàn)了一個已隔離的,可重現(xiàn)的問題后,應(yīng)該對問題進行歸納。同一個問題是否出現(xiàn)在其他的模塊或其他的地方?同一個故障是否有更加嚴重的問題;對比對比compare:如果測試人員驗證過現(xiàn)在出錯的測試用例,那么他就應(yīng)該檢查以前的測試結(jié)果以檢查相同的條件是否通過以前的測試。如果是的話, 那么這個問題就象是一個回歸的錯誤。注意由于同一測

8、試條件有可能出現(xiàn)在多個測試用例中,這個步驟就不僅僅只是檢查一個測試用例在以前的多個結(jié)果;總結(jié)總結(jié)summarize:在bug report的第一行寫上錯誤的總結(jié)是非常關(guān)鍵的。測試人員要思考已發(fā)現(xiàn)的錯誤對客戶有何影響。這不僅僅要求測試人員編寫的報告要能夠吸引讀者,可以和讀者溝通清晰,還要能夠幫助設(shè)置錯誤修復的優(yōu)先級別;精簡精簡condense:在bug report的初稿完成后,測試人員應(yīng)該反復閱讀它,集中剔除那些沒有關(guān)系的步驟或詞語。隱含的或模糊的說明和那些由于對沒有任何關(guān)系的細節(jié)或者那些在重現(xiàn)錯誤過程中不需要的步驟而消磨報告歡迎程度的無窮嘮叨都不是bug report的目標;消除歧義消除歧義

9、disambiguate:測試人員在精簡空話的同時或其之后隨即應(yīng)該再仔細檢查報告是否有會產(chǎn)生誤解的地方。測試人員應(yīng)該盡量避免使用模糊的,會產(chǎn)生歧義的和主觀的詞語。目標是使用能夠表述事實,清楚的,不會產(chǎn)生爭執(zhí)的詞語;中立中立neutralize:如同所有的錯誤總結(jié)一樣,獨立的bug report在措辭方面應(yīng)該保持公正。攻擊開發(fā)人員,指責潛在的錯誤,企圖詼諧或使用挖苦將引起開發(fā)人員的憎惡,并且使注意力從“提高產(chǎn)品質(zhì)量”這個大的目標上轉(zhuǎn)移開了。謹慎的測試人員只用bug report來描述事實;檢查檢查review:一旦編寫好bug report,作者應(yīng)該再次閱讀,確保符合缺陷報告的寫作準則,然后提交

10、至bug管理工具中。同時,也可以在測試人員之間互相檢查,完善后再提交。在允許的時間里,測試小組應(yīng)該盡可能提交最好的bug report。2.5缺陷報告寫作過程中注意事項 標題應(yīng)該保持簡短、準確、易于理解,提供缺陷的本質(zhì)信息,并且便于讀者搜索查尋;使用委婉的說法:“混亂的ui”可以被溫和些改為“不正確的ui”; 避免使用: “我(i)”“你(you)”情緒化的語言和強調(diào)符號!“似乎”“看上去可能” 認為比較幽默的內(nèi)容不確定的測試問題清楚的列出前提條件;“可重現(xiàn)的步驟”的流程應(yīng)該是合乎邏輯的;“可重現(xiàn)的步驟”應(yīng)該詳盡。例如,如果你想用戶在microsoft word里保存一個文件,你可以要求用戶到

11、file菜單并且點擊save子菜單項。你也可以只說“保存文件”;如果bug是隨機出現(xiàn)的,只需在bug report中說一下就可以了。但是不要忘記歸檔它;寫下問題可以被重現(xiàn)的平臺;遇到幾個問題卻有一樣的結(jié)果,只需寫一個bug report;截屏截屏是驗證的一種方法。在截屏上寫上注釋以指出問題所在。這將幫助開發(fā)人員一眼就可以馬上定位問題; 盡量使用jpg或gif的格式,而不是bmp格式; 為了更好的傳遞缺陷圖像的信息,圖片的命名應(yīng)該盡量與bug內(nèi)容一致。書寫摘要的例子原始描述錯誤原因改進的標題英文單詞的連字符不管用描述太籠統(tǒng)。什么時候不起作用?在行末尾換行時,不能根據(jù)英文單詞長度設(shè)置連字符。段落調(diào)整出現(xiàn)錯誤狀態(tài)描述太籠統(tǒng)。不正確的行為是什么?選定兩個單詞,啟動單詞“字間距”自動調(diào)整后間隔排版錯誤。警告:該命令產(chǎn)生

溫馨提示

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

評論

0/150

提交評論