第三次作业+105032014037

被测代码链接：http://www.cnblogs.com/ddanwu-blogs/p/6623048.html

修正流程图：

测试用例设计:

单元测试框架:

 1 package one;
 2 
 3 import static org.junit.Assert.*;
 4 
 5 import org.junit.Before;
 6 import org.junit.Test;
 7 
 8 public class Case1 {
 9     
10     @Before
11     public void setUp() throws Exception {
12     }
13     
14     @Test
15     public void testCommission() {        
16         assertEquals(98.0, new TestPractice().Commission(10, 10, 10),0.0);
17         assertEquals(267.0, new TestPractice().Commission(20, 10, 10),0.0);
18         assertEquals(376.0, new TestPractice().Commission(20, 20, 10),0.0);
19     }
20 }

测试结果：

测试小结：

通过对白盒测试方法的学习，能够熟练运用语句覆盖、判定覆盖等白盒覆盖方法进行分析程序并写出测试用例。对于判定条件少的程序，个人认为先使用路径覆盖，然后进行条件判断，再结合组合覆盖，最后进行判定覆盖和语句覆盖检查，能够用更少更准确的用例就能覆盖越多越广的覆盖方式，这能减轻测试工作数据量。
运用JUnit是对方法的测试，必须基于测试用例正确，不然你把程序已经排除在外的数据给方法测，肯定不通过。JUnit能测试方法的正确性，减轻了开发人员一次又一次的跑main（）方法，如果main（）方法大且调用方法多，那跑一次就会产生很多中间数据，对于检查哪里出错很不容易。
调试要跑完整的程序代码，从main入口开始，一步一步执行，程序员需要一直盯着debug查看进行到哪里了。调试就是通过dubug进行编码错误检查。测试则是通过用例进行找茬，找出程序员功能或逻辑上的漏洞。我认为单元测试则居两者之中，通过Junit提取一个个小的程序方法，只进行一个个方法的测试，没有顺序，没有时间限制，哪里有问题就可以着重测试哪个方法,程序员通过单元测试保证程序局部的正确，但不能完全满足需求（例如逻辑上的错误）。而测试人员可以用之进行局部测试，但不能进行更完整、更具针对性的用例测试。