1、畢業設計（論文）題 目：軟件測試方法研究學 生： 指導老師： 系 別： 計算機與信息科學系 專 業： 網絡工程 班 級： 網絡0803 學 號： 08300403 2012年4月目 錄摘 要3Abstract41. 軟件測試業現狀52. 軟件測試的目的62.1測試的目的62.2軟件測試的原則63. 軟件測試分類64. 測試用例設計實例114.1黑盒測試114.1.1等價類劃分法124.1.2邊界值分析法124.1.3因果圖方法134.1.4決策表法144.1.5錯誤推測方法154.2白盒測試155.測試案例分析165.1軟硬件環境165.1.1網絡拓撲175.1.2 Bug趨勢圖175.1.3

2、 Bug嚴重程度195.1.4 Bug引入階段205.1.5 Bug引入原因215.1.6 Bug狀態分布215.2測試結論215.2.1功能性215.2.2易用性225.2.3可靠性225.2.4兼容性225.2.5安全性225.3分析摘要225.3.1覆蓋率225.3.2遺留缺陷的影響235.4建議246.軟件測試中存在的問題及建議256.1軟件測試只是開發過程中的一個階段256.2測試人員是軟件質量的責任人256.3軟件測試的專業性266.4測試工具和測試自動化重要性的不斷提高267.總結27致 謝28參考文獻29摘 要軟件測試作為保證軟件質量和生存周期，提高軟件可靠性的重要手段，在軟件

3、開發中有著重要的作用，是軟件開發周期中必不可少的環節。隨著現代面向對象軟件工程的發展，面向對象軟件測試方法也日益顯現出其重要性。由于面向對象軟件開發方法引入了不同于傳統軟件的新特性，面向對象軟件測試與傳統軟件測試相比有更多的困難。本文系統地介紹了軟件測試的現狀、目的、分類、以及軟件測試實例，給出了軟件測試案例的選擇方法，探討了軟件測試過程中的一些注意事項以及建議。關鍵字：軟件測試；軟件可靠性；軟件開發；AbstractSoftware testing, software quality assurance and life cycle, an important means to improv

4、e software reliability, has an important role in software development is an essential part of the software development cycle. With the development of modern object-oriented software engineering, object-oriented software testing methods are also increasingly showing its importance. As the object-orie

5、nted software development methods to introduce new features, different from the traditional software object-oriented software testing and software testing compared with more difficulties. This paper systematically describes the status of software testing, the purpose of classification, as well as so

6、ftware test case, given the choice of method for software test case to explore some of the considerations in the software testing process as well as the proposed.Keyword：Software Testing；Software reliability；Software Development；1. 軟件測試業現狀近年來，盡管國內應用軟件的開發取得了突飛猛進的發展，但是離國際先進水平仍然有不小的差距，人們對于軟件質量的重視程度越來越高

7、，就導致了測試在軟件開發中的地位將越來越重要，畢竟測試是目前用來驗證軟件是否能夠完成所期望的功能的唯一有效方法。隨著計算機應用領域的迅速擴大，計算機軟、硬件新技術的不斷涌現，人們對軟件質量提出了新的更高的要求。軟件測試是軟件開發過程的一個重要組成部分，對于質量保證具有舉足輕重的作用，軟件測試的實質是根據軟件開發各階段的規格說明和程序的內部結構精心選取一批測試數據，形成測試用例，并用這些測試用例去驅動被測程序，觀察程序的執行結果，驗證所得結果與預期結果是否一致，然后做相應的調整。與國外的狀況相比，國內在軟件測試方面的研究內容相對較少，因為軟件測試在我國起步較晚，起初只是簡單的手工測試，也很少見到

8、各種軟件測試模型，軟件測試時間預測方面的研究也較少，但近幾年來隨著軟件在各個行業的應用，軟件測試也得以迅速發展。現代大規模軟件系統開發中，多層次分布式結構因其可伸縮性好、可管理性強、安全性高、軟件重用性好以及節省開發時間等諸多優點而得到廣泛應用。在系統的性能測試過程中，為了取得完整的性能數據，測試要求在不同的參數配置下反復運行、分析和調試:在同一組參數配置下，往往還要重復運行多次以收集到更可靠的數據，為了模擬系統真實的工作情形或者取得系統的極限狀態，必須進行強壓力測試，即大批量，長時間地向系統施加負荷。軟件開發過程中，迭代式的開發過程己經顯示出了與瀑布式開發相比巨大的好處，并己逐漸取代傳統的瀑

9、布式開發成為目前最流行的軟件開發過程。目前的GUI等開發技術己經非常先進，它提供給開發人員快捷開發的能力。保證軟件質量關鍵的軟件測試必然需要更多的關注與投入。2. 軟件測試的目的從不同的立場出發，對測試目的的理解是不同的，可以從軟件開發者和用戶兩個角度出發看看軟件測試的目的。軟件開發者：希望通過軟件測試驗證該軟件產品達到了用戶的要求，軟件質量是有保證的。用戶：希望經過軟件測試，暴露出軟件中的錯誤和缺陷，是否完全實現了所期望的軟件功能，從而判斷能否接受該軟件產品。2.1測試的目的2.1.1證明軟件的功能和性能是否符合規定的需求2.1.2為軟件可靠性的分析奠定了基礎；2.1.3以最少的時間和人力，

