軟體工程白盒測試方法

1. 什麼是軟體的白盒和黑盒測試法

黑盒測試和白盒測試：
黑盒測試
黑盒測試也稱功能測試或數據驅動測試，它是在已知產品所應具有的功能，通過測試來檢測每個功能是否都能正常使用，在測試時，把程序看作一個不能打開的黑盆子，在完全不考慮程序內部結構和內部特性的情況下，

測試者在程序介面進行測試，它只檢查程序功能是否按照需求規格說明書的規定正常使用，程序是否能適當地接收輸入數鋸而產生正確的輸出信息，並且保持外部信息（如資料庫或文件）的完整性。黑盒測試方法主要有等價類劃分、邊值分析、因—果圖、錯誤推測等，主要用於軟體確認測試。 「黑盒」法著眼於程序外部結構、不考慮內部邏輯結構、針對軟體界面和軟體功能進行測試。「黑盒」法是窮舉輸入測試，只有把所有可能的輸入都作為測試情況使用，才能以這種方法查出程序中所有的錯誤。
白盒測試：
白盒測試也稱結構測試或邏輯驅動測試，它是知道產品內部工作過程，可通過測試來檢測產品內部動作是否按照規格說明書的規定正常進行，按照程序內部的結構測試程序，檢驗程序中的每條通路是否都有能按預定要求正確工作，而不顧它的功能，白盒測試的主要方法有邏輯驅動、基路測試等，主要用於軟體驗證。「白盒」法全面了解程序內部邏輯結構、對所有邏輯路徑進行測試。「白盒」法是窮舉路徑測試。在使用這一方案時，測試者必須檢查程序的內部結構，從檢查程序的邏輯著手，得出測試數據。

黑盒測試和白盒測試

任何工程產品（注意是任何工程產品）都可以使用以下兩種方法之一進行測試。
黑盒測試：已知產品的功能設計規格，可以進行測試證明每個實現了的功能是否符合要求。
白盒測試：已知產品的內部工作過程，可以通過測試證明每種內部操作是否符合設計規格要求，所有內部成分是否以經過檢查。

軟體的黑盒測試意味著測試要在軟體的介面處進行。這種方法是把測試對象看做一個黑盒子，測試人員完全不考慮程序內部的邏輯結構和內部特性，只依據程序的需求規格說明書，檢查程序的功能是否符合它的功能說明。因此黑盒測試又叫功能測試或數據驅動測試。黑盒測試主要是為了發現以下幾類錯誤：

1、是否有不正確或遺漏的功能？
2、在介面上，輸入是否能正確的接受？能否輸出正確的結果？
3、是否有數據結構錯誤或外部信息（例如數據文件）訪問錯誤？
4、性能上是否能夠滿足要求？
5、是否有初始化或終止性錯誤？

軟體的白盒測試是對軟體的過程性細節做細致的檢查。這種方法是把測試對象看做一個打開的盒子，它允許測試人員利用程序內部的邏輯結構及有關信息，設計或選擇測試用例，對程序所有邏輯路徑進行測試。通過在不同點檢查程序狀態，確定實際狀態是否與預期的狀態一致。因此白盒測試又稱為結構測試或邏輯驅動測試。白盒測試主要是想對程序模塊進行如下檢查：

1、對程序模塊的所有獨立的執行路徑至少測試一遍。
2、對所有的邏輯判定，取「真」與取「假」的兩種情況都能至少測一遍。
3、在循環的邊界和運行的界限內執行循環體。
4、測試內部數據結構的有效性，等等。

以上事實說明，軟體測試有一個致命的缺陷，即測試的不完全、不徹底性。由於任何程序只能進行少量（相對於窮舉的巨大數量而言）的有限的測試，在未發現錯誤時，不能說明程序中沒有錯誤

2. 軟體工程 白盒測試

是採用的哪種測試方法，所有的條件都覆蓋到了，所以就沒有了（f，f）吧！

3. 軟體測試的方法一共有幾種

1、從是否關心內部結構來看

（1）白盒測試：又稱為結構測試或邏輯驅動測試，是一種按照程序內部邏輯結構和編碼結構，設計測試數據並完成測試的一種測試方法。

（2）黑盒測試：又稱為數據驅動測試，把測試對象當做看不見的黑盒，在完全不考慮程序內部結構和處理過程的情況下，測試者僅依據程序功能的需求規范考慮，確定測試用例和推斷測試結果的正確性，它是站在使用軟體或程序的角度，從輸入數據與輸出數據的對應關系出發進行的測試。

（3）灰盒測試：是一種綜合測試法，它將「黑盒」測試與「白盒」測試結合在一起，是基於程序運行時的外部表現又結合內部邏輯結構來設計用例，執行程序並採集路徑執行信息和外部用戶介面結果的測試技術。

2、從是否執行代碼看

（1）靜態測試：指不運行被測程序本身，僅通過分析或檢查源程序的語法、結構、過程、介面等來檢查程序的正確性。

(2)動態測試：是指通過運行被測程序，檢查運行結果與預期結果的差異，並分析運行效率、正確性和健壯性等性能指標。

3、從開發過程級別看

