开发人员的测试悖论

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

　　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）测试，你就需要认真考虑你的更改，而不是仅仅移出错误测试。我们要做的是能提高代码和测试可信度，而非仅仅解决一个新问题。

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

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

　　译文出处：伯乐在线- 职场博客 - 程序员
　　译文链接：http://www.jobbole.com/entry.php/794

　　原文：Ramiro Rinaudo　　文章推荐：关关　　翻译：敏捷翻译 - 祝佳

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