【引言】工作關系，作為曾經的獨立測試部門，現在與開發團隊一起組成Scrum Team融合階段。

因為以前的項目系統問題較多，上邊大老板為了提高開發團隊的代碼提交質量，要求開發除了必要的Unit Test之外，也到做一些E2E的Functioanl Testing俗稱Dev Testing；而QA的SIT Testing則可以側重更廣的E2E範圍甚至直接上Regression。

而跟開發最近幾次的會議討論中，發現很多開發人員多次提出Dev Testing的側重點和測試範圍，並反復提到很可能與QA Testing有重復性工作。

作為從獨立的QA/Testing部門來的測試人員，當開發把問題拋給我們的時候，我們可能比較套路的回復說，建議開發做“白盒測試”，而測試團隊負責“黑盒測試”。

但其實從一直以來的“黑盒測試”入門軟件測試的人來說，對什麽是真正高效和有效的“白盒測試”並不十分清楚。所以需要補充下理論知識，並嘗試了解下業內較為成熟的實踐部分，再回頭找開發團隊討論，並希望提供給他們一些關於“白盒測試”的好的思路。

參考

白盒測試：理論基礎

ISTQB – White Box Testing Techniques in Software Testing

為什麽國內很少有公司做白盒測試？

Structure Based or White Box techniques

White-box test design techniques (also called structural or structure- based techniques) are used to derive test cases from an analysis of the program(code). Deriving test case after analysis or understanding programs

In contrast to black box testing where test cases are designed from specification.

How to derive test cases from a program? And also how to derive coverage metrics for tests undertake?

Test cases from code are similar to black box test cases, but think test data here – like what values you will provide to run through the code. The emphasis here is what lines will be executed with the data you provide. And the minimum number of test cases to achieve this.

Blank Box testing limitations: During Black Box testing, depending on the tester’s experience, after a full round of System testing, the lines of code covered varies between 30% and 70%. So that leaves a lot of lines of code untested.

Coverage metrics help understand what lines are not covered and help us design test cases to increase the coverage. There are certain tools available to measure the lines of code covered when tests are run.

Statement coverage: If the test case executes every line of code in the program, it is called 100% statement coverage.

Decision coverage: If the test cases execute both the decisions, it is called 100% decision coverage.

Statement Coverage = Number of executable statements executed x 100
                        Total number of executable statements

Decision Coverage = Number of decisions exercised x 100
                        Total number of decisions

Coding Structures: A program code can be sequential where statements execute one after another. Execution of code can also be based on a condition being true or false.

Sequential or Linear statements: Example of a sequential code, where the program is executed line after line.

1  READ  A
2  READ B
3  Sum = A+ B

Test cases for Sequential statements are simple, assign values to A & B.

For eg, test case /data : A=1, B=2, will run through statements 1,2,3 or all the lines of this program. In this case, one test case is needed for 100% Statement coverage.

Selection or Decisions: In this case the computer has to decide if a condition is true or false. If it is true the computer takes one route, and if it is false the computer takes a different route.

IF (condition is true)
   Do this
ELSE  (condition is False)
   Do something else
END IF

Eg:

1 IF Age  > 16
2              Process License application
3 ELSE
4              Decline the License application process
5 END IF

Test cases: Age =18 tests lines 1,2,5 and Age =14 tests lines 1,3,4,5.

So, 2 test cases are needed to execute every line of code. And 2 test cases to execute the True and False conditions. So 2 test cases are needed for 100% Statement and Decision coverage.

There may not always be an ELSE part, as below:

 1 IF Age  >16
 2    THEN
 3     "Process License Application"
 4  ENDIF

Test cases for the above, assigning Age =18 tests lines 1,2,3,4, so only one test case is needed to execute every line of code.

But 2 test cases are needed to test the decisions: 1 to execute the True (Age > 16) and False(Age < 16). Why?

Because for Age <16 , we need to ensure the program does not do anything, it needs to go to the ENDIF.

Hence Decision coverage is stronger than Statement coverage. 100% Decision coverage ensures 100% Statement coverage. The vice versa is not true.

Consider the following:

1  IF (Age  > 16) and (Gender = Female)
2              Process License application
3 ELSE
4              Decline the License application process
5 END IF

1  IF (Age  > 16) or (Gender = Female)
2              Process License application
3 ELSE
4              Decline the License application process
5 END IF

Assign (Age =18 and Gender=Female) to test lines 1,2,5 and (Age=14, Gender = Male) to test lines 1,3,4,5. So, 2 test cases are needed to execute every line of code(100% Statement coverage). And 2 test cases to test both the decisions – true and false (100% Decision Coverage).

In the above examples, we see why Decision coverage is inadequate, all conditions are not fully tested:

Age >16 & Female, Age > 16 & Male, Age <16 and Female and Age <16 & Male will cover all the combinations. Hence the need for other stronger metrics.