10、弄清預期結果與實際結果之間的差別。在用戶使用之前，通過發現并修正錯誤、缺陷來提高軟件質量，以避免日后軟件的錯誤和缺陷帶來難以估計的風險。2.2軟件測試的原則2.2.1軟件開發者要把“及早地、不斷地進行軟件測試”這一信條付諸行動；2.2.2由測試輸入數據、對應的預期輸出結果組成測試用例；2.2.3設計測試用例時，應包括不合理的輸入條件、合理的輸入條件；2.2.4由于存在盲目的自信，所以程序員應避免檢查自己的程序；2.2.5排除測試的隨意性，對每一個測試都嚴格執行測試計劃；2.2.6測試后，殘存的缺陷數和已發現的缺陷數成正比，所以測試過程中，要重點測試群集的程序；2.2.7為了更好地維護軟件，要妥

11、善保存測試計劃、測試用例、出錯統計和分析報告。3. 軟件測試分類隨著軟件測試技術的發展，測試方法更加多樣化，針對性更強;選擇合適的軟件測試方法可以讓我們事半功倍。以下是一些常用的軟件測試方法。測試_Beta測試軟件的多個用戶在一個或多個用戶的實際使用環境下進行的測試。測試_Alpha測試：由一個用戶在開發環境下進行的測試，在系統開發接近完成時對應用系統的測試。可移植性測試：指測試軟件是否可以被成功移植到指定的硬件或軟件平臺上。UI 測試的目標是確保用戶界面會通過測試對象的功能來為用戶提供相應的訪問或瀏覽功能，確保用戶界面符合公司或行業的標準。冒煙測試：任何新電路板焊好后，先通電檢查，如果存在設

12、計缺陷，電路板可能會短路，板子冒煙。隨機測試：根據測試者的經驗對軟件進行功能和性能抽查。隨機測試是根據測試說明書執行用例測試的重要補充手段，是保證測試覆蓋完整性的有效方式和過程。本地化測試：測試的目的是測試特定目標區域設置的軟件本地化質量，測試的環境是在本地化的操作系統上安裝本地化的軟件。國際化測試：目的是測試軟件的國際化支持能力，發現軟件的國際化的潛在問題，保證軟件在世界不同區域都能正常運行。安裝測試：確保軟件在正常情況和異常情況下，進行首次安裝、升級、完整的或自定義的安裝都能進行安裝的測試。異常情況包括磁盤空間不足、缺少目錄創建權限等場景。白盒測試：白盒測試是根據被測程序的內部結構及有關信

13、息來設計測試用例，并測試程序的邏輯路徑，所以白盒測試又稱作結構測試。在全面清楚了解軟件產品的內部工作處理過程、程序的語句和結構的前提下，白盒測試要求針對程序模塊的結構特性的達到一定覆蓋率，以檢測軟件工作處理過程的細節為基礎，通過對程序模塊完成以下工作來對軟件進行驗證：1，測試程序中每條路徑、所有內部成分是否按照規定和要求進行工作；2，測試程序內部的運行路徑、變量狀態、邏輯關系等；3，檢驗程序的運行是否滿足需求設計。黑盒測試：黑盒測試是根據程序的功能來設計測試用例。把被測程序視為一個不能打開的黑盒子，重點放在程序外部結構，不關心內部邏輯結構和特性，只針對軟件功能及界面開展測試。自動化測試：通常在

14、GUI、性能等測試和功能測試中使用。回歸測試：在發生修改之后重新測試先前的測試以保證修改的正確性。驗收測試：系統開發生命周期方法論的一個階段，這時相關的用戶或獨立測試人員根據測試計劃和結果對系統進行測試和接收。驗收測試有的三種策略：正式驗收、非正式驗收。動態測試：動通過運行軟件來檢驗軟件的動態行為和運行結果的正確性。1，單元測試2，集成測試3，系統測試4，驗收測試5，回歸測試。探索測試：指通常用于沒有產品說明書的測試，這需要把軟件當作產品說明書來看待，分步驟逐項探索軟件特性，記錄軟件執行情況，詳細描述功能，綜合利用靜態和動態技術來進行測試。單元測試：最微小規模的測試，以測試某個功能或代碼塊。典

15、型地由程序員而非測試員來做，因為它需要知道內部程序設計和編碼的細節知識。集成測試：應用系統的各個部件的聯合測試，以決定他們能否在一起共同工作并沒有沖突。部件可以是代碼塊、獨立的應用、網絡上的客戶端或服務器端程序。系統測試：基于系統整體需求說明書的黑盒類測試，應覆蓋系統所有聯合的部件。系統測試是針對整個產品系統進行的測試，目的是驗證系統是否滿足了需求規格的定義，找出與需求規格不相符合或與之矛盾的地方。端到端測試：類似于系統測試，測試級的“宏大”的端點，涉及整個應用系統環境在一個現實世界使用時的模擬情形的所有測試。健全測試：初始化的測試工作，以決定一個新的軟件版本測試是否足以執行下一步大的測試能力

