軟件測試 - 測試基礎知識

 

 

 

 

 

 

 

軟件測試知識整理

 

 

 

軟件測試

   

    使用人工或自動手段，來運行或測試某個系統的過程。其目的在於檢驗它是否知足規定的需求或弄清預期結果與實際結果之間的差異。

 

 

 

 

 

賈祥玉

 

軟件測試經常使用術語

 1、軟件【Software】
    軟件（software）是計算機中與硬件（hardware）相結合的一部分，包括程序（program）和文檔（document）。用一個等式表示爲：軟件＝程序＋文檔。其中，「程序」指的是可以實現某種功能的指令的集合，如C語言程序，Java程序等；「文檔」指的是在軟件開發、使用和維護過程當中產生的圖文集合，如《系統需求規格說明書》、《用戶手冊》、readme，甚至是一些軟件市場宣傳資料，包裝文字和圖形等。
   【備註：軟件測試毫不等同於程序測試，文檔測試也是軟件測試的一個重要組成部分。一般，程序測試主要包括程序邏輯功能、界面、性能、易用性、兼容性、安裝等的測試；文檔測試主要包括文檔內容和截圖的校驗，排版風格的檢查，錯別字的校驗等】
 2、客戶端/服務器【C/S】
    C指的是客戶端（Client），S指的是服務器端（Server）,這種軟件是基於局域網或互聯網的，須要一臺服務器來安裝服務器端軟件，每臺客戶端都須要安裝客戶端軟件。好比咱們常常用的QQ、MSN和各類網絡遊戲就屬於C/S結構的軟件。
   【備註：C/S結構的軟件過去比較流行，可是不便於升級和維護，如今逐漸被B/S結構軟件所取代】
 3、瀏覽器/服務器【B/S】
    B指的是瀏覽器（Browser），S指的是服務器（Server），這種軟件一樣是基於局域網或互聯網的，它與結C/S構軟件的區別就在於，不須要安裝客戶端（client），只須要有IE等瀏覽器，就能夠直接使用。好比搜狐、新浪等門戶網站及163郵箱都屬於B/S結構的軟件。
   【備註：B/S結構軟件是如今軟件的主流，與C/S結構軟件相比，便於升級和維護，是測試的重點】
 4、缺陷【Bug/Defect】
   軟件的Bug指的是軟件中（包括程序和文檔）不符合用戶需求的問題。
  【備註：這個定義是判斷一個軟件問題是不是Bug個惟一標準】
 五、軟件測試【Software Testing】
   使用人工或自動手段，來運行或測試某個系統的過程。其目的在於檢驗它是否知足規定的需求或弄清預期結果與實際結果之間的差異（1983，IEEE軟件工程標準術語）。
 六、測試環境【Testing Environment(TE)】
   軟件測試環境就是軟件運行的平臺，包括軟件、硬件和網絡的集合。用一個等式來表示：測試環境＝軟件＋硬件＋網絡。其中，「硬件」主要包括PC機（包括品牌機和兼容機）、筆記本、服務器、各類PDA終端等；「軟件」主要指軟件運行的操做系統；「網絡」主要針對的是C/S結構和B/S結構的軟件。
  【備註：做爲一個合格的軟件測試工程師，不只要熟悉軟件的知識，也要了解硬件和網絡的相關知識】
 7、測試用例【Test Case(TC)】
   指的是在測試執行以前設計的一套詳細的測試方案，包括測試環境、測試步驟、測試數據和預期結果。用一個等式來簡單表示：測試用例＝輸入＋輸出＋測試環境。其中，「輸入」包括測試數據和操做步驟；「輸出」指的是指望結果；測試環境指的是系統環境設置。
 8、黑盒測試【Black-Box Testing】
   通俗：指的是把被測軟件看做是一個黑盒子，咱們不去關心盒子裏面的結構是什麼樣子的，只關心軟件的輸入數據和輸出結果。

  定義：是把測試對象當作看不見內部結構的黑盒，在徹底不考慮程序內部結構和處理過程的基礎上，測試者僅根據程序功能的需求規範考慮肯定測試用例和推斷測試結果的正確性。又稱功能測試或數據驅動測試。
   備註：黑盒測試既包括功能測試，也包括性能測試。
 九、白盒測試【White-Box Testing】
   通俗：指的是把盒子蓋打開，去研究裏面的源代碼和程序結構。

  定義：一種按照程序內部邏輯結構和編碼設計結構測試數據並完成測試的測試方法。又稱結構測試或邏輯驅動測試。
 10、灰盒測試【Gray-Box Testing】
   能夠把它看做是黑盒測試和白盒測試的一種結合。
 11、靜態測試【Static Testing】
   是指不實際運行被測軟件，而只是靜態地檢查程序代碼、界面或文檔中可能存在的錯誤的過程。
 12、代碼走查【Walkthrough】
   靜態測試的一種方法，由開發組內部進行，採用講解、討論和模擬運行的方式進行的查找錯誤的活動。
 13、代碼審查【Inspection】
   靜態測試的一種方法，由開發組內部進行，採用講解、提問並使用編碼模板進行的查找錯誤的活動。通常有正式的計劃、流程和結果報告。
 14、技術評審【Review】
   靜態測試的一種方法，由開發組、測試組和相關人員（QA、產品經理等）聯合進行，採用講解、提問並使用編碼模板進行的查找錯誤的活動。通常有正式的計劃、流程和結果報告。
 15、動態測試【Dynamic Testing】
   是指實際運行被測程序，輸入相應的測試數據，檢查實際輸出結果和預期結果是否相符的過程。
 16、單元測試【Unit Testing】
   是指對軟件中的最小可測試單元進行檢查和驗證。例如，在C語言中，單元通常指1個函數；Java裏，單元通常指1個類；在圖形化的軟件中，單元也能夠指1個窗口、1個菜單等。
 17、樁模塊【Stub】
   是指模擬被測模塊所調用的模塊。
 18、驅動模塊【Driver】
   是指模擬被測模塊的上級模塊，驅動模塊用來接收測試數據，啓動被測模塊，並輸出結果。
 19、集成測試【Integration Testing】
   是指將經過測試的單元模塊組裝成系統或子系統，在進行測試，重點測試不一樣模塊的接口部分。
 20、系統測試【System Testing】
   指的是將整個軟件系統看做是一個總體測試，包括對功能、性能的測試，以及對軟件所運行的軟、硬件環境的測試。
 21、驗收測試【Acceptance Testing】
   指的是在系統測試的後期，以用戶測試爲主，或有測試人員等質量保障人員共同參與的測試，它也是軟件正式交給用戶使用的最後一道工序。
 ① α測試：
   驗收測試的一種，指的是由用戶、測試人員、開發人員等共同參與的內部測試。
 ② β測試：
   驗收測試的一種，指的是內測後的公測，即徹底交給最終用戶測試。
 22、功能測試【Function Testing】
   是黑盒測試的一種，它檢查實際軟件的功能是否符合用戶的需求。
 23、界面測試【UI Testing】
   UI是User Interface，即用戶界面的縮寫。通常狀況下，都把軟件的界面測試用例同軟件的邏輯功能測試用例分開去寫。
 24、易用性測試【Usability Testing】
   是指從軟件使用的合理性和方便性等角度對軟件系統進行檢查，來發現軟件中不方便用戶使用的地方。
 25、安裝測試【Installation Testing】
   這裏的安裝測試是指廣義上的，包括安裝、卸載。
 26、兼容性測試【Compatibility Testing】
   兼容性測試包括硬件兼容性測試和軟件兼容性測試；硬件兼容性主要是指軟件運行的不一樣硬件平臺的兼容性，如PC機、筆記本、服務器等；軟件兼容性主要是指軟件運行在不一樣操做系統等軟件平臺上的兼容性。
 27、性能測試【Performance Testing】
   是指對軟件的運行反饋速度、所消耗系統資源等各類性能指標的測試。
 28、可靠性測試【Reliability Testing】
   也叫穩定性測試，是指連續運行被測系統，檢查系統運行時的穩定程度。人們一般用MTBF（Mean Time Between Failure）來衡量系統的穩定性，MTBF越大，系統的穩定性越強。
 29、負載測試【Load Testing】
   是性能測試的一種，一般是指被測系統在其能忍受的壓力<極限範圍以內連續運行>，來測試系統的穩定性。
 30、壓力測試【Stress Testing】
   是性能測試的一種，一般是指持續<不斷地>給被測系統增長壓力，直到將被測系統<壓跨爲止>，用來測試系統所能承受的最大壓力。
 31、迴歸測試【Regression Testing】
   是指對軟件的新版本測試時，重複執行上一個版本測試時的用例。
 32、冒煙測試【Smoke Testing】  又名：ad-hoc
   是指在對一個新版本進行系統大規模地測試以前，先驗證一下軟件的基本功能是否實現，是否具有可測性。
 33、隨機測試【Random Testing】
   是指測試中全部的輸入數據都是隨機生成的，其目的是模擬用戶的真實操做，並發現一些邊緣性的錯誤。
 34、軟件質量保障【Software Quality Assurance(SQA)】
   爲了確保軟件<開發過程和結果符合預期的要求>，而創建的一系列規程，以及依照規程和計劃採起的一系列活動及其結果評價。

 35、軟件能力成熟度模型【Capability Maturity Model(CMM)】
   CMM就是SQA用來監督項目的一個標準質量模型，是由卡耐基－梅隆大學於20實際80年代制定的，最初只是應用於本校的軟件項目開發，後來逐漸推廣爲主流的行業標準。CMM共爲5級：初始級、可重複級、已定義級、已管理級和優化級。
 36、有效等價類【Valid Equivalence Class】
   是指符合《需求規格說明書》，合理地輸入數據集合。
 37、無效等價類【Invalid Equivalence Class】
   是指不符合《需求規格說明書》，無心義地輸入數據集合。
 38、軟件生命週期【Software Life Cycle】
   是指軟件開發和測試所有過程、活動和任務的結構框架，是從可行性研究到需求分析、軟件設計、編碼、測試、軟件發佈維護的過程。
 39、黑盒測試工具【Black-Box Testing Tools】
   是指測試功能或性能的工具，主要用於系統測試和驗收測試；其又可分爲功能測試工具和性能測試工具。
 40、白盒測試工具【White-Box Testing tools】
   是指測試軟件的源代碼的工具，能夠實現代碼的靜態分析、動態測試、評審等功能，主要用於單元測試。
 41、測試管理工具【Testing Management Tools】
   是指管理整個測試流程的工具，主要功能有測試計劃的管理、測試用例的管理、缺陷跟蹤、測試報告管理等，通常貫穿於整個軟件生命週期。
