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 ]
[
下一页 ]