16、。衰竭測試：指軟件或環境的修復或更正后的“再測試”。接受測試：基于客戶或最終用戶的規格書的最終測試，或基于用戶一段時間的使用后，看軟件是否滿足客戶要求。負載測試：測試一個應用在重負荷下的表現。強迫測試：用于描述象在異乎尋常的重載下的系統功能測試之類的測試。壓力測試：基本的質量保證行為，它是每個重要軟件測試工作的一部分。性能測試：性能測試一般包括負載測試和壓力測試。通常驗證軟件的性能在正常環境和系統條件下重復使用是否還能滿足性能指標。可用性測試：可用性測試是對“用戶友好性”的測試。卸載測試：對軟件的全部、部分或升級卸載處理過程的測試。主要是測試軟件能否卸載，卸載是否干凈，對系統有無更改，在系統中

17、的殘留與后來的生成文件如何處理等。恢復測試：恢復測試是測試一個系統從如下災難中能否很好地恢復，如遇到系統崩潰、硬件損壞或其他災難性問題。安全測試：安全測試是測試系統在防止非授權的內部或外部用戶的訪問或故意破壞等情況。兼容性測試兼容測試是測試軟件在一個特定的硬件/軟件/操作系統/網絡等環境下的性能如何。向上兼容向下兼容，軟件兼容硬件兼容。比較測試：比較測試是指與競爭伙伴的產品的比較測試，如軟件的弱點、優點或實力。可接受性測試：可接受性測試是在把測試的版本交付測試部門大范圍測試以前進行的對最基本功能的簡單測試。因為在把測試的版本交付測試部門大范圍測試以前應該先驗證該版本對于所測試的功能基本上比較穩

18、定。邊界條件測試：一種黑盒測試方法，適度等價類分析方法的一種補充，由長期的測試工作經驗得知，大量的錯誤是發生在輸入或輸出的邊界上。強力測試：強力測試通常驗證軟件的性能在各種極端的環境和系統條件下是否還能正常工作。或者說是驗證軟件的性能在各種極端環境和系統條件下的承受能力。裝配/安裝/配置測試：裝配/安裝/配置測試是驗證軟件程序在不同廠家的硬件上，所支持的不同語言的新舊版本平臺上，和不同方式安裝的軟件都能夠如預期的那樣正確運行。靜態測試：靜態測試指測試不運行的部分，靜態方法通過程序靜態特性的分析，找出欠缺和可疑之處。靜態測試常用工具有：Logiscope、PRQA;隱藏數據測試：隱藏數據測試在軟

19、件驗收和確認階段是十分必要和重要的一部分。程序的質量不僅僅通過用戶界面的可視化數據來驗證，而且必須包括遍歷系統的所有數據。等價劃分測試：等價劃分測試是根據等價類設計測試用例的一種技術。通過把被測試程序所有可能的輸入數據域劃分成若干部分。從每一部分中選取少數有代表性的數據作為測試用例，可有效減少測試次數，極大提高軟件測試效率，縮短軟件開發周期。判定表：是指一個表格，用于顯示條件和條件導致動作的集合。判定表是分析和表達多邏輯條件下執行不同操作的情況的工具。能夠將復雜的問題按照各種可能的情況全部列舉出來，簡明并避免遺漏。深度測試：是指執行一個產品的一個特性的所有細節，但不測試所有特性。必須啟用“#深

20、度測試”，才能執行測試。基于設計的測試：是根據軟件的構架或詳細設計引出測試用例的一種方法。一種基于設計模型的測試方法利用用戶界面自動生成方法，把設計模型中的類屬性定義和實現中的控件屬性組織在一起，構建描述界面的邏輯對照表，輔助測試腳本引擎執行自動測試腳本.借助設計模型中擴展的類定義，MATIS方法可以自動生成測試用例和測試數據。文檔測試：文檔測試有三大類分別是開發文件、用戶文件、管理文件。1，開發文件：可行性研究報告、軟件需求說明書、數據要求說明書、概要設計說明書、詳細設計說明書、數據庫設計說明書、模塊開發卷宗。2，用戶文件：用戶手冊、操作手冊。3，管理文件：項目開發計劃、測試計劃、測試分析報