42、測試工做的正確四步曲
    ① What to do   第一步, 確立測試範圍和對象, 若是這一步漏了,後面的質量全打折扣--測試計劃
    ② How  to do   第二步, 決定用什麼測試技術或手段來測試這些測試對象  --測試方案
    ③ When to do   第三步, 決定先測試哪些測試對象和先應用哪些測試技術  --測試策略
    ④ Automation   第四步, 儘量把how to do的工做都自動化,從而提高執行效率(僅僅是執行效率) --測試效率
43、產品全部的架構和設計缺陷 ：

異常處理；功能組合處理；算法選取考慮不周全；以及非功能屬性的設計需求。
44、需求的質量也是有維度的： 

二義性、可測性、完整性、先後一致性、可實現性、必要性。

 

 

 

 

 

第一章 軟件工程要點

1、軟件的定義及其特性

一、定義：軟件包含 程序、數據和文檔

（1）當運行時，可以提供可以提供所要求功能和性能的指令或計算機程序集合；

（2）改程序可以具備滿意的處理信息的數據結構；

（3）描述程序功能需求以及程序如何操做和使用所要求的文檔。

二、特性：

（1）軟件是一種邏輯實體，具備抽象性

    （2）軟件沒有明顯的製做過程

    （3）軟件在使用過程當中沒有磨損、老化的問題，但有退化問題

    （4）軟件對硬件和環境有着不一樣程度的依賴性

    （5）軟件的開發至今還沒有徹底擺脫手工做坊式的開發方式，生產效率低

    （6）軟件是複雜的，並且之後會更加複雜

    （7）軟件的成本至關昂貴

    （8）軟件工做牽涉不少社會因素

2、軟件危機的定義，產生緣由及消除方法

一、定義：

落後的軟件生產維護方式沒法知足迅速增加的計算機軟件需求，從而致使軟件開發與維護過程當中出現一系列嚴重問題的現象。歸納地說主要包含兩方面的問題：如何開發軟件，怎樣知足對軟件日益增加的需求；如何維護數量不斷膨脹的已有的軟件。

二、產生緣由：

（1）主要緣由是對用戶的需求不明確；

（2）缺少正確的理論指導；

（3）軟件開發規模愈來愈大；

（4）軟件開發複雜程度愈來愈高。

