第1章? 軟件測試概述

什么是軟件測試

ü? 廣義的概念：指軟件生存周期中所有的檢查、評審和確認工作，其中包括了對分析、設計階段，以及完成開發后維護階段的各類文檔、代碼的審查和確認

ü? 狹義概念：識別軟件缺陷的過程，即實際結果與預期結果的不一致

ü? 軟件測試通常包括驗證(verification)和確認(validation)：

-????驗證指保證軟件正確的實現了某一特定功能的一系列活動

-????確認指的是保證軟件的實現滿足了用戶需求的一系列活動

軟件測試的目的

ü? 測試的目的就是發現軟件中的各種缺陷

ü? 測試只能證明軟件存在缺陷，不能證明軟件不存在缺陷

ü? 測試可以使軟件中缺陷降低到一定程度，而不是徹底消滅

ü? 以較少的用例、時間和人力找出軟件中的各種錯誤和缺陷，以確保軟件的質量

測試的目標

ü? 最終目的是確保軟件的功能符合用戶的需求，把盡可能多的問題在發布或交付前發現并改正：

-????確保軟件完成了它所承諾或公布的功能

-????確保軟件滿足性能的要求

-????確保軟件是健壯的和適應用戶環境的

ü? 為軟件的質量評估提供依據

ü? 為軟件質量改進和管理提供幫助

軟件測試原則

ü? Good-enough: 一種權衡投入/產出比的原則

ü? 保證測試的覆蓋程度，但窮舉測試是不可能的

ü? 所有的測試都應追溯到用戶需求

ü? 越早測試越好，測試過程與開發過程應是相結合的

ü? 測試的規模由小而大，從單元測試到系統測試

ü? 為了盡可能地發現錯誤，應該由獨立的第三方來測試

ü? 不能為了便于測試擅自修改程序

ü? 既應該測試軟件該做什么也應該測試軟件不該做什么

測試的規律

ü? 木桶原理：

-????軟件質量的關鍵因素是分析、設計和實現，測試應該是融于其中的補充檢查手段，其他管理、支持、甚至文化因素也會影響最終軟件的質量

-????測試是提高軟件質量的必要條件，最直接、最快捷的手段，但決不是一種根本手段

ü? Bug的80-20原則

-????在分析、設計、實現階段的復審和測試工作能夠發現和避免80%的Bug

-????而系統測試又能找出其余Bug中的80%

-????最后的5%的Bug可能只 有在用戶的大范圍、長時間使用后才會曝露出來

軟件測試的重點

ü? 測試用例的良好設計

-????測試用例的設計是整個軟件測試工作的核心

-????測試用例反映對被測對象的質量要求，決定對測試對象的質量評估

ü? 測試工作的管理

-????尤其是對包含多個子系統的大型軟件系統，其測試工作涉及大量人力和物力，有效的測試工作管理是保證有效測試工作的必要前提

ü? 測試環境的建立

-????測試環境應該與實際測試環境一致

軟件缺陷含義

ü? IEEE (1983) 729 軟件缺陷一個標準的定義：

-????從產品內部看，軟件缺陷是軟件產品開發或維護過程中所存在的錯誤、毛病等各種問題；

-????從外部看，軟件缺陷是系統所需要實現的某種功能的失效或違背。

軟件缺陷的主要類型/現象：

-????功能、特性沒有實現或部分實現

-????設計不合理，存在缺陷

-????實際結果和預期結果不一致

-????運行出錯，包括運行中斷、系統崩潰、界面混亂

-????數據結果不正確、精度不夠

-????用戶不能接受的其他問題，如存取時間過長、界面不美觀

ü? 軟件缺陷的產生

①??????技術問題：算法錯誤，語法錯誤，計算和精度問題，接口參數傳遞不匹配

②??????團隊工作：誤解、溝通不充分

③??????軟件本身：文檔錯誤、用戶使用場景(user scenario)，時間上不協調、或不一致性所帶來的問題。系統的自我恢復或數據的異地備份、災難性恢復等問題

軟件缺陷在不同階段的分布

在真正的程序測試之前，通過審查、評審會可以發現更多的缺陷。規格說明書的缺陷會在需求分析審查、設計、編碼、測試等過程中會逐步發現，而不能在需求分析一個階段發現

軟件測試的質量

ü? 軟件測試可以發現以下軟件缺陷：

-????軟件實現的功能不正確

-????“缺少”：軟件沒有實現某項功能

-????“多余”：軟件實現的某項功能在需求中沒有定義

ü? 發現第一類軟件缺陷的過程 --- “驗證”

ü? 發現后兩類軟件缺陷的過程 --- “確認”

ü? 軟件測試本身的質量在于：

-????發現軟件缺陷并能區分其類型

-????提供關于軟件質量和開發過程質量的信息

軟件測試度量

ü? 測試覆蓋率

-????有多少需求、代碼已經被測試了

ü? 缺陷發現率

-????缺陷是何時被發現，并且有多少缺陷已經被發現。缺陷可以根據嚴重性來分類。需記錄以下值：

?? 缺陷數目

?? 缺陷的嚴重性

軟件測試的分類

ü? 典型的軟件測試類型

-????功能測試

-????可靠性測試

-????容錯性測試

-????恢復測試

-????易用性測試

-????性能測試

-????可維護性測試

-????可移植性測試

-????安全性測試

-????用戶文檔測試

-????軟件測試技術

ü? 黑盒測試/白盒測試

ü? 動態測試/靜態測試

黑盒測試和白盒測試

ü? 黑盒測試

-????又稱功能測試或數據驅動測試，是針對軟件的功能需求/實現進行測試

-????通過測試來檢測每個功能是否符合需求，不考慮程序內部的邏輯結構

-????窮舉輸入測試

ü? 黑盒測試方法

-????功能劃分

-????等價類劃分

-????邊界值分析

-????因果圖

-????錯誤推測等

-????白盒測試

-????白盒測試也稱結構測試或邏輯驅動測試

-????必須知道軟件內部工作過程，通過測試來檢測軟件內部是否按照需求、設計正常運行

-????通過邏輯覆蓋、路徑覆蓋等方式選擇測試用例，可以用測試覆蓋率評價測試用例

ü? 白盒測試的主要方法

-????對應于程序的一些主要結構：語句、分支、邏輯路徑、變量

?? 語句覆蓋方法

?? 分支覆蓋方法

?? 邏輯覆蓋方法

動態測試和靜態測試

ü? 動態測試

-????動態測試需要在開發/測試環境或實際運行環境中運行軟件，并使用測試用例去查找軟件缺陷

-????動態測試包括功能確認與接口測試、覆蓋率分析、性能分析、內存分析等?

ü? 靜態測試

-????靜態測試不實際運行軟件，主要是對軟件的編程格式、結構等方面進行評估

-????靜態測試包括代碼檢查、程序結構分析、代碼質量度量等。它可以由人工進行，也可以借助軟件工具自動進行

黑盒白盒測試與動態靜態測試的關系

ü? 黑盒測試、白盒測試

-????測試用例設計階段采用的方法

ü? 動態測試、靜態測試

-????測試執行階段采用的方法

軟件測試方法

手工測試和自動測試

ü? 手工測試

ü? 自動測試

ü? 適合自動化的測試操作

ü? 手工測試和自動測試的比較

ü? 手工測試

ü? 傳統的測試方法

ü? 由測試人員手工編寫測試用例

ü? 缺點在于測試工作量大，重復多，回歸測試難以實現

自動測試

ü? 利用軟件測試工具自動實現全部或部分測試工作：管理、設計、執行和報告

ü? 自動測試節省大量的測試開銷，并能夠完成一些手工測試無法實現的測試

適合自動化的測試操作

ü? 測試用例的生成（包括測試輸入，標準輸出，測試操作指令等）

ü? 測試的執行與控制（包括單機與網絡多機分布運行；夜間及假日運行）

ü? 測試對象、范圍、版本等的控制

ü? 測試結果與預期輸出的對比

ü? 不吻合的測試結果的分析、記錄、分類、和通報

ü? 測試的統計，報表的產生

手工測試和自動測試的比較

ü? 手工完成測試的全部過程無法保證測試的科學性與嚴密性:

-????修改的缺陷越多，回歸測試越困難

-????沒有人能向決策層提供精確的數據以度量當前的工作進度及工作效率

-????反復測試帶來的倦怠情緒及其他人為因素使得測試標準前后不一

-????測試花費的時間越長，測試的嚴格性也就越低

ü? 自動測試將測試人員從反復、煩雜的測試執行中解放出來，用更多的時間進行測試設計和結果分析

ü? 軟件測試不可能完全自動化

ü? 不能完成所有手工測試任務

ü? 無創造性且靈活性差，不能改進測試的有效性

ü? 過程中可能會遇到許多意想不到的問題，特別是當軟件不穩定時

ü? 測試腳本的維護高

測試流程

ü? 單元測試

ü? 集成測試

ü? 系統測試

ü? 用戶驗收測試

ü? 回歸測試

ü? V模型示意圖

單元測試

ü? 完成對最小的軟件設計單元—模塊的驗證工作

ü? 目標是確保模塊被正確地編碼

ü? 使用過程設計描述作為指南，對重要的控制路徑進行測試以發現模塊內的錯誤

ü? 通常情況下是面向白盒的

ü? 對代碼風格和規則、程序設計和結構、業務邏輯等進行靜態測試，及早地發現和解決不易顯現的錯誤

單元測試

ü? 單元測試的內容

-????接口測試

-????內部數據結構

-????全局數據結構

-????邊界

-????語句覆蓋

-????錯誤路徑

集成測試

ü? 通過測試發現與模塊接口有關的問題

ü? 目標是把通過了單元測試的模塊拿來，構造一個在設計中所描述的程序結構

ü? 應當避免一次性的集成（除非軟件規模很小），而采用增量集成

系統測試

ü? 根據軟件需求規范的要求進行系統測試，確認系統滿足需求的要求

ü? 系統測試人員相當于用戶代言人

ü? 在需求分析階段要確定軟件的可測性，保證有效完成系統測試工作

ü? 系統測試主要內容

-????所有功能需求得到滿足

-????所有性能需求得到滿足

-????其他需求（例如安全性、容錯性、兼容性等）得到滿足

用戶驗收/確認測試

ü? 配置審查

-????確保已開發軟件的所有文件資料均已編寫齊全，并分類編目

ü? Alpha測試

-????是由用戶在開發者的場所來進行的，Alpha測試是在一個受控的環境中進行的

ü? Beta測試

-????由軟件的最終用戶在一個或多個用戶場所來進行的

-????開發者通常不在現場，用戶記錄測試中遇到的問題并報告給開發者

-????開發者對系統進行最后的修改，并開始準備發布最終的軟件

回歸測試

ü? 當發現并修改缺陷后，或者在軟件中添加新功能后，重新測試，用來檢查被發現的缺陷是否被改正，并且所作的修改沒有引發新的問題

ü? 回歸測試可以通過人工重新執行測試用例，也可以使用自動化的捕獲回放工具來進行

ü? 回歸測試方式

-????再測試全部用例

?? 選擇基線測試用例庫中的全部測試用例組成回歸測試包，測試成本最高

-????基于風險選擇測試

?? 可以基于一定的風險標準來從基線測試用例庫中選擇回歸測試包

各階段測試所使用的方法技術

ü? 單元測試

白盒、自動、靜態

ü? 集成測試

白盒、黑盒、自動、靜態

ü? 系統測試

黑盒、自動、手工

ü? 用戶驗收/確認測試

黑盒、自動、手工

第2章? 軟件測試策略與過程

2.1? 軟件測試的復雜性分析

1、無法對程序進行完全測試

（1）測試所需要的輸入量太大

（2）測試的輸出結果太多

（3）軟件實現的途徑太多

（4）軟件規格說明沒有一個客觀標準

2、測試無法顯示潛在的軟件缺陷和故障

??? ——通過軟件測試只能報告軟件已被發現的缺陷和故障，無法報告隱藏的軟件故障。

3、存在的故障現象與發現的故障數量成正比

??? ——結論：應當對故障集中的程序段進行重點測試

4、不能修復所有的軟件故障

??? ——原因：沒有足夠的進行修復；修復的風險較大；? 不值得修復；可不算做故障的一些缺陷；“殺蟲劑現象”。

??? ——結論：關鍵是要進行正確的判斷、合理的取舍，根據風險分析決定哪些故障必須修復，哪些故障可以不修復。

5、軟件測試的代價

??? ——工作原則：就是如何將無邊無際的可能性減小到一個可以控制的范圍，以及如何針對軟件風險做出恰當選擇，去粗存精，找到最佳的測試量，使得測試工作量不多也不少，既能達到測試的目的，又能較為經濟。

2.2? 軟件測試方法與策略

軟件測試策略

l? 什么是軟件測試策略？

??? ——是為軟件工程過程定義的一個軟件測試的模板，也就是把特定的測試用例方法放置進去的一系列步驟。

l? 軟件測試策略包含的特征：

（1）測試從模塊層開始，然后擴大延伸到整個基于計算機的系統集合中。