21、告、開發進度月報、項目開發總結報告。域測試：一般分為單域測試和多域測試，其中單域測試包括設備測試和業務測試，設備測試包括測試某個系統的軟交換設備、中繼媒體網關設備、信令網關設備、接入媒體網關和IAD等設備。接口測試：接口測試的好處：由于接口測試代碼本身就是用junit來實現的，是屬于自動化測試的范疇，因此必定也包含自動化測試所固有的優勢。逆向、反向、負面測試：負面測試是相對于正面測試而言的。它們也是測試設計時的兩個非常重要的劃分。正面測試就是測試系統是否完成了它應該完成的工作，而負面測試就是測試系統是否不執行它不應該完成的操作。4. 測試用例設計實例隨著軟件測試技術的發展，測試方法更加多樣化，

22、針對性更強;選擇合適的軟件測試方法可以讓我們事半功倍。以下是常用的黑盒、白盒測試方法。4.1黑盒測試黑盒測試有時也叫作為功能測試.在這種測試方法中更多的關注于程序的外部結構，不過多考慮內部邏輯結構，主要針對軟件界面和軟件功能進行測試。在黑盒測試中，形象的把程序比作一個不能打開的盒子，在不考慮代碼的內部流程和內部優化性能的情況下，對程序的接口各個功能塊等進行測試。它只檢查程序功能是否按照需求規格說明書的規定正常使用，不考慮性能是否優化合理，只考慮程序是否能正確地接收輸入數據而產生正確的輸出信息，不考慮信息處理優化性能等。黑盒測試法主要試圖發現的錯誤有:界面圖形化錯誤，功能模塊錯誤或者遺漏，初始化

23、和終止錯誤，數據庫訪問錯誤等;用于黑盒測試的常用方法有如下幾種洲:等價類劃分法、邊界值分析法、因果圖方法、決策表法、錯誤推測方法等。4.1.1等價類劃分法等價類劃分法是指把所有可能的輸入數據劃分成若干部分，即將輸入域劃分為若干個子集。在該子集合中，各個輸入數據對于發現程序中的缺陷都是等效的，它們具有等價特性，也就是說從每個子集中選取少量具有代表性的數據作為測試用例輸入數據，它們就代表了此子集的整個類別。每一類的代表性數據在測試中的作用都等價于這一類中的其它數據。等價類劃分是黑盒測試用例設計中的常用設計方法，它將本來就不可能窮舉完的測試過程進行合理的分類，從而保證設計出來的測試用例具有典型的代表

24、性和完整性。等價類劃分方法在使用過程中有兩個步驟:第一為分類，分類就是將輸入域輸入空間，按照具有相同特性或者類似功能劃分成各個類或者等價子域;第二為抽象，就是在各個子類中抽象出相同特性，并用要用實例來表征這個特性。等價類劃分可有兩種不同的情況:有效等價類和無效等價類。舉例，在輸入條件規定了取值范圍或值的個數的情況下，則可以確立一個有效等價類和兩個無效等價類。例如數學科成績，范圍是O一150（圖4.1.1）0 150無效等價類 有效等價類 無效等價類數學成績0 0數學成績150 數學成績150圖4.1.1等價類劃分圖4.1.2邊界值分析法邊界值分析法是作為對等價類劃分方法的補充，因為它是對輸入或

25、輸出的邊界值進行測試的一種黑盒測試方法。由于它是對于等價類劃分方法的補充，所以其測試用例數據也就來自等價類的邊界。根據實際項目經驗，大部分的問題會出現在輸入域或者輸出域的邊界上，而出現在輸入域或者輸出域的內部的情況較少，因此邊界值分析法在實際項目的實施測試過程中很有實用價值。邊界值分析當然不是從某個等價類中隨便挑一個數據作為代表，而是將這個等價類的每個邊界都要作為測試條件。一般情況下，邊界值分析不僅考慮輸入條件輸入域，還要考慮輸出空間輸出域產生的測試結果情況。利用邊界值分析方法設計測試用例，首先要確定邊界情況。別外還要分析規格說明，找出邏輯中的邊界條件。通常輸入域和輸出域等價類的邊界，就是要著

26、重測試的邊界情況。在數據選取時應當選取正好等于這個邊界值，正好小于或正好大于邊界的值作為測試數據，而不是選取等價類中的典型值或任意值作為測試數據。當然在測試的過程中，這些典型的數據也是要測試的。只是在等價類劃分方法中它們不是重點測試對象而已。下面是對于不同的測試項邊界值分析選取典型值的分類總結（表4.1.2）。表4.1.2邊界值分析方法項邊界值設計思路字符起始減去1個字符/結束加上1個字符假設某個格式輸入區域允許輸入1個到1024個字符，輸入1個和1024個字符作為有效等價類，輸入0個和1025個字符作為無效等價類，這幾個數值都屬于邊界條件值。數值最小值減去1/最大值加上1假設一個軟件的數據輸

27、入4位數值，可以使用1000作為最小值，9999作為最大值，然后使用剛剛小于4位和大于四位的值作為邊界條件空間小于空余空間一點/大于滿空間一點例如在用硬盤存儲數據時，使用比剩余磁盤空間剛好大一點（及KB）的文件作為邊界條件4.1.3因果圖方法因果圖方法是一種利用圖解法分析輸入的各種組合情況，是利用因果圖解法分析輸入組合后從而設計測試用例的方法囚，它適合于要檢查程序輸入條件的各種組合的情況。為何會出現因果圖方法，這還要從等價類劃分法和邊界值分析法說起，因為等價類劃分法和邊界值分析法它們兩個都是著重考慮輸入條件，但沒有考慮輸入條件的各種組合，沒有考慮輸入條件之間的相互制約關系。這樣雖然各種輸入條件