三、消除方法：主要是 組織管理 + 技術措施

①應當對軟件有個正確的認識（程序+數據+文檔）；

②在軟件開發過程當中學會研製和使用軟件工具，用來輔助進行軟件項目管理和技術生產；

③必須充分認識到軟件開發應該是一種組織良好、管理嚴密、各種人員協同配合、共同完成的工程項目。

3、軟件工程的定義，三要素，目標，方法及原則

一、定義：軟件工程是一門研究如何系統化、規範化、數量化等工程原則和方法去進行軟件開發和維護的學科。

二、三要素：方法、工具和過程。

三、目標：生產具備正確性、可用性、開銷適宜、進度保證而且項目成功的軟件產品。

四、方法：項目計劃與估算 → 軟件系統需求分析 → 數據結構 → 系統整體結構的設計 → 算法過程的設計 → 編碼 → 測試

五、原則：

①採起適宜的開發模型，用以控制易變的需求；

②採用合適的設計方法，支持軟件的模塊化、抽象化等設計要求；

③提供高質量的工程支持；

④重視開發過程的管理。

4、軟件生命週期的定義、階段、模型 以及 敏捷開發

一、定義：同任何事物同樣，軟件產品或軟件系統也要經歷孕育、誕生、成長、成熟、衰亡等階段，通常稱爲軟件生存週期（又稱軟件生命週期），是指軟件開發和測試所有過程、活動和任務的結構框架，是從可行性研究到需求分析、軟件設計、編碼、測試、軟件發佈維護的過程。

二、階段： ①可行性分析和開發項目計劃；  ②需求分析；  ③設計（概要設計和詳細設計）；  ④編碼；  ⑤測試；  ⑥維護。

三、模型： ①瀑布模型  ②迭代式模型  ③快速原型模型 ④增量模型  ⑤螺旋模型  ⑥V模型

四、敏捷開發：敏捷開發是一種以人爲核心、迭代、按部就班的開發方法；核心思想是：測試驅動開發，測試與開發並行；經常使用方法有：XP（策劃、設計、編碼、測試。）

5、軟件體系結構

一、軟件體系結構大致上分爲主機終端模式、文件服務器模式、C/S模式和B/S模式。

二、C/S結構 ： (Client/Server)

（1）C/S結構的節本原則是將計算機應用任務分解成多個子任務，由多臺計算機分工完成，克服終端/主機結構中主機負擔太重、用戶界面不友好等缺點。

（2）C/S系統由3個基本部分組成：客戶機、服務器和中間件。

（3）C/S體系結構的技術特色 ：C/S根據服務的觀點對功能進行明確劃分，共享資源，不對稱協議，定位透明性，基於消息的交換，可擴展性。

三、B/S結構 ： （Browser/Server） 瀏覽器/服務器模式

（1）B/S模式是指在TCP/IP協議簇的支持下，以HTTP爲傳輸協議，客戶端經過Browser訪問Web服務器以及與之相連的後臺數據庫的技術及體系結構。

（2）B/S結構由客戶端、應用服務器和數據層（數據庫系統和遺留系統）組成。

（3）B/S結構的優點在於： 簡化了客戶端；簡化了系統的開發與維護；用戶操做變得更簡單；適用於網上信息發佈。

6、惠普應用生命週期管理（ALM）

一、惠普應用生命週期管理（ALM）主要應用於整個應用生命週期中管理跨項目的應用發佈： ①項目計劃和跟蹤；②跨項目報告；③資產共享和重用；④流程標準化；⑤缺陷共享；⑥無限的高可用服務器。

二、這樣帶來的好處有： ①對於跨項目的計劃，項目跟蹤，趨勢和實時應用狀態提升可見性；②集中管理，保證一致的流程和規範，減小成本；③減小重複工做，共享最佳實踐，下降成本，提升效率。

第二章 軟件測試基礎

7、軟件測試的定義，目的，原則，包含的概念，質量的度量方法以及與軟件開發之間的關係

一、軟件測試

使用人工或自動手段，來運行或測試某個系統的過程。其目的在於檢驗它是否知足規定的需求或弄清預期結果與實際結果之間的差異（1983，IEEE軟件工程標準術語）。

二、軟件測試的目的：驗證需求

（1）發現軟件缺陷，提升軟件質量；

（2）驗證軟件是否知足用戶的需求；

（3）創建軟件質量的信心。

三、軟件測試的原則：

（1）足夠好原則：good-enough原則；

（2）二八原則（BUG的80-20原則）；

（3）測試顯示缺陷的存在；

（4）窮盡測試是不可能的；

（5）測試儘早進入；

（6）殺蟲劑悖論（更新修改用力測試庫）；

（7）測試活動依賴測試背景；

（8）不存在缺陷（就是有用系統）的謬論。

四、軟件測試包含的概念

（1）軟件測試是對程序或系統可否完成特定任務創建信心的過程，也是幫助識別開發完成（中間或最終版本）的計算機軟件（總體或部分）的正確度、徹底度和質量的軟件程；                                                                                                                                       

（2）軟件測試就是爲了發現程序中的錯誤而分析或執行的過程，或者說是根據軟件開發各階段的規格說明和程序的內部而精心設計一批測試用例，並利用這些測試用例去運行程序，以發現程序錯誤的過程；

（3）軟件測試的目標在於儘量地發現錯誤（缺陷）；

（4）軟件測試的目的在於鑑定程序或系統的屬性或功能的各類活動，是軟件質量的一種度量，是SQA的重要值域

（5）用人工或自動手段來運行或測定某個系統的過程，其目的在於檢驗它是否知足規定的需求（遺漏、超出）或是弄清楚預期結果與實際結果之間是否有差異。

五、如何度量

對於軟件測試的度量，應該從對軟件產品的度量轉移到軟件測試產出物的度量，以及測試過程的度量。

六、軟件測試和軟件開發的關係

軟件開發是自頂向下，逐步細化的過程。軟件計劃階段定義軟件做用域；軟件需求分析階段創建軟件信息域、功能和性能需求、約束等；軟件設計階段把設計用某種程序設計語言轉換成程序代碼。測試過程依相反順序自底向上，逐步集成的過程。對每一個程序模塊進行單元測試，消除程序模塊內部邏輯和功能上的錯誤和缺陷；對照軟件設計進行集成測試、檢驗和排除子系統或系統結構上的錯誤；對照需求，進行確認測試；最後從系統總體出發，運行系統，看是否知足。

8、軟件測試工做的內容，流程，測試工具的做用以及人們對測試工做的誤解