（2）不同的測試技術適用于不同的時間點。

（3）測試是由軟件的開發人員和（對于大型系統而言）獨立的測試組來管理的。

（4）測試和調試是不同的活動，但是調試必須能夠適應任何的測試策略。

軟件測試充分性準則

l? 對任何軟件都存在有限的充分測試集合。

l? 如果一個軟件系統在一個測試數據集合上的測試是充分的，那么再多測試一些數據也應該是充分的。這一特性稱為單調性。

l? 即使對軟件所有成分都進行了充分的測試，也并不表明整個軟件的測試已經充分了。這一特性稱為非復合性。

l? 即使對軟件系統整體的測試是充分的，也并不意味軟件系統中各個成分都已經充分地得到了測試。這個特性稱為非分解性。

l? 軟件測試的充分性應該與軟件的需求和軟件的實現都相關。

l? 軟件越復雜，需要的測試數據就越多。這一特性稱為復雜性。

l? 測試得越多，進一步測試所能得到的充分性增長就越少。這一特性稱為回報遞減率。

2.2.1? 靜態測試與動態測試

1、靜態測試

l? 靜態測試不實際運行軟件，主要是對軟件的編程格式、結構等方面進行評估。

l? 靜態測試包括代碼檢查、靜態結構分析、代碼質量度量等。它可以由人工進行，也可以借助軟件工具自動進行。

l? 靜態測試方法也可利用計算機作為對被測程序進行特性分析的工具，但與人工測試方式有著根本區別。另一方面，因它并不真正運行被測程序，只進行特性分析，這又與動態方法不同。所以，靜態方法常常稱為“分析”，靜態測試是對被測程序進行特性分析方法的總稱。

代碼檢查

l? 代碼檢查包括代碼走查、桌面檢查、代碼審查等，主要檢查代碼和設計的一致性，代碼對標準的遵循、可讀性，代碼的邏輯表達的正確性，代碼結構的合理性等方面。

l? 代碼檢查的具體內容：變量檢查、命名和類型審查、程序邏輯審查、程序語法檢查和程序結構檢查等。

l? 代碼檢查的優點：在實際使用中，代碼檢查比動態測試更有效率，能快速找到缺陷，發現30%～70%的邏輯設計和編碼缺陷；代碼檢查看到的是問題本身而非征兆。

l? 代碼檢查的缺點：非常耗費時間，而且代碼檢查需要知識和經驗的積累。

靜態結構分析

l? 靜態結構分析主要是以圖形的方式表現程序的內部結構。例如函數調用關系圖、函數內部控制流圖。其中：

——函數調用關系圖以直觀的圖形方式描述一個應用程序中各個函數的調用和被調用關系；

——控制流圖顯示一個函數的邏輯結構，由許多節點組成，一個節點代表一條語句或數條語句，連接結點的叫邊，邊表示節點間的控制流向。

代碼質量度量

l? 軟件質量包括六個方面：功能性、可靠性、易用性、效率、可維護性和可移植性。軟件的質量是軟件屬性的各種標準度量的組合。

l? 針對軟件的可維護性，目前業界主要存在三種度量參數：Line復雜度、Halstead復雜度和McCabe復雜度。其中Line復雜度以代碼的行數作為計算的基準。Halstead以程序中使用到的運算符與運算元數量作為計數目標（直接測量指標），然后可以據以計算出程序容量、工作量等。McCabe復雜度 一般稱為圈復雜度，它將軟件的流程圖轉化為有向圖，然后以圖論來衡量軟件的質量。

靜態測試與動態測試（續）

l? 靜態測試階段的任務：

（1）檢查算法的邏輯正確性。

（2）檢查模塊接口的正確性。

（3）檢查輸入參數是否有合法性檢查。

（4）檢查調用其他模塊的接口是否正確。

（5）檢查是否設置了適當的出錯處理。

（6）檢查表達式、語句是否正確，是否含有二義性。

（7）檢查常量或全局變量使用是否正確。

（8）檢查標識符的使用是否規范、一致。

（9）檢查程序風格的一致性、規范性。

（10）檢查代碼是否可以優化，算法效率是否最高。

（11）檢查代碼注釋是否完整，是否正確反映了代碼的功能。

靜態測試可以完成以下工作：

（1）發現下列程序的錯誤：錯用局部變量和全局變量；未定義的變量、不匹配的參數；不適當的循環嵌套或分支嵌套、死循環、不允許的遞歸；調用不存在的子程序，遺漏標號或代碼。

（2）找出以下問題的根源：從未使用過的變量；不會執行到的代碼、從未使用過的標號；潛在的死循環。

（3）提供程序缺陷的間接信息：所用變量和常量的交叉應用表；是否違背編碼規則；標識符的使用方法和過程的調用層次。

（4）為進一步查找做好準備。

（5）選擇測試用例。

（6）進行符號測試。

2、動態測試

l? 動態方法的主要特征是：

——計算機必須真正運行被測試的程序，通過輸入測試用例，對其運行情況即輸入與輸出的對應關系進行分析，以達到檢測的目的。

l? 動態測試包括：

（1）功能確認與接口測試

（2）覆蓋率分析

（3）性能分析

（4）內存分析

2.2.2? 黑盒測試和白盒測試

l? 若測試規劃是基于產品的功能，目的是檢查程序各個功能是否能夠實現，并檢查其中的功能錯誤，則這種測試方法稱為黑盒測試(Black-box Testing)方法。

——黑盒測試又稱為功能測試、數據驅動測試和基于規格說明的測試。它是一種從用戶觀點出發的測試，一般被用來確認軟件功能的正確性和可操作性。

l? 若測試規劃基于產品的內部結構進行測試，檢查內部操作是否按規定執行，軟件各個部分功能是否得到充分使用，則這種測試方法稱為白盒測試(White-box Testing)方法。

——白盒測試又稱為結構測試、邏輯驅動測試或基于程序的測試，一般用來分析程序的內部結構。

1、黑盒測試

l? 黑盒測試的基本觀點是：任何程序都可以看作是從輸入定義域映射到輸出值域的函數過程，被測程序被認為是一個打不開的黑盒子，黑盒中的內容（實現過程）完全不知道，只明確要做到什么。

l? 黑盒測試主要根據規格說明書設計測試用例，并不涉及程序內部構造和內部特性，只依靠被測程序輸入和輸出之間的關系或程序的功能設計測試用例。

l? 黑盒測試的特點：

（1）黑盒測試與軟件的具體實現過程無關，在軟件實現的過程發生變化時，測試用例仍然可以使用。

（2）黑盒測試用例的設計可以和軟件實現同時進行，這樣能夠壓縮總的開發時間。

黑盒測試是在程序接口進行測試，它只是檢查程序功能是否按照規格說明書的規定正常使用。也被稱為用戶測試。

l? 黑盒測試主要是為了發現以下幾類錯誤：

-????是否有不正確或遺漏了的功能？

-????在接口上，輸入能否正確地接受？能否輸出正確的結果？

-????是否有數據結構錯誤或外部信息訪問錯誤？

-????性能上是否能夠滿足要求？

-????是否有初始化或終止性錯誤？

l? 黑盒測試的難點：在哪個層次上進行測試？

l? 黑盒測試的具體技術方法 ：

①邊界值分析法 ②等價類劃分法 ③因果圖法 ④決策表法

2、白盒測試

l? 白盒測試將被測程序看作一個打開的盒子，測試者能夠看到被測源程序，可以分析被測程序的內部結構，此時測試的焦點集中在根據其內部結構設計測試用例。

l? 白盒測試要求是對某些程序的結構特性做到一定程度的覆蓋，或者說這種測試是“基于覆蓋率的測試”。

l? 通常的程序結構覆蓋有：

①語句覆蓋 ②判定覆蓋 ③條件覆蓋 ④判定/條件覆蓋 ⑤路徑覆蓋

白盒測試需要完全了解程序結構和處理過程，它按照程序內部邏輯測試程序，檢驗程序中每條通路是否按預定要求正確工作。也被稱為程序員測試。

l? 黑盒測試：

??? ——以用戶的觀點，從輸入數據與輸出數據的對應關系，即根據程序外部特性進行測試，而不考慮內部結構及工作情況。

??? ——黑盒測試技術注重于軟件的信息域（范圍），通過劃分程序的輸入和輸出域來確定測試用例。

??? ——若外部特性本身存在問題或規格說明的規定有誤，則應用黑盒測試方法是不能發現問題的。

l? 白盒測試：

??? ——只根據程序的內部結構進行測試。

——測試用例的設計要保證測試時程序的所有語句至少執行一次，而且要檢查所有的邏輯條件。

——如果程序的結構本身有問題，比如說程序邏輯有錯誤或者有遺漏，那也是無法發現的。

項目	黑盒測試	白盒測試
規劃方面	功能的測試	結構的測試
有點方面	能確保從用戶的角度出發進行測試	能對程序內部的特定部位進行覆蓋測試
缺點方面	無法測試程序內部特定部位；當規格說明有誤，則不能發現問題	無法檢查程序的外部特性； 無法對未實現規格說明的程序內部欠缺部分進行測試
應用范圍	邊界分析法 等價類劃分法 決策表測試	語句覆蓋，判定覆蓋，條件覆蓋， 判定/條件覆蓋，路徑覆蓋，循環覆蓋， 模塊接口測試

2.2.3? 軟件測試過程

軟件測試的過程流程

l? 單元測試：針對每個單元的測試， 以確保每個模塊能正常工作為目標。

l? 集成測試：對已測試過的模塊進行組裝，進行集成測試。目的在于檢驗與軟件設計相關的程序結構問題。

l? 確認（有效性）測試：是檢驗所開發的軟件能否滿足所有功能和性能需求的最后手段。

l? 系統測試：檢驗軟件產品能否與系統的其他部分（比如，硬件、數據庫及操作人員）協調工作。

l? 驗收（用戶）測試：檢驗軟件產品質量的最后一道工序。主要突出用戶的作用，同時軟件開發人員也應有一定程度的參與。

2.3? 單元測試

l? 單元測試針對每個程序的模塊，主要測試5個方面的問題：

??? ——模塊接口、局部數據結構、邊界條件、獨立的路徑和錯誤處理。

模塊接口

l? 這是對模塊接口進行的測試，檢查進出程序單元的數據流是否正確。模塊接口測試必須在任何其它測試之前進行。

l? 模塊接口測試至少需要如下的測試項目：

（1）調用所測模塊時的輸入參數與模塊的形式參數在個數、屬性、順序上是否匹配；

（2）所測模塊調用子模塊時，它輸入給子模塊的參數與子模塊中的形式參數在個數、屬性、順序上是否匹配；

（3）是否修改了只做輸入用的形式參數；

（4）調用標準函數的參數在個數、屬性、順序上是否正確；

（5）全局變量的定義在各模塊中是否一致。

局部數據結構

l? 在模塊工作過程中，必須測試模塊內部的數據能否保持完整性，包括內部數據的內容、形式及相互關系不發生錯誤。

l? 對于局部數據結構，應該在單元測試中注意發現以下幾類錯誤：

（1）不正確的或不一致的類型說明。

（2）錯誤的初始化或默認值。

（3）錯誤的變量名，如拼寫錯誤或書寫錯誤。

（4）下溢、上溢或者地址錯誤。

路徑測試

l? 在單元測試中，最主要的測試是針對路徑的測試。測試用例必須能夠發現由于計算錯誤、不正確的判定或不正常的控制流而產生的錯誤。

l? 常見的錯誤有：

??? 誤解的或不正確的算術優先級；混合模式的運算；錯誤的初始化；精確度不夠精確；表達式的不正確符號表示。

l? 針對判定和條件覆蓋，測試用例還要能夠發現如下錯誤：

??? 不同數據類型的比較；不正確的邏輯操作或優先級；應當相等的地方由于精確度的錯誤而不能相等；不正確的判定或不正確的變量；不正確的或不存在的循環終止；當遇到分支循環時不能退出；不適當地修改循環變量。

邊界條件

l? 邊界測試是單元測試的最后一步，必須采用邊界值分析方法來設計測試用例，認真仔細地測試為限制數據處理而設置的邊界處，看模塊是否能夠正常工作。

l? 一些可能與邊界有關的數據類型如數值、字符、位置、數量、尺寸等，還要注意這些邊界的首個、最后一個、最大值、最小值、最長、最短、最高、最低等特征。

l? 在邊界條件測試中，應設計測試用例檢查以下情況：

（1）在n次循環的第0次、1次、n次是否有錯誤。

（2）運算或判斷中取最大值、最小值時是否有錯誤。

（3）數據流、控制流中剛好等于、大于、小于確定的比較值是否出現錯誤。

出錯處理

l? 測試出錯處理的重點是模塊在工作中發生了錯誤，其中的出錯處理設施是否有效。

l? 檢驗程序中的出錯處理可能面對的情況有：

（1）對運行發生的錯誤描述難以理解。

（2）所報告的錯誤與實際遇到的錯誤不一致。

（3）出錯后，在錯誤處理之前就引起系統的干預。

（4）例外條件的處理不正確。