（1）單元測試：又稱模塊測試，是針對軟體設計的最小單位----程序模塊或功能模塊，進行正確性檢驗的測試工作。其目的在於檢驗程序各模塊是否存在各種差錯，是否能正確地實現了其功能，滿足其性能和介面要求。

(2)集成測試：又叫組裝測試或聯合，是單元測試的多級擴展，是在單元測試的基礎上進行的一種有序測試。旨在檢驗軟體單元之間的介面關系，以期望通過測試發現各軟體單元介面之間存在的問題，最終把經過測試的單元組成符合設計要求的軟體。

（3）系統測試：是為判斷系統是否符合要求而對集成的軟、硬體系統進行的測試活動、它是將已經集成好的軟體系統，作為基於整個計算機系統的一個元素，與計算機硬體、外設、某些支持軟體、人員、數據等其他系統元素結合在一起，在實際運行環境下，對計算機系統進行一系列的組裝測試和確認測試。

在系統測試中，對於具體的測試類型有：

（1）功能測試：對軟體需求規格說明書中的功能需求逐項進行的測試，以驗證功能是否滿足要求。

（2）性能測試：對軟體需求規格說明書的功能需求逐項進行的測試，以驗證功能是否滿足要求。

（3）介面測試：對軟體需求規格說明中的介面需求逐項進行的測試。

（4）人機交互界面測試：對所有人機交互界面提供的操作和顯示界面進行的測試，以檢驗是否滿足用戶的需求。

（5）強度測試：強制軟體運行在異常乃至發生故障的情況下（設計的極限狀態到超出極限），驗證軟體可以運行到何種程序的測試。

（6）餘量測試：對軟體是否達到規格說明中要求的餘量的測試。

（7）安全性測試：檢驗軟體中已存在的安全性、安全保密性措施是否有效的測試，

（8）可靠性測試：在真實的或模擬的環境中，為做出軟體可靠性估計而對軟體進行的功能（其輸入覆蓋和環境覆蓋一般大於普通的功能測試）

（9）恢復性測試：對有恢復或重置功能的軟體的每一類導致恢復或重置的情況，逐一進行的測試。

（10）邊界測試：對軟體處在邊界或端點情況下運行狀態的測試。

（11）數據處理測試：對完成專門數據處理功能所進行的測試。

（12）安裝性測試：對安裝過程是否符合安裝規程的測試，以發現安裝過程中的錯誤。

（13）容量測試：檢驗軟體的能力最高能達到什麼程度的測試。

（14）互操作性測試：為驗證不同軟體之間的互操作能力而進行的測試。

（15）敏感性測試：為發現在有效輸入類中可能引起某種不穩定性或不正常處理的某些數據的組合而進行的測試。

（16）標准符合性測試：驗證軟體與相關國家標准或規范（如軍用標准、國家標准、行業標准及國際標准）一致性的測試。

（17）兼容性測試：驗證軟體在規定條件下與若干個實體共同使用或實現數據格式轉換時能滿足有關要求能力的測試。

（18）中文本地化測試：驗證軟體在不降低原有能力的條件下，處理中文能力的測試。

4、從執行過程是否需要人工干預來看

（1）手工測試：就是測試人員按照事先為覆蓋被測軟體需求而編寫的測試用例，根據測試大綱中所描述的測試步驟和方法，手工地一個一個地輸 入執行，包括與被測軟體進行交互（如輸入測試數據、記錄測試結果等），然後觀察測試結果，看被測程序是否存在問題，或在執行過程中是否會有一場發生，屬於比較原始但是必須執行的一個步驟。

（2）自動化測試：實際上是將大量的重復性的測試工作交給計算機去完成，通常是使用自動化測試工具來模擬手動測試步驟，執行用某種程序設計語言編寫的過程（全自動測試就是指在自動測試過程中，不需要人工干預，由程序自動完成測試的全過程；半自動測試就是指在自動測試過程中，需要手動輸入測試用例或選擇測試路徑，再由自動測試程序按照人工指定的要求完成自動測試）

5、從測試實施組織看

（1）開發測試：開發人員進行的測試

（2）用戶測試：用戶方進行的測試

（3）第三方測試：有別於開發人員或用戶進行的測試，由專業的第三方承擔的測試，目的是為了保證測試工作的客觀性

6、從測試所處的環境看

（1）阿爾法測試：是由一個用戶在開發環境下進行的測試，也可以是公司內部的用戶在模擬實際操作環境下進行的測試

（2）貝塔測試：是用戶公司組織各方面的典型終端用戶在日常工作中實際使用貝塔版本，並要求用戶報告

(3)軟體工程白盒測試方法擴展閱讀

軟體測試的內容：

1 得到需求、功能設計、內部設計說書和其他必要的文檔

2 得到預算和進度要求

3 確定與項目有關的人員和他們的責任、對報告的要求、所需的標准和過程 ( 例如發行過程、變更過程、等等 )

4 確定應用軟體的高風險范圍，建立優先順序、確定測試所涉及的范圍和限制

5 確定測試的步驟和方法 ── 部件、集成、功能、系統、負載、可用性等各種測試