Nested Ifs or multiple IFs within an IF:

1 IF ( Age > 17)
2  IF Age <50
3     Print Age is between 17 and 50
4   ELSE IF ( Age > 50)
5      Print Age is greater than 50
6  END IF
7 ELSE
8   Print Age is less than 17.
9 END IF

Test cases for the above, assigning Age =16, Age =51 and Age =29 (3 test cases) will test every line/statement and every decision..

CASE Structure: The nested If can also be expressed as a CASE structure.

Case Age > 50:
Report “Age is greater than 50”
Case Grade > 17:
Report “Age is between 17 and 50”
Default:
Report “Age is less than 17”
End Case

Again, assigning Age =16, Age =51 and Age =29 (3 test cases) will test every line and every decision..

Iterations or loops: When an action needs to repeated until the Condition becomes False, loops are used. There are 2 types of loops, While -Do and Repeat Until

DO WHILE condition
  sequence
ENDWHILE

The loop is entered only if the condition is true. The “sequence” is performed for each iteration. At the conclusion of each iteration, the condition is evaluated and the loop continues as long as the condition is true.

Eg:

WHILE ( Shopping Trolley not empty)
DO
     Add Cost of Item to Total.
     Print the item name and item cost
END DO
Print TotalCost

　　Test cases for Do-While – the loop is entered if the condition is true, so one test case that has a true value is enough to test all the lines of code and the decision.

　　There is another variation of the loop structure known as a REPEAT UNTIL loop.

This loop is similar to the WHILE loop except that the test is performed at the bottom of the loop instead of at the top. Two keywords, REPEAT and UNTIL are used. The general form is:

REPEAT
   sequence
UNTIL condition

Again, only one test case is sufficient to test all lines of code for both Statement and Decision Coverage.

白盒測試前期成本之高是無法想象的，一是白盒測試人員的培訓，二是工具的開發。
人員培訓包括要知道語句覆蓋，條件覆蓋，判斷覆蓋，條件判斷覆蓋，獨立路徑覆蓋。再深入一點還要懂數據流測試(定義使用，程序切片…)。直接上來就設計白盒測試用例比較少，原因是設計的信息不足。一般是先按功能需求，以黑盒測試設計方法寫用例。跑了用例，再用白盒的方法精簡用例和增加用例。以白盒測試的方法增加用例，必要的技能是看懂代碼吧。不然怎麽保證用例能覆蓋到某個if分支，while循環次數要求呢？要是對模塊進行接口測試，要寫驅動，要寫樁程序吧。
要做上面的事還要寫測試框架，把一些與具體用例無關，但是常用的公共功能，如參數化，結果斷言，出報告等等實現。讓測試人員專心為用例寫測試代碼。還好來源大潮提供了不少選擇，如xunit，googletest。還有覆蓋工具，如Emma,codecover, ncover,不過大部分也只提供了語句覆蓋，判斷覆蓋的信息，少部分有循環覆蓋信息。開源的數據流測試的工具沒見過。

作者：知乎用戶
鏈接：https://www.zhihu.com/question/28700827/answer/41799444
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請註明出處。

白盒測試因為其特性，優點自然是精準，但是缺點也是太費時間，而且都是國外產品比較貴，對測試人員的代碼要求太高，現在互聯網比的就是時間，自然不適合所以了大多都是黑盒，不過有取兩者之間的工具，我這裏推薦一款threadingtest的工具，也有雲化的叫星雲測試，國人做的還不錯，他可以用黑盒的測試方法做白盒測試，對測試人員要求簡單不少，通過報告也不用太懂代碼就能測試代碼的覆蓋率

作者：一騎
鏈接：https://www.zhihu.com/question/28700827/answer/78493610
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請註明出處。

為了衡量測試的覆蓋程度，需要建立一些標準，目前常用的一些覆蓋標準從低到高分別是：

• 語句覆蓋：是一個比較弱的測試標準，它的含義是：選擇足夠的測試用例，使得程序中每個語句至少都能被執行一次。它是最弱的邏輯覆蓋，效果有限，必須與其它方法交互使用。
• 判定覆蓋（也稱為分支覆蓋）：執行足夠的測試用例，使得程序中的每一個分支至少都通過一次。判定覆蓋只比語句覆蓋稍強一些，但實際效果表明，只是判定覆蓋，還不能保證一定能查出在判斷的條件中存在的錯誤。因此，還需要更強的邏輯覆蓋準則去檢驗判斷內部條件。
• 條件覆蓋：執行足夠的測試用例，使程序中每個判斷的每個條件的每個可能取值至少執行一次；條件覆蓋深入到判定中的每個條件，但可能不能滿足判定覆蓋的要求。
• 判定/條件覆蓋：執行足夠的測試用例，使得判定中每個條件取到各種可能的值，並使每個判定取到各種可能的結果。判定/條件覆蓋有缺陷。從表面上來看，它測試了所有條件的取值。但是事實並非如此。往往某些條件掩蓋了另一些條件。會遺漏某些條件取值錯誤的情況。為徹底地檢查所有條件的取值，需要將判定語句中給出的復合條件表達式進行分解，形成由多個基本判定嵌套的流程圖。這樣就可以有效地檢查所有的條件是否正確了。
• 條件組合覆蓋：執行足夠的例子，使得每個判定中條件的各種可能組合都至少出現一次。這是一種相當強的覆蓋準則，可以有效地檢查各種可能的條件取值的組合是否正確。它不但可覆蓋所有條件的可能取值的組合，還可覆蓋所有判斷的可取分支，但可能有的路徑會遺漏掉。測試還不完全。

