按是否查看代碼的角度划分
1.黑盒測試（Black-box Testing）
黑盒測試也是功能測試，測試中把被測的軟件當成一個黑盒子，不關心盒子的內部結構是什么，只關心軟件的輸入數據和輸出數據。
黑盒測試也稱功能測試，它是通過測試來檢測每個功能是否都能正常使用。在測試中，把程序看作一個不能打開的黑盒子，在完全不考慮程序內部結構和內部特性的情況下，在程序接口進行測試，它只檢查程序功能是否按照需求規格說明書的規定正常使用，程序是否能適當地接收輸入數據而產生正確的輸出信息。黑盒測試着眼於程序外部結構，不考慮內部邏輯結構，主要針對軟件界面和軟件功能進行測試。
黑盒測試是以用戶的角度，從輸入數據與輸出數據的對應關系出發進行測試的。很明顯，如果外部特性本身設計有問題或規格說明的規定有誤，用黑盒測試方法是發現不了的。
作用
黑盒測試法注重於測試軟件的功能需求，主要試圖發現下列幾類錯誤。
功能不正確或遺漏；
界面錯誤；
輸入和輸出錯誤；
數據庫訪問錯誤；
性能錯誤；
初始化和終止錯誤等。
優點
1、對於子系統甚至系統，效率要比白盒測試高。
2、測試人員不需要了解實現的細節，包括特定的編程語言。
3、測試人員和編程人員彼此獨立。
4、從用戶的角度進行測試，很容易理解和接受。
5、有助於暴露規格的不一致或有歧義的問題。
6、測試用例可以在規格完成后馬上進行。
缺點
1、只有一小部分輸入被測試到，要測試每個可能的輸入幾乎不可能。
2、沒有清晰、簡明的規格，測試用例很難設計。
3、如果測試人員不被告知開發人員已經執行過的用例，在測試數據上會存在不必要的重復。
4、有很多程序路徑沒有被測試到。
5、不能直接針對特定程序段測試，而這些程序段可能很復雜，有可能隱藏更多的問題。
6、大部分和研究相關的測試都是直接針對白盒測試的。
測試用例設計方法
從理論上講，黑盒測試只有采用窮舉輸入測試，把所有可能的輸入都作為測試情況考慮，才能查出程序中所有的錯誤。實際上測試情況有無窮多個，人們不僅要測試所有合法的輸入，而且還要對那些不合法但可能的輸入進行測試。這樣看來，完全測試是不可能的，所以我們要進行有針對性的測試，通過制定測試案例指導測試的實施，保證軟件測試有組織、按步驟，以及有計划地進行。黑盒測試行為必須能夠加以量化，才能真正保證軟件質量，而測試用例就是將測試行為具體量化的方法之一。具體的黑盒測試用例設計方法包括等價類划分法、邊界值分析法、錯誤推測法、因果圖法、判定表驅動法、正交試驗設計法、功能圖法、場景法等。
等價類划分法
等價類是指某個輸入域的子集合。在該子集合中，各個輸入數據對於揭露程序中的錯誤都是等效的，並合理地假定：測試某等價類的代表值就等於對這一類其它值的測試.因此，可以把全部輸入數據合理划分為若干等價類，在每一個等價類中取一個數據作為測試的輸入條件，就可以用少量代表性的測試數據.取得較好的測試結果.等價類划分可有兩種不同的情況：有效等價類和無效等價類。
有效等價類：是指對於程序的規格說明來說是合理的，有意義的輸入數據構成的集合.利用有效等價類可檢驗程序是否實現了規格說明中所規定的功能和性能。
無效等價類：與有效等價類的定義恰巧相反。
設計測試用例時，要同時考慮這兩種等價類.因為，軟件不僅要能接收合理的數據，也要能經受意外的考驗.這樣的測試才能確保軟件具有更高的可靠性。
划分等價類的原則
① 在輸入條件規定了取值范圍或值的個數的情況下，則可以確立一個有效等價類和兩個無效等價類。
例：輸入值是學生成績，范圍是0～100：
② 在輸入條件規定了輸入值的集合或者規定了“必須如何”的條件的情況下，可確立一個有效等價類和一個無效等價類。
③ 在輸入條件是一個布爾類型的情況下，可確定一個有效等價類和一個無效等價類。
④在規定了輸入數據的一組值（假定n個），並且程序要對每一個輸入值分別處理的情況下，可確立n個有效等價類和一個無效等價類。
⑤在規定了輸入數據必須遵守的規則的情況下，可確立一個有效等價類（符合規則）和若干個無效等價類（從不同角度違反規則）。
⑥在確知已划分的等價類中各元素在程序處理中的方式不同的情況下，則應再將該等價類進一步的划分為更小的等價類。
建立等價類表
設計測試用例：在確立了等價類后，可建立等價類表，列出所有划分出的等價類：
確定測試用例
輸入條件 有效等價類 或 無效等價類
然后從划分出的等價類中按以下三個原則設計測試用例：
① 為每一個等價類規定一個唯一的編號。
② 設計一個新的測試用例，使其盡可能多地覆蓋尚未被覆蓋地有效等價類，重復這一步.直到所有的有效等價類都被覆蓋為止。
③ 設計一個新的測試用例，使其僅覆蓋一個尚未被覆蓋的無效等價類，重復這一步.直到所有的無效等價類都被覆蓋為止。
舉例：判斷三角形類別
【問題描述】程序要求：輸入三個整數 a 、 b 、 c 分別作為三角形的三邊長度，通過程序判定所構成的三角形的類型；當三角形為一般三角形、等腰三角形或等邊三角形時，分別作處理 。
【問題分析】
(1) 輸入值域的顯/隱式要求：A 整數、B 三個、C 正數、D 兩邊之和大於第三邊、E 三邊均不相等、F 兩邊相等但不等於第三邊、G 三邊相等；（D~G由輸出值域的等價類隱性確定）
(2) 輸出值域的等價類：R1={不構成三角形}、R2={一般三角形}、R3={等腰三角形}、R4={等邊三角形}；
【問題解答】
(1) 列出等價類表並編號
(2) 設計覆蓋有效等價類的測試用例
(3) 設計覆蓋無效等價類的測試用例
【問題描述】程序要求：輸入三個數 a 、 b 、 c 分別作為三角形的三邊長度，通過程序判定所構成的三角形的類型；當三角形為一般三角形、等腰三角形或等邊三角形時，分別作處理 。注：a、b、c非空。
【問題分析】
(1) 輸入值域的顯/隱式要求：B 三個、C 正數、D 兩邊之和大於第三邊、E 三邊均不相等、F 兩邊相等但不等於第三邊、G 三邊相等；（D~G由輸出值域的等價類隱性確定）
(2) 輸出值域的等價類：R1={不構成三角形}、R2={一般三角形}、R3={等腰三角形}、R4={等邊三角形}；
【問題解答】
(1) 列出等價類表並編號
(2) 設計覆蓋有效/無效等價類的測試用例
邊界值分析法
邊界值分析是通過選擇等價類邊界的測試用例。邊界值分析法不僅重視輸入條件邊界，而且也必須考慮輸出域邊界。它是對等價類划分方法的補充。
（1）邊界值分析方法的考慮：
長期的測試工作經驗告訴我們，大量的錯誤是發生在輸入或輸出范圍的邊界上，而不是發生在輸入輸出范圍的內部.因此針對各種邊界情況設計測試用例，可以查出更多的錯誤。
使用邊界值分析方法設計測試用例，首先應確定邊界情況.通常輸入和輸出等價類的邊界，就是應着重測試的邊界情況.應當選取正好等於，剛剛大於或剛剛小於邊界的值作為測試數據，而不是選取等價類中的典型值或任意值作為測試數據。
（2）基於邊界值分析方法選擇測試用例的原則：
1）如果輸入條件規定了值的范圍，則應取剛達到這個范圍的邊界的值，以及剛剛超越這個范圍邊界的值作為測試輸入數據。
2）如果輸入條件規定了值的個數，則用最大個數,最小個數，比最小個數少一，比最大個數多一的數作為測試數據。
3）根據規格說明的每個輸出條件，使用前面的原則1）。
4）根據規格說明的每個輸出條件，應用前面的原則2）。
5）如果程序的規格說明給出的輸入域或輸出域是有序集合，則應選取集合的第一個元素和最后一個元素作為測試用例。
6）如果程序中使用了一個內部數據結構，則應當選擇這個內部數據結構的邊界上的值作為測試用例。
7）分析規格說明，找出其它可能的邊界條件。
舉例：區間值的邊界值取值問題
用邊界值分析法，假定1<X<10，那么X在測試中應該取的邊界值是( A )
X=1，X=2，X=9，X=10
X=2，X=9
X=1，X=10
X=1，X=5，X=6，X=10
這里涉及到開閉區間和離點的概念，在邊界值分析時，有下面幾個點：
上點：就是指得邊界上得點，無論此時得域是開區間還是閉區間，開區間得話，上點就是在域外，閉區間得話，上點就是在域內。
離點：指得就是離上點最近得點，這里就跟是閉區間還是開區間就有關系了，如果是開區間，那么離點就在域內，如果是閉區間，那么離點就在域外。
內點：域內得任意點都是內點。
題目中給的是開區間，不包括等於的情況。這里上點是1和10，因為是開區間，所以離點是在區間內，即2和9。所以邊界值要覆蓋1 2 9 10。
上點很好理解，但是開區間的離點為什么在區間內，0和11需要覆蓋嗎？
其實可以這么理解，對開區間，范圍不包括邊界，上點是在范圍之外的，所以需要再測一個在范圍之內，又離上點最近的點，這個值就是范圍內離上點最近的點。
另外，假如題目給的條件是1≦x≦10，那答案就是0 1 10 11，如果是1＜x≦10，那答案就應該是1 2 10 11。
舉例：判斷三角形類別
【問題描述】程序要求：輸入三個不超過200的整數 a 、 b 、 c 分別作為三角形的三邊長度，通過程序判定所構成的三角形的類型；當三角形為一般三角形、等腰三角形或等邊三角形時，結果打印出來 。
【問題分析】
(1) 輸入值域的顯/隱式要求：A 整數、B 三個、C 正數、D 兩邊之和大於第三邊、E 三邊均不相等、F 兩邊相等但不等於第三邊、G 三邊相等；（D~G由輸出值域的等價類隱性確定）
(2) 輸出值域的等價類：R1={不構成三角形}、R2={一般三角形}、R3={等腰三角形}、R4={等邊三角形}；
（3）邊界值：0、1、2、100、199、200、201
當僅有一個變量取邊界值，其他取正常值，從一般邊界值的角度考慮{1、2、100、199、200}，（4n+1=13，n=3）如下表所示。
| 序號 |
輸入及操作說明 |
期望的測試結果 |
| 1 |
1、100、100 |
等腰三角形 |
| 2 |
2、100、100 |
|
| 3 |
199、100、100 |
|
| 4 |
200、100、100 |
非三角形 |
| 5 |
100、1、100 |
等腰三角形 |
| 6 |
100、2、100 |
|
| 7 |
100、199、100 |
|
| 8 |
100、200、100 |
非三角形 |
| 9 |
100、100、1 |
等腰三角形 |
| 10 |
100、100、2 |
|
| 11 |
100、100、199 |
|
| 12 |
100、100、200 |
非三角形 |
| 13 |
100、100、100 |
等邊三角形 |
| 當僅當有一個變量取邊界值，其他取正常值，從健壯邊界值的角度考慮{0、1、2、100、199、200、201},(6n+1=19，n=3) 如下表所示。 |
||
| 序號 |
輸入及操作說明 |
期望的測試結果 |
| 1 |
0、100、100 |
非三角形 |
| 2 |
1、100、100 |
等腰三角形 |
| 3 |
2、100、100 |
|
| 4 |
199、100、100 |
|
| 5 |
200、100、100 |
非三角形 |
| 6 |
201、100、100 |
|
| 7 |
100、0、100 |
|
| 8 |
100、1、100 |
等腰三角形 |
| 9 |
100、2、100 |
|
| 10 |
100、199、100 |
|
| 11 |
100、200、100 |
非三角形 |
| 12 |
100、201、100 |
|
| 13 |
100、100、0 |
|
| 14 |
100、100、1 |
等腰三角形 |
| 15 |
100、100、2 |
|
| 16 |
100、100、199 |
|
| 17 |
100、100、200 |
非三角形 |
| 18 |
100、100、201 |
|
| 19 |
100、100、100 |
等邊三角形 |
| 當所有變量取邊界值時，介於篇幅原因，可使用上述表中的邊界值自行完成53、73個測試用例。 |
||
總結：
由於多變量同時取邊界值，關注的是變量同時取值對功能的影響，三角形問題的各個變量之間相對獨立，因此對於三角形問題僅考慮使用一個變量取邊界值，其他變量取正常值即可
錯誤推測法
錯誤推測法是基於經驗和直覺推測程序中所有可能存在的各種錯誤，從而有針對性的設計測試用例的方法.
錯誤推測方法的基本思想： 列舉出程序中所有可能有的錯誤和容易發生錯誤的特殊情況，根據他們選擇測試用例。 例如，在單元測試時曾列出的許多在模塊中常見的錯誤. 以前產品測試中曾經發現的錯誤等，這些就是經驗的總結。還有，輸入數據和輸出數據為0的情況. 輸入表格為空格或輸入表格只有一行. 這些都是容易發生錯誤的情況。可選擇這些情況下的例子作為測試用例。
它的要素共有三點，分別為：經驗、知識、直覺。關於如何使用的問題，我們提煉出兩點：
1.列舉出程序中所有可能有的錯誤和容易發生錯誤的特殊情況；
2.根據他們選擇測試用例。
我們知道經驗是錯誤推測法的一個重要要素，也就說帶有主觀性，那么這就決定了錯誤猜測法的優缺點，首先我們來看優點：
1.充分發揮人的直覺和經驗；
2.集思廣益；
3.方便使用；
4.快速容易切入；
對應的缺點有：
1.難以知道測試的覆蓋率；
2.可能丟失大量未知的區域；
3.帶有主觀性且難以復制；
舉例：手機終端通話功能
例如：測試手機終端的通話功能，可以設計哪些通話失敗的情況來補充測試用例
1、無SIM 插入是進行呼出（非緊急呼叫）
2、插入已欠費SIM卡進行呼出
3、射頻器件損壞或無信號區域插入有效SIM卡呼出
4、網絡正常、插入有效SIM卡，呼無效號碼（如1、888、33333、不輸入任何號碼等）
5、網絡正常，插入有效SIM卡，使用“快速拔號”功能呼出設置無效號碼的數字
因果圖法
前面介紹的等價類划分方法和邊界值分析方法，都是着重考慮輸入條件，但未考慮輸入條件之間的聯系，相互組合等。 考慮輸入條件之間的相互組合，可能會產生一些新的情況. 但要檢查輸入條件的組合不是一件容易的事情，即使把所有輸入條件划分成等價類，他們之間的組合情況也相當多. 因此必須考慮采用一種適合於描述對於多種條件的組合，相應產生多個動作的形式來考慮設計測試用例. 這就需要利用因果圖（邏輯模型）。
因果圖方法最終生成的就是判定表。它適合於檢查程序輸入條件的各種組合情況。
生成測試用例
(1) 分析軟件規格說明描述中，哪些是原因（即輸入條件或輸入條件的等價類），哪些是結果（即輸出條件），並給每個原因和結果賦予一個標識符。
(2) 分析軟件規格說明描述中的語義。找出原因與結果之間，原因與原因之間對應的關系. 根據這些關系，畫出因果圖。
(3) 由於語法或環境限制，有些原因與原因之間，原因與結果之間的組合情況不可能出現. 為表明這些特殊情況，在因果圖上用一些記號標明約束或限制條件。
(4) 把因果圖轉換為判定表。
(5) 把判定表的每一列拿出來作為依據，設計測試用例。
從因果圖生成的測試用例（局部，組合關系下的）包括了所有輸入數據的取TRUE與取FALSE的情況，構成的測試用例數目達到最少，且測試用例數目隨輸入數據數目的增加而線性地增加。
前面因果圖方法中已經用到了判定表。判定表（Decision Table）是分析和表達多邏輯條件下執行不同操作的情況下的工具.在程序設計發展的初期，判定表就已被當作編寫程序的輔助工具了.由於它可以把復雜的邏輯關系和多種條件組合的情況表達得既具體又明確。
因果圖標識
原因和結果之間的關系有：
①恆等：若C1是1，則E1也是1；若C1是0，則E1也是0。
②非：若C1是1，則E1是0；若C1是0，則E1是1。
③或：若c1或c2是1，則E1是1；否則E1為0。 或的含義：只有所有條件都為0時，結果為0，有任何1個條件為1（或者所有條件為1）時，結果為1
④與：若c1和c2都是1，則E1為1；否則E1為0。與的含義：只有所有條件都為1時，結果為1，有任何一個條件為0（或者所有條件為0）那么結果為0.
因果圖約束
約束條件符號：
輸入條件的約束有以下4類：
1. E約束（互斥/異）：a和b中至多有一個可能為1，即a和b不能同時為1。含義：可以不選，如果選，只能選1個
2. I約束（或）：a、b和c中至少有一個必須是1，即 a、b 和c不能同時為0。含義：至少選1個（可以多選，不能不選，最少得選1個）
3. O約束（唯一）；a和b必須有一個，且僅有1個為1。含義：有且只有1個（必須要選，而且只能選1個）
4. R約束（）；若a為1時，則b必須為1。而當a為0時，b的值不定。
輸出條件約束類型
輸出條件的約束只有M約束（屏蔽/強制）：若結果a是1，則結果b強制為0。而當a為0時，b的值不定。
因果圖法測試用例的設計步驟
（1） 確定軟件規格(需求)中的原因和結果
分析軟件規格說明描述中，哪些是原因(即輸入條件或輸入條件的等價類)，哪些是結果(即輸出條件), 並給每個原因和結果賦予一個標識符。
（2） 確定原因和結果之間的邏輯關系
分析軟件規格說明描述中的語義。找出原因與結果之間，原因與原因之間對應的關系。根據這些關系，畫出因果圖。
（3） 確定因果圖中的各個約束(constraints)
由於語法或環境限制，有些原因與原因之間,原因與結果之間的組合情況下不可能出現。 為表明這些特殊情況，在因果圖上用一些記號表明約束或限制條件。
（4）畫出因果圖並轉換為決策表
（5）根據決策表設計測試用例
因果圖法優缺點
優點：
① 考慮到了輸入情況的各種組合以及各個輸入情況之間的相互制約關系。
② 能夠幫助測試人員按照一定的步驟，高效率的開發測試用例。
③ 因果圖法是將自然語言規格說明轉化成形式語言規格說明的一種嚴格的方法，可以指出規格說明存在的不完整性和二義性。
缺點：
① 因果圖來設計測試用例時，作為輸入條件的原因與輸出結果之間的因果關系，有時很難從軟件需求規格說明中得到。
② 而且往往因果關系非常龐大，以至於據此因果圖而得到的測試用例數目多的驚人，給軟件測試，特別是手工測試帶來沉重的負擔，為了有效地，合理地減少測試的工時與費用，可利用正交實驗設計方法進行測試用例的設計。
舉例：自動售貨機
產品說明書：有一個處理單價為1元5角錢的盒裝飲料的自動售貨機軟件。若投入1元5角硬幣，按下“可樂”、“雪碧”、或“紅茶”按鈕，相應的飲料就送出來。若投入的是2元硬幣，在送出飲料的同時退還5角硬幣。
判定表法
1.判定表是分析和表達多邏輯條件下執行不同操作的情況的工具。判定表通常由四個部分組成：
條件樁（Condition Stub）：列出了問題的所有條件.通常認為列出的條件的次序無關緊要。
動作樁（Action Stub）：列出了問題規定可能采取的操作.這些操作的排列順序沒有約束。
條件項（Condition Entry）：列出針對它左列條件的取值.在所有可能情況下的真假值。
動作項（Action Entry）：列出在條件項的各種取值情況下應該采取的動作。
2.規則：任何一個條件組合的特定取值及其相應要執行的操作.在判定表中貫穿條件項和動作項的一列就是一條規則.顯然，判定表中列出多少組條件取值，也就有多少條規則，既條件項和動作項有多少列。
3. 判定表的化簡：合並判定表中兩條或多條具有相同動作，並且其條件項之間存在着極為相似關系的規則這一過程。
4. 判定表使用場景：如果程序中多個條件決定一個動作，並且每個條件的取值只有兩種，且條件和動作之間的邏輯關系明確
5. 優點：能夠將復雜的問題按照各種可能的情況全部列舉出來，簡明並且可以避免遺漏。
判定表的建立步驟：（根據軟件規格說明）
1.列出所有的條件樁和動作樁。
2.確定規則的個數。假如有n個條件.每個條件有兩個取值（0,1），故有2n種規則。
3.填入條件項。
4.填入動作項.等到初始判定表。
5.簡化.合並相似規則（相同動作）。
有兩個或者多條規則具有相同的動作，並且條件項之間存在極為相似的關系就可以進行合並。
判定表設計測試用例的條件：
規格說明以判定表形式給出，或很容易轉換成判定表。
① 條件的排列順序不會也不影響執行哪些操作。
② 規則的排列順序不會也不影響執行哪些操作。
③ 每當某一規則的條件已經滿足，並確定要執行的操作后，不必檢驗別的規則。
④ 如果某一規則得到滿足要執行多個操作，這些操作的執行順序無關緊要。
判定表法優缺點
判定表的優點：
1） 充分考慮了輸入條件簡的組合，對組合情況覆蓋充分；
2） 最終每個用例覆蓋多種輸入情況，有利於提高測試效率；
3） 設計過程中，對輸入條件間的約束關系做了考慮，避免了無效用例，用例的有效性高；
4） 能同時得出每個測試項目的預期輸出。
判定表的缺點：
1） 當被測試特性輸入較多時，會造成判定表規格龐大；
2） 輸入之間的約束條件不能有效區分輸入是否確實需要進行組合測試，會造成不需要組合測試的輸入做了組合，從而產生用例冗余。
舉例：判斷三角形類別
正交試驗設計法
就是使用已經造好了的正交表格來安排試驗並進行數據分析的一種方法，目的是用最少的測試用例達到最高的測試覆蓋率。
使用正交試驗設計法首先要知道正交表，正交表是研究多因素多水平的一種設計方法，它是格局正交性從全面試驗中挑選出部分有代表性的點進行試驗，這些有代表性的點具備了“均勻分散，齊整可比”的特點，正交試驗設計是一種基於正交表的、高效率、快速、經濟的試驗設計方法。
正交表由三個成分構成：
Runs:正交表的行數，即實驗的次數；
Factors：正交表的列數，即因素數；
Levels:水平數，任何單個因素能夠取得的值的最大個數。正交表中的包含的值為從0到數“水平數-1”或從1到“水平數”
正交表的表現形式是：L行數(水平數因素數) L runs（levels^factors ）。
設計過程
1)確定試驗因素及水平數;
2)選用合適的正交表;
3)列出試驗方案及試驗結果;
4)對正交試驗設計結果進行分析，包括極差分析和方差分析;
5)確定最優或較優因素水平組合。
用正交表設計測試用例的步驟：
1. 有哪些因素（變量）；
2. 每個因素有哪幾個水平（變量的取值）：用等價類划分出來的；
3. 選擇一個合適的正交表；
4. 把變量的值映射到表中；
5. 把每一行的各因素水平的組合作為一個測試用例；
6. 加上你認為可以且沒有在表中出現的組合。
如何選擇正交表呢？取行數最少的一個，情況分三種：
1.因素數（變量）、水平數（變量值）相符；
2.因素數不相同: 取因素數最接近但略大的實際值的表；
3.水平數不相同: 有五個因素（變量）A、B、C、D和E。兩個因素有兩個水平（變量的取值）、兩個因素有三個水平，一個因素有六個水平。行數取最少的一個（ 行數取最少的一個（L49(78)、 L18（3661）
教你用Minitab進行正交試驗設計（極差）分析
首先，根據實驗要求，確定你實驗條件的因素、水平數，最好通過列表形式明確（如圖：以影響大豆出油率為例）。
然后，可以通過Minitab創建以上確定的正交表，依次選擇工具欄“統計”—“DOE”—“田口”—“創建田口設計”選項，調出“田口設計”對話框。
如圖：
在“田口設計”對話框中，根據需求選擇合適的因素、水平數，並點擊“設計”按鈕，選擇合適正交表。
注意：要考慮到試驗過程中的誤差，所選正交表安排完因素后，要有一列空白列，以考察試驗誤差進行方差分析。（故本例：選4因素，3水平，L9表）。
如圖，創建的“四因素三水平正交表”（注意：此處不考慮交互作用）。
在正交設計表等的基礎上，將所選正交表中各列的“數字”換成對應因素的具體“實驗水平值”（每一因素的某一水平均唯一對應一個實驗條件值），便形成了試驗方案。如圖：
此時可以根據此表安排實驗方案。
經過實驗后，得到對應的數據結果后，填入正交表對應位置（本例：“大豆出油率/%”），進行實驗數據分析。如圖：
接着可進行數據分析：依次選擇工具欄“統計”—“DOE”—“田口”—“分析田口設計”選項，調出“分析田口設計”對話框。如圖：
然后，將實驗數值列選擇到“響應數據位於”（本例：C5 “大豆出油率/%”）框內，再點擊“分析”按鈕，選擇要分析的項（本例：均值）如圖：
最后，依次點擊“確定”按鈕，即可得極差分析結果（如圖）。本例中由於大豆出油率越大越好（B>A>D>C)，所以最優水平為：B3 A2 D1 C2
另外，Minitab軟件還進行方差分析哦，（這里不再詳述，請自行學習！）。
希望能對你有幫助！
場景法
軟件幾乎都是用事件觸發來控制流程的，事件觸發的情景便形成了場景，而同一事件不同的觸發順序和處理結果就形成事件流。這種在軟件設計方面的思想也可以引入到軟件測試中，可以比較生動地描繪出事件觸發時的情景，有利於測試設計者設計測試用例，同時使測試用例更容易理解和執行。
場景法組成：基本流和備選流：如下圖所示，圖中經過用例的每條路徑都用基本流和備選流來表示，直黑線表示基本流，是經過用例的最簡單的路徑。備選流用不同的色彩表示，一個備選流可能從基本流開始，在某個特定條件下執行，然后重新加入基本流中（如備選流1和3）；也可能起源於另一個備選流（如備選流2），或者終止用例而不再重新加入到某個流（如備選流2和4）。
備選流
每個經過用例的可能路徑，可以確定不同的用例場景。從基本流開始，再將基本流和備選流結合起來，可以確定以下用例場景：
場景 1 基本流
場景 2 基本流 備選流 1
場景 3 基本流 備選流 1 備選流 2
場景 4 基本流 備選流 3
場景 5 基本流 備選流 3 備選流 1
場景 6 基本流 備選流 3 備選流 1 備選流 2
場景 7 基本流 備選流 4
場景 8 基本流 備選流 3 備選流 4
場景法的核心概念
1、基本流（正確流）：模擬用戶正確的操作流程
目的：驗證軟件的業務流程和主要功能
2、備選流（錯誤流）：模擬用戶錯誤的操作流程
目的：驗證軟件的錯誤處理能力
場景法的本質
1、場景法是一種基於等價類划分的測試技術（技術層面）
2、場景法的應用是基於對軟件業務（需求）的深入理解（業務層面）
用例設計步驟
1. 根據說明，描述出程序的基本流及各項備選流
2. 根據基本流和各項備選流生成不同的場景
3. 對每一個場景生成相應的測試用例
4. 對生成的所有測試用例重新復審，去掉多余的測試用例，測試用例確定后，對每一個測試用例確定測試數據值
舉例：分析ATM取款機的場景流程
例子：分析ATM取款機的場景流程，並設計測試用例和測試數據
1、根據需求，找到基本流和備選流（找出正確的操作流程和可能出錯的環節）
基本流：1.插入磁卡
2.ATM驗證賬戶正確
3.輸入密碼正確，通過驗證
4.輸入取款金額
5.取出金額
6.取卡
備選流一：賬戶不存在或者受限制
備選流二：密碼不正確，還有輸入機會
備選流三：密碼不正確，沒有輸入機會
備選流四：卡中余額不足
備選流五：ATM機中余額不足
備選流六：超過每日最大提款限額
備選流七：輸入金額非100的倍數
2.白盒測試（White-box Testing）
白盒測試又稱結構測試、透明盒測試、邏輯驅動測試或基於代碼的測試。盒子指的是被測試的軟件，白盒指的是盒子是可視的，你清楚盒子內部的東西以及里面是如何運作的。
"白盒"法全面了解程序內部邏輯結構、對所有邏輯路徑進行測試。"白盒"法是窮舉路徑測試。在使用這一方案時，測試者必須檢查程序的內部結構，從檢查程序的邏輯着手，得出測試數據。白盒測試是指打開盒子，去研究里面的源代碼和程序結果。
白盒測試也是接口測試的一種。
目的
1.保證一個模塊中的所有獨立路徑至少被執行一次；
2.對所有的邏輯值均需要測試真、假兩個分支；
3.在上下邊界及可操作范圍內運行所有循環；
4.檢查內部數據結構以確保其有效性。
測試方法
白盒測試的測試方法有代碼檢查法、靜態結構分析法、靜態質量度量法、邏輯覆蓋法、基本路徑測試法、域測試、符號測試、Z路徑覆蓋和程序變異。
白盒測試法的覆蓋標准有邏輯覆蓋、循環覆蓋和基本路徑測試。
覆蓋標准
邏輯覆蓋有：語句覆蓋、判定覆蓋（分支覆蓋）、條件覆蓋、判定/條件覆蓋、條件組合覆蓋、路徑覆蓋；
控制結構覆蓋有：基本路徑測試、循環測試、條件測試、數據流測試
代碼檢查法
代碼檢查是白盒測試的一種靜態測試方法，是一種對程序代碼進行靜態檢查。代碼檢查包括桌面檢查、代碼審查和走查等，主要檢查：
- 檢查代碼和設計的一致性；
- 代碼的可讀性及對軟件設計標准的遵循情況；
- 代碼邏輯表達的正確性；
- 代碼結構的合理性；
- 發現違背程序編寫標准的問題，程序中不安全、不明確和模糊的部分，找出程序中不可移植部分；
- 違背程序編程風格的內容，包括變量檢查、命名和類型審查、程序邏輯審查、程序語法檢查和程序結構檢查等內容。
代碼檢查方法
（1） 桌面檢查：
這是一種傳統的檢查方法，由程序員檢查自己編寫的程序。程序員在程序通過編譯之后，對源程序代碼進行分析、檢驗，並補充相關文檔，目的是發現程序中的錯誤。由於程序員熟悉自己的程序及其程序設計風格，桌面檢查由程序員自己進行可以節省很多的檢查時間，但應避免主觀片面性。
（2）代碼審查
由若干程序員和測試員組成一個審查小組，通過閱讀、討論和爭議，對程序進行靜態分析的過程。代碼審查分兩步：第一步，小組負責人提前把設計規格說明書、控制流程圖、程序文本及有關要求、規范等分發給小組成員，作為審查的依據。小組成員在充分閱讀這些材料后，進入審查的第二步，召開程序審查會。在會上，首先由程序員逐句簡介程序的邏輯。在此過程中，程序員或其他小組成員可以提出問題，展開討論，審查錯誤是否存在。實踐表明，程序員在講解過程中能發現許多原來自己沒有發現的錯誤，而討論和爭議則促進了問題的暴露。
在會前，應當給審查小組每個成員准備一份常見錯誤的清單，把以往所有可能發生的常見錯誤羅列出來，供與會者對照檢查，以提高審查的失效。這個常見的錯誤清單也成為檢查表，它把程序中可能發生的各種錯誤進行分類，對每一類錯誤列出盡可能多的典型錯誤，然后把它們制成表格，供再審查時使用。
（3）走查
與代碼審查基本相同，分為兩步，第一步也是把材料分給走查小組的每個成員，讓他們認真研究程序，然后再開會。開會的程序與代碼審查不同，不是簡單地讀程序和對照錯誤檢查表進行檢查，而是讓與會者“充當”計算機，即首先由測試組成員為所測試程序准備一批有代表性的測試用例，提交給走查小組。走查小組開會，集體扮演計算機角色，讓測試用例沿程序的邏輯運行一遍，隨時記錄程序的蹤跡，供分析和討論用。
代碼檢查應在編譯和動態測試之前進行，在檢查前，應准備好需求描述文檔、程序設計文檔、程序的源代碼清單、代碼編譯標准和代碼缺陷檢查表等。在實際使用中，代碼檢查能快速找到缺陷，發現30%～70%的邏輯設計和編碼缺陷，而且代碼檢查看到的問題本身而非征兆。但是代碼檢查非常耗費時間，而且代碼檢查需要知識和經驗的積累。
代碼檢查可以使用測試軟件進行自動化測試，以利於提高測試效率，降低勞動強度，或者使用人工進行測試，以充分發揮人力的邏輯思維能力。
代碼檢查項目
變量交叉引用表；標號的交叉引用表；檢查子程序、宏、函數；等價性檢查；常量檢查；標准檢查；風格檢查；比較控制流；選擇、激活路徑；補充文檔
根據檢查項目可以編制代碼規則、規范和檢查表等作為測試用例，如編碼規范、代碼檢查規范、缺陷檢查表等。
編碼規范
編碼規范是指程序在編寫過程中必須遵循的規則，一般會詳細制定代碼的語法規則、語法格式等。
代碼檢查規范
在代碼檢查中，需要依據被測軟件的特點，選用適當的標准與規則規范。在使用測試軟件進行自動化代碼檢查時，測試工具一般會內置許多的編碼規則。在自動化測試基礎上使用桌面檢查、代碼走查、代碼審查等人工檢查的方法仔細檢查程序的結構、邏輯等方面的缺陷。
缺陷檢查表
在進行人工代碼檢查時，代碼缺陷檢查表是我們用到的測試用例。代碼缺陷檢查表中一般包括容易出錯的地方和在以往的工作中遇到的典型錯誤。
靜態結構分析法
在靜態結構分析中，測試者通過使用測試工具分析程序源代碼的系統結構、數據結構、內部控制邏輯等內部結構，生成函數調用關系圖、模塊控制流圖、內部文件調用關系圖、子程序表、宏和函數參數表等各類圖形圖標，可以清晰地標識整個軟件系統的組成結構，使其便於閱讀和理解，然后可以通過分析這些圖標，檢查軟件有沒有存在缺陷或錯誤。
其中函數調用關系圖通過應用程序中各函數之間的調用關系展示了系統的結構。通過查看函數調用關系圖，可以檢查函數之間的調用關系是否符合要求，是否存在遞歸調用，函數的調用是否過深，有沒有存在獨立的沒有被調用的函數。從而可以發現系統是否存在結構缺陷，發現哪些函數是重要的，哪些是次要的，需要使用什么級別的覆蓋要求等。
模塊控制流圖是與程序流程圖相類似的，由許多節點和連接節點的邊組成的一種圖形，其中一個節點代表一條語句或數條語句，邊代表節點間控制流向，它顯示了一個函數的內部邏輯結構。模塊控制流圖可以直觀地反映出一個函數的內部邏輯結構，通過檢查這些模塊控制流圖，能夠很快發現軟件的錯誤與缺陷。
檢查項：代碼風格和規則審核；程序設計和結構的審核；業務邏輯的審核；走查、審查與技術復審手冊。
靜態質量度量法
1、度量規則
度量規則使用了代碼行數、注釋頻度等參數度量軟件的各種行為屬性。
2、分類標准
軟件的可維護性采用以下四個分類標准來評估：可分析性（ANALYZABILITY）、可修改性（CHANGEABILITY）、穩定性（STABILITY）、可測性（TESTABILITY）。每個分類標准由一系列度量規則組成，各個規則分配一個權重，由規則的取值與權重值計算出每個分類標准的取值。
function_TESTABILITY_DRCT_CALLS+LEVL+PATH+PARA
3、質量因素
質量因素的取值與分類標准的計算方式類似：依據各分類標准取值組合權重方法計算。
function_MAINTAINABILITY=function_ANALYZABILITY + function_CHANGEABILITY + function_ATABILITY + function_TESTABILITY
質量度量模型（從上到下）
質量因素（Factors）：與分類標准的計算方式相似，依據各分類標准取值組合權重方法來計算，依據結果將軟件質量分為四個等級，與分類標准等級內容相同。
分類標准（criteria）：對某一軟件質量分為不同的分類標准，每個分類標准由一系列度量規則組成，每個規則分配一個權重，每個分類標准的取值由規則的取值與權重值計算得出，依據結果將軟件質量分為四個等級：
優秀（exceent）：符合本模型框架中的所有規則（可以接受）
良好（good）：未大量偏離模型框架中的規則（可以接受）
一般（fair）：違背了模型框架中的大量規則（可以接受）
較差（poor）：無法保障正常的軟件可維護性（不可以接受）
度量規則（Metrics）：使用代碼行數、注釋頻度等參數度量軟件各種行為屬性
邏輯覆蓋
邏輯覆蓋是以程序內部的邏輯結構為基礎的設計測試用例的技術。其中邏輯覆蓋包括語句覆蓋、判定覆蓋、條件覆蓋、判定條件組合覆蓋、條件組合覆蓋和路徑覆蓋。六種覆蓋標准發現錯誤的能力呈由弱到強的變化：
1.語句覆蓋每條語句至少執行一次。
2.判定覆蓋每個判定的每個分支至少執行一次。
3.條件覆蓋每個判定的每個條件應取到各種可能的值。
4.判定/條件覆蓋同時滿足判定覆蓋和條件覆蓋。
5.條件組合覆蓋每個判定中各條件的每一種組合至少出現一次。
6.路徑覆蓋使程序中每一條可能的路徑至少執行一次。
邏輯覆蓋原則
語句覆蓋
定義
“語句覆蓋”是一個比較弱的測試標准，它的含義是：在測試時，首先設計若干個測試用例，然后運行被測程序， 使程序中的每個可執行語句至少執行一次。這時所謂“若干個”，自然是越少越好。即用最少得測試用例來達到語句全覆蓋。
用例設計
為使程序中每個語句至少執行一次，只需設計一個能通過路徑ace的例子就可以了，例如選擇輸入數據為： A=2，B=0，X=4
這樣該程序段的4個語句均得到執行，從而作到了語句覆蓋。
優點
可以很直觀地從源代碼得到測試用例，無須細分每條判定表達式。
缺點
由於這種測試方法僅僅針對程序邏輯中顯式存在的語句（即可執行語句），但對於隱藏的條件和可能到達的隱式邏輯分支，是無法測試的。
判定覆蓋
定義
比“語句覆蓋”稍強的覆蓋標准是“判定覆蓋”(或稱branch coverage分支覆蓋)標准。判定覆蓋准則進行測試是指，設計若干測試用例，運行被測程序，使得程序中每個判斷的取真分支和取假分支至少經歷一次，即判斷的真假值均曾被滿足。判定覆蓋又稱為分支覆蓋。設計測試用例只需要用最少條數，以判定條件結果為全真或者全假的思路來編寫測試用例。
用例設計
如果設計兩個例子，使它們能通過路徑ace和abd，或者通過路徑acd和abe，就可達到“判定覆蓋”標准，為此，可以選擇輸入數據為：
①A=2，B=0，X=4(沿判定條件結果為全真路徑ace執行)
②A=1，B=1，X=1(沿判定條件結果為全假路徑abd執行)
優點
判定覆蓋比語句覆蓋要多幾乎一倍的測試路徑，當然也就具有比語句覆蓋更強的測試能力。同樣判定覆蓋也具有和語句覆蓋一樣的簡單性，無須細分每個判定就可以得到測試用例。
缺點
往往大部分的判定語句是由多個邏輯條件組合而成（如，判定語句中包含AND、OR、CASE），若僅僅判斷其整個最終結果，而忽略每個條件的取值情況，必然會遺漏部分測試路徑。
條件覆蓋
定義
條件覆蓋於分支覆蓋不同，條件覆蓋要求所設計的測試用例能使每個判定中的每一個條件都獲得可能的取值，即每個條件至少有一次真值、有一次假值。
用例設計
A＞1、B=0、A=2、X＞1
為了達到“條件覆蓋”標准，需要執行足夠的測試用例使得在判定條件1處有：
A＞1、A≤1、B=0、B≠0
等各種結果出現，以及在判定條件2處有：A=2、A≠2、X＞1、X≤1等各種結果出現。
現在只需設計以下兩個測試用例就可滿足這一標准：
① A=2，B=0，X=4(沿判定條件中的各個條件都為真路徑ace執行)；
② A=1，B=1，X=1(沿判定條件中的各個條件都為假路徑abd執行)
優點
增加了對條件判定情況的測試，增加了測試路徑。
缺點
條件覆蓋不一定包含判定覆蓋。條件覆蓋只能保證每個條件至少有一次為真，而不考慮所有的判定結果。
判定條件組合覆蓋
定義
執行足夠的測試用例，使得判定中每個條件取到各種可能的值，並使每個判定取到各種可能的結果。
用例設計
A＞1、B=0、A=2、X＞1
為了達到“條件覆蓋”標准，需要執行足夠的測試用例使得在判定條件1處有：
A＞1、A≤1、B=0、B≠0
等各種結果出現，以及在判定條件2處有：A=2、A≠2、X＞1、X≤1等各種結果出現。
另外也要滿足判定條件1處結果出現一次真和一次假，則要保證（A>1 AND B=0）為真（A=2，B=0）和為假（A=1，B=1），同時也滿足了條件覆蓋說的每個條件都要出現一次真和一次假。（A=2為真，B=0為真）和為假（A=1為假，B=1為假）。
同理判定條件2處結果出現一次真和一次假，則要保證（A=2 OR X>1）為真（A=2，X=4）和為假（A=1，X=1），同時也滿足了條件覆蓋說的每個條件都要出現一次真和一次假。（A=2為真，X=4為真）和為假（A=1為假，X=1為假）。
現在只需設計以下兩個測試用例就可滿足這一標准：
① A=2，B=0，X=4(沿判定條件中的各個條件都為真，同時也滿足判定條件結果均為真路徑ace執行)；
② A=1，B=1，X=1(沿判定條件中的各個條件都為假，同時也滿足判定條件結果均為假路徑abd執行)
優點
能同時滿足判定、條件兩種覆蓋標准。
缺點
判定/條件覆蓋准則的缺點是未考慮條件的組合情況。
條件組合覆蓋
定義
執行足夠的例子，使得每個判定中條件的各種可能組合都至少出現一次。顯然，滿足“條件組合覆蓋”的測試用例是一定滿足“判定覆蓋”、“條件覆蓋”和“判定/條件覆蓋”的。
用例設計
條件組合覆蓋說的判定條件里的每個條件組合在一起形成的各種可能。
使得下面8種條件組合都能夠出現：
1)A>1, B=0 2)A>1, B≠0 3)A≤1, B=0 4)A≤1, B≠0
5)A=2, X>1 6)A=2, X≤1 7)A≠2, X>1 8)A≠2, X≤1
判定條件1里有2個條件，所以條件組合的情況是2*2=4個的情況；排列組合里的組合邏輯形成的個數。如果有3個條件，則就有2*2*2=8個的情況，以此類推。
判定條件1：（A=2為真，B=0為真）、（A=2為真，B=1為假）、（A=1為假，B=0為真）、（A=1為假，B=1為假）。
判定條件2:（A=2為真，X=4為真）、（A=2為真，X=1為假）、（A=1為假，X=4為真）、（A=1為假，X=1為假）。
現在只需設計以下兩個測試用例就可滿足這一標准：
① A=2，B=0，X=4(沿判定條件中的各個條件A=2為真，B=0為真，A=2為真，X=4為真，路徑ace執行)；
② A=2，B=1，X=1(沿判定條件中的各個條件A=2為真，B=1為假，A=2為真，X=1為假，路徑abe執行)；
③ A=1，B=0，X=2(沿判定條件中的各個條件A=1為假，B=0為真，A=1為假，X=2為真，路徑abe執行)；
④ A=1，B=1，X=1(沿判定條件中的各個條件A=1為假，B=1為假，A=1為假，X=1為假，路徑abd執行)
上面四個例子雖然滿足條件組合覆蓋，但並不能覆蓋程序中的每一條路徑，例如路徑acd就沒有執行，因此，條件組合覆蓋標准仍然是不徹底。
優點
能同時滿足判定、條件兩種覆蓋標准。條件組合覆蓋准則滿足判定覆蓋、條件覆蓋和判定/條件覆蓋准則。
缺點
線性地增加了測試用例的數量。
路徑覆蓋
定義
選取足夠多的測試數據，使程序的每條可能路徑都至少執行一次（如果程序圖中有環，則要求每個環至少經過一次）。
對於比較簡單的小程序來說，實現路徑覆蓋是可能的，但是如果程序中出現了多個判斷和多個循環，可能的路徑數目將會急劇增長，以致實現路徑覆蓋是幾乎不可能的。
所以我們需要路徑分析，計算程序中的路徑數（復雜度）。
以下的公式：V（G）=e-n+2
PS:其中e為邊數，n為結點數。
優點
這種測試方法可以對程序進行徹底的測試，比前面五種的覆蓋面都廣。
缺點
需要設計大量、復雜的測試用例，使得工作量呈指數級增長，不見得把所有的條件組合都覆蓋。
基本路徑測試法
在程序控制圖的基礎上，通過分析控制構造的環行復雜性，導出基本可執行路徑集合，從而設計測試用例。設計出的測試用例要保證在測試中程序的每一個基本獨立路徑至少執行一次。
在程序控制流圖的基礎上，通過分析控制構造的環路復雜性，導出基本可執行路徑集合，從而設計測試用例。
包括以下4 個步驟
1. 程序的控制流圖：描述程序控制流的一種圖示方法。
2. 程序圈復雜度：McCabe復雜性度量。從程序的環路復雜性可導出程序基本路徑集合中的獨立路徑條數，這是確定程序中每個可執行語句至少執行一次所必須的測試用例數目的上界。
3. 導出測試用例：根據圈復雜度和程序結構設計用例數據輸入和預期結果。
4. 准備測試用例：確保基本路徑集中的每一條路徑的執行。
一個工具方法：
圖形矩陣：是在基本路徑測試中起輔助作用的軟件工具，利用它可以實現自動地確定一個基本路徑集。
另外，對於測試用例的選擇除了滿足所選擇的覆蓋程度(或覆蓋標准)外還需要盡可能的采用邊界值分析法、錯誤推測法等常用地設計方法。采用邊界值分析法設計合理的輸入條件與不合理的輸入條件;條件邊界測試用例應該包括輸入參數的邊界與條件邊界(if，while，for，switch ，SQL Where子句等)。錯誤推測法，列舉出程序中所有可能的錯誤和容易發生錯誤的特殊情況，根據它們選擇測試用例;在編碼、單元測試階段可以發現很多常見的錯誤和疑似錯誤，對於這些錯誤應該作重點測試，並設計相應的測試用例。
控制流圖
基本語句對應的控制流圖：
程序流程圖->控制流圖
如何根據程序流程圖畫出控制流程圖?
在將程序流程圖簡化成控制流圖時，應注意：
1）在選擇或多分支結構中，分支的匯聚處應有一個匯聚結點。
2）邊和結點圈定的范圍叫做區域，當對區域計數時，圖形外的區域也應記為一個區域。
如下圖所示：
三種計算方法：
1. 控制流圖中區域的數量
2. V（G）= E-N+2，E是邊數，N是結點數
3. V（G）= P+1，P是判定結點的數量
圓圈稱為控制流圖的一個結點，表示一個或多個無分支的語句或源程序語句
獨立路徑( 基本路徑)
一條程序執行的路徑 ，至少包含一條在定義該路徑之前的其他基本路徑中所不曾用過的邊( 即：至少引入程序的一個新處理語句集合或一個新條件)
注意：獨立路徑不應該經過同一個判定結點的左右兩側，否則這條路徑如果出現錯誤，則不知道是哪一側出現錯誤。
設計測試用例步驟
第一步：畫出控制流圖
流程圖用來描述程序控制結構。可將流程圖映射到一個相應的流圖(假設流程圖的菱形決定框中不包含復合條件)。在流圖中，每一個圓，稱為流圖的結點，代表一個或多個語句。一個處理方框序列和一個菱形決策框可被映射為一個結點，流圖中的箭頭，稱為邊或連接，代表控制流，類似於流程圖中的箭頭。一條邊必須終止於一個結點，即使該結點並不代表任何語句(例如：if-else-then結構)。由邊和結點限定的范圍稱為區域。計算區域時應包括圖外部的范圍。
畫出其程序流程圖和對應的控制流圖如下
第二步：計算圈復雜度
圈復雜度是一種為程序邏輯復雜性提供定量測度的軟件度量，將該度量用於計算程序的基本的獨立路徑數目，為確保所有語句至少執行一次的測試數量的上界。獨立路徑必須包含一條在定義之前不曾用到的邊。
有以下三種方法計算圈復雜度：
流圖中區域的數量對應於環型的復雜性;
給定流圖G的圈復雜度V(G)，定義為V(G)=E-N+2，E是流圖中邊的數量，N是流圖中結點的數量;
給定流圖G的圈復雜度V(G)，定義為V(G)=P+1，P是控制流圖G中判定結點的數量。
第三步：導出測試用例
根據上面的計算方法，可得出四個獨立的路徑。(一條獨立路徑是指和其他的獨立路徑相比，至少引入一個新處理語句或一個新判斷的程序通路。V(G)值正好等於該程序的獨立路徑的條數。)
路徑1：4-14
路徑2：4-6-7-14
路徑3：4-6-8-10-13-4-14
路徑4：4-6-8-11-13-4-14
根據上面的獨立路徑，去設計輸入數據，使程序分別執行到上面四條路徑。
第四步：准備測試用例
為了確保基本路徑集中的每一條路徑的執行，根據判斷結點給出的條件，選擇適當的數據以保證某一條路徑可以被測試到，滿足上面例子基本路徑集的測試用例是：
工具方法：圖形矩陣
導出控制流圖和決定基本測試路徑的過程均需要機械化，為了開發輔助基本路徑測試的軟件工具，稱為圖形矩陣(graph matrix)的數據結構很有用。利用圖形矩陣可以實現自動地確定一個基本路徑集。一個圖形矩陣是一個方陣,其行/列數控制流圖中的結點數，每行和每列依次對應到一個被標識的結點，矩陣元素對應到結點間的連接（即邊）。
對每個矩陣項加入連接權值(link weight)，圖矩陣就可以用於在測試中評估程序的控制結構，連接權值為控制流提供了另外的信息。最簡單情況下，連接權值是 1(存在連接)或0(不存在連接)，但是，連接權值可以賦予更有趣的屬性：
執行連接(邊)的概率。
穿越連接的處理時間。
穿越連接時所需的內存。
穿越連接時所需的資源。
上圖為圖形矩陣：
連接權為“1”表示存在一個連接，在圖中如果一行有兩個或更多的元素“1”，則這行所代表的結點一定是一個判定結點，通過連接矩陣中有兩個以上（包括兩個）元素為“1”的個數，就可以得到確定該圖圈復雜度的另一種算法。
循環測試
從本質上來說，循環測試的目的就是檢查循環結構的有效性。
四種循環 ：簡單循環 、嵌套循環 、串接循環、無結構循環（非結構循環）
簡單循環
對於簡單循環，測試應包括以下幾種，其中的n 表示循環允許的最大次數。
1.零次循環：從循環入口直接跳到循環出口。 （換句話說：跳過循環）
2. 一次循環：查找循環初始值方面的錯誤。
3. 二次循環：檢查在多次循環時才能暴露的錯誤。
4. m次循環：此時的m＜n-1（通常取m=n/2），也是檢查在多次循環時才能暴露的錯誤。
5. n(最大)次數循環、n+1(比最大次數多一)次的循環、n-1(比最大次數少一)次的循環。
嵌套循環
1.從最內層循環開始，設置所有其他層的循環為最小值；
2.對最內層循環使用簡單循環的全部測試。測試時保持所有外層循環的循環變量（迭代參數）為最小值。另外，對越界值和非法值增加一些額外的測試。
3.逐步外推，對其外面一層循環進行測試。測試時保持所有外層循環的循環變量取最小值，所有其它嵌套內層循環的循環變量取“典型”值。
4.反復進行，直到所有各層循環測試完畢。
5.對全部各層循環同時取最小循環次數，或者同時取最大循環次數。對於后一種測試，由於測試量太大，需人為指定最大循環次數。
舉例說明
1 案例描述
昨天去面試，面試官出了一道面試題目，但是知道一個初步的優化，但不知道為什么會有性能提高,下去上網才恍然大悟：
題目是這樣的：請對以下的代碼進行優化
Java代碼
for (int i = 0; i < 1000; i++)
for (int j = 0; j < 100; j++)
for (int k = 0; k < 10; k++)
testFunction (i, j, k);
（注：為了同后面的內容一致，這里對原題目進行了部分修改）
2 案例分析
從給出的代碼可知，不論如何優化，testFunction執行的次數都是相同的，該部分不存在優化的可能。那么，代碼的優化只能從循環變量i、j、k的實例化、初始化、比較、自增等方面的耗時上進行分析。
首先，我們先分析原題代碼循環變量在實例化、初始化、比較、自增等方面的耗時情況：
| 變量 |
實例化(次數) |
初始化(次數) |
比較(次數) |
自增(次數) |
| i |
1 |
1 |
1000 |
1000 |
| j |
1000 |
1000 |
1000 * 100 |
1000 * 100 |
| k |
1000 * 100 |
1000 * 100 |
1000 * 100 * 10 |
1000 * 100 * 10 |
（注：由於單次耗時視不同機器配置而不同，上表相關耗時采用處理的次數進行說明）
該代碼的性能優化就是盡可能減少循環變量i、j、k的實例化、初始化、比較、自增的次數，同時，不能引進其它可能的運算耗時。
3 解決過程
從案例分析，對於原題代碼，我們提出有兩種優化方案：
3.1 優化方案一
代碼如下：
Java代碼
for (int i = 0; i < 10; i++)
for (int j = 0; j < 100; j++)
for (int k = 0; k < 1000; k++)
testFunction (k, j, i);
該方案主要是將循環次數最少的放到外面，循環次數最多的放里面，這樣可以最大程度的（注：3個不同次數的循環變量共有6種排列組合情況，此種組合為最優）減少相關循環變量的實例化次數、初始化次數、比較次數、自增次數，方案耗時情況如下：
| 變量 |
實例化(次數) |
初始化(次數) |
比較(次數) |
自增(次數) |
| i |
1 |
1 |
10 |
10 |
| j |
10 |
10 |
10 * 100 |
10 * 100 |
| k |
10 * 100 |
10 * 100 |
10 * 100 * 1000 |
10 * 100 * 1000 |
3.2 優化方案二
代碼如下：
Java代碼
int i, j, k;
for (i = 0; i < 10; i++)
for (j = 0; j < 100; j++)
for (k = 0; k < 1000; k++)
testFunction (k, j, i);
該方案在方案一的基礎上，將循環變量的實例化放到循環外，這樣可以進一步減少相關循環變量的實例化次數，方案耗時情況如下：
| 變量 |
實例化(次數) |
初始化(次數) |
比較(次數) |
自增(次數) |
| i |
1 |
1 |
10 |
10 |
| j |
1 |
10 |
10 * 100 |
10 * 100 |
| k |
1 |
10 * 100 |
10 * 100 * 1000 |
10 * 100 * 1000 |
4 解決結果
那么，提出的優化方案是否如我們分析的那樣有了性能上的提升了呢？我們編寫一些測試代碼進行驗證，數據更能說明我們的優化效果。
4.1 測試代碼
Java代碼
public static void testFunction(int i, int j, int k) {
System.out.print(""); // 注：該方法不影響整體優化，這里只有簡單輸出
}
public static void testA() {
long start = System.nanoTime();
for (int i = 0; i < 1000; i++)
for (int j = 0; j < 100; j++)
for (int k = 0; k < 10; k++)
testFunction(i, j, k);
System.out.println("testA time>>" + (System.nanoTime() - start));
}
public static void testB() {
long start = System.nanoTime();
for (int i = 0; i < 10; i++)
for (int j = 0; j < 100; j++)
for (int k = 0; k < 1000; k++)
testFunction(k, j, i);
System.out.println("testB time>>" + (System.nanoTime() - start));
}
public static void testC() {
long start = System.nanoTime();
int i;
int j;
int k;
for (i = 0; i < 10; i++)
for (j = 0; j < 100; j++)
for (k = 0; k < 1000; k++)
testFunction(k, j, i);
System.out.println("testC time>>" + (System.nanoTime() - start));
}
4.2 測試結果
1、測試機器配置：Pentium(R) Dual-Core CPU E5400 @2.70GHz 2.70GHz, 2GB內存；
2、循環變量i、j、k循環次數分別為10、100、1000，進行5組測試，測試結果如下：
|
|
第1組 |
第2組 |
第3組 |
第4組 |
第5組 |
| 原方案 |
171846271 |
173250166 |
173910870 |
173199875 |
173725328 |
| 方案一 |
168839312 |
168466660 |
168372616 |
168310190 |
168041251 |
| 方案二 |
168001838 |
169141906 |
168230655 |
169421766 |
168240748 |
從上面的測試結果來看，優化后的方案明顯性能優於原方案，達到了優化的效果。但優化方案二並沒有如我們預期的優於方案一，其中第2、4、5組的數據更是比方案一差，懷疑可能是循環次數太少，以及測試環境相關因素影響下出現的結果。
3、重新調整循環變量i、j、k循環次數分別為20、200、2000，進行5組測試，測試結果如下：
|
|
第1組 |
第2組 |
第3組 |
第4組 |
第5組 |
| 原方案 |
1355397203 |
1358978176 |
1358128281 |
1350193682 |
1354786598 |
| 方案一 |
1343482704 |
1348410388 |
1343978037 |
1347919156 |
1340697793 |
| 方案二 |
1342427528 |
1343897887 |
1342662462 |
1342124048 |
1336266453 |
從上面的測試結果來看，優化后的方案基本符合我們的預期結果。
5 總結
從案例分析和解決過程中的三個表的分析可知，優化方案一和優化方案二的性能都比原代碼的性能好，其中優化方案二的性能是最好的。在嵌套For循環中，將循環次數多的循環放在內側，循環次數少的循環放在外側，其性能會提高；減少循環變量的實例化，其性能也會提高。從測試數據可知，對於兩種優化方案，如果在循環次數較少的情況下，其運行效果區別不大；但在循環次數較多的情況下，其效果就比較明顯了。
串接循環
對於串接循環，要區別兩種情況。
1.如果各個循環互相獨立，則串接循環可以用與簡單循環相同的方法進行測試。
2.如果有兩個循環處於串接狀態，而前一個循環的循環變量的值是后一個循環的初值。則這幾個循環不是互相獨立的，則需要使用測試嵌套循環的辦法來處理。
對於非結構循環，不能測試， 應重新設計循環結構，使之成為其它循環方式，然后再進行測試。
條件測試
條件測試方法注重於測試程序中的條件。是檢查程序模塊中所包含邏輯條件的測試用例設計方法。
條件
程序中的條件分為簡單條件和復合條件。
簡單條件是一個布爾變量或一個可能帶有NOT(“！”)操作符的關系表達式。關系表達式的形式如：
E1＜關系操作符＞E2
其中E1和E2是算術表達式，而＜關系操作符＞是下列之一：“＜”、“≤”、“=”、“≠”(“！=”)、“＞”、或“≥”。
復合條件由簡單條件通過邏輯運算符（AND、OR、NOT）和括號連接而成，不含關系表達式的條件稱為布爾表達式。
所以條件的成分類型包括：布爾操作符、布爾變量、布爾括弧(括住簡單或復雜條件)、關系操作符、算術表達式。
條件測試的目的
條件測試是測試程序條件錯誤和程序的其他錯誤。如果程序的測試集能夠有效地檢測程序中的條件錯誤，則該測試集可能也會有效地檢測程序中的其他錯誤。此外，如果測試策略對檢測條件錯誤有效，則它也可能有效地檢測程序錯誤。
條件測試策略
1) 窮舉測試（條件組合）
有n個變量的布爾表達式需要2n個可能的測試(n＞0)。這種策略可以發現布爾操作符、變量和括弧的錯誤，但是只有在n很小時實用。
2) 分支測試
分支測試可能是最簡單的條件測試策略，它是真假分支必須至少執行一次的路徑策略，對於復合條件C，C的真分支和假分支以及C中的每個簡單條件都需要至少執行一次。
域測試是對於大於、小於和等於的值的測試路徑策略。域測試要求從有理表達式中導出三個或四個測試，有理表達式的形式如：
E1＜關系操作符＞E2
需要三個測試分別用於計算E1的值是大於、等於或小於E2的值。如果＜關系操作符＞錯誤，而E1和E2正確，則這三個測試能夠發現關系算式的錯誤。為了發現E1和E2的錯誤，計算E1小於或大於E2的測試應使兩個值間的差別盡可能小。
3) BRO(branch and relational) 測試
如果在一個判定的復合條件表達式中每個布爾變量和關系運算符最多只出現一次，而且沒有公共變量，應用一種稱之為BRO（分支與關系運算符）的測試法可以發現多個布爾運算符或關系運算符錯，以及其他錯誤。
BRO策略引入條件約束的概念。設有n個簡單條件的復合條件C，其條件約束為D= (D1，D2，…，Dn) ，其中Di(0＜i≤n)是條件C中第i個簡單條件的輸出約束。如果在C的執行過程中，其每個簡單條件的輸出都滿足D中對應的約束，則稱條件C的條件約束D由C的執行所覆蓋。對於布爾變量或布爾表達式B，B的輸出約束必須是真（t）或假（f）；對於關系表達式，其輸出約束為符號>、=、< 。
域測試
由於程序中每條路徑對應着一個輸入域，是程序的一個子計算。如果程序的控制流有錯誤，則對某一特定的輸入可能執行的是一條錯誤路徑，這種錯誤被稱為路徑錯誤或域錯誤。
而域測試主要是針對域錯誤進行的測試。
域測試的基本步驟如下：
（1）：根據各個分支謂詞，給出子域的分割圖；
（2）：對每個子域的邊界，采用ON-OFF-ON原則選取測試點。
（3）：在子域內選取一些測試點。
（4）：針對這些測試點進行測試。
符號測試
Z路徑覆蓋測試
實施步驟
1.測試計划階段：根據需求說明書，制定測試進度。
2.測試設計階段：依據程序設計說明書，按照一定規范化的方法進行軟件結構划分和設計測試用例。
3.測試執行階段：輸入測試用例，得到測試結果。
4.測試總結階段：對比測試的結果和代碼的預期結果，分析錯誤原因，找到並解決錯誤。
優缺點
優點
1.迫使測試人員去仔細思考軟件的實現
2.可以檢測代碼中的每條分支和路徑
3.揭示隱藏在代碼中的錯誤
4.對代碼的測試比較徹底
5.最優化
缺點
1.代價有些高，需要測試人員有編程能力
2.無法檢測代碼中遺漏的路徑和數據敏感性錯誤
3.不能直接驗證需求的正確性
局限
即使每條路徑都測試了仍然可能有錯誤。可能出現的情況如下：
窮舉路徑測試決不能查出程序違反了設計規范，即程序本身是個錯誤的程序。
窮舉路徑測試不可能查出程序中因遺漏路徑而出錯。
窮舉路徑測試可能發現不了一些與數據相關的錯誤。
3.灰盒測試（Gray-Box Testing）
灰盒測試是介於白盒測試和黑盒測試之間的一種，灰盒測試多用於集成測試階段，不僅關注輸入、輸出的正確性，同時也關注程序內部的情況。灰盒測試不像白盒測試那樣詳細、完整，但又比黑盒測試更關注程序的內部邏輯，常常是通過一些表征性的現象、事件、標志來判斷內部的運行狀態。有時候輸出是正確的，但內部其實已經錯誤了，這種情況非常多，如果每次都通過白盒測試來操作，效率會很低，因此需要采取這樣的一種灰盒的方法。
灰盒測試：功能+接口
定義
灰盒測試由方法和工具組成，這些方法和工具取材於應用程序的內部知識和與之交互的環境，能夠用於黑盒測試以增強測試效率、錯誤發現和錯誤分析的效率。灰盒測試涉及輸入和輸出，但使用關於代碼和程序操作等通常在測試人員視野之外的信息設計測試。
目的
一、確認軟件的質量
二、提供信息，提供給開發人員或程序經理的反饋信息，為風險評估所准備的信息。
三、軟件測試不僅是在測試軟件產品的本身，而且還包括軟件開發的過程。
測試任務
1、尋找Bug；
2、避免軟件開發過程中的缺陷；
3、衡量軟件的品質；
4、關注用戶的需求。
如何做好灰盒測試？
- 測試定位要清晰。灰盒測試的對象應該是整個產品，而非各個組件，應從整個測試產品的業務出發進行測試設計。
- 測試階段要正確。灰盒測試應該在集成測試中采用,他並不適合於單元測試。
- 測試輔助要必備。灰盒測試需要深入產品代碼邏輯，對於測試人員來說，業務邏輯圖是必不可少的，測試人員需要根據業務邏輯圖進行功能點划分，並擴展用例。另外可以借助於測試覆蓋率等工具輔助查找遺漏功能點。
- 運行狀態檢查點要仔細選擇。灰盒測試對於程序運行狀態的檢查往往采用標志來判斷，測試人員一定要仔細考慮，否則很容易遺漏某些bug。
做灰盒測試需要哪些條件呢？
1、需要在測試中，除了部署產品之外，還有就是程序源代碼，不管外部是多少漂亮界面或易用的功能，最終都是由源代碼來實現的。所以在部署時，要安裝源代碼。從源代碼編譯生成的目錄中運行軟件。
2、需要代碼覆蓋率工具的配置；部署可以針對本軟件開發語言的代碼覆蓋率工具；
3、測試人員要具備閱讀代碼的能力，其對開發語言的熟悉程度和程序設計經驗多少決定了采用灰盒測試能夠取得多大的好處，所以配置這方面的測試人員或進行必要的培訓是必要的。
那么有人可能問，服務器端軟件適合做灰盒測試嗎？回答是肯定的。任何一個項目都可以從灰盒測試中獲得裨益。不管是手機中使用的各種嵌入式軟件、還是web頁面和服務器端的任何腳本，都可以運用這種測試方法。
優點
1、 能夠進行基於需求的覆蓋測試和基於程序路徑覆蓋的測試；
2、 測試結果可以對應到程序內部路徑，便於bug的定位、分析和解決；
3、 能夠保證設計的黑盒測試用例的完整性，防止遺漏軟件的一些不常用的功能或功能組合；
4、 能夠需求或設計不詳細或不完整對測試造成的影響。
缺點
1、 投入的時間比黑盒測試大概多20-40％的時間；
2、 對測試人員的技術要求更高；
灰盒測試的好處
測試者可能知道系統組件之間是如何互相作用的，但缺乏對內部程序功能和運作的詳細了解。對於內部過程，灰盒測試把程序看作一個必須從外面進行分析的黑盒。灰盒測試通常與web服務應用一起使用，因為盡管應用程序復雜多變，並不斷發展進步，因特網仍可以提供相對穩定的接口。由於不需要測試者接觸源代碼，因此灰盒測試不存在侵略性和偏見。開發者和測試者間有明顯的區別，人事沖突的風險減到最小。
灰盒測試相對於黑盒測試和白盒測試有什么特點？
1.灰盒測試比白盒測試效率高，從程序的整體出發，而非細節.
2.灰盒測試健壯性好，相對於白盒測試降低了程序代碼改變而導致用例失效的風險。
3.灰盒測試更細致。灰盒測試要求測試人員關注程序的代碼邏輯，根據代碼邏輯擴充用例，更加細致。