28、可能出錯的情況已經測試到了，但多個輸入條件組合起來可能出錯的情況卻容易被忽視，這個問題就要因果圖法來解決。另外一個因果圖法存在的理由是如果在測試時必須考慮輸入條件的各種組合，組合數目可能會相當大，我們不可能將所有的組合都試一遍，而因果圖是一種適合于描述多種條件的組合邏輯模型，可以產生多個動作的形式來進行測試用例的設計。采用因果圖法設計測試用例的一般需要三個步驟:第一步:根據需求規格說明書描述，畫出因果圖。第二步:將因果圖轉換為判定表。第三步:將判定表轉換為測試用例。（圖4.1.3）11011101 （a）恒等 （b）非11110112131201（c）或 （d）與圖4.1.3因果圖的四種因果關

29、系在因果圖的基本符號中，圖中的左結點h表示輸入狀態，右結點Oi表示輸出狀態。h與Oi取值0或1，O表示狀態不出現，1則表示狀態出現。恒等:若cl是1，則01也為1，否則01為O。非:若11是1，則01為0，否則01為l。或:若n或12或13是1，則01為1，否則01為O。與:若11和12都是1，則01為l，否則01為0。4.1.4決策表法決策表法也稱判定表法，一般認為基于決策表的測試是最為嚴格、最具邏輯性的測試方法。決策表的概念:一決策表L州是表達多邏輯條件下分析和執行不同操作的情況的工具。判定表通常由四個部分組成:它們四個部分的關系可以用（圖4.1.4.1）表示 規則條件樁 條件項 動作樁

30、動作項 圖4.1.4決策表的條件樁與動作樁在判定表分析法里有相當多的規則如（表4.1.4.2）所示的規則合并。在第一個條件與第二個項分別取A、B時，無論條件三取何值，都執行同一操作。即要執行的動作與第三個條件無關。于是可合并。“一”表示與取值無關。 AABBABCCAB-C表4.1.4.2規則合并較圖4.1.5錯誤推測方法錯誤推測法是基于測試人員的經驗和直覺推測程序中所有可能存在的各種錯誤，從而有針對性的去設計測試用例的方法。錯誤推測方法的最基本思想是列舉出程序中所有可能的錯誤和最容易發生錯誤的特殊情況，從這一點就可以看出經驗在這個方法里的要求是很高的，根據羅列出的的條件來選擇測試用例。以上列

31、舉了黑盒測試常用的方法，下面是黑盒測試的流程:黑盒測試的簡要流程，第一步:測試計劃。第二步:測試設計。第三步:測試開發。第四步:測試執行。第五步:測試評估4.2白盒測試白盒測試也稱結構性測試或者邏輯驅動測試，它是按照程序內部的結構來測試程序，通過測試來檢測軟件內部是否按照需求規格說明書與設計規格說明書的規定正常進行，檢測程序代碼中的每條路徑是否都能按預定的要求正確工作。白盒測試最主要關注的是測試用例執行的程度，或者覆蓋程序源代碼邏輯結構的程度。白盒測試法要試圖發現的缺陷與錯誤如下:對程序模塊的所有獨立的執行路徑至少測試一次，看各個獨立模塊是否正確。對所有的邏輯判定，將所有真假情況都要遍歷到，取

32、“真”與取“假”的兩種情況都最少測試一次。在循環的邊界和運行界限內執行循環體，測試循環體是否正確。測試程序內部數據結構的有效性等。用于白盒測試的常用方法有如下幾種:白盒測試的測試方法有代碼檢查法、靜態結構分析法、靜態質量度量法、邏輯覆蓋法、基本路徑測試法、域測試、符號測試、Z路徑覆蓋、程序變異。白盒測試法的覆蓋標準有邏輯覆蓋、循環覆蓋和基本路徑測試。常用的六種覆蓋標準語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋和路徑覆蓋，它們發現錯誤的能力呈由弱至強的變化趨勢（表4.2.1）（表4.2.2）。表4.2.1六種覆蓋標準定義對比表語句覆蓋指的是每條語句最少執行一次判定覆蓋指的是每個判

33、定的分支最少執行一次條件覆蓋每個判定的每個條件都要取到可能的值判定判定/條件覆蓋顧名思義同時滿足判定覆蓋與條件覆蓋的情況條件組合覆蓋每個判定中各條件的每一種組合最少出現一次路徑覆蓋使程序中每一條可能的路徑最少執行一次采用白盒測試設計測試用例的一般需要三個步驟:第一步:根據代碼的功能、程序控制流程圖，規劃測試用例;第二步:統計覆蓋率，比較理想的覆蓋率是實現100%;第三步:捕捉可能未處理的某些特殊輸入所形成的錯誤或者缺陷來補充測試用例。 表4.2.2控制結構測試方法路徑測試利用流圖標識獨立路徑等路徑測試分支測試域測試等控制結構測試路徑測試包含循環和嵌套選擇路徑的策略路徑測試簡單循環嵌套串接無結構