一、軟件測試工做包括的內容

    測試工做的流程、測試工具的支持、測試人員的素質

二、流程

（1）需求閱讀與評審

（2）用例設計與評審

（3）環境搭建

（4）軟件測試

（5）編寫有關測試文檔（測試用例設計、測試報告、問題報告）

（6）SE與測試經理審覈

三、測試工具的支持

 （1）提升工做效率

 （2）保證測試的準確性    

 （3）有些測試很難開展，必須使用工具（如性能測試）

 （4）測試工具很好的保證測試工做的規範性和一致性

 （5）測試工具體現了先進的測試思想、方法和技術

四、對測試工做不正確的認識

 （1）總體認識上重開發輕測試

 （2）軟件開發完成後進行軟件測試

 （3）軟件測試時爲了證實軟件的正確性

 （4）軟件發佈後若是發現質量問題，那是軟件測試人員的錯

 （5）軟件測試要求不過，隨便找我的就行

 （6）軟件測試是軟件開發的對頭

 （7）軟件測試是測試人員的事情，與程序員無關

 （8）項目進度吃緊時少作些測試，時間富裕時多作些測試

 （9）軟件測試時沒有前途的工做，只有程序員纔是軟件高手 

 （10）軟件測試就是程序測試，測試發現了錯誤就說明程序員編寫的程序有問題

 （11）指望用測試自動化代替大部分人工勞動

 （12）全部軟件缺陷均可以修復

 （13）認爲軟件測試文檔不重要

 （14）指望短時間經過增長軟件測試投入，迅速達到零缺陷率

 （15）規範化軟件測試會增長項目成本

第三章 基於生命週期的軟件測試

9、生命週期測試包含的內容、測試計劃以及基於風險的軟件測試方法

一、生命週期測試包含的內容：生命週期測試應伴隨整個軟件開發週期，此時測試的對象不只僅是程序，需求、功能和設計一樣須要測試：①在項目需求分析階段就要開始參與，審查需求分析文檔、產品規格說明書；②在設計階段，要審查系統設計文檔、程序設計流程圖、數據流圖等，③在代碼編寫階段，須要審查代碼，看是否遵循代碼的變量定義原則、是否有足夠的註釋行等。  測試與開發同步進行，有利於儘早的發現問題，同時縮短項目的開發建設週期。

二、測試計劃：

（1）測試計劃是描述要進行的測試活動的範圍、方法、資源和進度的文檔。它肯定測試項、被測特性、測試任務、誰執行任務、各類可能的風險。測試計劃能夠有效預防計劃的風險，保障計劃的順利實施。5W1H → what where when why who how

（2）測試計劃最關機的一部就是將軟件分解成單元，寫成測試需求。這樣作的好處有：①測試需求是測試設計和開發測試用例的基礎，分紅單元能夠進行更好的設計；②詳細的測試需求使用來衡量測試覆蓋率的重要指標；③測試需求包含各類測試設計和開發，以及所需資源。

三、基於風險的軟件測試

（1）風險能夠定義爲事件、危險、威脅或狀況等發生的可能性以及由此產生的不可預料的後果，即潛在的問題。風險級別由出現不肯定時間的可能性以及出現後所產生的影響兩個方面來決定。

（2）基於風險的軟件測試（Risk Based software Testing，RBT）是指首先評估被測軟件的風險，而後根據不一樣的風險採用不一樣的測試力度。

（3）基於風險的軟件測試的方法：①列出風險列表；②對每一個風險進行分析和評估，肯定風險級別；③進行考察每項風險的測試；④當風險消失而新的風險出現的時候，調整測試策略。

10、生命週期各個測試階段的測試需求

一、需求階段測試：在需求階段測試中，須要創建風險列表，進行風險分析和檢查，以此肯定項目的風險；創建控制目標，確保有足夠的控制力度來保證項目的開發與測試。在完全的分析需求的充分性後，生成基礎的測試用例。

二、設計階段測試：①分析測試要素②給測試要素打分③對設計進行評審④檢查修改的部分。

三、編碼階段測試：在編碼階段，測試須要解決的首要問題是編碼是否和設計一致；其次是系統是否可維護，系統的規格說明是否正確的實現，編碼是否按照既有的標準進行，是否有充分的測試計劃評價可執行的程序，程序是否提供足夠的文檔資料，程序內部是否有足夠的註釋行等。

四、測試階段：

（1）典型的測試類型：

①手冊和文檔測試：測試軟件的操做說明文檔是否全面、正確、簡單和知足標準，即測試軟件文檔的易用性；

②一致性測試：包括測試軟件的受權、安全性和性能是否達到需求分析中的要求；

③符合性測試：驗證軟件系統和相應標準的符合程度，如受權規則是否正確實現，安全方法是否合適，是否按照相應的標準、指南、規程進行測試等。

④功能測試：運行部分或所有系統，確認用戶的需求被知足這包括可靠性、文件完整性、審計追蹤、功能正確性、互連等項測試，檢驗系統在各類環境和重複的事物條件下可否正確的執行系統的需求，控制計算機文件的完整性，追蹤原始事物到總的控制，按用戶規定的需求測試應用功能，以及與其餘應用系統可否正確的通訊。

⑤覆蓋性測試：檢驗軟件代碼中各語句及分支等是否所有執行到（死代碼等）。

⑥性能測試：經過測量響應時間、CPU使用和其餘量化的操做特徵，評估軟件系統的性能指標。（量化標準/時間/硬件要求）

⑦壓力測試：以大信息量的數據進行輸入，測試軟件的性能。（在線系統必須進行壓力測試）

⑧強度測試：對系統進行驗收測試，測試系統對極端條件的反應，標識軟件的薄弱點，指出系統可以承受的正常工做量。

⑨操做測試：在沒有開發人員指導和幫助的狀況下，由操做人員進行測試，以評估操做命令的完整性和系統是否容易操做。

⑩恢復測試：故意使系統失敗，測試人工和自動的恢復過程。

（2）測試用例

①IEEE稱測試用例爲「編寫用於輸入的實際數值和預期輸出結果數據。測試用例也明確指定使用具體測試用例產生的測試程序的任何限制」。

②在設計測試用例的輸入數據時，要包含合法和非法的輸入，要嘗試將測試數據違反程序的規則進行輸入；在設計輸出數據時，要描述測試用例的預期結果。

③測試用例包含的基本信息：標識符、輸入說明、輸出要求、環境要求、特殊過程要求、用例之間的依賴性。