6 確定對測試環境的要求 ( 硬體、軟體、通信等 )

7 確定所需的測試用具 (testware) ，包括記錄 / 回放工具、覆蓋分析、測試跟蹤、問題 / 錯誤跟蹤、等等

8 確定對測試的輸入數據的要求

9 分配任務和任務負責人，以及所需的勞動力

10 設立大致的時間表、期限、和里程碑

11 確定輸入環境的類別、邊界值分析、錯誤類別

12 准備測試計劃文件和對計劃進行必要的回顧

13 准備白盒測試案例

14 對測試案例進行必要的回顧 / 調查 / 計劃

15 准備測試環境和測試用具，得到必需的用戶手冊 / 參考文件 / 結構指南 / 安裝指南，建立測試跟蹤過程，建立日誌和檔案、建立或得到測試輸入數據

16 得到並安裝軟體版本

17 進行測試

18 評估和報告結果

19 跟蹤問題 / 錯誤，並解決它

20 如果有必要，重新進行測試

21 在整個生命周期里維護和修改測試計劃、測試案例、測試環境、和測試用具

4. 軟體工程黑盒測試以什麼為依據 白盒測試以什麼為依據

什麼是黑盒測試和白盒測試？
任何工程產品（注意是任何工程產品）都可以使用以下兩種方法之一進行測試。
黑盒測試：已知產品的功能設計規格，可以進行測試證明每個實現了的功能是否符合要求。
白盒測試：已知產品的內部工作過程，可以通過測試證明每種內部操作是否符合設計規格要求，所有內部成分是否以經過檢查。

軟體的黑盒測試意味著測試要在軟體的介面處進行。這種方法是把測試對象看做一個黑盒子，測試人員完全不考慮程序內部的邏輯結構和內部特性，只依據程序的需求規格說明書，檢查程序的功能是否符合它的功能說明。因此黑盒測試又叫功能測試或數據驅動測試。黑盒測試主要是為了發現以下幾類錯誤：

1、是否有不正確或遺漏的功能？
2、在介面上，輸入是否能正確的接受？能否輸出正確的結果？
3、是否有數據結構錯誤或外部信息（例如數據文件）訪問錯誤？
4、性能上是否能夠滿足要求？
5、是否有初始化或終止性錯誤？

軟體的白盒測試是對軟體的過程性細節做細致的檢查。這種方法是把測試對象看做一個打開的盒子，它允許測試人員利用程序內部的邏輯結構及有關信息，設計或選擇測試用例，對程序所有邏輯路徑進行測試。通過在不同點檢查程序狀態，確定實際狀態是否與預期的狀態一致。因此白盒測試又稱為結構測試或邏輯驅動測試。白盒測試主要是想對程序模塊進行如下檢查：

1、對程序模塊的所有獨立的執行路徑至少測試一遍。
2、對所有的邏輯判定，取「真」與取「假」的兩種情況都能至少測一遍。
3、在循環的邊界和運行的界限內執行循環體。
4、測試內部數據結構的有效性，等等。

以上事實說明，軟體測試有一個致命的缺陷，即測試的不完全、不徹底性。由於任何程序只能進行少量（相對於窮舉的巨大數量而言）的有限的測試，在未發現錯誤時，不能說明程序中沒有錯誤。

5. 軟體工程試題，誰知道答案