34、循環路徑選擇5.測試案例分析5.1軟硬件環境硬件環境應用服務器數據庫服務器客戶端硬件配置CPU：Intel(R) Celeron(R) CPU 2.40GHz stepping 01Memory： 1048256kHD：ST380817AS 80G SATACPU：Intel(R) Celeron(R) CPU 2.40GHz stepping 01Memory： 1048256kHD：ST380817AS 80G SATACPU：Intel(R) Celeron(R) CPU 2.40GHz stepping 01Memory： 1048256kHD：ST380817AS 80G SATA軟

35、件配置OS：CentOS 4.2JDK 1.5.0_06Apache 2.2.0Tomcat 5.5.15OS：CentOS 4.2MySQL 5.0.17 LinuxWindow 2000 Professional （SP2）IE6.0.2900.2180.xpsp_sp2網絡環境10M LAN10M LAN10M LAN 5.1.1網絡拓撲5.1.2 Bug趨勢圖此次黑盒測試總共發布11個版本，B1B5為計劃內迭代開發版本（針對項目計劃的基線標識），B6-B11為進行的回歸測試版本，bug版本趨勢圖如下圖所示：第一階段，增量確認測試。時間從2011年7月2日到2011年8月3日。從Bug趨

36、勢圖中可以看出，每個版本的bug數基本維持在60個左右。B1：從圖中看到B1共有33個BUG，因為B1版本有一個功能模塊在B2版本才開始測試，B1測試模塊相對較少，所以B1版本bug相對較少。B2：由于B1中的一個功能模塊增加到Build 2中進行測試，這一版本除了對B1中的BUG進行驗證同時對B1進行了回歸測試，所以B2中的bug數相對B1出現了明顯的增長趨勢， B3：B3版本因為有B2版本的bug驗收測試，以及B1,B2的回歸測試，共發現67個bug，和B2基本保持一致。B4：B4版本bug數有一個下降的趨勢，是因為B4版本推遲發布，新增加了測試人員參與測試，對系統不夠熟悉，以及測試時間緊

37、張，部分測試用例沒有執行，測試覆蓋度不夠，所以發現bug數呈下降趨勢。B5：B5版本bug數又有一個增加的趨勢，主要是由于開發功能模塊多，該版本需求定義不明確。 第二階段，BUG驗證和功能回歸確認測試。時間從2011年8月4日到2011年8月14日。B6和 B7進行了回歸測試，B8沒有進行回歸測試，只驗證了B1B7的bug。B6 ：進行第一輪回歸測試，發現的bug數為33個，遺留一個問題，為數據字典種類默認值問題B7 ：進行第二輪回歸測試，第一次回歸測試沒有涉及到權限控制菜單按鈕的測試，在本次回歸測試的時候，重點進行了這個方面的測試，又發現了大量的權限相關的bug。B8 ：B8沒有進行全面的回

38、歸測試，只驗證了B1B7未通過驗證的bug，所以該版本的bug數明顯比較少。B9 ：B9版本進行了全面的回歸測試，同時重點測試了權限控制，所以發先的bug數又呈現上升的趨勢。測試發現44個bug，嚴重級別的bug為14個，嚴重級別的bug集中在權限控制上，功能性嚴重bug沒有發現，說明權限控制依舊不穩定，但是系統功能已經穩定。B10：B10版本驗證了B9版本發現得bug，沒有進行全面的回歸測試。B10版本在驗證bug的時候，重現打開Bug6個，新增bug2個，重新打開bug有5個為嚴重級別bug，是關于權限控制的bug，而新發現的bug，1個為嚴重級別的bug，也是屬于權限控制的。說明，權限控

39、制還存在著問題，需要修改權限管理bug，重新發布版本后進行全面的回歸測試。B10版本新發現的bug詳細分析見遺留bug分析。B11：B11中驗證了B1B10未驗證的bug，重點測試了權限控制，同時進行了查詢，添加，刪除，修改的功能測試，測試過程中未發現bug。5.1.3 Bug嚴重程度 測試發現的bug主要集中在normal和minor階段，屬于一般性的缺陷，但是測試的時候，出現了68個嚴重級別的bug，出現嚴重級別的bug主要表現在以下幾個方面ü 系統主要功能沒有實現ü 添加數據代碼重復后，出現的找不到頁面的錯誤ü 多語言處理，未考慮非語種代碼的情況ü