（5）提供的錯誤信息不足，以至于無法找到錯誤的原因。

2.3.2? 單元測試的執行過程

l? 何時進行單元測試？單元測試常常是和代碼編寫工作同時進行的，在完成了程序編寫、復查和語法正確性驗證后，就應進行單元測試用例設計。

l? 在單元測試時，如果模塊不是獨立的程序，需要設置一些輔助測試模塊。輔助測試模塊有兩種：

（1）驅動模塊(Drive)? 用來模擬被測試模塊的上一級模塊，相當于被測模塊的主程序。它接收數據，將相關數據傳送給被測模塊，啟動被測模塊，并打印出相應的結果。

（2）樁模塊(Stub)? 用來模擬被測模塊工作過程中所調用的模塊。它們一般只進行很少的數據處理。

l? 驅動模塊和樁模塊都是額外的開銷，雖然在單元測試中必須編寫，但并不需要作為最終的產品提供給用戶。

l? 被測模塊、驅動模塊和樁模塊共同構成了一個如下圖所示的單元測試的測試環境：

2.4? 集成測試

2.4.1? 非增量式測試

l? 實例? 采用非增量式測試方法進行集成測試

l? 非增量式測試是采用一步到位的方法來構造測試：??

——對所有模塊進行個別的單元測試后，按照程序結構圖將各模塊連接起來，把連接后的程序當作一個整體進行測試。

l? 采用非增量式測試方法進行集成測試

l? 非增量式測試的缺點：

——當一次集成的模塊較多時，非增量式測試容易出現混亂，因為測試時可能發現了許多故障，為每一個故障定位和糾正非常困難，并且在修正一個故障的同時，可能又引入了新的故障，新舊故障混雜，很難判定出錯的具體原因和位置。

2.4.2? 增量式測試

l? 增量式測試的集成是逐步實現的：

??? ——逐次將未曾集成測試的模塊和已經集成測試的模塊（或子系統）結合成程序包，再將這些模塊集成為較大系統，在集成的過程中邊連接邊測試，以發現連接過程中產生的問題。

l? 按照不同的實施次序，增量式集成測試又可以分為三種不同的方法：

?? （1）自頂向下增量式測試

?? （2）自底向上增量式測試

?? （3）混合增量式測試

自頂向下增量式測試

l? 自頂向下增量式測試表示逐步集成和逐步測試是按照結構圖自上而下進行的，即模塊集成的順序是首先集成主控模塊（主程序），然后依照控制層次結構向下進行集成。從屬于主控模塊的按深度優先方式（縱向）或者廣度優先方式（橫向）集成到結構中去。

l? 深度優先方式的集成：

??? ——首先集成在結構中的一個主控路徑下的所有模塊，主控路徑的選擇是任意的。

l? 廣度優先方式的集成：

??? ——首先沿著水平方向，把每一層中所有直接隸屬于上一層的模塊集成起來，直到底層。

集成測試的整個過程由3個步驟完成：

? （1）主控模塊作為測試驅動器。

? （2）根據集成的方式（深度或廣度），下層的樁模塊一次一次地被替換為真正的模塊。

? （3）在每個模塊被集成時，都必須進行單元測試。重復第2步，直到整個系統被測試完成。

l 實例 按照廣度優先方式進行集成測試

l 實例 按照深度優先方式進行集成測試

自底向上增量式測試

l? 自底向上增量式測試表示逐步集成和逐步測試的工作是按結構圖自下而上進行的，即從程序模塊結構的最底層模塊開始集成和測試。

l? 由于是從最底層開始集成，對于一個給定層次的模塊，它的子模塊（包括子模塊的所有下屬模塊）已經集成并測試完成，所以不再需要使用樁模塊進行輔助測試。在模塊的測試過程中需要從子模塊得到的信息可以直接運行子模塊得到。

l? 實例 采用自底向上增量式測試方法進行集成測試

混合增量式測試

l? 混合增量式測試是把自頂向下測試和自底向上測試這兩種方式結合起來進行集成和測試。這樣可以兼具兩者的優點，而摒棄其缺點。

l? 常見的兩種混合增量式測試方式：

（1）衍變的自頂向下的增量式測試：基本思想是強化對輸入/輸出模塊和引入新算法模塊的測試，并自底向上集成為功能相對完整且相對獨立的子系統，然后由主模塊開始自頂向下進行增量式測試。

（2）自底向上-自頂向下的增量式測試：首先對含讀操作的子系統自底向上直至根節點模塊進行集成和測試，然后對含寫操作的子系統做自頂向下的集成與測試。

2.4.3? 不同集成測試方法的比較

1、非增量式測試與增量式測試的比較

l? 非增量式測試的方法是先分散測試，然后集中起來再一次完成集成測試。假如在模塊的接口處存在錯誤，只會在最后的集成測試時一下子暴露出來。

l? 增量式測試是逐步集成和逐步測試的方法，把可能出現的差錯分散暴露出來，便于找出問題和修改。而且一些模塊在逐步集成的測試中，得到了較多次的考驗，因此，可能會取得較好的測試效果。

結論：增量式測試要比非增量式測試具有一定的優越性。

2、自頂向下與自底向上增量式測試的比較

l? 自頂向下增量式測試：

——主要優點在于它可以自然的做到逐步求精，一開始就能讓測試者看到系統的框架。

——主要缺點是需要提供樁模塊，并且在輸入/輸出模塊接入系統以前，在樁模塊中表示測試數據有一定困難。

l? 自底向上增量式測試：

——優點在于，由于驅動模塊模擬了所有調用參數，即使數據流并未構成有向的非環狀圖，生成測試數據也無困難。

——主要缺點在于，直到最后一個模塊被加進去之后才能看到整個程序（系統）的框架。

2.4.4? 回歸測試

l? 什么是回歸測試？

——在集成測試策略的環境中，回歸測試是對某些已經進行過的測試的某些子集再重新進行一遍，以保證上述改變不會傳播無法預料的副作用或引發新的問題。

——在更廣的環境里，回歸測試就是用來保證（由于測試或其他原因的）改動不會帶來不可預料的行為或另外的錯誤。

l? 回歸測試可以通過重新執行所有的測試用例的一個子集人工地進行，也可以使用自動化的捕獲回放工具來進行。

l? 回歸測試集包括三種不同類型的測試用例：

?（1）能夠測試軟件的所有功能的代表性測試用例

?（2）專門針對可能會被修改而影響軟件功能的附加測試

?（3）針對修改過的軟件成分的測試

2.5? 確認測試

1、確認測試的準則

l? 確認測試也稱為合格性測試，是檢驗所開發的軟件是否能按用戶提出的要求進行。軟件確認要通過一系列證明軟件功能和要求一致的黑盒測試來完成。

l? 經過確認測試，應該為已開發的軟件給出結論性評價：

（1）經過檢驗的軟件的功能、性能及其他要求均已滿足需求規格說明書的規定，則可被認為是合格的軟件。

（2）經過檢驗發現與需求說明書有相當的偏離，得到一個各項缺陷清單。

2、配置審查的內容

l? 確認測試過程的重要環節就是配置審查工作。其目的在于確保已開發軟件的所有文件資料均已編寫齊全，并得到分類編目，足以支持運行以后的軟件維護工作。

l? 配置審查的文件資料包括用戶所需的以下資料：

?? （1）用戶手冊

?? （2）操作手冊

?? （3）設計資料——如：設計說明書、源程序以及測試資料（測試說明書、測試報告）等

2.6? 系統測試

l? 為什么要進行系統測試？

??? ——由于軟件只是計算機系統中的一個組成部分，軟件開發完成之后，最終還要和系統中的硬件系統、某些支持軟件、數據信息等其他部分配套運行。因此，在投入運行前要完成系統測試，以保證各組成部分不僅能單獨的得到檢驗，而且在系統各部分協調工作的環境下也能正常工作。

l? 盡管每一個檢驗有特定的目標，然而所有的檢測工作都要驗證系統中每個部分均已得到正確的集成，并能完成指定的功能。

l? 嚴格的說，系統測試超出了軟件工程范圍。通常這項工作并不由系統開發人員或系統開發組織來承擔，而是由軟件用戶或軟件開發機構委托獨立測試機構來完成。

恢復測試

l? 恢復測試是通過各種手段，強制性地使軟件出錯，使其不能正常工作，進而檢驗系統的恢復能力。

l? 恢復測試包含的內容：

??? ——如果系統恢復是自動的（由系統自身完成），則應該檢驗：重新初始化、檢驗點設置機構、數據恢復以及重新啟動是否正確。

??? ——如果這一恢復需要人為干預，則應考慮平均修復時間是否在限定的、可以接受的范圍之內。

安全測試

l? 安全測試的目的在于驗證安裝在系統內的保護機制能否在實際中保護系統且不受非法入侵，不受各種非法干擾。

l? 在安全測試中，測試者扮演著試圖攻擊系統的個人角色：

?? — 嘗試去通過外部的手段來獲取系統的密碼

?? — 使用可以瓦解任何防守的客戶軟件來攻擊系統

?? — 把系統“癱瘓”，使得其他用戶無法訪問

?? — 有目的地引發系統錯誤，期望在恢復過程中侵入系統

?? — 通過瀏覽非保密的數據，從中找到進入系統的鑰匙

l? 系統的安全測試要設置一些測試用例試圖突破系統的安全保密措施，檢驗系統是否有安全保密的漏洞。

強度測試

l? 從本質上來說，強度測試（也稱壓力測試-Stree Testing）的目的是要檢測非正常的情形，測試是想要破壞程序。

??? 強度測試需要在反常規數據量、頻率或資源的方式下運行系統，以檢驗系統能力的最高實際限度。

l? 舉例：

??? — 如果正常的中斷頻率為每秒5次，強度測試設計為每秒50次中斷。

??? — 把輸入數據的量提高一個數量級來測試輸入功能會如何響應。

??? — 若某系統正常運行可支持200個終端并行工作，強度測試則檢驗1000個終端并行工作的情況。

??? — 運行大量的消耗內存或其他系統資源的測試實例。

性能測試

l? 性能測試用來測試軟件在系統集成中的運行性能，特別是針對實時系統和嵌入式系統，僅提供符合功能需求但不符合性能需求的軟件是不能被接受的。

l? 性能測試可以在測試過程的任意階段進行，但只有當整個系統的所有成分都集成在一起后，才能檢查一個系統的真正性能。

l? 性能測試常常和強度（壓力）測試結合起來進行，而且常常需要硬件和軟件測試設備，這就是說，常常有必要在一種苛刻的環境中衡量資源的使用（比如，處理器周期）。

正確性測試

l? 正確性測試檢查軟件的功能是否符合規格說明。

l? 正確性測試的方法：

?? ——枚舉法，即構造一些合理輸入，檢查是否得到期望的輸出。測試時應盡量設法減少枚舉的次數，關鍵在于尋找等價區間，因為在等價區間中，只需用任意值測試一次即可。

???? ——邊界值測試，即采用定義域或者等價區間的邊界值進行測試。因為程序設計容易疏忽邊界情況，程序也容易在邊界值處出錯。

可靠性測試

l? 可靠性測試是從驗證的角度出發，檢驗系統的可靠性是否達到預期的目標，同時給出當前系統可能的可靠性增長情況。

l? 對可靠性性測試來說，最關鍵的測試數據包括失效間隔時間，失效修復時間，失效數量，失效級別等。根據獲得的測試數據，應用可靠性模型，可以得到系統的失效率及可靠性增長趨勢。

l? 可靠性指標有時很難測試，通常采用平均無故障時間或系統投入運行后出現的故障不能大于多少數量這些指標來對可靠性進行評估。

兼容性測試

l? 軟件兼容性測試是檢測各軟件之間能否正確地交互和共享信息，其目標是保證軟件按照用戶期望的方式進行交互，使用其它軟件檢查軟件操作的過程。

l? 兼容性的測試通常需要解決以下問題：

? （1）新開發的軟件需要與哪種操作系統、Web瀏覽器和應用軟件保持兼容，如果要測試的軟件是一個平臺，那么要求應用程序能在其上運行。

? （2）應該遵守哪種定義軟件之間交互的標準或者規范。

? （3）軟件使用何種數據與其它平臺、與新的軟件進行交互和共享信息。

2.7? 驗收測試

2.7.1? 驗收測試的內容

l? 軟件驗收測試應完成的工作內容包括：

（1）明確驗收項目，規定驗收測試通過的標準。

（2）確定測試方法。

（3）決定驗收測試的組織機構和可利用的資源。

（4）選定測試結果分析方法。

（5）指定驗收測試計劃并進行評審。

（6）設計驗收測試所用的測試用例。

（7）審查驗收測試準備工作。

（8）執行驗收測試。

（9）分析測試結果。

（10）做出驗收結論，明確通過驗收或不通過驗收。

在驗收測試計劃當中，可能包括的檢驗方面有以下幾種：

l? 功能測試。如完整的工資計算過程。

l? 逆向測試。如檢驗不符合要求數據而引起出錯的恢復能力。

l? 特殊情況。如極限測試、不存在的路徑測試。

