1.軟件缺陷的定義
軟件缺陷，常常又被叫做Bug，從產品內部看，缺陷是軟件產品開發(fā)或維護過程中存在的錯誤、毛病
等各種問題；從產品外部看，缺陷是系統(tǒng)所需要實現的某種功能的失效或違背。
格蕾絲·赫柏（GraceMurrayHopper），是一位為美國海軍工作的電腦專家，也是最早將人類語言
融入到電腦程序的人之一。而代表電腦程序出錯的“bug”這名字，正是由赫柏所取的。1947年9月9
日，赫柏對HarvardMarkII設置好17000個繼電器進行編程后，技術人員正在進行整機運行時，它突然
停止了工作。于是他們爬上去找原因，發(fā)現這臺巨大的計算機內部一組繼電器的觸點之間有一只飛蛾，這
顯然是由于飛蛾受光和熱的吸引，飛到了觸點上，然后被高電壓擊死。所以在報告中，赫柏用膠條貼上飛
蛾，并把“bug”來表示“一個在電腦程序里的錯誤”，“Bug”這個說法一直沿用到今天。
2.軟件缺陷的種類劃分
按照軟件缺陷的產生原因，可以將其劃分為不同的缺陷類別：
1、功能不正常
簡單地說就是所應提供的功能，在使用上并不符合產品設計規(guī)格說明書中規(guī)定的要求，或是根本無法
使用。這個錯誤常常會發(fā)生在測試過程的初期和中期，有許多在設計規(guī)格說明書中規(guī)定的功能無法運行，
或是運行結果達不到預期設計。最明顯的例子就是在用戶接口上所提供的選項及動作，使用者操作后毫無
反應。
2、軟件在使用上感覺不方便
只要是不知如何使用或難以使用的軟件，在產品設計上一定是出了問題。所謂好用的軟件，就是使用
上盡量方便，使用戶易于操作。如微軟推出的軟件，在用戶接口及使用操作上確實是下了一番功夫。有許
多軟件公司推出的軟件產品，在彼此的接口上完全不同，這樣其實只會增加使用者的學習難度，另一方面
也凸顯了這些軟件公司的集成能力不足。
3、軟件的結構未做良好規(guī)劃
這里主要指軟件是以自頂向下方式開發(fā)，還是以自底向上方式開發(fā)。如果是以自頂向下的結構或方法
開發(fā)的軟件，在功能的規(guī)劃及組織上比較完整，相反以自底向上的組合式方法開發(fā)處的軟件則功能較為分
散，容易出現缺陷。
4、提供的功能不充分
這個問題與功能不正常不同，這里指的是軟件提供的功能在運作上正常，但對于使用者而言卻不完整。
即使軟件的功能運作結果符合設計規(guī)格的要求，系統(tǒng)測試人員在測試結果的判斷上，也必須從使用者的角
度進行思考，這就是所謂的“從用戶體驗出發(fā)”。
5、與軟件操作者的互動不良
一個好的軟件必須與操作者之間可以實現正?；印Ｔ诓僮髡呤褂密浖倪^程中，軟件必須很好地響
應。例如在瀏覽網頁時，如果操作者在某一網頁填寫信息，但是輸入的信息不足或有誤。當點擊“確定”
按鈕后，網頁此時提示操作者輸入信息有誤，卻并未指出錯誤的哪里，操作者只好回到上一頁重新填寫，
或直接放棄離開。這個問題就是典型的在軟件對操作互動方面未做完整的設計。
6、使用性能不佳
被測軟件功能正常，但使用性能不佳，這也是一個問題。此類缺陷通常是由于開發(fā)人員采用了錯誤的
解決方案，或使用了不恰當的算法導致的，在實際測試中有很多缺陷都是因為采用了錯誤的解決方法，需
要加以注意！
7、為做好錯誤處理
軟件除了避免出錯之外，還要做好錯誤處理，許多軟件之所以會產生錯誤，就是因為程序本身對于錯
誤和異常處理的缺失。例如被測軟件讀取外部的信息文件并已做了一些分類整理，但剛好所讀取的外部信
息文件內容已被損毀。當程序讀取這個損毀的信息文件時，程序發(fā)現問題，此時操作系統(tǒng)不知該如何處理
這個情況，為保護系統(tǒng)自身只好中斷程序。由此可見設立錯誤和異常處理機制的重要性！
8、邊界錯誤
緩沖區(qū)溢出問題在這幾年已成為網絡攻擊的常用方式，而這個缺陷就屬于邊界錯誤的一種。簡單來說，
程序本身無法處理超越邊界所導致的錯誤。而這個問題，除了編程語言所提供的函數有問題之外，很多情
況下是由于開發(fā)人員在聲明變量或使用邊界范圍時不小心引起的。
9、計算錯誤
只要是計算機程序，就必定包括數學計算。軟件之所以會出現計算錯誤，大部分出錯的原因是由
于采用了錯誤的數學運算工時或未將累加器初始化為0.
10、使用一段時間所產生的錯誤
這類問題是程序開始運行正常，但運行一段時間后卻出現了故障。最典型的例子就是數據庫的查
找功能。某些軟件在剛開始使用時，所提供的信息查找功能運作良好，但在使用一段時間后發(fā)現，進行信
息查找所需的時間越來越長。經分析查明，程序采用的信息查找方式是順序查找，隨著數據庫信息的增加，
查找時間自然會變長。這就需要改變解決方案了！
11、控制流程的錯誤
控制流程的好壞，在于開發(fā)人員對軟件開發(fā)的態(tài)度及程序設計是否嚴謹。軟件在狀態(tài)間的轉變是
否合理，要依據業(yè)務流程進行控制。例如，用軟件安裝程序解釋這類問題最方便直觀。用戶在進行軟件安
裝時，輸入用戶名和一些信息后，軟件就直接進行了安裝，未提示用戶變更安裝路徑、目的地等。這就是
軟件控制流程不完整導致的錯誤問題。
12、在大數據量壓力下所產生的錯誤
程序在處于大數據量狀態(tài)下運行出現問題，就屬于這類軟件錯誤。大數據量壓力測試對于Server
級的軟件是必須進行的一項測試，因為服務器級的軟件對穩(wěn)定性的要求遠比其它軟件要高。通常連續(xù)的大
數據量壓力測試是必須實施的，如讓程序處理超過10萬筆數據信息，再來觀察程序運行的結果。
13、在不同硬件環(huán)境下產生的錯誤
這類問題的產生與硬件環(huán)境的不同相關。如果軟件與硬件設備有直接關系，這樣的問題就是數量
相當多。例如有些軟件在特殊品牌的服務器上運行就會出錯，這是由于不同的Server內部硬件了不同的處
理機制。
14、版本控制不良導致的錯誤
出現這樣的問題屬于項目管理的疏忽，當然測試人員未能盡忠職守也是原因之一。例如一個軟件
被反映有安全上的漏洞，后來軟件公司也很快將修復版本提供給用戶。但在一年后他們推出新版本時，卻
忘記將這個已解決的bug-fix加入到新版本中。所以對用戶來說，原本的問題已經解決了，但想不到新版本
升級之后，問題又出現了。這就是由于版本控制問題，導致不同基線的merge出現誤差，使得產品質量也
出現了偏差。
15、軟件文檔的錯誤
最后這類缺陷是軟件文檔錯誤。這里所提及的錯誤，除了軟件所附帶的使用手冊、說明文檔及其
它相關的軟件文檔內容錯誤之外，還包括軟件使用接口上的錯誤文字和錯誤用語、產品需求設計PD、UISpec
等的錯誤。錯誤的軟件文檔內容除了降低產品質量外，最主要的問題是會誤導用戶！
軟件缺陷是計算機軟件或程序中存在的某種破壞正常運行能力的問題、錯誤,或者隱藏的功能缺陷。缺陷的存在會導致軟件產品在某種程度上不能滿足用戶的需要。IEEE729-1983對缺陷有一個標準的定義:從產品內部看,缺陷是軟件產品開發(fā)或維護過程中存在的錯誤、毛病等各種問題;從產品外部看,缺陷是系統(tǒng)所需要實現的某種功能的失效或違背。在軟件開發(fā)生命周期的后期,修復檢測到的軟件錯誤的成本較高。缺陷的表現形式不僅體現在功能的失效方面,還體現在其他方面。
主要類型:
軟件沒有實現產品規(guī)格說明所要求的功能模塊;
軟件中出現了產品規(guī)格說明指明不應該出現的錯誤;
軟件實現了產品規(guī)格說明沒有提到的功能模塊;
軟件沒有實現雖然產品規(guī)格說明沒有明確提及但應該實現的目;
軟件難以理解,不容易使用,運行緩慢,或從測試員的角度看,最終用戶會認為不好。
注意
發(fā)現缺陷后,要盡快修復缺陷。其原因在于錯誤并不只是在編程階段產生,需求和設計階段同樣會產生錯誤。也許一開始,只是一個很小范圍內的錯誤,但隨著產品開發(fā)工作的進行,小錯誤會擴散成大錯誤,為了修改后期的錯誤所做的工作要大得多,即越到后來往前返工也越遠。如果錯誤不能及早發(fā)現,那只可能造成越來越嚴重的后果。缺陷發(fā)現或解決的越遲,成本就越高。
3.軟件缺陷的屬性
1.1.14.按照嚴重程度分:
一般分為5個等級:
系統(tǒng)崩潰，嚴重，一般，次要，建議
在軟件缺陷中不僅僅只是嚴重極別，更多的則是功能沒有做到。說到這里也許大家都理解了，就是需求沒有考慮到，可需求不會一次就很完美的，需要大家的共同努力，來不斷的完善。那么怎樣才能讓測試人員提出的好的建議得到有效的執(zhí)行？這就是我下面想說的。在軟件缺陷中還有一種分法，跟據缺陷內容來分，主要分為需求Bug與程序Bug，對于這種分法的好處就是明確了Bug處理的責任人。對于程序Bug我們都知道是由相關開發(fā)人員進行處理。下面主要討論一下需求Bug,需求Bug從名稱上來就知道是要交由需求人員進行處理，可怎么處理，怎樣在處理的過程中有效的讓這些創(chuàng)意得到體現?，F在我們都有Bug管理系統(tǒng)，這時我們的測試人員將需求Bug不是提交給程序員，而是提交給需求分析人員，由他們進行處理，不過這里我想強調的是對需求Bug的定位，如果這個Bug在軟件需求說明書中明確提到了，這時就不可能定位它為需求Bug，它是必需讓程序員實現的，稱為軟件功能缺陷，提交由程序員進行處理。但如果需求說明書沒有明確提到的，我們則可以定位為需求Bug.
這樣處理有以下好處，首先需求Bug再不象以前，沒有人進行確認，需求的處理人員本來就是需求人員，由他們確認與跟蹤是最好不過的，因為他們對需求有絕對的權威。同時測試人員其實就是最早的用戶，他們的需求就是用戶的需求，這種方法加強了需求人員與測試人員的溝通，使需求得到有效的補充，從而讓產品更加完善。還有測試人員從本質上來說與程序員還是對立的，這里如果為了這樣一個不是軟件本身問題的問題形成與開發(fā)人員的對立，則會出現贏得戰(zhàn)役而丟失整個戰(zhàn)爭的情況，測試人員協(xié)調好與開發(fā)人員的關系，讓他們更有效的對軟件本身的缺陷形成有效的關注是最好的。還有最為關鍵的一點，測試人員的激情是最重要的，如果他們的想法沒有得到體現，這時會漸漸的失去對測試的興趣，從而軟件的質量則會無法得到保證，通過這種方法可以讓他們看到自己的建議可以通過對需求人員的反映得到實現，讓他們時時覺得自己的想法是可以通過這種方法來有效的推行，這樣工作的積極性才會有保障。
不過從實施的角度來說，還是有一定的困難的，首先要讓大家改變以前那種凡是Bug就是由開發(fā)人員負責的觀念，其次需求人員的工作量是要加大的，不過廣泛的了解需求是他們的本份工作，想來不會很困難，還有必需要有有效的Bug管理工具，比如BugManage等等，不要出現那種對需求人員說了，可過兩天就忘的情況出現，這時需求Bug的生命周期會出現跨越兩個軟件開發(fā)周期，因為有些需求會在下一版實現，這時測試人員需要延長對這些需求Bug的管理，不過我想這些需求是他們提出的，會有興趣對這些Bug進行管理的。
1.1.15.按優(yōu)先級分:
修正優(yōu)先級：高，中，低