40、 數據庫設計未考慮系統管理員角色，導致用系統管理員進行操作的時候出現找不到頁面錯誤ü 權限控制異常嚴重級別bug按版本分布如下：由嚴重bug版本分布圖可以看出，嚴重級別的bug版本趨勢和bug版本趨勢基本是一致的，但是，在B7和B9版本中年，嚴重級別的bug明顯增多，主要原因是B7和B9版本測試了權限控制按鈕功能，權限問題出現的嚴重級別的bug比較多。權限bug主要表現：ü 具有相應按鈕操作的權限，頁面無相應按鈕，無法執行該功能ü 無相應按鈕操作權限，頁面有相應按鈕，點擊按鈕能出現權限異常錯誤ü 有相應按鈕操作權限，有相應按鈕，執行該功能出現權限異常錯誤

41、5.1.4 Bug引入階段由上圖可以看出，主要為前臺編碼和頁面設計方面的bug，占到了全部bug的2/3。5.1.5 Bug引入原因由上圖可以看出，主要為前臺編碼和易用性方面的bug，占到了全部bug的2/3。5.1.6 Bug狀態分布由bug狀態圖可以看出，未解決的bug有4個，主要是B8中新提交的bug，是關于用戶管理的bug，因為用戶權限管理需要重新設計所以，該部分的bug暫時沒有解決。5.2測試結論5.2.1功能性系統正確實現了通過數據字典管理基礎數據的功能，實現了數據內容的多語言功能，實現了中英文界面。實現了基礎數據管理，酒店集團管理，酒店基礎信息管理，渠道管理，代理管理，用戶管理的

42、查詢，添加，修改，刪除的功能，系統還實現了將權限控制細化到菜單按鈕的功能。系統在實現用戶管理下的權限管理功能時，存在重大的缺陷，權限控制不嚴密，權限設計有遺漏。5.2.2易用性 現有系統實現了如下易用性：ü 查詢，添加，刪除，修改操作相關提示信息的一致性，可理解性ü 輸入限制的正確性ü 輸入限制提示信息的正確性，可理解性，一致性現有系統存在如下易用性缺陷：ü 界面排版不美觀ü 輸入，輸出字段的可理解性差ü 輸入缺少解釋性說明ü 中英文對應的正確性ü 中英文混排5.2.3可靠性現有系統的可靠性控制不夠嚴密，很多控制是

43、通過頁面控制實現的，如果頁面控制失效，可以向數據庫插入數據，引發錯誤。現有系統的容錯性不高，如果系統出現錯誤，返回錯誤類型為找不到頁面錯誤，無法回復到出錯前的狀態5.2.4兼容性現有系統支持window下的IE瀏覽器和傲游瀏覽器，支持linux系統下的IE瀏覽器和火狐瀏覽器。5.2.5安全性現有系統控制了以下安全性問題：ü 把某一個登錄后的頁面保存下來，不能單獨對其進行操作不進行登錄ü 直接輸入某一頁面的Url能否打開頁面并進行操作不應該允許。現有系統未控制以下安全性問題：ü 用戶名和密碼應對大小寫敏感ü 登陸錯誤次數限制5.3分析摘要5.3.1覆蓋率此

44、次測試，所有測試用例都是在中文界面下執行，未在英文界面下執行，測試不包括英文界面下的測試，也不包括正對英文翻譯的測試。此次測試，部分頁面需求描述無明確的定義，對輸入限制無詳細定義，無明確的測試依據，在測試過程中，測試是根據輸入字段含義，測試人員理解，以及和項目經理，開發人員溝通獲得測試依據，無法保證測試依據的正確性和完整性，因此，沒有進行完整的，正確的無效數據的測試，測試覆蓋率不夠，無法保證測試的有效性和正確性下面為此次測試測試用例覆蓋率分析圖：5.3.2遺留缺陷的影響 缺陷描述：酒店娛樂項添加頁面， “距離”字段無單位，建議增加單位缺陷影響：距離字段無單位說明，無衡量標準，用戶易用性不好推遲

45、原因：需求定義無單位定義，統一在升級版本中解決缺陷描述：酒店基礎信息管理模塊，默認語言設置不一致。用中文查詢酒店，進入酒店基礎信息模塊后，如下模塊，語言顯示為“請選擇”列表頁面添加頁面取消政策停留政策擔保政策機場參照點會議室詳情打包促銷服務Rate而其他模塊語言顯示“中文語言”缺陷影響：相同功能模塊默認語言設置不一致，一致性不好推遲原因：默認語言設置，目前無統一標準，升級版本中統一缺陷描述：tomcat日志有亂碼，日志無項目名稱，查看不方便缺陷影響：其他項目日志都有項目名稱，日志無項目名稱，查看不方便推遲原因：目前的日志為了調試方便，顯示了很多其它信息，在項目正式發布時會統一處理的。缺陷描述：

