被测代码链接:
修正流程图:
测试用例设计:
覆盖方式 | 用例编号 | 输入 | 期待结果 | 实际结果 | 是否通过 | 时间 |
判定/条件覆盖 | 1 | 0.1 0 0 | 错误 | 0.8 | × | 2017.3.30 |
判定/条件覆盖 | 2 | 0 0.1 0 | 错误 | 0.1 | × | 2017.3.30 |
判定/条件覆盖 | 3 | 0 0 0.1 | 错误 | 0.08000000000000002 | × | 2017.3.30 |
判定/条件覆盖 | 4 | a 100 0 | 错误 | 100.0 | × | 2017.3.30 |
判定/条件覆盖 | 5 | 0 181 0 | 222.0 | 222.0 | √ | 2017.3.30 |
判定/条件覆盖 | 6 | 0 180 0 | 220.0 | 220.0 | √ | 2017.3.30 |
判定/条件覆盖 | 7 | 0 101 0 | 101.5 | 101.5 | √ | 2017.3.30 |
判定/条件覆盖 | 8 | 0 100 0 | 100.0 | 100.0 | √ | 2017.3.30 |
判定/条件覆盖 | 9 | 0 0 0 | 0.0 | 0.0 | √ | 2017.3.30 |
判定/条件覆盖 | 10 | 0 -100 0 | 错误 | -100.0 | × | 2017.3.30 |
单元测试框架:
package ttt;import static org.junit.Assert.*;import org.junit.Before;import org.junit.Test;public class Test1 { @Before public void setUp() throws Exception { } @Test public void test() { assertEquals(222.0, new yongjin01().Commission(0, 181, 0), 0.001); assertEquals(220.0, new yongjin01().Commission(0, 180, 0), 0.001); assertEquals(101.5, new yongjin01().Commission(0, 101, 0), 0.001); assertEquals(100.0, new yongjin01().Commission(0, 100, 0), 0.001); assertEquals(-1, new yongjin01().Commission(0, -100, 0), 0.001); assertEquals(-1, new yongjin01().Commission(0.1, 0, 0), 0.001); }}
测试结果:
测试小结:
1.刚开始写测试用例的时候遇到很多问题,最大的问题是返回值是double类型,而double类型的值不能直接通过"=="来判断值是否相等,所以不能直接采用assertEquals(expected, actual)的形式来运行测试程序。后来找到了assertEquals(expected, actual, delta)形式,可以利用detal来取舍精度,使double数值在一定精度范围内判定相等。
2.程序虽然较上次更正了一些判定逻辑,但仍然存在很多问题,比如输入错误之后还能继续输入下一个值并计算、输入负数或小数值后仍然可以计算结果、在num=0赋值语句后不改变num值的情况下判断num<0等问题。有的问题造成了部分判断语句必定为真或必定为假,是测试样例不可能完全覆盖所有语句,造成了很大的困扰。
3.Junit的使用学习了很久,遇到了很多问题,查了很多资料,也问了很多大佬才能运行起来,尝试了很多次才能比较熟练的应用。但是Junit的断言一旦遇到错误就会立刻停止并报错,而不继续执行后续断言的机制感觉很不科学,因为这样每次都要将这条错误发生的断言删除,重新执行才能观察后续的断言是否存在错误。而相比main函数去调试唯一比较方便的是免去了运行程序时一遍又一遍的输入过程。