彩票走势图

单元测试注意事项总结(三)

原创|行业资讯|编辑:龚雪|2014-03-19 10:01:46.000|阅读 516 次

概述:单元测试在整个软件测试工程中非常重要,本文总结了单元测试需要注意的一些事项。

# 慧都年终大促·界面/图表报表/文档/IDE等千款热门软控件火热促销中 >>

相关链接:

19. 使用显式断言

  应该总是优先使用 assertEquals(a, b) 而不是 assertTrue(a == b), 因为前者会给出为何导致测试失败的更有意义的信息. 在事先不确定输入值的情况下, 这条规则尤为重要, 比如之前使用随机参数值组合的例子.

20. 提供反向测试

  反向测试是指刻意编写问题代码, 来验证鲁棒性和能否正确的处理错误.

  假设如下方法的参数如果传进去的是负数, 会立马抛出异常:

  void setLength(double length) throws IllegalArgumentExcepti

  可以用下面的方法来测试这个特例是否被正确处理:

  try {

  set Length(-1.0);

  fail(); // If we get here, something went wrong

  }

  catch (IllegalArgumentException exception) {

  // If we get here, all is fine

  }

21. 代码设计时谨记测试

  编写和维护单元测试的代价是很高的, 减少代码中的公有接口和循环复杂度是降低成本, 使高覆盖率测试代码更易于编写和维护的有效方法.

  一些建议:

  使类成员常量化, 在构造函数中进行初始化. 减少 setter 方法的数量.

  限制过度使用继承和公有虚函数.

  通过使用友元类 (C++) 或包作用域 (JAVA) 来减少公有接口.

  避免不必要的逻辑分支.

  在逻辑分支中编写尽可能少的代码.

  在公有和私有接口中尽量多用异常和断言验证参数参数的有效性.

  限制使用快捷函数. 对于黑箱而言, 所有方法都必须一视同仁的进行测试. 考虑以下简短的例子:

  public void scale(double x0, double y0, double scaleFactor)

  {

  // scaling logic

  }

  public void scale(double x0, double y0)

  {

  scale(x0, y0, 1.0);

  }

  删除后者可以简化测试, 但用户代码的工作量也将略微增加.

22. 不要访问预定的外部资源

  单元测试代码不应该假定外部的执行环境, 以便在任何时候/任何地方都能执行. 为了向测试提供必需的资源, 这些资源应该由测试本身提供.

  比如一个解析某类型文件的类, 可以把文件内容嵌入到测试代码里, 在测试的时候写入到临时文件, 测试结束再删除, 而不是从预定的地址直接读取.

23. 权衡测试成本

  不写单元测试的代价很高, 但是写单元测试的代价同样很高. 要在这两者之间做适当的权衡, 如果用执行覆盖率来衡量, 业界标准通常在 80% 左右.

  很典型的, 读写外部资源的错误处理和异常处理就很难达到百分百的执行覆盖率. 模拟数据库在事务处理到一半时发生故障并不是办不到, 但相对于进行大范围的代码审查, 代价可能太大了.

24. 合理安排测试优先次序

  单元测试是典型的自底向上过程, 如果没有足够的资源测试一个系统的所有模块, 就应该先把重点放在较底层的模块.

25. 为测试失败做好准备

  考虑下面的这个例子:

  Handle handle = manager.getHandle();

  assertNotNull(handle);

  String handleName = handle.getName();

  assertEquals(handleName, "handle-01");

  如果第一个断言失败, 紧接其后的语句会导致代码崩溃, 剩下的测试都将不被执行. 任何时候都要为测试失败做好准备, 避免单个失败的测试项中断整个测试套件的执行. 上面的例子可以重写成:

  Handle handle = manager.getHandle();

  assertNotNull(handle);

  if (handle == null) return;

  String handleName = handle.getName();

  assertEquals(handleName, "handle-01");

26. 写测试用例重现BUG

  每上报一个 bug, 都要写一个测试用例来重现这个 bug (即无法通过测试), 并用它作为成功修正代码的标准.

27. 了解局限

  单元测试永远无法证明代码的正确性

  一个跑失败的测试可能表明代码有错误, 但一个跑成功的测试什么也证明不了.

  单元测试最有效的应用场合是验证和,以及回归测试: 当新功能增加和代码进行重构的同时,会不会影响到旧功能的正确性.

慧都测试工具一览


标签:软件测试技术

本站文章除注明转载外,均为本站原创或翻译。欢迎任何形式的转载,但请务必注明出处、不得修改原文相关链接,如果存在内容上的异议请邮件反馈至chenjj@pclwef.cn


为你推荐

  • 推荐视频
  • 推荐活动
  • 推荐产品
  • 推荐文章
  • 慧都慧问
扫码咨询


添加微信 立即咨询

电话咨询

客服热线
023-68661681

TOP