l? 文檔檢查。

l? 強度檢查。如大批量的數據或者最大用戶并發使用。

l? 恢復測試。如硬件故障或用戶不良數據引起的一些情況。

l? 可維護性的評價。

l? 用戶操作測試。如啟動、退出系統等。

l? 用戶友好性檢驗。

l? 安全測試。

2.7.2? 軟件配置和文檔資料測試

l? 對文檔的測試包括以下內容：

? （1）檢查產品說明書屬性?

? （2）檢查是否完整?

? （3）檢查是否準確?

? （4）檢查是否精確

? （5）檢查是否一致

? （6）檢查是否貼切

? （7）檢查是否合理?

? （8）檢查代碼無關?

? （9）檢查可測試性

2.8? 測試后的調試

l? 軟件調試和軟件測試有完全不同的含義：

???? ——測試的目的是顯示存在錯誤。

???? ——調試的目的是發現錯誤或導致程序失效的錯誤原因，并修改程序以修正錯誤。

l? 通常情況是在測試以后緊接著要進行調試，調試是在測試發現錯誤后消除錯誤的過程。實際上這兩項工作是交叉進行的。

2.9? 面向對象的軟件測試

1、面向對象的軟件測試

l? 面向對象軟件測試的目標與傳統測試一樣，即用盡可能低的測試成本和盡可能少的測試用例，發現盡可能多的軟件缺陷。面向對象的測試策略也遵循從“小型測試”到“大型測試”，即從單元測試到最終的功能性測試和系統性測試。

l? 但面向對象技術所獨有的封裝、繼承、多態等新特點給測試帶來一系列新的問題，增加了測試的難度。與傳統的面向過程程序設計相比，面向對象程序設計產生錯誤的可能性增大，或者使得傳統軟件測試中的重點不再那么突出，或者使得原來測試經驗和實踐證明的次要方面成為了主要問題。

2、面向對象的單元測試

l? 與傳統的單元不同，面向對象軟件測試中的單元是封裝的類和對象。每個類和類的實例（對象）包含了屬性和操作這些屬性的方法。

l? 類包含一組不同的操作，并且某個或某些特殊操作可能作為一組不同的類的一部分而存在，測試時不再測試單個孤立的操作，而是測試操作類及類的一部分，單元測試的意義發生了較大的變化。

l? 對面向對象軟件的類測試等價于對面向過程軟件的單元測試。傳統的單元測試主要關注模塊的算法和模塊接口間數據的流動，即輸入和輸出；而面向對象軟件的類測試主要是測試封裝在類中的操作以及類的狀態行為。

3、面向對象的集成測試

l? 面向對象的集成測試通常需要進行兩級集成：

? （1）將成員函數集成到完整類中；

? （2）將類與其它類集成。

l? 對面向對象的集成測試有兩種不同的策略：

? （1）基于線程的測試。集成針對回應系統的一個輸入或事件所需的一組類，每個線程被集成并分別進行測試。

? （2）基于使用的測試。首先測試獨立的類，并開始構造系統，然后測試下一層的依賴類（使用獨立類的類），通過依賴類層次的測試序列逐步構造完整的系統。

4、面向對象的確認測試

l? 與傳統的確認測試一樣，面向對象軟件的有效性集中在用戶可見的動作（事件驅動與過程）和用戶可識別的系統輸出（結果），通過測試檢驗軟件是否滿足用戶的需求。

l? 在面向對象的確認測試中，通常采用傳統的黑盒測試方法，以證明軟件功能和需求的一致性。

第3章? 黑盒測試及其用例的設計

3.1? 測試用例設計概述

3.1.1? 測試用例的定義和特征

l? 測試用例的定義：

（1）測試用例是為特定的目的而設計的一組測試輸入、? 執行條件和預期的結果。

（2）測試用例是執行的最小實體。

l? 測試用例的特征：

（1）最有可能抓住錯誤的；

（2）不是重復的、多余的；

（3）一組相似測試用例中最有效的；

（4）既不是太簡單，也不是太復雜。

3.1.2? 設計測試用例的基本準則

l? 測試用例的代表性

能夠代表并覆蓋各種合理的和不合理的、合法的和非法的、邊界的和越界的以及極限的輸入數據、操作和環境設置等。

l? 測試結果的可判定性

即測試執行結果的正確性是可判定的，每一個測試用例都應有相應的期望結果。

l? 測試結果的可再現性

即對同樣的測試用例，系統的執行結果應當是相同的。

3.1.3? 設計測試用例的著眼點

l? 根據產品規格，測試基本功能；

l? 考慮設計一般用戶（非專業人員）的使用方案；

l? 考慮設計稀有或特殊的使用方案；

l? 與系統其他組成部分的配合（如FAX和上網可能要用到MODEM，測試中考慮對設備的共享）；

l? 考慮特殊情況（如內存和硬件的沖突等）；

l? 設計極端情況（如內存泄漏、破壞性測試等）；

l? 好的測試用例集能花費最小的代價（人力、物力、財力、時間）做最好的測試。

3.1.4? 測試用例設計書寫標準

在ANSI/IEEE829-1983標準中列出了和測試設計相關的測試用例編寫規范和模板。標準模板中主要元素如下：

l? 標識符——惟一標識每一個測試用例

l? 測試項——準確的描述所需要測試的項及其特征

l? 測試環境要求——表征執行該測試用例需要的測試環境

l? 輸入標準——執行測試用例的輸入需求（這些輸入可能包括數據、文件或者操作）

l? 輸出標準——按照指定的環境和輸入標準得到的期望輸出結果

l? 測試用例之間的關聯——標識該測試用例與其它的測試（或其它測試用例）之間的依賴關系

3.2? 黑盒測試法的概念

l? 黑盒測試被稱為功能測試或數據驅動測試。在測試時，把被測程序視為一個不能打開的黑盒子，在完全不考慮程序內部結構和內部特性的情況下進行。

l? 采用黑盒測試的目的主要是在已知軟件產品所應具有的功能的基礎上，進行：

（1）檢查程序功能能否按需求規格說明書的規定正常使用，測試各個功能是否有遺漏，檢測性能等特性要求是否滿足。

（2）檢測人機交互是否錯誤，檢測數據結構或外部數據庫訪問是否錯誤，程序是否能適當地接收輸入數據而產生正確的輸出結果，并保持外部信息（如數據庫或文件）的完整性。

（3）檢測程序初始化和終止方面的錯誤。

3.3? 三角形問題與NextDate函數

1、三角形問題

輸入三個整數a、b、c，分別作為三角形的三條邊，現通過程序判斷由三條邊構成的三角形的類型為等邊三角形、等腰三角形、一般三角形（特殊的還有直角三角形），以及構不成三角形。

現在要求輸入三個整數a、b、c，必須滿足以下條件：

條件1?? 1≤a≤100??????? 條件4?? a<b+ c

條件2?? 1≤b≤100??????? 條件5?? b<a+ c

條件3?? 1≤c≤100??????? 條件6?? c<a+ b

l? 如果輸入值a、b、c不滿足條件1、條件2和條件3 ，程序給出“邊的取值超出允許范圍”的信息。

l? 如果輸入值a、b、c 滿足條件1、條件2和條件3，則輸出下列四種情況之一：

（1）如果不滿足條件4、條件5和條件6中的一個，則程序輸出為“非三角形”。

（2）如果三條邊相等，則程序輸出為“等邊三角形”。

（3）如果恰好有兩條邊相等，則程序輸出為“等腰三角形”。

（4）如果三條邊都不相等，則程序輸出為“一般三角形”。

l? 結論：三角形問題的復雜之處在于輸入與輸出之間的關系比較復雜。

2、NextDate函數

NextDate函數說明另一種復雜的關系，即輸入變量之間邏輯關系的復雜性。

NextDate函數包含三個變量month、day和year，函數的輸出為輸入日期后一天的日期。 要求輸入變量month、day和year均為整數值，并且滿足下列條件：

條件1? 1≤ month≤12

條件2? 1≤ day ≤31

條件3? 1912≤ year≤2050

l? 結論：在NextDate函數中有兩種復雜性的輸入來源，一是輸入域的復雜性，二是確定閏年的規則并要增加“額外天”。

3.4? 等價類劃分法

l? 等價類劃分法是一種重要的、常用的黑盒測試方法，它將不能窮舉的測試過程進行合理分類，從而保證設計出來的測試用例具有完整性和代表性。

l? 舉例：設計這樣的測試用例，來實現一個對所有實數進行開平方運算（ y =sqrt(x) ）的程序的測試。

l? 思考方向：由于開平方運算只對非負實數有效，這時需要將所有的實數（輸入域x）進行劃分，可以分成：正實數、0 和 負實數。假設我們選定+1.4444代表正實數，-2.345代表負實數，則為該程序設計的測試用例的輸入為+1.4444、 0 和 -2.345。

l? 等價類劃分法是把所有可能的輸入數據，即程序的輸入域劃分為若干部分（子集），然后從每一個子集中選取少數具有代表性的數據作為測試用例。

l? 所謂等價類是指某個輸入域的子集合。在該子集合中，各個輸入數據對于揭露程序中的錯誤都是等效的，它們具有等價特性，即每一類的代表性數據在測試中的作用都等價于這一類中的其它數據。這樣，對于表征該類的數據輸入將能代表整個子集合的輸入。因此，可以合理的假定：——測試某等價類的代表值就是等效于對于這一類其它值的測試。

3.4.1? 等價類的劃分原則

l? 等價類是輸入域的某個子集合，而所有等價類的并集就是整個輸入域。因此，等價類對于測試有兩個重要的意義：

?? 完備性——整個輸入域提供一種形式的完備性

?? 無冗余性——若互不相交則可保證一種形式的無冗余性

l? 如何劃分？——先從程序的規格說明書中找出各個輸入條件，再為每個輸入條件劃分兩個或多個等價類，形成若干的互不相交的子集。

l? 采用等價類劃分法設計測試用例通常分兩步進行：

（1）確定等價類，列出等價類表。

（2）確定測試用例。

l? 劃分等價類可分為兩種情況：

（1）有效等價類

是指對軟件規格說明而言，是有意義的、合理的輸入數據所組成的集合。利用有效等價類，能夠檢驗程序是否實現了規格說明中預先規定的功能和性能。

（2）無效等價類

是指對軟件規格說明而言，是無意義的、不合理的輸入數據所構成的集合。利用無效等價類，可以鑒別程序異常處理的情況，檢查被測對象的功能和性能的實現是否有不符合規格說明要求的地方。

l? 進行等價類劃分的依據：

（1）按照區間劃分——在輸入條件規定了取值范圍或值的個數的情況下，可以確定一個有效等價類和兩個無效等價類。

例：程序輸入條件為小于100大于10的整數x，則有效等價類為10＜x＜100，兩個無效等價類為x≤10和x≥100。

（2）按照數值劃分——在規定了一組輸入數據（假設包括n個輸入值），并且程序要對每一個輸入值分別進行處理的情況下，可確定n個有效等價類（每個值確定一個有效等價類）和一個無效等價類（所有不允許的輸入值的集合）。

例：程序輸入x取值于一個固定的枚舉類型{1,3,7,15}，且程序 中對這4個數值分別進行了處理，則有效等價類為x=1、x=3、x=7、x=15，無效等價類為x≠1,3,7,15的值的集合。

（3）按照數值集合劃分——在輸入條件規定了輸入值的集合或規定了“必須如何”的條件下，可以確定一個有效等價類和一個無效等價類（該集合有效值之外）。

例：程序輸入條件為取值為奇數的整數x，則有效等價類為x的值為奇數的整數，無效等價類為x的值不為奇數的整數。

（4）按照限制條件或規則劃分——在規定了輸入數據必須遵守的規則或限制條件的情況下，可確定一個有效等價類（符合規則）和若干個無效等價類（從不同角度違反規則）。

例：程序輸入條件為以字符‘a’開頭、長度為8的字符串，并且字符串不包含‘a’~ ‘z’之外的其它字符，則有效等價類為滿足了上述所有條件的字符串，無效等價類為不以‘a’開頭的字符串、長度不為8的字符串和包含了‘a’~ ‘z’之外其它字符的字符串。

（5）細分等價類——在確知已劃分的等價類中各元素在程序中的處理方式不同的情況下，則應再將該等價類進一步劃分為更小的等價類，并建立等價類表。

3.4.2? 等價類劃分法的測試用例設計

l? 在設計測試用例時，應同時考慮有效等價類和無效等價類測試用例的設計。

l? 根據已列出的等價類表可確定測試用例，具體過程如下：

（1）首先為等價類表中的每一個等價類分別規定一個唯一的編號。

（2）設計一個新的測試用例，使它能夠盡量覆蓋尚未覆蓋的有效等價類。重復這個步驟，直到所有的有效等價類均被測試用例所覆蓋。

（3）設計一個新的測試用例，使它僅覆蓋一個尚未覆蓋的無效等價類。重復這一步驟，直到所有的無效等價類均被測試用例所覆蓋。

3.4.3? 常見等價類劃分測試形式