一, 單項選擇題(每題1分,共10分):
1. ( ) 計算機系統就是:
A) 主機,顯示器,硬碟,軟碟機,列印機等.
B) CPU,存儲器,控制器,I/O介面及設備.
C) 計算機硬體系統和軟體系統.
D) 計算機及其應用系統.
2.( )產生軟體危機的原因主要與兩個方面的問題有關:
A) 軟體在計算機中很難識別,存在磁碟中也看不到.
B) 軟體設計對人的智商要求很高,也要求很高的資金投入.
C) 軟體產品本身的特點與其它工業產品不一樣,而且在軟體的開發和維護過程中用
的方法不正確.
D) 軟體很難理解,硬體也很復雜.
3.( )軟體開發瀑布模型中的軟體定義時期各個階段依次是:
A) 可行性研究,問題定義,需求分析.
B) 問題定義,可行性研究,需求分析.
C) 可行性研究,需求分析,問題定義.
D) 以上順序都不對.
4.( )軟體維護的四類維護活動是:
A) 改正性維護,適應性維護,完善性維護和預防性維護.
B) 適應性維護,完善性維護,搶救性維護和輔助性維護.
C) 改正性維護,適應性維護,完善性維護和輔助性維護.
D) 適應性維護,完善性維護,搶救性維護和預防性維護.
5.( ) 可行性研究主要從以下幾個方面進行研究:
A) 技術可行性,經濟可行性,操作可行性.
B) 技術可行性,經濟可行性,系統可行性.
C) 經濟可行性,系統可行性,操作可行性.
D) 經濟可行性,系統可行性,時間可行性.
6.( ) 系統邏輯模型主要由以下內容:
A) 數據流程圖,數據字典,簡要的演算法描述.
B) 程序流程圖,Jackson圖,IPO圖.
C) 數據流程圖,數據字典,ER圖.
D) Jackson圖,ER圖,IPO圖.
7. ( ) 耦合是對軟體不同模塊之間互連程度的度量.各種耦合按從強到弱排列如下:
A) 內容耦合,控制耦合,數據耦合,公共環境耦合.
B) 內容耦合,控制耦合,公共環境耦合,數據耦合.
C) 內容耦合,公共環境耦合,控制耦合,數據耦合.
D) 控制耦合,內容耦合,數據耦合,公共環境耦合.
8. ( ) 在詳細設計階段所使用到的設計工具是:
A) 程序流程圖,PAD圖,N-S圖,HIPO圖,判定表,判定樹.
B) 數據流程圖,Yourdon 圖,程序流程圖,PAD圖,N-S圖,HIPO圖.
C) 判定表,判定樹,數據流程圖,系統流程圖,程序流程圖,PAD圖,N-S圖.
D) 判定表,判定樹,數據流程圖,系統流程圖,程序流程圖,層次圖.
9. ( ) 按照軟體工程的原則,模塊的作用域和模塊的控制域之間的關系是:
A) 模塊的作用域應在模塊的控制域之內.
B) 模塊的控制域應在模塊的作用域之內.
C) 模塊的控制域與模塊的作用域互相獨立.
D) 以上說法都不對.
10. ( ) 包含所有可能情況的測試稱為窮盡測試.下面結論成立的是:
A) 只要對每種可能的情況都進行測試,就可以得出程序是否符合要求的結論.
B) 一般來說對於黑盒測試,窮盡測試是不可能作到的.
C) 一般來說對於白盒測試,窮盡測試是不可能作到的.
D) 在白盒測試和黑盒測試這兩個方法中,存在某一個是可以進行窮盡測試的.
二, 填空題(每題1分,共10分)
1.軟體危機是指在( )所遇到的一系列嚴重問題.
2.在軟體開發的各個階段經過階段評審後的文檔和程序代碼成為( ).
3.結構程序設計的基本思想是( ).
4.總體設計的第二項任務是設計軟體的結構,即確定( ).
5.描繪物理系統的傳統工具是( ).
6.如果模塊內所有元素都使用同一個輸入數據和產生同一個輸出,稱為( )內聚.
7.數據流程圖按照信息流的類型主要分為( )兩種.
8.( )年,( )和( )證明了SISO程序只需要三種基本控制結構.
9. 從應用特點分類,高級語言主要分為( ),( )和( )三類.
10. 黑盒測試又稱為( ),白盒測試也稱為( ).
三, 多項選擇題(以下各題均有兩個以上的正確答案.將正確答案的標號填入各題前面括弧
內,注意多選或少選該題均不得分,每題2分,共20分):
1.( )軟體開發各個階段所耗費的時間或工作量是:
A) 可行性研究佔5%;
B) 綜合測試佔40%;
C) 設計階段在所有開發階段所佔的比例最大.
D) 編碼和單元測試佔20%.
E) 以上說法都不對.
2.( )對軟體開發與維護,以下觀點是正確的:
A) 為了加快開發速度,可以一邊寫程序,一邊設計文檔.
B) 對於軟體而言,程序和軟體配置成分是同等重要的,不能重此偏0.
C) 把軟體漫長的生命周期劃分為若干個階段的出發點是降低開發的困難程度和
簡化復雜性.
D) 可行性研究的主要任務就是確定軟體項目的工程規模和目標.
E) 面向對象的方法學比傳統的軟體開發方法開發軟體容易,開發效率提高.
3.( ) 對於以下圖形工具的作用,
A) 數據流程圖和數據字典共同構成軟體的高層數據模型.
B) 層次圖是用來描述軟體結構的,不能用於描述數據結構.
C) IPO圖能方便地描繪輸入數據,對數據的處理和輸出數據的關系,它是美國微
軟公司發明並逐漸發展完善起來的.
D) ER圖描述現實世界中的實體,不涉及這些實體在系統中的實現方法.
E) Yourdon圖實際上也是結構圖,所以它與層次方框圖是等價的.
4.( ) 面向數據結構的設計方法有:
A) Jackson方法.
B) Warnier方法.
C) Halstead方法.
D) PAD方法.
E) G. M y e r s方法.
5.( )以下測試方法是白盒測試方法的是:
A) 判定覆蓋和邊界值分析法.
B) 等價劃分和錯誤推測法.
C) 路徑覆蓋和判定/條件覆蓋法.
D) 條件組合覆蓋和語句覆蓋法.
E) 條件覆蓋和錯誤推測法.
6.( )以下關於集成測試的論述,正確的是:
A) 先對每個模塊分別測試,然後統一組裝成軟體系統的方法稱為非漸增式測試.
B) 自頂向下的集成測試本質上是漸增式測試方法.
C) 存根模塊是漸增式測試方法中使用的,在非漸增式測試中也用不到樁模塊.
D) 一般來說,存根模塊和樁模塊在用過以後,不會作為軟體的正式模塊而存在.
E) 由於是對程序進行測試,測試方案的設計一般在詳細設計階段完成以後才進行.
7. ( ) 對於程序設計,正確的陳述是:
A) 為了減少程序的長度,最好不要在程序中增加註釋.
B) 變數名以簡潔為好,名字太長了難以理解,增加了程序的復雜性.
C) 程序語句要求體現層次性,以使結構清晰明顯.
D) 數據結構的組織和復雜程度在設計期間確定,但數據說明的風格是在寫程序時確
定的.
E) 對所有的輸入數據都要進行檢驗,以便確定其合法性.
8. ( ) 內聚標志一個模塊內各個元素彼此結合的緊密程度.
A) 內聚是信息隱蔽和局部化概念的自然擴展.理想內聚的模塊只做臆見事情.
B) 一個模塊所包含的任務必須在同一段時間內執行,該模塊的內聚為時間內聚.
C) 一個模塊內的處理元素是相關的,必須以特定次序執行,稱為過程內聚.
D) 順序內聚和功能內聚是高內聚,而偶然內聚和邏輯內聚是低內聚.
E) 時間內聚,通信內聚,過程內聚是中等程度的內聚.
9. ( )McCabe方法對程序復雜程度的定量度量的結果稱為程序的環行復雜度,
其計算公式是:V(G)=m-n+p.
A) 應用McCabe方法的前提是對應的程序圖變換成強連通圖.
B) V(G)代表程序圖G的線性無關環的個數.
C) 一般對於結構化程序,p恆等於1.
D) m是有向圖G中的弧數.
E) n是有向圖G中的節點數.
10.( )詳細設計階段的根本目標是確定應該怎樣具體的實現所要求的系統.
A) 詳細設計階段不具體的編寫程序.
B) 詳細設計階段的設計結果基本決定了最終的程序代碼質量.
C) 詳細設計的目標不僅要邏輯上正確的實現每個模塊的功能,而且對每個模塊的處
理過程也應確保簡明易懂,清晰具體.
D) 詳細設計的關鍵技術是結構程序設計技術.
四, 基本概念題(每題2分,共10分)
1. 軟體工程.
2. 軟體測試.
3. 數據流圖及其組成和作用.
4. 結構化分析方法.
5. 信息隱蔽原理.
五, 敘述分析題:(每題5分,共20分)
1. 試述對用戶要求沒有完整的認識就匆忙著手編寫程序是許多軟體開發工程失敗的主要
原因.
2. 簡述軟體可靠性和可用性的定義,平均無故障時間的計算公式及應用.
3. 簡述軟體重用的定義,范圍和主要技術.
4. 說明軟體測試在軟體開發階段的地位和作用.比較測試和調試的異同點.
六, 設計,作圖,計算題(每題5分,共30分)
1.以下是某系統的數據流程圖,請將其轉換成相應的SC圖.
2. 研究下面的偽碼程序,完成以下問題:
START
INPUT X,N
DIMENSION A(N),F(N)
DO I=1 TO N
INPUT F(I)
END DO
K=0
DO WHILE (KA(K)=0
DO J=1 TO N-K
A(K)=A(K)+F(J)*F(J+K)/(N-K+1)
END DO
PRINT K*X,A(K)
K=K+1
END DO
STOP
A) 畫出等價的控制流程圖,.
B) 判斷是否結構化的,說明理由.
C) 寫出對應的PAD圖.
D) 用McCabe方法計算環行復雜度.
3. 為方便儲戶,某銀行擬開發計算機儲蓄系統.儲戶填寫的存款單或取款單由業務員鍵
入系統.如果是存款,系統記錄存款人姓名,住址,存款類型,存款日期,利率等信
息,並印出存款單給儲戶;如果是取款,系統計算利息並印出利息清單給儲戶.
1)畫出該系統的高層數據流程圖和第二層細化流程圖.
2)對數據流定義數據字典.
4. 某航空公司規定,乘客可以免費托運不超過20公斤的行李.當行李重量超過20公斤
時,對頭等艙的乘客超重部分每公斤收費4元,其它艙的乘客收費6元.對殘疾乘客超重部分
在艙位等次相同的情況下收費減半.用判定表描述行李托運費的處理過程.
5.設計程序,先讀入三個整數值代表一個三角形的三條邊,然後根據這三個值判斷該三
角形屬於不等邊,等腰或等邊三角形中的哪一種.請設計滿足判定/條件覆蓋標準的測試
方案.
6.設模塊RootForSquare(int a,int b,int c,int *x,int *y) 的功能是一元二次方程求根.請使用
等價劃分法來設計測試方案.