46、取消政策管理要么，取消時間“天/小時”缺少單位補充字段缺陷影響：該處因為是兩個不同的單位時間，需要有另外一個單位補充字段補充所所填寫內容的單位推遲原因：該缺陷單位補充字段本來存在，翻譯不夠準確，不能理解為補充單位的字段，需要等翻譯完畢后再確認。缺陷描述：數據字典種類修改，默認值設置后，在調用該數據字典種類的數據字典，默認值無顯示缺陷影響：數據字典種類的默認值設置后，不能顯示設置的默認值，相當于數據字典種類默認值設置功能未實現推遲原因：該功能暫時不好實現，需要和和系統的默認語種一起處理。缺陷描述：擔保政策管理頁面，“Edposit Due”缺少解釋行輸入描述信息缺陷影響：缺少解釋性輸入描述信息，

47、用戶不理解應該輸入什么內容推遲原因：需求沒有描述，需要解釋性說明文字由項目經理整理后，在升級版本中添加缺陷描述：多媒體添加，文件上傳功能未實現缺陷影響：文件上傳功能未實現推遲原因：該功能暫時不好完成，在下個版本中完成缺陷描述：參照點添加權限和修改權限單獨控制出現權限異常錯誤缺陷影響：用戶執行添加，修改時，出現權限異常，無法完成任務推遲原因：B9版本發現該權限，B10版本未通過驗證，目前該模塊開發人員調休，無法修改bug，缺陷描述：酒店渠道綁定關系權限控制出現權限異常錯誤缺陷影響：a>權限控制易用性不好，會引起用戶誤操作;b>權限控制錯誤推遲原因：B9版本發現該權限，B10版本未通過

48、驗證。該模塊后臺無insert權限,只有Update權限，與其他模塊不同，需要重新設置權限控制方式。缺陷描述：酒店Rate綁定關系權限控制出現權限異常錯誤缺陷影響：a>權限控制易用性不好，會引起用戶誤操作; b>權限控制錯誤推遲原因：B9版本發現該權限，B10版本未通過驗證。該模塊后臺無insert權限,只有Update權限，與其他模塊不同，需要重新設置權限控制方式。缺陷描述：新建業務管理員權限用戶，進入打包促銷頁面出現權限異常錯誤缺陷影響：除系統管理員外，其他用戶無法進行打包促銷操作推遲原因：B10版本發現該bug，目前該模塊開發人員調休，無法修改bug5.4建議在項目開始的時候

49、應該制定編碼標準，數據庫標準，需求變更標準，開發和測試人員都嚴格按照標準進行，可以在后期減少因為開發，測試不一致而導致的問題，同時也可以降低溝通成本。發布版本的時候，正確布置測試環境，減少因為測試環境，測試數據庫數據的問題而出現的無效bug。開發人員解決bug的時候，填寫bug原因以及解決方式，方便bug的跟蹤。開發人員在開發版本上發現bug，可以通知測試人員，因為開發人員發現的bug很有可能在測試版本上出現，而測試人員和開發人員的思路不同，有可能測試人員沒有發現該bug，而且，這樣可以保證發現的bug都能夠被跟蹤。6.軟件測試中存在的問題及建議隨著客戶對軟件產品質量的要求越來越高，軟件測試的

50、重要性也在逐步增加。然而，重視開發而輕視測試的現象依舊存在，其中存在的軟件測試的一些誤區，將會進一步影響軟件測試活動的有效開展，并且阻礙測試質量和能力的提高。 對軟件測試過程中的一些現象進行分析和梳理，以幫助測試人員更好定位和開展測試工作。 6.1軟件測試只是開發過程中的一個階段在傳統的瀑布軟件開發模型中，軟件測試只是開發過程中“編碼和實現”階段之后的一個階段，是軟件產品交付給用戶之前的保證軟件質量的一個手段。 但是，隨著客戶對軟件質量的要求越來越高，以及軟件測試行業的不斷發展，軟件測試在開發過程中扮演的角色越來越重要。人們逐步認識到軟件測試不只是軟件項目的收尾工作，而應該貫穿于整個軟件開發生

51、命周期。軟件測試過程應該并行與軟件開發過程，具體的測試過程應該包括測試計劃階段、測試設計階段、測試執行階段、測試結束階段，以及貫穿于整個過程的測試監控。在軟件開發生命周期的每個階段，都需要進行不同目的和內容的測試活動，以保證每個階段軟件工作產品的正確性。同時，軟件測試的對象也不僅僅是代碼，同時也包括需求規格說明、設計規格說明等工作產品，即軟件測試不僅僅包括動態測試，也需要評審這樣的靜態測試。 6.2測試人員是軟件質量的責任人 很多人認為測試人員需要對發布的軟件產品質量負責，假如軟件產品提交給客戶之后發現問題，那就是測試人員的責任。這種認識誤區非常打擊測試人員的積極性，同時也給予了測試人員過高的產品質量方面的壓力。因此通過測試只能證明軟件中存在缺陷，但無法保證其中沒有缺陷，在用戶現場發現缺陷是正常的，我們需要做的是分析為什么會遺漏這樣的缺陷，是由于測試覆蓋不全面，還是原來的需求定義和功能設計方面的錯誤引起的，避免在將來的項目中