l? 針對是否對無效數據進行測試，可以將等價類測試分為 標準等價類測試和健壯等價類測試。

?? 標準等價類測試——不考慮無效數據值，測試用例使用 每個等價類中的一個值。

?? 健壯等價類測試——主要的出發點是考慮了無效等價類。對有效輸入，測試用例從每個有效等價類中取一個值； 對無效輸入，一個測試用例有一個無效值，其他值均取 有效值。

健壯等價類測試存在兩個問題：

（1）需要花費精力定義無效測試用例的期望輸出

（2）對強類型的語言沒有必要考慮無效的輸入

3.4.4? 使用等價類劃分法測試的實例

實例1? 三角形問題

分析：

在多數情況下，是從輸入域劃分等價類的，但并非不能從被測程序的輸出域反過來定義等價類，事實上，這對于三角形問題卻是最簡單的劃分方法。 在三角形問題中，有四種可能的輸出：等邊三角形、等腰三角形、一般三角形和非三角形。利用這些信息能夠確定下列輸出（值域）等價類。

R1 = { <a,b,c>: 邊為a,b,c的等邊三角形 }

R2 = { <a,b,c>: 邊為a,b,c的等腰三角形 }

R3 = { <a,b,c>: 邊為a,b,c的一般三角形 }

R4 = { <a,b,c>: 邊為a,b,c不能組成三角形 }

三角形問題的4個標準等價類測試用例

測試用例	a	b	c	預期輸出
Test1	10	10	10	等邊三角形
Test2	10	10	5	等腰三角形
Test3	3	4	5	一般三角形
Test4	4	1	2	非三角形

三角形問題的7個健壯等價類測試用例

測試用例	a	b	c	預期輸出
Test1	5	6	7	一般三角形
Test2	-1	5	5	a值超出輸入值定義域
Test3	5	-1	5	b值超出輸入值定義域
Test4	5	5	-1	c值超出輸入值定義域
Test5	101	5	5	a值超出輸入值定義域
Test6	5	101	5	b值超出輸入值定義域
Test7	5	5	101	c值超出輸入值定義域

實例2? 保險公司計算保費費率的程序

某保險公司的人壽保險的保費計算方式為：投保額×保險費率

其中，保險費率依點數不同而有別，10點及10點以上保險費率為0.6%，10點以下保險費率為0.1%；而點數又是由投保人的年齡、性別、婚姻狀況和撫養人數來決定，具體規則如下：

年齡			性別		婚姻		撫養人數
20~39	40~59	其它	M	F	已婚	未婚	1人扣0.5點，最多扣3點 （四舍五入取整）
6點	4點	2點	5點	3點	3點	5點

計算保費費率的程序

（1）分析程序規格說明中給出和隱含的對輸入條件的要求，列出等價類表（包括有效等價類和無效等價類）。

l? 年齡：一位或兩位非零整數，值的有效范圍為1~99

l? 性別：一位英文字符，只能取值‘M’或’F’

l? 婚姻：字符，只能取值‘已婚’或‘未婚’

l? 撫養人數：空白或一位非零整數（1~9）

l? 點數 ：一位或兩位非零整數，值的范圍為1~99

輸入條件	有效等價類	編號	無效等價類	編號
年齡	20~39歲	1	?	?
	40~59歲	2	?	?
	1~19歲 60~99歲	3	小于1	12
			大于99	13
性別	單個英文字符	4	非英文字符	14
			非單個英文字符	15
	M	5	除‘M’和‘F’之外的其它單個字符	16
	F	6
婚姻	已婚	7	除‘已婚’和‘未婚’之外的其它字符	17
	未婚	8
撫養人數	空白	9	除空白和數字之外的其它字符	18
	1~6人	10	小于1	19
	6~9人	11	大于9	20

（2）根據（1）中的等價類表，設計能覆蓋所有等價類的測試用例。

測試用例編號	輸入數據				預期輸出
	年齡	性別	婚姻	撫養人數	保險費率
1	27	F	未婚	空白	0.6%
2	50	M	已婚	2	0.6%
3	70	F	已婚	7	0.1%
4	0	M	未婚	空白	無法推算
5	100	F	已婚	3	無法推算
6	99	男	已婚	4	無法推算
7	1	Child	未婚	空白	無法推算
8	45	N	已婚	5	無法推算
9	38	F	離婚	1	無法推算
10	62	M	已婚	沒有	無法推算
11	18	F	未婚	0	無法推算
12	40	M	未婚	10	無法推算

3.5? 邊界值分析法

3.5.1? 邊界值分析法概要

l? 邊界值分析法就是對輸入或輸出的邊界值進行測試的一種黑盒測試方法。通常邊界值分析法是作為對等價類劃分法的補充，這種情況下，其測試用例來自等價類的邊界。

l? 為什么使用邊界值分析法？

無數的測試實踐表明，大量的故障往往發生在輸入定義域或輸出值域的邊界上，而不是在其內部。因此，針對各種邊界情況設計測試用例，通常會取得很好的測試效果。

l? 怎樣用邊界值分析法設計測試用例？

（1）首先確定邊界情況。通常輸入或輸出等價類的邊界就是應該著重測試的邊界情況。

（2）選取正好等于、剛剛大于或剛剛小于邊界的值作為測試數據，而不是選取等價類中的典型值或任意值。

邊界值分析

l? 邊界值分析使用與等價類劃分法相同的劃分，只是邊界值分析假定錯誤更多地存在于劃分的邊界上，因此在等價類的邊界上以及兩側的情況設計測試用例。

l? 例：測試計算平方根的函數

——輸入：實數

——輸出：實數

——規格說明：當輸入一個0或比0大的數的時候，返回其正平方根；當輸入一個小于0的數時，顯示錯誤信息“平方根非法-輸入值小于0”并返回0；庫函數Print-Line可以用來輸出錯誤信息。

實例分析

l? 等價類劃分：

-????可以考慮作出如下劃分：

ü? 輸入 (i)<0 和 (ii)>=0

ü? 輸出 (a)>=0 和 (b) Error

-????測試用例有兩個：

ü? 輸入4，輸出2。對應于 (ii) 和 (a) 。

ü? 輸入-10，輸出0和錯誤提示。對應于(i)和(b)

l? 邊界值分析：

-????劃分(ii)的邊界為0和最大正實數；劃分(i)的邊界為最小負實數和0。由此得到以下測試用例：

ü? 輸入 {最小負實數}

ü? 輸入 {絕對值很小的負數}

ü? 輸入 0

ü? 輸入 {絕對值很小的正數}

ü? 輸入 {最大正實數}

l? 通常情況下，軟件測試所包含的邊界檢驗有幾種類型：

數字、字符、位置、質量、大小、速度、方位、尺寸、空間等

l? 相應地，以上類型的邊界值應該在：

最大/最小、首位/末位、上/下、最快/最慢、最高/最低、最短/最長、空/滿等情況下

選擇測試用例的原則

（1）如果輸入條件規定了值的范圍，則應取剛達到這個范圍的邊界值以及剛剛超過這個范圍邊界的值作為測試輸入數據。

（2）如果輸入條件規定了值的個數，則用最大個數、最小個數和比最大個數多1個、比最小個數少1個的數作為測試數據。

（3）根據程序規格說明的每個輸出條件，使用原則 (1)。

（4）根據程序規格說明的每個輸出條件，使用原則 (2) 。

（5）如果程序的規格說明給出的輸入域或輸出域是有序集合（如有序表、順序文件等），則應選取集合中的第一個和最后一個元素作為測試用例。

（6）如果程序中使用了一個內部數據結構，則應當選擇這個內部數據結構的邊界上的值作為測試用例。

（7）分析程序規格說明，找出其它可能的邊界條件。

3.5.2? 邊界值分析法測試用例

l? 采用邊界值分析測試的基本思想是：故障往往出現在輸入變量的邊界值附近。

——因此，邊界值分析法利用輸入變量的最小值(min)、略大于最小值(min+)、輸入值域內的任意值(nom)、略小于最大值(max-)和最大值(max)來設計測試用例。

l? 邊界值分析法是基于可靠性理論中稱為“單故障”的假設，即有兩個或兩個以上故障同時出現而導致軟件失效的情況很少，也就是說，軟件失效基本上是由單故障引起的。

——因此，在邊界值分析法中獲取測試用例的方法是：

(1) 每次保留程序中一個變量，讓其余的變量取正常值，被保留的變量依次取min、min+、nom、max-和max。

(2) 對程序中的每個變量重復 (1) 。

例：有二元函數f(x,y)，其中x∈[1,12]，y∈[1,31]。則采用邊界值分析法設計的測試用例是：

{ <1,15>, <2,15>, <11,15>,<12,15>, <6,15>, <6,1>, <6,2>, <6,30>, <6,31>}

?? 推論：對于一個含有n個變量的程序，采用邊界值分析法測試程序會產生4n+1個測試用例。

健壯性測試

l? 健壯性測試是作為邊界值分析的一個簡單的擴充，它除了對變量的5個邊界值分析取值外，還需要增加一個略大于最大值(max+)以及略小于最小值(min-)的取值，檢查超過極限值時系統的情況。因此，對于有n個變量的函數采用健壯性測試需要6n+1個測試用例。

3.5.3? 邊界值分析法測試舉例

實例1? 三角形問題的邊界值分析測試用例

在三角形問題描述中，除了要求邊長是整數外，沒有給出其它的限制條件。在此，我們將三角形每邊邊長的取范圍值設值為[1, 100] 。

說明：如果程序規格說明中沒有顯式地給出邊界值，則可以在設計測試用例前先設定取值的下限值和上限值。

測試用例	a	b	c	預期輸出
Test1	60	60	1	等腰三角形
Test2	60	60	2	等腰三角形
Test3	60	60	60	等邊三角形
Test4	50	50	99	等腰三角形
Test5	50	50	100	非三角形
Test6	60	1	60	等腰三角形
Test7	60	2	60	等腰三角形
Test8	50	99	50	等腰三角形
Test9	50	100	50	非三角形
Test10	1	60	60	等腰三角形
Test11	2	60	60	等腰三角形
Test12	99	50	50	等腰三角形
Test13	100	50	50	非三角形

?

實例2? NextDate函數的邊界值分析測試用例

在NextDate函數中，隱含規定了變量mouth和變量day的取值范圍為1≤mouth≤12和1≤day≤31，并設定變量year的取值范圍為1912≤year≤2050 。

測試用例	Month	Day	Year	預期輸出
Test1	6	15	1911	1911.6.16
Test2	6	15	1912	1912.6.16
Test3	6	15	1913	1913.6.16
Test4	6	15	1975	1975.6.16
Test5	6	15	2049	2049.6.15
Test6	6	15	2050	2050.6.15
Test7	6	15	2051	2051.6.15
Test8	6	-1	2001	day超出[1…31]
Test9	6	1	2001	2001.6.1
Test10	6	2	2001	2001.6.2
Test11	6	30	2001	2001.6.30
Test12	6	31	2001	輸入日期超界
Test13	6	32	2001	day超出[1…31]
Test14	-1	15	2001	Mouth超出[1…12]
Test15	1	15	2001	20011.15
Test16	2	15	2001	2001.2.15
Test17	11	15	2001	2001.11.15
Test18	12	15	2001	2001.12.15
Test19	13	15	2001	Mouth超出[1…12]

3.6? 因果圖法

3.6.1? 因果圖法的簡介

l? 因果圖法產生的背景：

等價類劃分法和邊界值分析方法都是著重考慮輸入條件，但沒有考慮輸入條件的各種組合、輸入條件之間的相互制約關系。這樣雖然各種輸入條件可能出錯的情況已經測試到了，但多個輸入條件組合起來可能出錯的情況卻被忽視了。

如果在測試時必須考慮輸入條件的各種組合，則可能的組合數目將是天文數字，因此必須考慮采用一種適合于描述多種條件的組合、相應產生多個動作的形式來進行測試用例的設計，這就需要利用因果圖（邏輯模型）。

l? 因果圖法是基于這樣的一種思想：一些程序的功能可以用判定表（或稱決策表）的形式來表示，并根據輸入條件的組合情況規定相應的操作。

l? 因果圖法的定義：是一種利用圖解法分析輸入的各種組合情況，從而設計測試用例的方法，它適合于檢查程序輸入條件的各種組合情況。

l? 采用因果圖法設計測試用例的步驟：

（1）根據程序規格說明書描述，分析并確定因（輸入條件）和果（輸出結果或程序狀態的改變），畫出因果圖。

（2）將得到的因果圖轉換為判定表。

（3）為判定表中每一列所表示的情況設計一個測試用例。

l? 使用因果圖法的優點：

（1）考慮到了輸入情況的各種組合以及各個輸入情況之間的相互制約關系。

（2）能夠幫助測試人員按照一定的步驟，高效率的開發測試用例。

（3）因果圖法是將自然語言規格說明轉化成形式語言規格說明的一種嚴格的方法，可以指出規格說明存在的不完整性和二義性。

3.6.2? 因果圖

l? 因果圖中用來表示4種因果關系的基本符號：