6. 什麼是白盒測試

白盒測試也稱結構測試或邏輯驅動測試，它是按照程序內部的結構測試程序，通過測試來檢測產品內部動作是否按照設計規格說明書的規定正常進行，檢驗程序中的每條通路是否都能按預定要求正確工作。 這一方法是把測試對象看作一個打開的盒子，測試人員依據程序內部邏輯結構相關信息，設計或選擇測試用例，對程序所有邏輯路徑進行測試，通過在不同點檢查程序的狀態，確定實際的狀態是否與預期的狀態一致。
白盒測試的測試方法有代碼檢查法、靜態結構分析法、靜態質量度量法、邏輯覆蓋法、基本路徑測試法、域測試、符號測試、Z路徑覆蓋、程序變異。 白盒測試法的覆蓋標准有邏輯覆蓋、循環覆蓋和基本路徑測試。其中邏輯覆蓋包括語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋和路徑覆蓋。 六種覆蓋標准：語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋和路徑覆蓋發現錯誤的能力呈由弱至強的變化。語句覆蓋每條語句至少執行一次。判定覆蓋每個判定的每個分支至少執行一次。條件覆蓋每個判定的每個條件應取到各種可能的值。判定/條件覆蓋同時滿足判定覆蓋條件覆蓋。條件組合覆蓋每個判定中各條件的每一種組合至少出現一次。路徑覆蓋使程序中每一條可能的路徑至少執行一次。 "白盒"法全面了解程序內部邏輯結構、對所有邏輯路徑進行測試。"白盒"法是窮舉路徑測試。在使用這一方案時，測試者必須檢查程序的內部結構，從檢查程序的邏輯著手，得出測試數據。貫穿程序的獨立路徑數是天文數字。但即使每條路徑都測試了仍然可能有錯誤。第一，窮舉路徑測試決不能查出程序違反了設計規范，即程序本身是個錯誤的程序。第二，窮舉路徑測試不可能查出程序中因遺漏路徑而出錯。第三，窮舉路徑測試可能發現不了一些與數據相關的錯誤。 白盒測試，有時稱為玻璃盒測試，是一種測試用例設計方法，它使用程 序設計的控制結構導出測試用例。使用白盒測試方法，軟體工程師能夠產生 測試用例(1)保證一個模塊中的所有獨立路徑至少被使用一次；(2)對所有邏 輯值均需測試true 和 false；(3)在上下邊界及可操作范圍內運行所有循 環；(4)檢查內部數據結構以確保其有效性。