（3）測試報告：測試總結報告的內容有：測試結果數據，測試任務、測試集合和測試事件的描述，目前的軟件狀態描述，各個階段的項目測試總結等。

五、安裝階段測試

六、驗收階段測試

七、維護階段測試

第四章 軟件測試分類與分級

11、軟件測試分類

一、對於軟件測試，能夠從不一樣的角度進行分類：

（1）從是否關心軟件內部結構和具體實現的角度：白盒測試、黑盒測試、灰盒測試

（2）從軟件開發過程的角度：單元測試、集成測試、系統測試、驗收測試

（3）從是否執行程序的角度：靜態測試和動態測試

（4）從程序執行時是否須要人工干預的角度：人工測試和自動化測試

（5）從測試實施組織的角度：開發方測試、用戶測試、第三方測試

二、計算機軟件配置項：

計算機軟甲配置項縮寫爲CSCI，是爲獨立的配置管理（技術狀態管理）而設計的且能知足最終用戶需求的一組軟件，簡稱軟件配置項。

三、基於CSCI的軟件測試分類：

單元測試、集成測試、配置項測試（確認測試）、系統測試、驗收測試和迴歸測試。

12、各種測試的名詞解釋

一、單元測試：單元測試又稱模塊測試，是針對軟件設計的最小階段（程序模塊或功能模塊）進行正確性檢驗的測試工做。

二、集成測試：集成測試也叫組裝測試、聯合測試，是一種旨在暴露接口以及集成組件/系統間交互時存在缺陷的測試。

三、配置項測試：配置項測試又稱確認測試，是在完成集成測試後，依據確認測試原則，針對軟件需求規格說明進行的測試，以確認所開發的軟件系統可否知足規定的功能和性能需求。

四、系統測試：系統測試是爲判斷系統是否符合規定而對集成的軟、硬件系統進行的測試活動。它是將已經集成好的軟件系統做爲計算機系統的一部分，與計算機系統硬件、某些支持軟件、數據和人員等系統元素結合起來，在實際運行環境下對計算機系統進行一系列嚴格有效的測試。

五、驗收測試：驗收測試一般有使用系統的用戶來進行測試，目的是確保系統功能、系統的某部分或特定的系統非功能性特徵知足驗收準則，發現缺陷不是驗收測試的主要目標。

六、迴歸測試：迴歸測試是指修改了舊代碼後，從新進行測試以確認修改沒有引入新的錯誤或致使其餘代碼產生錯誤。

第五章 軟件缺陷管理

十3、什麼是軟件缺陷？軟件缺陷的五條規則？產生軟件缺陷的緣由？通常如何描述和分類軟件缺陷？

一、軟件缺陷的定義：

（1）從產品內部來看，軟件缺陷是軟件產品開發或維護過程當中所存在的錯誤、毛病等各類問題；

（2）從外部看，軟件缺陷是系統所須要實現的某種功能的失效或違背。

二、軟件缺陷的五條規則

（1）少：軟件未實現產品說明書要求的功能；

（2）錯：軟件出現了產品說明書指明不該該出現的錯誤；

（3）多：軟件出現了產品說明書未提到的功能；

（4）軟件未實現產品說明書雖未明確說起但應該實現的目標；

（5）軟件難以理解、不易使用、運行緩慢或者—從測試員的角度看—最終用戶認爲很差。

三、產生軟件缺陷的緣由：

（1）需求的不完善定義；

（2）客戶—開發者通訊失敗；

（3）對軟件需求的故意偏離；

（4）邏輯設計錯誤；

（5）編碼錯誤；

（6）不符合文檔編制與編碼規定；

（7）測試過程不足；

（8）規程錯誤；

（9）文檔編制錯誤。

四、軟件缺陷的描述：

對軟件缺陷進行有效的描述涉及如下內容：

（1）可追蹤信息：缺陷ID

（2）缺陷的基本信息

①缺陷標題 ②缺陷的緊急程度 ③缺陷的嚴重程度 ④缺陷提交人 ⑤缺陷提交時間 ⑥缺陷所屬項目/模塊 ⑦缺陷指定解決人 ⑧缺陷指定解決時間 ⑨缺陷處理人 ⑩、缺陷處理結果描述 十一、缺陷處理時間 十二、缺陷驗證人 1三、缺陷驗證結果描述 1四、缺陷驗證時間

（3）對缺陷的詳細描述

（4）測試環境說明

（5）必要的附件

（6）從統計的角度上出發，能夠添加上「缺陷引入階段」、「缺陷修正工做量」等項目。

五、軟件缺陷的分類

（1）在對缺陷進行分類以前，首先定義缺陷的屬性：屬性名稱描述、缺陷標識、缺陷類型、缺陷嚴重程度、缺陷優先級、缺陷狀態、缺陷起源、缺陷來源、缺陷根源。

（2）缺陷分類方法

①Putnam分類法：需求缺陷、設計缺陷、文檔缺陷、算法缺陷、界面缺陷和性能缺陷。

②軍標分類法：程序錯誤、文檔錯誤和設計錯誤

③Thayer分類法：16類：計算錯誤、邏輯錯誤、I/O錯誤、數據錯誤加工、操做系統和支持軟件錯誤、配置錯誤、接口錯誤、用戶需求改變、預置數據庫錯誤、全局變量錯誤、重複的錯誤、文檔錯誤、需求實現錯誤、不明性質錯誤、人員操做錯誤、問題。

④IEEE分類法：分類過程由識別（RR）、調查（IV）、行動計劃（AC）、實施處理（DP）四個步驟組成，每個步驟包括三項活動：記錄、分類和肯定影響（IM）。

⑤正交缺陷分類法：由IBM公司提出。

缺陷特徵包括8個屬性：發現缺陷的活動、缺陷影響、缺陷引起事件、缺陷載體、缺陷年齡、缺陷來源、缺陷類型和缺陷限定詞。

缺陷類型被分爲8大類：賦值、檢驗、算法、時序、接口、功能、文檔、關聯

（3）按照缺陷的生命週期劃分：new（新建）、confirmed（確認）、fixed（解決）、closed（關閉）、reopen（從新打開）。

每一個缺陷都是由測試人員發現並提交的，這個狀態標註爲new（新建）；缺陷被提交後，有相應的負責人接受，即confirmed（確認）狀態；相應的負責人員解決了該缺陷後，該缺陷的狀態就改成fixed（解決）；而且將其發給測試人員進行迴歸測試，若是肯定已經解決，那麼缺陷的狀態就改成closed（關閉），不然就須要返還給該缺陷的負責人從新修正；有的缺陷在之前的版本中已經關閉，可是在新的版本中又從新出現，則須要將其狀態改成reopen（從新打開）。

 

