有人说，软件测试是一个经济学问题。我们希望对软件进行最充分的测试，发现最多的潜在问题。然而测试的资源(人力/时间)是有限的，如何用有限资源获取最大利益，是我们要思考的问题。
软件测试的类型在100种以上。显然，并不是每一种软件测试活动都有同样的投入产出。那么，有哪些测试活动是有高投入产出比的呢？
1灰度测试
软件测试中有一个根深蒂固，普遍存在的问题。那就是在A环境中测试通过，但是在B环境中却失败了。例如，在测试环境中，反复测试都没有问题，信心满满。结果一到生产环境，就出现了故障，让人气愤。
软件是运行在特定环境中的。软件的实际行为与其所处的环境具有高度的依赖性。我们任何时候都不能忘记这一点。
软件运行的终极环境是生产环境。只有在生产环境测试通过，我们才能认为软件有问题的风险已经极低。如何在生产环境中做测试，而又最小化对用户的影响，这就是灰度测试的范畴了。
在灰度测试中，通常将待发布的软件部署在部分生产环境(即灰度环境)上，然后将测试流量或部分用户流量引入到灰度环境。如果没有问题，才逐步部署到全部生产环境。
灰度测试实现了在生产环境对软件的终极验证，是软件发布前的最后一道防线。
它的投入(环境配置/引流/自动化用例)等是一次性的，但是其产出是显著的(提前于用户发现问题)，并且可以持续产出(每一次软件升级都受益)。
2冒烟测试
“修复1个老bug，引入10个新bug”。
“开发提供的版本，一会启动不起来，一会基本功能又有问题，计划中的特性测试根本没法开展”。
这些都是日常工作中的常见问题。它们极大地降低了工作效率，拖累了项目进度，埋下了质量隐患。
解决这些问题有一个办法，那就是给开发提交测试版本设置一道防线，这道防线就是冒烟测试。
如果说回归测试追求大而全，那么冒烟测试追求的是小而精。冒烟用例是自动化的。冒烟用例/测试环境/执行入口由测试提供，覆盖被测软件最基础的功能，例如部署，启动，登陆，核心业务流程等。
冒烟测试通过了，可以说明开发的代码改动没有很大的问题，软件也有了基本的质量，后续的测试阶段也就可以更顺利地开展。
冒烟测试作为开发提测的一道防线，可以减少浪费，提高效率。冒烟测试的用例比较少，因此开发和维护成本不高。主要的成本是冒烟用例失败的定位分析成本，这是一件持续的事情。
3单元测试
所有的软件问题，归根结底是编码(Coding)问题。
在编码阶段发现问题，不会对任何人有影响，并且随手就可以把问题解决掉，这是成本最低，效率最高的。
如何在编码阶段尽可能多的发现问题呢？我们可以依靠肉眼自查、依靠IDE的告警、依靠各种静态检查工具、依靠结对编程、依靠……。
所有这些办法有一个共同点，那就是不会执行代码。然而，“纸上得来终觉浅，绝知此事要躬行”。
单元测试，与上述办法的根本区别在于，它是会一行一行执行代码的。只有让代码跑起来，才能发现一些表面之下深层次的问题。
单元测试带来的收益，还有更多，例如：更好的模块设计，更放心的代码重构等。当然，单元测试的成本也是不低的，需要编写测试代码，并且有持续的维护成本。
要不要做单元测试，历来都有“支持派”和“反对派”，双方各执一词。我本人是坚定的单元测试“支持派”。
不为别的原因，就为了单元测试是开发提交代码的最后一道防线。单元测试做好了，后面的阶段，后面的人，痛苦也少许多。