7. 請問那位大蝦知道關於電子商務當中提到的 白盒測試與黑盒測試的問題！！！

一、黑盒測試在快速應用開發（rad）環境中的重要作用

軟體測試方法一般分為兩種：白盒測試與黑盒測試。其中，白盒測試又稱為結構測試、邏輯驅動測試或基於程序本身的測試，著重於程序的內部結構及演算法，通常不關心功能與性能指標。黑盒測試又被稱為功能測試、數據驅動測試或基於規格說明的測試，實際上是站在最終用戶的立場上，檢驗輸入輸出信息及系統性能指標是否符合規格說明書中有關功能需求及性能需求的規定。

隨著rad環境的發展，軟體工程面臨新的挑戰，其中包括：

●應用系統的規模越來越龐大，結構越來越復雜；

●開發團隊人員越來越多，分工越來越細；

●項目投資日益提高，導致投資風險增大。

在這樣一種背景下，軟體質量面臨著更大的危機，而解決問題的關鍵正是黑盒測試，可是由於傳統的黑盒測試往往局限於手工測試，憑借工程人員的經驗自發地進行，缺乏嚴格的測試管理機制，因而效果並不明顯。

在分發一個應用系統之前，若沒有經過科學、周密的黑盒測試，就相當於將大量隱含的缺陷（defect）交付到最終用戶手中，這對於開發團隊自身、項目投資方及最終用戶來說都是不負責任的表現，也將嚴重損害三方的利益。

今天，軟體的質量要求越來越受到重視，在對軟體的質量監督中，黑盒測試起著重要的、不可替代的作用；而隨著軟體開發平台及軟體設計思想的進步和發展，特別是rad技術的發展，對黑盒測試提出了更明確的要求，人們發現，必須遵循一定的測試理論，依賴於優秀的測試工具，才能進行科學、完備的測試。

二、黑盒測試的操作步驟

在傳統的軟體開發生命周期當中，測試工作往往被擱置到整個開發過程的後期進行，也就是說，當應用程序的編碼工作已經基本完成，才開始進行測試，這樣做的缺點在於：

a）由於應用程序龐大而復雜，測試工作千頭萬緒，測試人員難以組織科學、全面的測試用例，從而大幅度提高了測試成本，並嚴重影響測試的全面性和有效性；

b）由於缺陷所涉及的模塊從開發到測試之間的時間間隔較長，使得程序員的修改和維護工作要付出更大的代價；

c）由於受到分發日期的限制，測試工作往往是在忙碌中結束的，而將大量的缺陷遺留給最終用戶，也就是說，真正的測試工作實際上是由最終用戶來完成的。

因此，為了保證測試工作科學、精確、全面、有序地進行，應該採取一邊開發一邊測試的策略，使得開發工作與測試工作平行進行，這也就是俗話所說的「越早測試越好」的概念。

一套完整的測試應該由五個階段組成：

1．測試計劃

首先，根據用戶需求報告中關於功能要求和性能指標的規格說明書，定義相應的測試需求報告，即制訂黑盒測試的最高標准，以後所有的測試工作都將圍繞著測試需求來進行，符合測試需求的應用程序即是合格的，反之即是不合格的；同時，還要適當選擇測試內容，合理安排測試人員、測試時間及測試資源等。

2．測試設計