十4、軟件缺陷管理

一、軟件缺陷管理是軟件測試的一個有機組成部分，是CMM2級的要求。在CMM第二級的軟件組織中，軟件項目從自身的需求出發，制定項目的缺陷管理過程。項目組將完整記錄開發過程當中的缺陷，監控缺陷的修改過程，並驗證修改缺陷的結果。

二、卻見缺陷跟蹤管理的目標「

（1）確保每一個被發現的缺陷都可以解決；

（2）手機缺陷數據並根據缺陷趨勢曲線識別測試過程的階段；

（3）收集缺陷數據並在其上進行數據分析，做爲組織的過程財富。

三、缺陷記錄日誌用於缺陷數據的收集，收集軟件缺陷數據的步驟以下：

（1）爲測試和同行評審中發現的每一個缺陷作記錄；

（2）對每一個缺陷記錄足夠詳細的信息，以便之後能更好地瞭解這個缺陷；

（3）分析這些數據以找出哪些缺陷類型引發大部分的問題；

（4）設計出現和修復這些缺陷的方法（缺陷排除）。

四、軟件缺陷管理流程圖：

 

 

 

十5、軟件缺陷的度量、分析和軟件缺陷報告

一、軟件缺陷度量

（1）缺陷度量就是對項目過程當中產生的缺陷數據進行採集和量化，將分散的缺陷數據統一管理，使其有效而清晰，而後經過採用一系列數學函數，對數據進行處理，分析缺陷密度和趨勢等信息，從而提升產品質量和改進開發過程。

（2）主要的度量方法：

①缺陷密度 = 已知的缺陷數量 / 產品規模；

②缺陷率：必定時間範圍內的缺陷數與錯誤概率的比值；

③缺陷清除率：缺陷清除率 = 已發現的缺陷 / 潛在的缺陷（已發現的缺陷+之後發現的缺陷）；

④缺陷趨勢：缺陷趨勢是在必定週期時間或必定階段內，產生/發現缺陷的動向或規律，是缺陷率按時間或按階段增加/降低的動態分佈；週期能夠是天、周、月，階段能夠是版本；一般用缺陷趨勢圖來表示缺陷趨勢；

⑤缺陷發現率 = ∑提交缺陷數（個） / ∑執行測試的有效時間（小時）

二、軟件缺陷分析

（1）缺陷分析是將軟件開發各個階段產生的缺陷信息進行分類和彙總統計，計算分析指標，編寫分析報告的活動。

（2）經過軟件缺陷分析能夠發現各種缺陷發生的機率，掌握缺陷集中的區域、明確缺陷發展趨勢、挖掘缺陷產生的根本緣由，便於有針對性的提出遏制缺陷發生的措施，下降缺陷數量。

（3）缺陷分析的步驟：

①記錄缺陷；

②對於測試出來的缺陷進行缺陷分類，找出關鍵的缺陷類型，進一步分析其產生的緣由，針對性的制定改進措施；

③進行缺陷預防分析，它是整個缺陷分析過程的核心；

④編制缺陷分析報告，繪製缺陷分析圖。

三、軟件缺陷報告：

（1）缺陷報告記錄了缺陷發生的環境，如各類資源的配置狀況、缺陷的再現步驟以及缺陷性質的說明。更重要的是還記錄着缺陷的處理過程和狀態。

（2）報告軟件缺陷的基本原則：

①儘快報告軟件缺陷；

②有效的描述軟件缺陷；

A.短小精悍：只解釋事實和演示、描述軟件缺陷必須的細節，解釋錯誤的實質；

B.單一：每一個缺陷報告只針對一個軟件缺陷；

C.使用IT業界慣用的表達術語和表達方式；

D.明確指明錯誤類型。

③在報告缺陷時不做任何評價；

④確保缺陷能夠重現。

第六章 軟件測試過程及測試過程管理

十6、軟件測試過程的模型、活動、內容和度量

一、軟件測試過程模型

（1）V模型

 

 

①單元測試和集成測試是驗證程序設計，開發人員和測試組應檢測程序的執行是否知足軟件設計的要求；系統測試應當驗證系統設計，檢測系統功能、性能的質量特性是否達到系統設計的標準；有測試人員和用戶進行軟件的確認測試和驗收測試，追溯軟件需求額說明書進行測試，以肯定軟件的實現是否知足用戶需求或合同的要求。

②V模型的侷限性在於沒有明確的說明早期的測試，不能體現「儘早的和不斷的進行測試」的原則。

（2）W模型（V&V：驗證和確認）

 

 

（3）H模型

 

 

二、軟件測試過程活動

提取測試需求，肯定測試策略，制定測試計劃，開展測試設計，執行測試用例，分析測試結果

三、軟件測試過程內容

測試過程的主要內容是 ： 基於項目目標，制定測試計劃，肯定測試策略，選定測試方法，排定優先級，創建里程碑，組織測試資源（測試團隊、軟硬件資源等）；而後，以測試計劃爲基礎，明確測試需求、測試對象和測試目標及功能與性能指標；最後，依據測試計劃和測試設計，測試人員能夠開展測試的相關活動（開發和設計測試用例、選定測試工具、設計自動化測試框架、編寫測試腳本、執行測試用例及測試腳本、分析測試結果、發現和報告缺陷等）。

四、軟件測試過程度量

4個度量指標：

（1）測試覆蓋率 = 已設計測試用例的需求數 / 需求總數

（2）測試執行率 = 已執行的測試用例數 / 設計的總測試用例數

（3）測試執行經過率 = 執行結果爲「經過」的測試用例數 / 實際執行的測試用例總數

（4）缺陷解決率 = 已關閉的缺陷數 / 缺陷總數

十7、軟件測試過程管理

一、軟件測試過程圖：

 

 

二、軟件測試過程管理的理念

（1）今早測試；

（2）全面測試；

（3）全過程測試；

（4）獨立的迭代測試。

三、測試需求的收集

（1）與被測軟件相關的各類文檔資料；

（2）與客戶或系統分析員的溝通；

（3）業務背景資料；

（4）正式與非正式的培訓；

（5）其餘（如新舊系統）。

四、測試策略

測試策略包括：

（1）要使用的測試技術和工具；

（2）測試完成標準，用於計劃和實施測試，及通報測試結果；

（3）影響資源分配的特殊考慮（例如：有些測試必須在週末進行，有些測試必須經過遠程環境進行，有些測試須要考慮外部接口或者硬件接口等）。