l? 因果圖中的4種基本關系

在因果圖的基本符號中，圖中的左結點ci表示輸入狀態（或稱原因），右結點ei表示輸出狀態（或稱結果）。ci 與 ei 取值0或1，0表示某狀態不出現，1則表示某狀態出現。

?? 恒等：若c1是1，則e1也為1，否則e1為0。

?? 非：若c1是1，則e1為0，否則e1為1。

?? 或：若c1或c2或c3是1，則e1為1，否則為0。

?? 與：若c1和c2都是1，則e1為1，否則e1為0。

l? 因果圖中的約束

在實際問題中輸入狀態相互之間、輸出狀態相互之間可能存在某些依賴關系，稱為“約束”。對于輸入條件的約束有E、I、O、R四種約束，對于輸出條件的約束只有M約束。

?? E約束(異)：a和b中最多有一個可能為1，即a和b不能同時 為1。

?? I 約束(或)：a、b、c中至少有一個必須為1，即 a、b、c不能同時為0。

?? O約束(唯一)：a和b必須有一個且僅有一個為1。

?? R約束(要求)：a是1時，b必須是1，即a為1時，b不能為0。

?? M約束(強制)：若結果a為1，則結果b強制為0。

l? 因果圖中用來表示約束關系的約束符號：

l? 因果圖法最終生成的是決策表。利用因果圖生成測試用例的基本步驟如下：

（1）分析軟件規格說明中哪些是原因（即輸入條件或輸入條件的等價類），哪些是結果（即輸出條件），并給每個原因和結果賦予一個標識符。

（2）分析軟件規格說明中的語義，找出原因與結果之間、原因與原因之間對應的關系， 根據這些關系畫出因果圖。

（3）由于語法或環境的限制，有些原因與原因之間、原因與結果之間的組合情況不可能出現。為表明這些特殊情況，在因果圖上用一些記號表明約束或限制條件。

（4）把因果圖轉換為決策表。

（5）根據決策表中的每一列設計測試用例。

3.6.3? 因果圖法測試舉例

l? 實例? 用因果圖法測試以下程序。

程序的規格說明要求：輸入的第一個字符必須是#或*，第二個字符必須是一個數字，此情況下進行文件的修改；如果第一個字符不是#或*，則給出信息N，如果第二個字符不是數字，則給出信息M。

?? 解題步驟：

（1）分析程序的規格說明，列出原因和結果。

（2）找出原因與結果之間的因果關系、原因與原因之間的約束關系，畫出因果圖。

（3）將因果圖轉換成決策表。

（4）根據（3）中的決策表，設計測試用例的輸入數據和預期輸出。

因果圖法測試舉例（續）

（1）分析程序規格說明中的原因和結果：

原因	結果
c1：第一個字符是#	e1：給出信息N
c2：第一個字符是*	e2：修改文件
c3：第二個字符是一個數字	e3：給出信息M

（2）畫出因果圖（編號為10的中間結點是導出結果的進一步原因）：

（3）將因果圖轉換成如下所示的決策表：

???? 規則 選項	1	2	3	4	5	6	7	8
條件：C1	1	1	1	1	0	0	0	0
C2	1	1	0	0	1	1	0	0
C3	1	0	1	0	1	0	1	0
10	?	?	1	1	1	1	0	0
動作：e1	?	?	?	?	?	?	√	√
e2	?	?	√	?	√	?	?	?
e3	?	?	?	√	?	√	?	√
不可能	√	√	?	?	?	?	?	?
測試用例	#3	#A	*6	*B	A1	GT

（4）根據決策表中的每一列設計測試用例：

測試用例編號	輸入數據	預期輸出
1	#3	修改文件
2	#A	給出信息M
3	*6	修改文件
4	*B	給出信息M
5	A1	給出信息N
6	GT	給出信息N和信息M

3.7? 決策表法

3.7.1? 決策表

l? 在所有的黑盒測試方法中，基于決策表（也稱判定表）的測試是最為嚴格、最具有邏輯性的測試方法。

l? 決策表的概念：決策表是分析和表達多邏輯條件下執行不同操作的情況的工具。

l? 決策表的優點：能夠將復雜的問題按照各種可能的情況全部列舉出來，簡明并避免遺漏。因此，利用決策表能夠設計出完整的測試用例集合。

l? 在一些數據處理問題當中，某些操作的實施依賴于多個邏輯條件的組合，即：針對不同邏輯條件的組合值，分別執行不同的操作。決策表很適合于處理這類問題。

決策表實例——“閱讀指南”決策表

??????????? 規則 選項		1	2	3	4	5	6	7	8
問題	覺得疲倦？	Y	Y	Y	Y	N	N	N	N
	感興趣嗎？	Y	Y	N	N	Y	Y	N	N
	糊涂嗎？	Y	N	Y	N	Y	N	Y	N
建議	重讀	?	?	?	?	√	?	?	?
	繼續	?	?	?	?	?	√	?	?
	跳下一章	?	?	?	?	?	?	√	√
	休息	√	√	√	√	?	?	?	?

決策表的組成

l? 決策表通常由以下4部分組成：

?? 條件樁—列出問題的所有條件

?? 條件項—針對條件樁給出的條件列出所有可能的取值

?? 動作樁—列出問題規定的可能采取的操作

?? 動作項—指出在條件項的各組取值情況下應采取的動作

決策表的生成

l? 構造決策表的5個步驟：

（1） 確定規則的個數。

?? 有n個條件的決策表有2n個規則（每個條件取真、假值）。

（2） 列出所有的條件樁和動作樁。

（3） 填入條件項。

（4） 填入動作項，得到初始決策表。

（5） 簡化決策表，合并相似規則。

?? 若表中有兩條以上規則具有相同的動作，并且在條件項之間存在極為相似的關系，便可以合并。

?? 合并后的條件項用符號“-”表示，說明執行的動作與該條件的取值無關，稱為無關條件。

三角形問題的決策表

?????????????? 規則 選項	規則1-8	規則9	規則10	規則11	規則12	規則13	規則14	規則15	規則16
條件：	?	?	?	?	?	?	?	?	?
c1:a,b,c構成三角形？	N	Y	Y	Y	Y	Y	Y	Y	Y
c2:a=b?	-	Y	Y	Y	Y	N	N	N	N
c3:a=c?	-	Y	Y	N	N	Y	Y	N	N
c4:b=c?	-	Y	N	Y	N	Y	N	Y	N
動作：	?	?	?	?	?	?	?	?	?
a1:非三角形	√	?	?	?	?	?	?	?	?
a2:一般三角形	?	?	?	?	?	?	?	?	√
a3:等腰三角形	?	?	?	?	√	?	√	√	?
a4:等邊三角形	?	√	?	?	?	?	?	?	?
a5:不可能	?	?	√	√	?	√	?	?	?

3.7.2? 決策表應用

l? NextDate函數的決策表測試用例設計

?? 問題分析：NextDate函數的三個變量之間在輸入定義域中存在一定的邏輯依賴關系，由于等價類劃分和邊界值分析測試都假設了變量是獨立的，如果采用上述兩種方法設計測試用例，那么這些依賴關系在機械的選取輸入值時可能會丟失。而采用決策表法則可以通過使用“不可能動作”的概念表示條件的不可能組合，來強調這種依賴關系。

?? 說明：當決策表規模（指規則的數目，n個條件的決策表有2n個規則）較大時，可以通過擴展條目決策表（條件使用等價類）、代數簡化表、將大表“分解”為小表等方法。

實例說明

NextDate函數

l? 為了獲得下一個日期，NextDate函數執行如下操作：

?? 如果輸入日期不是當月最后一天，則把day變量的值加1；

?? 如果輸入日期是1~11月份中某月的最后一天，則把day變量的值復位為1，month變量的值加1；

?? 如果輸入日期是12月的最后一天，則day變量和month變量的值都復位為1，year變量的值加1。

l? 關于最后一天的判斷：

?? 如果是有31天的月份(1,3,5,7,8,10,12)，day變量值為31；

?? 如果是有30天的月份(4,6,9,11)， day變量值為30；

?? 如果是有29天的月份(閏年的2月)，day變量值為29；

?? 如果是有28天的月份(非閏年的2月)，day變量值為28。

NextDate函數的動作樁和條件樁

l? 根據所執行的操作，可列出NextDate函數的動作樁：

a1: 不可能；a2:day加1；a3: day復位；a4: month加1；a5: month復位；a6: year加1

l? 考慮到決策表的規模，條件使用month、day、year變量的等價類，在以下等價類集合上建立決策表：

?? 對于month變量的取值

M1: {mouth: mouth有30天}；?? M2:{mouth:mouth有31天，12月除外}；???

M3: {mouth:mouth有12月}；??? M4:{mouth:mouth是2月}；

?? 對于day變量的取值

D1:{day:1≤day≤27}；?? D2: {day:day=28}；

D3: {day:day=29}；???? D4: {day:day=30}；???? D5: {day:day=31}；

?? 對于year變量的取值

Y1:{year:year是閏年}；????? Y2:{year:year不是閏年}

決策表應用（續）

l? 決策表測試法適用于具有以下特征的應用程序：

if-then-else邏輯突出；輸入變量之間存在邏輯關系；涉及輸入變量子集的計算；輸入與輸出之間存在因果關系。

l? 適用于使用決策表設計測試用例的條件：

?? 規格說明以決策表形式給出，或較容易轉換為決策表。

?? 條件的排列順序不會也不應影響執行的操作。

?? 規則的排列順序不會也不應影響執行的操作。

?? 當某一規則的條件已經滿足，并確定要執行的操作后，不必檢驗別的規則。

?? 如果某一規則的條件要執行多個操作，這些操作的執行順序無關緊要。

3.7.3? 決策表測試應用案例

l? 用決策表測試法測試以下程序：

該程序有三個輸入變量month、day、year（month、day和year均為整數值，并且滿足：1≤month≤12和1≤day≤31），分別作為輸入日期的月份、日、年份，通過程序可以輸出該輸入日期在日歷上隔一天的日期。例如，輸入為2004年11月29日，則該程序的輸出為2000年12月1日。

（1）分析各種輸入情況，列出為輸入變量month、day、year劃分的有效等價類。

（2）分析程序規格說明，結合以上等價類劃分的情況給出問題規定的可能采取的操作（即列出所有的動作樁）。

（3）根據（1）和（2），畫出簡化后的決策表。

案例分析

l? month變量的有效等價類：

M1: {month=4,6,9,11}? M2:{month=1,3,5,7,8,10}??? M3: {month=12}?? M4: {month=2}

l? day變量的有效等價類：

D1: {1≤day≤26}??? D2: {day=27}??????? D3: {day=28}??????? D4: {day=29}??????? D5:{day=30}??????? D6: {day=31}

l? year變量的有效等價類：

Y1:? {year是閏年}???????????? Y2:? {year不是閏年}

l? 考慮各種有效的輸入情況，程序中可能采取的操作有以下六種：

a1: day+2????????????? a2: day=2?????? a3: day=1????????????? a4:month+1?? a5: month=1?? a6: year+1

3.8? 錯誤推測法

l? 錯誤推測法的概念：基于經驗和直覺推測程序中所有可能存在的各種錯誤，從而有針對性的設計測試用例的方法。

l? 錯誤推測方法的基本思想：列舉出程序中所有可能有的錯誤和容易發生錯誤的特殊情況，根據它們選擇測試用例。例如：

?? 在單元測試時曾列出的許多在模塊中常見的錯誤、以前產品測試中曾經發現的錯誤等，這些就是經驗的總結。

?? 還有，輸入數據和輸出數據為0的情況、輸入表格為空格或輸入表格只有一行等。這些都是容易發生錯誤的情況，可選擇這些情況下的例子作為測試用例。

第4章? 白盒測試及其用例的設計

4.1? 白盒測試方法

l? 為什么要進行白盒測試？

如果所有軟件錯誤的根源都可以追溯到某個唯一原因，那么問題就簡單了。然而，事實上一個bug 常常是由多個因素共同導致的。

假設此時開發工作已結束，程序送交到測試組，沒有人知道代碼中有一個潛在的被 0 除的錯誤。若測試組采用的測試用例的執行路徑沒有同時經過x=0和y=5/x進行測試，顯然測試工作似乎非常完善，測試用例覆蓋了所有執行語句，也沒有被 0 除的錯誤發生。

l? 白盒測試也稱結構測試或邏輯驅動測試，是針對被測單元內部是如何進行工作的測試。它根據程序的控制結構設計測試用例，主要用于軟件或程序驗證。

l? 白盒測試法檢查程序內部邏輯結構，對所有邏輯路徑進行測試，是一種窮舉路徑的測試方法。但即使每條路徑都測試過了，仍然可能存在錯誤。因為：

?? 窮舉路徑測試無法檢查出程序本身是否違反了設計規范，即程序是否是一個錯誤的程序。

?? 窮舉路徑測試不可能查出程序因為遺漏路徑而出錯。

?? 窮舉路徑測試發現不了一些與數據相關的錯誤。