將測試計劃階段制訂的測試需求分解、細化為若干個可執行的測試過程，並為每個測試過程選擇適當的測試用例（測試用例選擇的好壞將直接影響到測試結果的有效性）。

3．測試開發

建立可重復使用的自動測試過程。

4．測試執行

執行測試開發階段建立的自動測試過程，並對所發現的缺陷進行跟蹤管理。測試執行一般由單元測試、組合測試、集成測試、系統聯調及回歸測試等步驟組成，測試人員應本著科學負責的態度，一步一個腳印地進行測試。

5．測試評估

結合量化的測試覆蓋域及缺陷跟蹤報告，對於應用軟體的質量和開發團隊的工作進度及工作效率進行綜合評價。

顯然，黑盒測試只有嚴格按照步驟進行，才可能對應用程序的質量進行把關。然而，如果沒有一種優秀的測試工具的幫助，單純憑藉手工測試，不但將耗費大量的人力、物力和財力，而且有很多測試工作是難以實現甚至是無法實現的。

三、手工測試與自動測試的比較

手工測試無法保證黑盒測試的科學性與嚴密性，這是因為：

●測試人員要負責大量文檔、報表的制訂和整理工作，會變得力不從心；

●受軟體分發日期、開發成本及人員、資源等諸多方面因素的限制，難以進行全面的測試；

●如果修正缺陷所花費的時間相當長，回歸測試將變得異常困難；

●對測試過程中發現的大量缺陷缺乏科學、有效的管理手段，責任變得含混不清，沒有人能向決策層提供精確的數據以度量當前的工作進度及工作效率；

●反復測試帶來的倦怠情緒及其他人為因素使得測試標准前後不一，測試花費的時間越長，測試的嚴格性也就越低；

●難以對不可視對象或對象的不可視屬性進行測試。

因此，自動測試成為最佳的解決方案。所謂自動測試，實際上是將大量的重復性工作交給計算機去完成，一個優秀的自動測試工具，不但可以滿足科學測試的基本要求，而且可以節約大量的時間、成本、人員和資源，並且測試腳本可以被重復利用（包括被不同的項目所利用）。

8. 什麼是黑盒測試和白盒測試

軟體測試按照測試技術劃分可以有：黑盒測試，白盒測試，灰盒測試

黑盒測試又叫功能測試

1.軟體黑色盒子，里邊的實現，看不見代碼

2.輸入，輸出結果---功能測試的方法

這是因為在黑盒測試中主要關注被測軟體的功能實現，而.不是內部邏輯。

在黑盒測試中，被測對象的內部結構，運作情況對測試人員是不可見的，測試人員主要是驗證系統功能與需求的一致性。

在絕大多數沒有用戶參與的黑盒測試中，最常見的測試有:功能性測試、容量測試、安全性測試、負載測試、恢復性測試、標桿測試、穩定性測試、可靠性測試等。

在我們軟體測試行業中最常見的還是功能測試，考察個人對需求的掌握度和軟體工程的基本知識。

白盒測試

1.白色透明的黑子；代碼實現，功能邏輯；

2.開發--看代碼---單元測試

是一種測試用例設計方法，在這里盒子指的是被測試的軟體，白盒,顧名思義即盒子是可視的，你可以清楚盒子內部.的東西以及裡面是如何運作的,因此白盒測試需要你對系統內部的結構和工作原理有一-個清楚的了解,並且基於這個知識來設計你的用例。

白盒測試技術一般可被分為靜態分析和動態分析兩類技術。

白盒測試優點:迫使測試人員去仔細的思考軟體的實現;可以檢測代碼中的每條分支和路徑;揭示隱藏在代碼中的錯誤;對代碼的測試比較徹底，最優化。

白盒測試缺點:無法檢測代碼中遺漏的路徑和數據敏感性錯誤;不驗證格式的正確性。

灰盒測試（補充）

1.介於白盒黑盒兩者之間

2.了解實現流程邏輯，不需要知道具體代碼

3.介面測試---使用方法

白盒測試和黑盒測試往往不是決然分開的，一般在白盒測試中交叉使用黑盒測試的方法，在黑盒測試中交叉使用白盒測試的方法。

最常見的灰盒測試是集成測試

9. 軟體工程單元測試應該怎麼寫

