如何保证单元测试的执行效果?

发表于:2012-5-21 11:23

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:marysnow    来源:51Testing软件测试网采编

  问题:众所周知,单元测试的执行做得不好,会影响系统集成测试,届时大量bug很难追踪,大部分bug本应在单元测试中解决的。那么大家说说如何来保证单元测试的执行效果呢?请大家给些建议。

  marysnow:

  单元测试的重要性,相信大家都清楚。可是往往很多的国内的中小企业难以实施单元测试,原因是开发人员认为写测试脚本浪费时间。那么我说说我们公司的做法:

  1)对于较复杂的单元,要求写非常详细的设计文档,同时进行组内的评审,来发现设计上的缺陷。

  2)然后开发人员依据设计文档或功能要求,来编写单元测试用例。(初期需要测试人员指导一下如何写测试用例),测试用例要经过测试人员的审查,看是否有遗漏。

  3)然后开始编写代码,编写完成后,交给另一个开发人员按照用例去执行测试,类似黑盒的做法,来逐一验证每个测试项。

  4)对于复杂的类需要借助工具如junit来进行单元测试,以发现更多的BUG。

  5)将每个项目编写的单元脚本放到共享库中,以后再有类似的功能,只需要改里面的参数即可,非常方便。

  单元测试在执行时,要交叉执行,这样效率往往比较高。

  总结:

  在初期时,我们主要是以测试用例+黑盒为主来做单元测试,等养成习惯后,就可以直接写测试脚本来做单元测试。很多开发人员一般都认为编译通过就没有问题了,而且只考虑正常情况,不考虑异常情况,所以通过写用例的方法,可以帮助开发人员梳理思路,知道如何来验证。

  对于单元测试的缺陷要及时整理总结,大部分的BUG都是自己编程习惯或粗心造成的。所以要总结出哪类BUG最多,来出台相应的编码规范和开发规范,以便减小类似BUG再出现。

  缺陷在记录时,有的开发人员觉写得麻烦,我们可以截屏的方式来保存,或者大家都能看懂的一些符号或语言来表示,等到后期测试人员再进行详细整理。

  对于用例的格式没有拘限,只要写清楚出测试项,预期结果,实际结果就行。

  前期在写测试用例时,测试人员多参与指导,教给开发人员怎么写用例,怎么选取测试数据( 正常值,异常值,边界值)。(比如讲解一些测试方法等价类,边界值,分支覆盖,循环覆盖,基本路径等)

  单元测试执行时要注意的内容:

  1、单元测试越早进行越好。在TDD方法中,Kent甚至认为开发团队应该遵行“先写测试、再写代码”的编程途径。

  2、对于修改过的代码应该重做单元测试,以保证对已发现错误的修改没有引入新的错误。

  3、测试人员的测试用例应经过审核,如有必要应经过会议评审,以保证测试用例的质量。

  4、当测试用例的测试结果与设计规格说明上的预期结果不一致时,测试人员应如实记录实际的测试结果。

  5、单元测试应该依据《软件详细设计规格说明》进行,而不要只看代码,不看设计文档。因为只查代码,仅仅能验证代码有没有做某件事,而不能验证它应不应该做这件事。

  6、单元测试应注意选择好被测软件单元的大小。软件单元划分太大,那么内部逻辑和程序结构就会变得很复杂,造成测试用例过于繁多,令用例设计和评审人员疲惫不堪;而软件单元划分太细会造成测试工作太繁琐,失去效率。工程实践中要适当把握好划分原则,不能过于拘泥。

  7、注意使用单元测试工具,可以替代一些重复性的劳动。

  我们在实施单元测试前期遇到很多问题,但是发现其实开发人员都知道单元测试很重要,只是没有正确的引导和教给他们方法而异。现在我们的开发人员都会主动使用junit来进行测试。(习惯慢慢养成)

《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号