五、測試用例設計的方法

軟件測試用例設計的方法有「白盒」測試 和 「黑盒」測試 ：

（1）「黑盒」測試：（適用於功能測試和驗收測試）

①等價類劃分；

②因果圖法；

③邊值分析；

④用戶界面測試；

⑤配置測試；

⑥安裝選項測試等。

（2）「白盒」測試：

①採用邏輯覆蓋的結構測試用例的設計方法（代碼的語句覆蓋、條件覆蓋、分支覆蓋）；

②基於程序結構的域測試用例設計方法（域是指程序的輸入空間，域測試正是在分析輸入空間的基礎上，完成域的分類、定義和驗證，從而對各類不一樣的域選擇適當的測試點（用例）進行測試）；

③數據流測試用例設計的方法（經過程序的控制流，從創建的數據目標狀態的序列中發現異常的結構測試方法）；

④根據對象狀態或等待狀態變化來設計測試用例；

⑤給予程序錯誤的變異來設計測試用例；

⑥基於代數運算符號的測試用例設計方法（受分支問題、二義性問題和大程序問題的困擾，使用較少）。

第七章 軟件靜態測試

十8、軟件靜態測試的定義、被測對象、緣由、目的及內容。

一、靜態測試是指不執行程序代碼而尋找代碼中可能存在的錯誤或評估程序代碼的過程。

二、被測對象是各類與軟件相關的有必要進行測試的產物（各種文檔、源代碼等）。

三、緣由：

（1）軟件內部結構複雜、混亂，代碼的編寫也沒有規範，使得軟件內部存在一些不易被察覺的錯誤，這些錯誤在特定條件下會形成重大影響；

（2）軟件產品升級維護時，因爲代碼的複雜度、代碼編寫的雜亂形成軟件的維護工做很難進行。

四、靜態測試的目的就是對代碼標準以及質量進行監控，以此來提升代碼的可靠性，使系統的設計符合模塊化、結構化、面向對象的要求。

五、靜態測試主要包括：各階段的評審、代碼檢查、程序分析和軟件質量度量等。

十9、評審、同行評審、代碼檢查及其方法、代碼編程規範檢查、數據流分析、代碼安全性檢查

一、評審：

（1）評審是對軟件元素或項目狀態進行評估的活動，用於肯定與預期結果之間的誤差和相應的改進意見，一般由人來執行。

（2）通常評審包括：培訓評審、預備評審、同行評審。

二、同行評審：同行評審通常包括：審查、小組評審、走查、桌面評審、臨時評審五種類型。

三、代碼檢查及其方法

（1）代碼檢查是「白盒」測試的一種靜態測試方法，主要檢查代碼和設計的一致性、代碼對標準的遵循、代碼的可讀性、代碼的邏輯表達正確性、代碼結構的合理性。

（2）代碼檢查通常採用靜態「白盒」測試的方法：代碼審查、桌面檢查、代碼走查和技術評審。

四、代碼編程規範檢查

編程規範又稱代碼規則、編碼規則，是對程序代碼的格式、註釋、標識符命名、漁具使用、函數、類、程序組織、公共變量等方面所作的要求。

五、數據流分析：

在數據流最初分析中，能夠集中關注定義/引用異常的缺陷（如：變量被定義，但歷來沒有使用；所使用的變量沒有被定義；變量在使用以前被定義了兩次）；另外，由於程序內的語句陰變量的定義和使用而彼此相關，因此使用數據流測試方法更能有效的發現軟件缺陷；但在度量測試覆蓋率和選擇測試路徑的時候，數據流測試很困難。

六、代碼安全性檢查

（1）所謂代碼安全性，就是你的代碼在尋行時，或被別人調用時產生錯誤的容易程度。

（2）代碼安全性檢查方法

①對變量類型和單位進行檢查；

②對變量引用進行檢查；

③對錶達式運算進行檢查；

④接口分析。

（3）代碼安全性關注的錯誤

①壞的存儲分配；

②內存泄露；

③指針引用；

④約束檢查；

⑤變量未初始化；

⑥錯誤邏輯結構；

⑦其餘（如緩衝區溢出、非法類型轉換、非法算術運算（除零錯誤、負數開方）、整數和浮點數的上溢出/下溢出、多線程對爲保護數據的訪問衝突等）。

二10、軟件複雜性度量

一、規模度量元Line Count 複雜度：統計程序的源代碼行數

二、難度度量元Halstead 複雜度

（1）根據可執行代碼行的操做符和操做數的數量來計算：

①操做符：程序調用、數學運算符以及相關的分隔符等；

②操做數：常數和變量。

（2）n1：程序中不一樣運算符的個數   n2：程序中不一樣操做數的個數

 N1：程序中實際運算符的總數   N2：程序中實際操做數的總數

N：實際的程序長度或簡單長度（N=N1+N2）   N^：程序的預測長度

①N^ = n1 log2 n1 +n2 log2 n2

②程序容量（程序體積）：V=N log2（n1+n2）

③程序級別：L^=（2/n1)*(n2/N2)

④編程時間（以小時計）：T^=E/（S*f） （S=60*60；f=18）

⑤程序中的錯誤數目預測值：B=N log2 （n1+n2）/3000 （B爲改程序的錯誤數）

三、結構度量元 McCabe複雜度

（1）McCade圈複雜度：

強連通圖指從圖中任一個節點出發都能到達全部的其餘節點

① V=m-n+p （m爲弧數，n爲節點數，p一般爲1）

② 圈複雜度 = 斷定節點的數目 +1

③ 圈複雜度 = 強連通程序圖在平面上圍成的區域個數

（2）McCade圈複雜度的優勢：

①避免軟件中的錯誤傾向；

②指出極複雜模塊，這樣的模塊也許能夠進一步細化；

③度量測試計劃，肯定測試重點；

④在開發過程當中經過限制程序邏輯，指導測試過程；

⑤指出將要測試的區域；

⑥幫助測試人員肯定測試盒維護對象；

⑦與所用的高級程序設計語言類型無關。

二11、軟件質量模型

一、軟件質量定義

（1）國際標準化組織ISO： 反應軟件產品知足規定需求和潛在需求能力的特徵和特性的綜合。

（2）MJ.Fisher ： 全部描述計算機優秀程度的特性的集合。

二、軟件質量的特性：

（1）功能性

（2）可靠性

（3）可用性

（4）效率

（5）維護性

（6）可移植性

三、軟件質量分層模型