單元測試是在軟體開發過程中要進行的最低級別的測試活動，在單元測試活動中，軟體的獨立單元將在與程序的其他部分相隔離的情況下進行測試。 單元測試不僅僅是作為無錯編碼一種輔助手段在一次性的開發過程中使用，單元測試必須是可重復的，無論是在軟體修改，或是移植到新的運行環境的過程中。因此，所有的測試都必須在整個軟體系統的生命周期中進行維護。
測試用例設計
下面談談測試用例設計。前面已經說了，測試用例的核心是輸入數據。預期輸出是依據輸入數據和程序功能來確定的，也就是說，對於某一程序，輸入數據確定了，預期輸出也就可以確定了，至於生成/銷毀被測試對象和運行測試的語句，是所有測試用例都大同小異的，因此，我們討論測試用例時，只討論輸入數據。
前面說過，輸入數據包括四類：參數、成員變數、全局變數、IO媒體，這四類數據中，只要所測試的程序需要執行讀操作的，就要設定其初始值，其中，前兩類比較常用，後兩類較少用。顯然，把輸入數據的所有可能取值都進行測試，是不可能也是無意義的，我們應該用一定的規則選擇有代表性的數據作為輸入數據，主要有三種：正常輸入，邊界輸入，非法輸入，每種輸入還可以分類，也就是平常說的等價類法，每類取一個數據作為輸入數據，如果測試通過，可以肯定同類的其他輸入也是可以通過的。下面舉例說明：
正常輸入
例如字元串的Trim函數，功能是將字元串前後的空格去除，那麼正常的輸入可以有四類：前面有空格；後面有空格；前後均有空格；前後均無空格。
邊界輸入
上例中空字元串可以看作是邊界輸入。
再如一個表示年齡的參數，它的有效范圍是0-100，那麼邊界輸入有兩個：0和100。
非法輸入
非法輸入是正常取值范圍以外的數據，或使代碼不能完成正常功能的輸入，如上例中表示年齡的參數，小於0或大於100都是非法輸入，再如一個進行文件操作的函數，非法輸入有這么幾類：文件不存在；目錄不存在；文件正在被其他程序打開；許可權錯誤。
如果函數使用了外部數據，則正常輸入是肯定會有的，而邊界輸入和非法輸入不是所有函數都有。一般情況下，即使沒有設計文檔，考慮以上三種輸入也可以找出函數的基本功能點。實際上，單元測試與代碼編寫是「一體兩面」的關系，編碼時對上述三種輸入都是必須考慮的，否則代碼的健壯性就會成問題。
白盒覆蓋
上面所說的測試數據都是針對程序的功能來設計的，就是所謂的黑盒測試。單元測試還需要從另一個角度來設計測試數據，即針對程序的邏輯結構來設計測試用例，就是所謂的白盒測試。在老納看來，如果黑盒測試是足夠充分的，那麼白盒測試就沒有必要，可惜「足夠充分」只是一種理想狀態，例如：真的是所有功能點都測試了嗎？程序的功能點是人為的定義，常常是不全面的；各個輸入數據之間，有些組合可能會產生問題，怎樣保證這些組合都經過了測試？難於衡量測試的完整性是黑盒測試的主要缺陷，而白盒測試恰恰具有易於衡量測試完整性的優點，兩者之間具有極好的互補性，例如：完成功能測試後統計語句覆蓋率，如果語句覆蓋未完成，很可能是未覆蓋的語句所對應的功能點未測試。
白盒測試針對程序的邏輯結構設計測試用例，用邏輯覆蓋率來衡量測試的完整性。邏輯單位主要有：語句、分支、條件、條件值、條件值組合，路徑。語句覆蓋就是覆蓋所有的語句，其他類推。另外還有一種判定條件覆蓋，其實是分支覆蓋與條件覆蓋的組合，在此不作討論。跟條件有關的覆蓋就有三種，解釋一下：條件覆蓋是指覆蓋所有的條件表達式，即所有的條件表達式都至少計算一次，不考慮計算結果；條件值覆蓋是指覆蓋條件的所有可能取值，即每個條件的取真值和取假值都要至少計算一次；條件值組合覆蓋是指覆蓋所有條件取值的所有可能組合。老納做過一些粗淺的研究，發現與條件直接有關的錯誤主要是邏輯操作符錯誤，例如：||寫成&&，漏了寫!什麼的，採用分支覆蓋與條件覆蓋的組合，基本上可以發現這些錯誤，另一方面，條件值覆蓋與條件值組合覆蓋往往需要大量的測試用例，因此，在老納看來，條件值覆蓋和條件值組合覆蓋的效費比偏低。老納認為效費比較高且完整性也足夠的測試要求是這樣的：完成功能測試，完成語句覆蓋、條件覆蓋、分支覆蓋、路徑覆蓋。做過單元測試的朋友恐怕會對老納提出的測試要求給予一個字的評價：暈！或者兩個字的評價：狂暈！因為這似乎是不可能的要求，要達到這種測試完整性，其測試成本是不可想像的，不過，出家人不打逛語，老納之所以提出這種測試要求，是因為利用一些工具，可以在較低的成本下達到這種測試要求，後面將會作進一步介紹。
關於白盒測試用例的設計，程序測試領域的書籍一般都有講述，普通方法是畫出程序的邏輯結構圖如程序流程圖或控制流圖，根據邏輯結構圖設計測試用例，這些是純粹的白盒測試，不是老納想推薦的方式。老納所推薦的方法是：先完成黑盒測試，然後統計白盒覆蓋率，針對未覆蓋的邏輯單位設計測試用例覆蓋它，例如，先檢查是否有語句未覆蓋，有的話設計測試用例覆蓋它，然後用同樣方法完成條件覆蓋、分支覆蓋和路徑覆蓋，這樣的話，既檢驗了黑盒測試的完整性，又避免了重復的工作，用較少的時間成本達到非常高的測試完整性。不過，這些工作可不是手工能完成的，必須藉助於工具，後面會介紹可以完成這些工作的測試工具。