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

　　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)

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

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

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

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

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

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