基本上，大家已达成共识：单元测试、集成测试一般由开发人员做效率更高些，而系统测试和验收测试由测试人员做比较好。为什么会有这样的共识呢？

　　如果开发人员先实现再测试，其测试的思路一定会受到实现的影响，不能达到良好的测试效果。如果先设计测试再实现产品，即采用TDD开发软件，让测试在先而不 受实现的影响，效果会不错。但问题是有多少开发团队能够真正做到TDD？而且TDD对需求有更高的要求，软件产品质量的验收标准事先需要被明确定义，然后 才能做到先开发测试脚本，后开发产品代码。而现实的需求又很难做到这点。

　　软件质量就是客户满意度。从这个角度看，测试工作更重要的任务是要 在系统层面验证是否能够全面满足业务需求、是否真正满足不同用户的实际需求。而这样的测试必须要等到系统建立起来之后才能进行，如果这时让开发人员来做测 试，必然会受到之前实现思维惯性的影响，效果明显降低。其次，每个开发人员通常只完成系统的很小一部分，对整体业务无法有效地把握，而且业务场景太多、繁 杂，这时很考察测试人员的专业能力。只有站得高、看得远，完成业务端到端的测试，覆盖各种业务场景，才能确保系统能够正确、有效地实现整个业务流程。

　　如果开发人员知道某些地方很有可能存在缺陷，那么就会设法避免这些缺陷的产生。但往往开发人员并不知道自己会犯哪些错误。而如果让专业的测试人员从不同的角度、不同的思路来测试软件，测试的效果会有效得多。

　　更何况测试本身具有很强的专业性，包括测试建模技术、测试方法及其工具的应用，只有专业的测试人员才能很好掌握。

　　举一个例子，仅仅是黑盒测试方法中一项具体的测试技术—因果分析法（cause-effect analysis），美国测试专家Richard Bender差不多用其一生的时间来研究它，才将这项技术做到极致。除系统的功能测试外，做好系统的性能测试、安全性测试等就更不容易，而且随着软件技术 和应用的不断发展会不断引发新的测试问题。因此，可以说这种专业的实践和积累将是一项长期的任务。

　　互联网的多数应用（如新浪微博、 Facebook、Google搜索）属于文化娱乐服务，受缺陷的影响非常有限。例如，新浪微博的Beta版能在线运行长达三年，但银行业务系统Beta 版在线运行一天都不可能。在金融、国防、航天、通信、交通控制乃至庞大的制造业生产控制等领域，无不要求零缺陷的软件产品，其独立的专业测试更是不可缺 少。最近几年，各大银行不仅建立了独立的测试团队，而且测试团队还保持30%以上的发展速度。如果考虑云计算、物联网等新技术的应用，软件系统的复杂性会 非线性增长，软件缺陷造成的负面影响也不能同日而语，那么在这些领域加强测试也是必然的，对专业的测试团队的需求不但不降低，反而会增强。

　　软件测试的未来

　　近几年，敏捷测试、探索式测试、精益测试、基于模型的测试等越来越受到大家的关注。《软件测试：经验与教训》一书的作者Bret Pettichord在2003年将软件测试归为四大学派（School），四年后（2007年）又增加了一个敏捷测试学派，将软件测试分为五个学派，如 图2所示。

图2 软件测试五大流派示意图

　　● 分析学派（Analytic School）：认为软件是逻辑性的，将测试看作计算机科学和数学的一部分，结构化测试、代码覆盖率就是其中一些典型的例子。他们认为测试工作是技术性很强的工作，侧重使用类似UML工具进行分析和建模。

　　● 标准学派（Standard School）：从分析学派分支出来并得到IEEE的支持，把测试看作侧重劣质成本控制并具有可重复标准的、旨在衡量项目进度的一项工作，测试是对产品需求的确认，每个需求都需要得到验证。