打字猴:1.70045322e+09
1700453220 //断言100除以10的结果为10
1700453221
1700453222 assertEquals(10,foo.divid(100,10));
1700453223
1700453224 }
1700453225
1700453226 //边界测试场景
1700453227
1700453228 @Test
1700453229
1700453230 public void testDividBroader(){
1700453231
1700453232 //断言最大值除以最小值结果为0
1700453233
1700453234 assertEquals(0,foo.divid(Integer.MAX_VALUE, Integer.MIN_VALUE));
1700453235
1700453236 //断言最小值除以最大值结果为-1
1700453237
1700453238 assertEquals(-1,foo.divid(Integer.MIN_VALUE, Integer.MAX_VALUE));
1700453239
1700453240 }
1700453241
1700453242 //异常测试场景
1700453243
1700453244 @Test(expected=ArithmeticException.class)
1700453245
1700453246 public void testDividException(){
1700453247
1700453248 //断言除数为0时抛出ArithmeticException
1700453249
1700453250 foo.divid(100,0);
1700453251
1700453252 //断言不会执行到这里
1700453253
1700453254 fail();
1700453255
1700453256 }
1700453257
1700453258 }
1700453259
1700453260 诸位可以看到这么简单的一个除法计算就需要如此多的测试代码,如果在生产代码中再加入就if、switch等判断语句,那它所需要的测试场景就会更加复杂了。只要有一个判断条件,就必须有两个测试场景(条件为真的场景和条件为假的场景),这也是在项目中的测试覆盖率不能达到100%的一个主要原因:单元测试的代码量远大于生产代码。通常在项目中,单元测试覆盖率很难达到60%,因为不能100%覆盖,这就导致了代码测试的不完整性,隐藏的缺陷也就必然存在了。
1700453261
1700453262 (2)代码整合错误是不可避免的
1700453263
1700453264 单元测试只是保证了分割的独立单元的正确性,它不能保证一个功能的完整性。单元测试首先会假设所有的依赖条件都满足,但真实情况并不是这样的,我们经常会发现虽然所有的单元测试都通过了,但在进行整合测试时仍然会产生大量的业务错误—很多情况下,此种错误是因为对代码的职责不清晰而引起的,这属于认知范畴,不能通过单元测试避免。
1700453265
1700453266 (3)部分代码无法(或很难)测试
1700453267
1700453268 如果把如下代码放置在一个多线程的环境下,思考一下该如何测试呢?代码如下:
1700453269
[ 上一页 ]  [ :1.70045322e+09 ]  [ 下一页 ]