l? 采用白盒測試方法必須遵循以下幾條原則，才能達到測試的目的：

?? 保證一個模塊中的所有獨立路徑至少被測試一次。

?? 所有邏輯值均需測試真 (true) 和假 (false) 兩種情況。

?? 檢查程序的內部數據結構，保證其結構的有效性。

?? 在上下邊界及可操作范圍內運行所有循環。

l? 白盒測試主要是檢查程序的內部結構、邏輯、循環和路徑。常用測試用例設計方法有：

?? 邏輯覆蓋法（邏輯驅動測試）

?? 基本路徑測試方法

4.2? 白盒測試的基本概念

4.2.1? 控制流圖

l? 控制流圖（可簡稱流圖）是對程序流程圖進行簡化后得到的，它可以更加突出的表示程序控制流的結構。

l? 控制流圖中包括兩種圖形符號：節點和控制流線。

?? 節點由帶標號的圓圈表示，可代表一個或多個語句、一個處理框序列和一個條件判定框（假設不包含復合條件）。

?? 控制流線由帶箭頭的弧或線表示，可稱為邊。它代表程序中的控制流。

l? 對于復合條件，則可將其分解為多個單個條件，并映射成控制流圖。

常見結構的控制流圖

其中，包含條件的節點被稱為判定節點（也叫謂詞節點），由判定節點發出的邊必須終止于某一個節點，由邊和節點所限定的范圍被稱為區域。

4.2.2? 環形復雜度

l? 環形復雜度也稱為圈復雜度，它是一種為程序邏輯復雜度提供定量尺度的軟件度量。

l? 環形復雜度的應用——可以將環形復雜度用于基本路徑方法，它可以提供：程序基本集的獨立路徑數量；確保所有語句至少執行一次的測試數量的上界。

?? 獨立路徑是指程序中至少引入了一個新的處理語句集合或一個新條件的程序通路。采用流圖的術語，即獨立路徑必須至少包含一條在本次定義路徑之前不曾用過的邊。

l? 測試可以被設計為基本路徑集的執行過程，但基本路徑集通常并不唯一。

計算環形復雜度的方法

l? 環形復雜度以圖論為基礎，為我們提供了非常有用的軟件度量。可用如下三種方法之一來計算環形復雜度：

?? 控制流圖中區域的數量對應于環形復雜度。

?? 給定控制流圖G的環形復雜度—V(G)，定義為V(G) =E-N+2

其中，E是控制流圖中邊的數量，N是控制流圖中的節點數量。

?? 給定控制流圖G的環形復雜度—V(G)，也可定義為 V(G) = P+1

其中，P是控制流圖G中判定節點的數量。

4.2.3? 圖矩陣

l? 圖矩陣是控制流圖的矩陣表示形式。

l? 圖矩陣是一個方形矩陣，其維數等于控制流圖的節點數。矩陣中的每列和每行都對應于標識的節點，矩陣元素對應于節點間的邊。

l? 通常，控制流圖中的結點用數字標識，邊則用字母標識。如果在控制流圖中從第 i 個結點到第 j 個結點有一個標識為 x 的邊相連接，則在對應圖矩陣的第 i 行第 j 列有一個非空的元素 x 。

4.3? 覆蓋測試

4.3.1? 測試覆蓋率

l? 測試覆蓋率：用于確定測試所執行到的覆蓋項的百分比。其中的覆蓋項是指作為測試基礎的一個入口或屬性，比如語句、分支、條件等。

l? 測試覆蓋率可以表示出測試的充分性，在測試分析報告中可以作為量化指標的依據，測試覆蓋率越高效果越好。但覆蓋率不是目標，只是一種手段。

l? 測試覆蓋率包括功能點覆蓋率和結構覆蓋率：

?? 功能點覆蓋率大致用于表示軟件已經實現的功能與軟件需要實現的功能之間的比例關系。

?? 結構覆蓋率包括語句覆蓋率、分支覆蓋率、循環覆蓋率、路徑覆蓋率等等。

4.3.2? 邏輯覆蓋法

l? 根據覆蓋目標的不同，邏輯覆蓋又可分為語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、組合覆蓋和路徑覆蓋。

?? 語句覆蓋：選擇足夠多的測試用例，使得程序中的每個可執行語句至少執行一次。

?? 判定覆蓋：通過執行足夠的測試用例，使得程序中的每個判定至少都獲得一次“真”值和“假”值， 也就是使程序中的每個取“真”分支和取“假”分支至少均經歷一次，也稱為“分支覆蓋”。

?? 條件覆蓋：設計足夠多的測試用例，使得程序中每個判定包含的每個條件的可能取值（真/假）都至少滿足一次。

l? 判定/條件覆蓋：設計足夠多的測試用例，使得程序中每個判定包含的每個條件的所有情況（真/假）至少出現一次，并且每個判定本身的判定結果（真/假）也至少出現一次。

??? ——滿足判定/條件覆蓋的測試用例一定同時滿足判定覆蓋和條件覆蓋。

l? 組合覆蓋：通過執行足夠的測試用例，使得程序中每個判定的所有可能的條件取值組合都至少出現一次。

??? ——滿足組合覆蓋的測試用例一定滿足判定覆蓋、條件覆蓋和判定/條件覆蓋。

l? 路徑覆蓋：設計足夠多的測試用例，要求覆蓋程序中所有可能的路徑。

語句覆蓋

l? 要實現DoWork函數的語句覆蓋，只需設計一個測試用例就可以覆蓋程序中的所有可執行語句。

?? 測試用例輸入為：{ x=4、y=5、z=5 }

?? 程序執行的路徑是：abd

l? 分析：

語句覆蓋可以保證程序中的每個語句都得到執行，但發現不了判定中邏輯運算的錯誤，即它并不是一種充分的檢驗方法。例如在第一個判定((x>3)&&(z<10))中把“&&”錯誤的寫成了“||”，這時仍使用該測試用例，則程序仍會按照流程圖上的路徑abd執行。可以說語句覆蓋是最弱的邏輯覆蓋準則。

判定覆蓋

l? 要實現DoWork函數的判定覆蓋，需要設計兩個測試用例。

?? 測試用例的輸入為：{x=4、y=5、z=5}；{x=2、y=5、z=5}

?? 程序執行的路徑分別是：abd；ace

l? 分析：

上述兩個測試用例不僅滿足了判定覆蓋，同時還做到語句覆蓋。從這點看似乎判定覆蓋比語句覆蓋更強一些，但仍然無法確定判定內部條件的錯誤。例如把第二個判定中的條件y>5錯誤寫為y<5，使用上述測試用例，照樣能按原路徑執行而不影響結果。因此，需要有更強的邏輯覆蓋準則去檢驗判定內的條件。

l? 說明：以上僅考慮了兩出口的判斷，我們還應把判定覆蓋準則擴充到多出口判斷（如Case語句）的情況。因此，判定覆蓋更為廣泛的含義應該是使得每一個判定獲得每一種可能的結果至少一次。

條件覆蓋

l? 在實際程序代碼中，一個判定中通常都包含若干條件。 條件覆蓋的目的是設計若干測試用例，在執行被測程序后，要使每個判定中每個條件的可能值至少滿足一次。

l? 對DoWork函數的各個判定的各種條件取值加以標記。

?? 對于第一個判定((x>3)&&(z<10) )：

條件x>3??? 取真值記為T1，取假值記為-T1

條件z<10?? 取真值記為T2，取假值記為-T2

?? 對于第二個判定( (x==4)||(y>5) )：

條件x==4?? 取真值記為T3，取假值記為-T3

條件y>5??? 取真值記為T4，取假值記為-T4

l? 根據條件覆蓋的基本思想，要使上述4個條件可能產生的8種情況至少滿足一次，設計測試用例如下：

測試用例	執行路徑	覆蓋條件	覆蓋分支
x=4、y=6、z=5	abd	T1、T2、T3、T4	bd
x=2、y=5、z=15	ace	-T1、-T2、-T3、-T4	ce

l? 分析：上面這組測試用例不但覆蓋了4個條件的全部8種情況，而且將兩個判定的4個分支b、c、d、e也同時覆蓋了，即同時達到了條件覆蓋和判定覆蓋。

l? 說明：雖然前面的一組測試用例同時達到了條件覆蓋和判定覆蓋，但是，并不是說滿足條件覆蓋就一定能滿足判定覆蓋。如果設計了下表中的這組測試用例，則雖然滿足了條件覆蓋，但只是覆蓋了程序中第一個判定的取假分支c 和第二個判定的取真分支d，不滿足判定覆蓋的要求。

測試用例	執行路徑	覆蓋條件	覆蓋分支
x=2、y=6、z=5	acd	-T1、T2、-T3、T4	cd
x=4、y=5、z=15	acd	T1、-T2、T3、-T4	cd

判定/條件覆蓋

l? 判定/條件覆蓋實際上是將判定覆蓋和條件覆蓋結合起來的一種方法，即：設計足夠的測試用例，使得判定中每個條件的所有可能取值至少滿足一次，同時每個判定的可能結果也至少出現一次。

l? 根據判定/條件覆蓋的基本思想，只需設計以下兩個測試用例便可以覆蓋4個條件的8種取值以及4個判定分支

測試用例	執行路徑	覆蓋條件	覆蓋分支
x=4、y=6、z=5	abd	T1、T2、T3、T4	bd
x=2、y=5、z=15	ace	-T1、-T2、-T3、-T4	ce

l? 分析：從表面上看，判定/條件覆蓋測試了各個判定中的所有條件的取值，但實際上，編譯器在檢查含有多個條件的邏輯表達式時，某些情況下的某些條件將會被其它條件所掩蓋。因此，判定/條件覆蓋也不一定能夠完全檢查出邏輯表達式中的錯誤。

?? 例如：對于第一個判定(x>3)&&(z<10)來說，必須x>3和z<10這兩個條件同時滿足才能確定該判定為真。如果x>3為假，則編譯器將不再檢查z<10這個條件，那么即使這個條件有錯也無法被發現。對于第二個判定(x==4)||(y>5)來說，若條件x==4滿足，就認為該判定為真，這時將不會再檢查y>5，那么同樣也無法發現這個條件中的錯誤。

組合覆蓋

l? 組合覆蓋的目的是要使設計的測試用例能覆蓋每一個判定的所有可能的條件取值組合。

l? 對DoWork函數中的各個判定的條件取值組合加以標記：

1、x>3, z<10??????? 記做T1 T2，第一個判定的取真分支

2、x>3, z>=10????? 記做T1 -T2，第一個判定的取假分支

3、x<=3, z<10????? 記做-T1 T2，第一個判定的取假分支

4、x<=3, z>=10??? 記做-T1 -T2，第一個判定的取假分支

5、x==4, y>5??????? 記做T3 T4，第二個判定的取真分支

6、x==4, y<=5????? 記做T3 -T4，第二個判定的取真分支

7、x!=4, y>5???????? 記做-T3 T4，第二個判定的取真分支

8、x!=4, y<=5?????? 記做-T3 -T4，第二個判定的取假分支

l? 根據組合覆蓋的基本思想，設計測試用例如下：

測試用例	執行路徑	覆蓋條件	覆蓋組合號
x=4、y=6、z=5	abd	T1、T2、T3、T4	1和5
x=4、y=5、z=15	acd	T1、-T2、T3、-T4	2和6
x=2、y=6、z=5	acd	-T1、T2、-T3、T4	3和7
x=2、y=5、z=15	ace	-T1、-T2、-T3、-T4	4和8

l? 分析：上面這組測試用例覆蓋了所有8種條件取值的組合，覆蓋了所有判定的真假分支，但是卻丟失了一條路徑abe。

路徑覆蓋

l? 前面提到的5種邏輯覆蓋都未涉及到路徑的覆蓋。事實上，只有當程序中的每一條路徑都受到了檢驗，才能使程序受到全面檢驗。路徑覆蓋的目的就是要使設計的測試用例能覆蓋被測程序中所有可能的路徑。

l? 根據路徑覆蓋的基本思想，在滿足組合覆蓋的測試用例中修改其中一個測試用例，則可以實現路徑覆蓋：

測試用例	執行路徑	覆蓋條件
x=4、y=6、z=5	abd	T1、T2、T3、T4
x=4、y=5、z=15	acd	T1、-T2、T3、-T4
x=2、y=5、z=15	ace	-T1、-T2、-T3、-T4
x=5、y=5、z=5	abe	T1、T2、-T3、-T4

l? 分析：雖然前面一組測試用例滿足了路徑覆蓋，但并沒有覆蓋程序中所有的條件組合（丟失了組合3和7），即滿足路徑覆蓋的測試用例并不一定滿足組合覆蓋。

l? 說明：

?? 對于比較簡單的小程序，實現路徑覆蓋是可能做到的。但如果程序中出現較多判斷和較多循環，可能的路徑數目將會急劇增長，要在測試中覆蓋所有的路徑是無法實現的。為了解決這個難題，只有把覆蓋路徑數量壓縮到一定的限度內，如程序中的循環體只執行一次。

