【Software Construction笔记】Reading 3:Testing

Testing

Choosing Test Cases by Partitioning

• Include BoundAries in the Partition
• Two Extremes for Covering the partion
  • Full Cartesian product
  • Cover each part

Automated Unit Testing with JUnit

+ @Test（注释）
+ assertEquals(expected result，actual result)
+ assertTrue()
+ assertFalse()

• Documenting Your Testing Strategy
  • method instruction
  • Testing strategy
    
• Black Box and Glass Box Testing
  • Black box testing: To test the code by partiton without looking at the actual code for these functions.
  • Glass box testing: To test the code base on the knowledge of how the function is actually implemented.
• Coverage
  • Statement coverage:is every statement run by some test case?
  • Branch coverage:for every if or while statement in the program,are both the true and the false direction taken by some test case?
  • Path coverage:is every possible combination or branches——every path through the program——taken by some test case?
  • A good coverage tool for Eclipse is EclEmma,green:be tested red：not be tested，yellow:always be wrong.
• Unit Testing vs. Integration Testing,and Stubs
  • unit test:test a single module in isolation
  • integration test:test a combination of modules,or even the entire program.
  • A stub is often called a mock object.Stubs are an important technique when building large systems.
• Automated Testing and Regression Testing
  • Automated Testing:running the tests and checking their results automatically.(But you have to come up with good test cases yourself.)
  • Regression Testing:It’s very important when you modify your code.Run all your tests after every change.Whenever you find and fix a bug, take the input that elicited the bug and add it to your automated test suite as a test case.
  • automated regression testing: the combination of two testing ways above.
• Summary:
  • Test-first programming.Write tests before you write code.
  • Partitioning and boundaries for choosing test cases systematically.
  • Glass box testing and statement coverage for filling out a test suite.
  • Unit-testing each module, in isolation as much as possible.
  • Automated regression testing to keep bud from coming back.

中文总结：

将输入空间划分

• 1.把输入空间分成若干个包含一系列输入的子域，全部的子域并起来要能覆盖整个输入空间，在每个子域中选取至少一个测试用例组成我们的总的测试用例。子域的划分原则是，在同一个子域中的输入，在该函数都有类似的行为。
• 2.也可以将输出空间划分为子域，使我们的输出结果覆盖整个输出空间，以此来选择测试用例，不同通常将输入空间划分得到的测试集，就已经是一个充分的测试集了。
• 3.划分方法：首先确定整个输入空间，如果一个函数有两个参数（包括调用的那个对象。eg：BigInteger ab = a.multiply(b)，其中multiply()方法就包含两个参数a和b），那么其输入空间就为二维空间。然后确定划分：划分就是使得不同的子域中的测试用例可能对于该函数会有不同的行为包括一些特殊值也要划分出来。例如multiply()方法就可以按如下划分：
  
• 最后在每个子域上随机地选择一个测试用例加入测试集中。
• 更进一步的划分技巧：将边界也作为一个子域，因为边界处最容易出现bug，常见的边界：
  
• 一个例子：

两种选择测试的策略

• 1.Full Cartesian product：对于划分之后的每个子域，都选取一个测试用例，比如multiply()的例子，选取了7*7=49个测试用例
• 2.Cover each part：每个子域中至多选择一个用例，比如在max()中，共有3*5*5个子域，但是有些测试是没有必要的，所以我们选择了5个测试用例。

使用Junit进行单元测试

使用assertEquals(,),assertTrue(,),assertFalse(,)等函数进行测试，其中第一个参数为期望值，第二个参数为实际值。

说明你的测试策略

上面的函数的测试策略如下：

黑盒测试和玻璃盒测试

• 黑盒测试：不知道函数的具体实现，只通过函数的接口说明(specification)来选择测试样例
• 玻璃盒测试：直到函数的具体实现，若对于不同的输入，函数的实现采用了不同的数据结构和算法，那么要把他们划分成不同子域。

覆盖率

• Statement coverage: is every statement run by some test case?
• Branch coverage: for every if or while statement in the program, are both the true and the false direction taken by some test case?
• Path coverage: is every possible combination of branches — every path through the program — taken by some test case?
• 上面的测试强度依次增加，一般来说我们只需要达到statement coverage就可以了。
• 可以利用代码覆盖工具来检测是否每条语句都已经执行过了。eclipse上一个比较好的工具是EclEmma。绿色代表执行过的语句，红色代表未执行的语句，黄色代表条件为假的语句。如下图：
  
• 此时下一步工作就是找一个测试用例使得if条件为真，然后所有语句都会变为绿色， 并把这个测试用例加入到你的测试集中。

模块测试和整体测试

• 模块测试能更好的发现某个模块中的bug，但是整体测试也有好处：能够发现模块连接出的bug

自动测试和回归测试

• 自动测试指自动测试样例并且判断结果是否正确，自动测试使用test driver来进行，比如Junit。他们都只能对你选择的测试样例自动进行测试，并输出测试结果。但是目前还不能自动生成测试样例，这依旧是一个研究的课题。
• 回归测试：每次对代码进行修改之后，都重新将test cases测试一遍。因为对代码很小的改动都有可能导致bug出现。然后找出能导致程序错误的test，并将其加入到测试集中。之后对代码改动依旧使用这个测试集，并不断的将新的有价值的测试样例加入到测试集中。