控制結構測試/白盒測試：

1. 基本路徑測試/分支測試
2. 條件測試
3. 數據流測試
4. 循環測試。

基本路徑測試就是這樣一種測試方法，它在程序控制圖的基礎上，通過分析控制構造的環行復雜性，導出基本可執行路徑集合，從而設計測試用例的方法。設計出的測試用例要保證在測試中程序的每一個可執行語句至少執行一次。

在程序控制流圖的基礎上，通過分析控制構造的環路復雜性，導出基本可執行路徑集合，從而設計測試用例。包括以下4個步驟和一個工具方法：

1. 程序的控制流圖：描述程序控制流的一種圖示方法。
2. 程序圈復雜度：McCabe復雜性度量。從程序的環路復雜性可導出程序基本路徑集合中的獨立路徑條數，這是確定程序中每個可執行語句至少執行一次所必須的測試用例數目的上界。
3. 導出測試用例：根據圈復雜度和程序結構設計用例數據輸入和預期結果。
4. 準備測試用例：確保基本路徑集中的每一條路徑的執行。

工具方法：

1. 圖形矩陣：是在基本路徑測試中起輔助作用的軟件工具，利用它可以實現自動地確定一個基本路徑集。

1) 控制流圖

圖3 流圖符號

2. 獨立路徑

獨立路徑：至少沿一條新的邊移動的路徑

第二步：計算圈復雜度

圈復雜度是一種為程序邏輯復雜性提供定量測度的軟件度量，將該度量用於計算程序的基本的獨立路徑數目，為確保所有語句至少執行一次的測試數量的上界。

獨立路徑必須包含一條在定義之前不曾用到的邊。

有以下三種方法計算圈復雜度：

1. 流圖中區域的數量對應於環型的復雜性；
2. 給定流圖G的圈復雜度V(G)，定義為V(G)=E-N+2，E是流圖中邊的數量，N是流圖中結點的數量；
3. 給定流圖G的圈復雜度V(G)，定義為V(G)=P+1，P是流圖G中判定結點的數量。

第三步：導出測試用例

根據上面的計算方法，可得出四個獨立的路徑。(一條獨立路徑是指，和其他的獨立路徑相比，至少引入一個新處理語句或一個新判斷的程序通路。V(G)值正好等於該程序的獨立路徑的條數。)

第四步：準備測試用例

為了確保基本路徑集中的每一條路徑的執行，根據判斷結點給出的條件，選擇適當的數據以保證某一條路徑可以被測試到。

必須註意，一些獨立的路徑，往往不是完全孤立的，有時它是程序正常的控制流的一部分，這時，這些路徑的測試可以是另一條路徑測試的一部分。

4) 工具方法：圖形矩陣

導出控制流圖和決定基本測試路徑的過程均需要機械化，為了開發輔助基本路徑測試的軟件工具，稱為圖形矩陣(graph matrix)的數據結構很有用。

利用圖形矩陣可以實現自動地確定一個基本路徑集。一個圖形矩陣是一個方陣

• • 其行/列數控制流圖中的結點數，每行和每列依次對應到一個被標識的結點，
  • 矩陣元素對應到結點間的連接（即邊）。

對每個矩陣項加入連接權值(link weight)，圖矩陣就可以用於在測試中評估程序的控制結構，連接權值為控制流提供了另外的信息。最簡單情況下，連接權值是 1(存在連接)或0(不存在連接)，但是，連接權值可以賦予更有趣的屬性：

• • 執行連接(邊)的概率。
  • 穿越連接的處理時間。
  • 穿越連接時所需的內存。
  • 穿越連接時所需的資源。

圖9 圖形矩陣

連接權為“1”表示存在一個連接，在圖中如果一行有兩個或更多的元素“1”，則這行所代表的結點一定是一個判定結點，通過連接矩陣中有兩個以上（包括兩個）元素為“1”的個數，就可以得到確定該圖圈復雜度的另一種算法。

軟件測試之“白盒測試”