开发人员的测试悖论

多年来,我在软件开发过程中看到了许多不同的测试方式。每一种测试都有它的独特性,一些开发人员认定他们自己有不只一种方式。在本文中,我试着列举所有不同种类的测试,并说一说它们在项目上反映出的效果。

1. “我不是QA”(I’m not QA)

我提交代码,其他人验证其是否能正常运作。我的工作就是写代码,而不是测试。因为是我写的代码,所以,我不能测试出代码什么地方出错了。我需要让其他人看应用程序,并且学会如何使用,如何崩溃。通常,这种方式也说明缺乏说明文档,同样原因,这应该是其他人的工作。通常这种测试方式意味着,质量是其他人该负责任的事。

2. “我没时间”(I don’t have time)

我必须在3周时间内完成项目,再没有时间去写测试了。我想测试可以保证应用程序的质量,但是因为我必须三周内完成任务,所以我必须跳过开发中的这一部分, 直接做工作上的事情。一旦事情完成,我会做些手工检查,然后直接投产。这种方式通常和那些只用1或2个月来开发,并且4年内不用维护的小项目相关,他们只需要短时间内得到一个产品。这种案例没有说明文档,因为你没有时间去做。(编注:关于这种类型,可参见伯乐在线职场博客《每位开发人员都应铭记的10句编程谚语》一文中的“欲速则不达”。)

3. “管理故障”(Management fault)

许多大公司的雇员都遵循这种开发方式。他们有过失败或项目推迟的经历,因此,他们排斥一切不能给高层管理带来直接利益的事。通常情况下,在持续快速地开发一个功能性强大的项目时, 在开始阶段无需测试。随着时间的推移,应用程序的增多,添加了越来越多复杂的程序,并且开发进程越来越困难。每一个新的部署就意味着大量的新错误和新任务。短短几年,应用程序失去可信度,通常有人想在新技术下重新写程序。不幸的是,如果开发过程没有改变,几年后他们会在不同的技术中以同样的方式结束。

4. “测试只是一个工具”(Testing is just a tool)

这种情形下,由开发人员编写测试,但仅限于某些对他们编码有帮助的地方。测试是用来作为创造新功能的工具,而非在代码中增加可信度的方式。如果任何新功能的添加破坏了已存在的测试,开发员会假定测试错误,测试需要更改、取消或删除。虽然是对应用程序的测试,但是这些测试并不可信。如果这些测试不可信,应用程序也就毫无价值可言了。

5. “热衷测试覆盖率”(Test coverage maniac)

所有的一切都是关于代码的覆盖率。使代码的覆盖率达到100%是最终目标。查看测试的覆盖率以及查看测试未能通过的地方,为那些路径添加测试成了一项重复的工作。我的意思是,增加毫无意义的测试只是增加覆盖率。测试将变得复杂,新开发人员通常要花很长时间才能明白这个代码是做什么的。在这种情况下,我们就比其他人处于更有利的位置,测试不仅是和覆盖率有关,还有可信度。

6. “可信度测试”(Test to trust)

这是终极方式。软件开发的测试有许多目的,但是最重要的是在代码中建立可信度。如果队员对测试有信心,他们会很自如地改进或更改代码。使其效率更高,质量更佳,周转更快。

测试中有可信度并不是和代码覆盖率有关,而是相信团队成员,他们会为重要的事物增加测试。如果你做了更改或者破坏(break)测试,你就需要认真考虑你的更改,而不是仅仅移出错误测试。我们要做的是能提高代码和测试可信度,而非仅仅解决一个新问题。

这些年我了解到,测试是开发过程中至关重要的一部分。每次代码修改后,都应该进行测试。用于提高测试可信度的每一秒钟,就是你每次运行测试都会成功的时候。在软件开发上,取得最大效率的唯一方式不是不写测试,而是相信你的测试。

你是一位开发人员吗?你为你的应用程序写测试吗?你每次提交都在提高测试中的可信度吗?每次提交都需要提高可信度,否则你就是增加了一个有问题的代码,最后终将导致你重写整个程序。

相关阅读:《程序出错后,程序员给测试人员的20条高频回复

译文出处:伯乐在线

原文:Ramiro Rinaudo  翻译:敏捷翻译 – 祝佳

如需转载,但请注明原文/译文出处、译文超链接和译者等信息,否则视为侵权,谢谢合作!

收藏 评论

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部