?? 在實際測試中，即使對于路徑數很有限的程序已經做到路徑覆蓋，仍然不能保證被測試程序的正確性，還需要采用其他測試方法進行補充。

4.3.3? 面向對象的覆蓋

l? 繼承上下文覆蓋

?? 由于傳統的結構化度量沒有考慮面向對象的一些特性（如多態、繼承和封裝等），所以在面向對象領域，傳統的結構化覆蓋必須被加強，以滿足面向對象特性。

?? 繼承上下文覆蓋考慮在每個類的上下文內獲得的覆蓋率級別。它是擴展到面向對象領域里的一種覆蓋率度量方法，用于度量在系統中的多態調用被測試得多好。

?? 繼承上下文定義將基類上下文內例行程序的執行作為獨立于繼承類上下文內例行程序的執行。同樣，它們在考慮繼承類上下文內例行程序的執行也獨立于基類上下文內例行程序的執行。為了獲得100％繼承上下文覆蓋，代碼必須在每個適當的上下文內被完全執行。

l? 基于狀態的上下文覆蓋

?? 在絕大多數面向對象的系統中存在這樣的一些類：這些類的對象可以存在于眾多不同狀態中的任何一種，并且由于類的行為依賴于狀態，每個類的行為在每個可能的狀態中其性質是不同的。

?? 基于狀態的上下文覆蓋對應于被測類對象的潛在狀態。

?? 這樣基于狀態的上下文覆蓋把一個狀態上下文內的一個例行程序的執行認為是獨立于另一個狀態內相同例行程序的執行。為了達到100％的基于狀態的上下文覆蓋，例行程序必須在每個適當的上下文（狀態）內被執行。

4.3.4? 測試覆蓋準則

l? 邏輯覆蓋的出發點是合理的、完善的。所謂“覆蓋”，就是想要做到全面而無遺漏，但邏輯覆蓋并不能真正做到無遺漏。

l? 例如：我們不小心將前面提到的程序段中的if (x>3 &&Z<10) { …… }錯寫成if (x>=3 &&Z<10) { …… }

按照我們前面設計的測試用例（x的值取2或4）來看，邏輯覆蓋對這樣的小問題都無能為力。分析出現這一情況的原因在于：錯誤區域僅僅在x=3這個點上，即僅當x的值取3時，測試才能發現錯誤。面對這類情況，我們應該從中吸取的教訓是測試工作要有重點，要多針對容易發生問題的地方設計測試用例。

l? ESTCA覆蓋準則：在容易發生問題的地方設計測試用例，即重視程序中謂詞（條件判斷）的取值。

l? ESTCA覆蓋準則是一套錯誤敏感用例分析規則。這一規則雖然并不完備，但在普通程序中卻是有效的。原因在于這是一種經驗型的覆蓋準則，規則本身針對了程序編寫人員容易發生的錯誤，或是圍繞著發生錯誤的頻繁區域，從而提高了發現錯誤的命中率。具體規則如下：

?? [規則1]? 對于A rel B型 (rel可以是<、= 或 >) 的分支謂詞，應適當的選擇A與B的值，使得測試執行到該分支語句時，A<B、A=B、A>B的情況分別出現一次。

??? ——這是為了檢測邏輯符號寫錯的情況，如將“A<B”錯寫為“A>B”。

測試覆蓋準則（續）

?? [規則2]? 對于A rel C型 (rel可以是>或<, A是變量，C是常量)的分支謂詞：當rel為<時，應適當的選擇A的值，使A=C-M （M是距C最小的機器容許正數，若A和C都為正整數時，M=1）；當rel為>時，應適當的選擇A的值，使A=C+M。

??? ——這是為了檢測“差1”之類的錯誤，如“A>1”錯寫成“A>0”。

?? [規則3]? 對外部輸入變量賦值，使其在每一個測試用例中均有不同的值與符號，并與同一組測試用例中其他變量的值與符號不同。

??? ——這是為了檢測程序語句中的錯誤，如應該引用某一變量而錯成引用另一個常量。

l? 關于LCSAJ

?? LCSAJ (Linear CodeSequence and Jump) 的字面含義是線性代碼序列與跳轉。在程序中，一個LCSAJ是一組順序執行的代碼，以控制跳轉為其結束點。

?? LCSAJ的起點是根據程序本身決定的。它的起點可以是程序第一行或轉移語句的入口點，或是控制流可跳達的點。

?? 如果有幾個LCSAJ首尾相接，且第一個LCSAJ起點為程序起點，最后一個LCSAJ終點為程序終點，這樣的LCSAJ串就組成了程序的一條路徑（LCSAJ路徑）。一條LCSAJ程序路徑可能是由2個、3個或多個LCSAJ組成的。

l? 基于LCSAJ與路徑的關系，提出了層次LCSAJ覆蓋準則。它是一個分層的覆蓋準則，可以概括的描述為：

?? 第一層 — 語句覆蓋。

?? 第二層 — 分支覆蓋。

?? 第三層 — LCSAJ覆蓋，即程序中的每一個LCSAJ都至少在測試中經歷過一次。

?? 第四層 — 兩兩LCSAJ覆蓋，即程序中的每兩個相連的LCSAJ組合起來在測試中都要經歷一次。

?? 第n+2層 — 每n個首尾相連的LCSAJ組合在測試中都要經歷一次。

l? 在實施測試時，若要實現上述的層次LCSAJ覆蓋，需要產生被測程序的所有LCSAJ。

l? 例：找出前面DoWork函數的所有LCSAJ和LCSAJ路徑。

?? LCSAJ（5個）：

? （1）int k=0,j=0;????? if ( (x>3)&&(z<10) )

? （2）k=x*y-1;?? j=sqrt(k); if( (x==4)||(y>5) )

? （3）if ( (x==4)||(y>5) )

? （4）j=x*y+10; j=j%3

? （5）j=j%3

?? LCSAJ路徑（4條）：

（1）-（2）-（4）????? （1）-（2）-（5）????? （1）-（3）-（4）????? （1）-（3）-（5）

4.4? 路徑測試

4.4.1? 路徑表達式

l? 為了滿足路徑覆蓋，必須首先確定具體的路徑以及路徑的個數。我們通常采用控制流圖的邊（弧）序列和節點序列表示某一條具體路徑，更為概括的表示方法為：

（1）弧a和弧b相乘，表示為ab，它表明路徑是先經歷弧a，接著再經歷弧b，弧a和弧b是先后相接的。

（2）弧a和弧b相加，表示為a+b，它表明兩條弧是“或”的關系，是并行的路段。

l? 路徑數的計算：

在路徑表達式中，將所有弧均以數值1來代替，再進行表達式的相乘和相加運算，最后得到的數值即為該程序的路徑數。

4.4.2? 基本路徑測試方法

l? 路徑測試就是從一個程序的入口開始，執行所經歷的各個語句的完整過程。從廣義的角度講，任何有關路徑分析的測試都可以被稱為路徑測試。

l? 完成路徑測試的理想情況是做到路徑覆蓋，但對于復雜性大的程序要做到所有路徑覆蓋（測試所有可執行路徑）是不可能的。

l? 在不能做到所有路徑覆蓋的前提下，如果某一程序的每一個獨立路徑都被測試過，那么可以認為程序中的每個語句都已經檢驗過了，即達到了語句覆蓋。這種測試方法就是通常所說的基本路徑測試方法。

l? 基本路徑測試方法是在控制流圖的基礎上，通過分析控制結構的環形復雜度，導出執行路徑的基本集，再從該基本集設計測試用例。基本路徑測試方法包括以下4個步驟：

（1）畫出程序的控制流圖。

（2）計算程序的環形復雜度，導出程序基本路徑集中的獨立路徑條數，這是確定程序中每個可執行語句至少執行一次所必須的測試用例數目的上界。

（3）導出基本路徑集，確定程序的獨立路徑。

（4）根據（3）中的獨立路徑，設計測試用例的輸入數據和預期輸出。

4.4.3? 循環測試方法

l? 從本質上說，循環測試的目的就是檢查循環結構的有效性。

l? 通常，循環可以劃分為簡單循環、嵌套循環、串接循環和 非結構循環4類。

（1）測試簡單循環。設其循環的最大次數為n ，可采用以下測試集：

?? 跳過整個循環；

?? 只循環一次；

?? 只循環兩次；

?? 循環 m 次，其中m<n；

?? 分別循環 n-1、n 和 n+1 次。

（2）測試嵌套循環。如果將簡單循環的測試方法用于嵌套循環，可能的測試次數會隨嵌套層數成幾何級數增加。 此時可采用以下辦法減少測試次數：

?? 測試從最內層循環開始，所有外層循環次數設置為最小值；

?? 對最內層循環按照簡單循環的測試方法進行；

?? 由內向外進行下一個循環的測試，本層循環的所有外層循環仍取最小值，而由本層循環嵌套的循環取某些“典型”值；

?? 重復上一步的過程，直到測試完所有循環。

（3）測試串接循環。若串接的各個循環相互獨立，則可分別采用簡單循環的測試方法；否則采用嵌套循環的測試方法。

（4）對于非結構循環這種情況，無法進行測試，需要按結構化程序設計的思想將程序結構化后，再進行測試。

Z路徑覆蓋下的循環測試方法

l? Z路徑覆蓋是路徑覆蓋的一種變體，它是將程序中的循環結構簡化為選擇結構的一種路徑覆蓋。

l? 循環簡化的目的是限制循環的次數，無論循環的形式和循環體實際執行的次數，簡化后的循環測試只考慮執行循環體一次和零次（不執行）兩種情況，即考慮執行時進入循環體一次和跳過循環體這兩種情況。

4.4.4? 產生測試用例

l? 在實踐中，除了前面給出的各種方法外，通常還可以采用以下三種方法來補充設計測試用例：

（1）通過非路經分析得到測試用例

??? ——這種方法得到的測試用例是在應用系統本身的實踐中提供的，基本上是測試人員憑工作經驗的得到，甚至是猜測得到的。

（2）尋找尚未測試過的路徑并生成相應的測試用例

??? ——這種方法需要窮舉被測程序的所有路徑，并與前面已測試路徑進行對比。

（3）通過指定特定路徑并生成相應的測試用例

4.5? 最少測試用例數計算

l? 為實現測試的邏輯覆蓋，必須設計足夠多的測試用例，并使用這些測試用例執行被測程序，實施測試。我們關心的是：對于某個具體的程序來說，至少需要設計多少個測試用例。這里提供一種估算最少測試用例數的方法。

l? 我們知道，結構化程序是由 3 種基本控制結構組成：順序型（構成串行操作）、選擇型（構成分支操作）和重復型（構成循環操作）。

l? 為了把問題化簡，避免出現測試用例極多的組合爆炸，把構成循環操作的重復型結構用選擇結構代替。這樣，任一循環便改造成進入循環體或不進入循環體的分支操作了。

l? 用N-S圖表示程序的3種基本控制結構：

?? 圖中A、B、C、D、S均表示要執行的操作，P是可取真假值的謂詞，Y表真值，N表假值。

?? 圖中的 (c) 和 (d) 兩種重復型結構代表了兩種循環。在做了簡化循環的假設以后，對于一般的程序控制流，我們只考慮選擇型結構。事實上它已經能體現順序型和重復型結構了。

l? 例如，右圖表達了兩個順序執行的分支結構。當兩個分支謂詞P1和P2取不同值時，將分別執行a或b及c或d操作。

l? 顯然，要測試這個小程序，需要至少提供4個測試用例才能作到邏輯覆蓋，使得ac、ad、bc及bd操作均得到檢驗。其實，這里的4是圖中的第1個分支謂詞引出的兩個操作，及第2個分支謂詞引出的兩個操作組合起來而得到的，即2×2=4。并且，這里的2是由于兩個并列的操作，即1+1=2 而得到的。

l? 對于一般的、更為復雜的問題，估算最少測試用例個數的原則也是同樣的：

?? 如果在N-S圖中存在有并列的層次A1、A2，A1和A2的最少測試用例個數分別為a1、a2，則由 A1、A2 兩層所組合的 N-S圖對應的最少測試用例數為a1×a2。

?? 如果在N-S圖中不存在有并列的層次，則對應的最少測試用例數由并列的操作數決定，即N-S圖中除謂詞之外的操作框的個數。

l? 例：如下圖所示的N-S圖，至少需要多少個測試用例完成邏輯覆蓋？

?? 由于圖中并不存在并列的層次

?? 最少測試用例數由并列的操作數決定

?? 即為1+1+1=3。

?? 由于圖中沒有包含并列的層次

?? 最少測試用例數仍由并列的操作數決定

?? 即為1+1+1+1+1=5。

?? 圖中的2345和67是并列的兩層。

?? 2345層對應的最少測試用例數為1+1+1+1+1=5

?? 67層對應的測試用例數為1+1+1=3

?? 2345和67這兩層組合后對應的測試用例數為5×3=15

?? 最后，由于兩層組合后的部分是不滿足謂詞1時所要做的操作，還要加上滿足謂詞1要做的操作，因此整個程序所需測試用例數為15+1=16。

總結

以上是生活随笔為你收集整理的软件测试重点的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。