第八章 動態測試

二12、動態測試的分類

一、從是否關心軟件內部結構和具體實現的角度：白盒測試、黑盒測試、灰盒測試

二、從軟件開發過程的角度：單元測試、集成測試、系統測試、驗收測試

三、從程序執行時是否須要人工干預的角度：人工測試和自動化測試

四、從測試實施組織的角度：開發方測試、用戶測試、第三方測試

二十3、白盒測試的定義、目的、特色、內容及方法

一、定義：一種按照程序內部邏輯結構和編碼設計結構測試數據並完成測試的測試方法。又稱結構測試或邏輯驅動測試。

二、目的：白盒測試的目的是發現問題；而調試的目的是改正缺陷。

三、特色：

（1）能夠構成測試數據，使特定程序部分獲得測試；

（2）有必定的充分性度量手段；

（3）可得到較多工具支持；

（4）一般只用於單元測試。

四、內容：

（1）對程序模塊的全部獨立執行路徑至少測試一次；

（2）對全部的邏輯斷定，取真與取假的兩種狀況都至少測試一次；

（3）在循環的邊界和運行的邊界限內執行循環體；

（4）測試內部數據結構的有效性。

五、方法：

（1）邏輯覆蓋：以程序內部的邏輯結構爲基礎的測試方法。

 

 

 

①、語句覆蓋：要求設計足夠多的測試用例，使得每條語句至少被執行一次：

A.優勢：

a、檢查全部語句；

b、結構簡單的代碼的測試效果較好；

c、容易實現自動測試；

d、代碼覆蓋率高；

e、若是是程序塊覆蓋，則沒必要考慮程序塊中的源代碼。

B.缺點：不能檢查出來的錯誤有：

a、條件語句錯誤；

b、邏輯運算錯誤；

c、循環語句錯誤（循環次數錯誤、跳出循環條件錯誤）。

②、斷定覆蓋（分支覆蓋）：要求設計足夠多的測試用例，使得程序中的每個分支至少經過一次，即每一條分支語句的「真」值和「假」值都至少執行一次：

A、優勢：

覆蓋能力比語句覆蓋強

B、缺點：

缺點通語句覆蓋

③、條件覆蓋：是指選擇足夠多的測試用例，使得運行這些測試案例後，要使每一個判斷中每一個條件的可能取值至少知足一次，但未必能覆蓋所有分支:

A、優勢：可以檢查全部條件錯誤；

B、缺點：不能實現對每一個分支的檢查，用例數增長。

④、斷定/條件覆蓋：設計足夠多的測試用例，使得斷定中每一個條件的全部可能取值至少可以執行一次，同時每一個判斷的全部肯呢搞的斷定結果都至少執行一次（即要求各個斷定的全部可能的條件取值組合至少執行一次）：

A、優勢：既考慮了每個條件，又考慮了每個分支，發現錯誤能力強於分支覆蓋和條件覆蓋；

B、缺點：並不能全面覆蓋全部路徑，用例數量增長。

⑤、條件組合覆蓋：要求設計足夠多的測試用例，使得每一個斷定中條件的各類組合至少出現一次：

A、優勢：條件組合覆蓋是前面幾種覆蓋標準中最強的；

B、缺點：不必定使程序中的每條路徑都執行到。

⑥、路徑覆蓋：要求設計足夠多的測試用例，使得程序中全部的路徑都至少執行一次。

（2）路徑測試：根據程序的邏輯控制所產生的路徑進行測試用例設計的方法，他是從一個程序的入口開始，執行所經歷的各個語句的完成過程

①、DD路徑測試（Decision-to-Decision Path）

主要着眼命令式程序語言的測試覆蓋率問題

②、基本路徑測試：

A、根據過程設計結果畫出相應的控制流圖；

B、計算控制流圖的圈複雜度；

C、肯定線性獨立路徑的基本集合（列出路徑）；

D、設計可強制執行基本集合中每條路徑的測試用例。

③循環路徑覆蓋：

A、0次循環：檢查跳出循環；

B、1次循環：檢查循環初始值；

C、2次循環：檢查屢次循環；

D、m次循環：檢查某次循環；

E、最大次數循環，比最大次數多一次、少一次循環，檢查循環次數邊界。

（3）數據流測試

（4）信息流測試

（5）覆蓋率分析及測試用例準則

①、覆蓋率=（至少被執行一次的item數）/ item的總數

Item ：需求、語句、分支、條件、路徑。

②、覆蓋準則：

A、ESTCA覆蓋準則

B、LCSAJ覆蓋準則（Liner Sequence and Jump Coverage）：線性代碼順序和調準覆蓋

二十4、黑盒測試的定義、要求、方法、缺點及黑盒測試設計測試用例的兩個標準

一、定義：黑盒測試是把測試對象當作看不見內部結構的黑盒，在徹底不考慮程序內部結構和處理過程的基礎上，測試者僅根據程序功能的需求規範考慮肯定測試用例和推斷測試結果的正確性。又稱功能測試或數據驅動測試。

二、要求：

（1）要求每一個軟件特性或功能必須被一個測試用例或一個被承認的一場所覆蓋；

（2）要求構造數據類型和數據值的最小集測試；

（3）要求測試不排斥輸入的能力；

（4）要求對影響性能的關鍵模塊測試其模塊性能。

三、方法：

（1）等價類劃分：等價類劃分法是把程序的輸入域劃分紅若干部分，而後從每一個部分中選取少數有表明性數據看成測試用例：

等價類的劃分有兩種不一樣的狀況：

A、有效等價類是指對於程序的規格說明來講是合法的、有意義的輸入數據構成的集合；

B、無效等價類是指對於程序的規格說明來講，是不合理的、無心義的輸入數據構成的集合。

（2）邊界值分析

（3）因果圖

（4）隨機測試

（5）猜錯法

（6）探索性測試

四、缺點：

（1）若是軟件外部特性自己設計有問題或規格說明的規定有誤，用黑盒測試方法是發現不了的；

（2）測試用例數較大；

（3）測試用例可能會產生不少冗餘；

（4）功能性測試的覆蓋率不可能達到100%；

（5）黑盒測試不能替代白盒測試，而是用來發現白盒測試之外的其餘類型的錯誤。

五、黑盒測試方法設計測試用例要知足的兩個標準

(1)所設計出的測試用例能較少爲達到合理測試所須要設計的測試用例的總數；

(2)所設計出的測試用例能告訴咱們，是否存在某些類型的錯誤，而不是僅僅指出與特定測試相關的錯誤是否存在。