专业测试团队的重要性和未来的发展

敏捷软件开发致使很多人质疑专业测试团队存在的价值，本文对此进行了深度的剖析，并结合技术发展现状给出了软件测试的未来方向。

敏捷软件开发带来的困惑

敏捷软件开发强调“拥抱变化”，认为不能将需求定义一次做到位，也没必要一次做到位，需要不断挖掘，才能逐渐获得真实的需求。这就给测试带来极大的挑战，因为测试需要把验证的标准作为参照系，否则如果需求不清楚，就很难确定测试中发现的问题是不是真正的缺陷，导致测试的设计与执行困难重重。在这种情况下，我们是否只能依赖探索式测试呢？

敏捷软件开发强调持续构建、持续测试。在构建中不仅可以完成单元测试，还可以完成集成测试。因为每天都构建软件包，一旦单元之间（接口）存在问题，就很容易暴露出来。每日构建和集成可被看作持续测试的一种体现。在这种情况下，是否就无需单独的集成测试阶段？测试的投入是否就可以减少呢？

敏捷软件开发强调与用户的沟通和协作，用户起初并不清楚自己的需求，通过软件产品的使用，才逐步明白自己想要什么。如果用户真能参与开发过程，即用户每天都能及时使用正在开发的软件，那么还需要测试人员吗？如果将持续集成和用户及时反馈结合起来，专业测试人员的测试投入是不是就可以大大降低？

敏捷软件开发强调持续交付，即及时发布有价值功能给客户，并尽快地满足客户的需求。之所以能做到持续交付，是因为软件已从产品销售模式转为服务模式—软件即服务（Software as a Service，SaaS），不存在以前产品模式的销售渠道，软件版本的更新只要在自己数据中心的服务器上打个patch就可以了。这种SaaS模式使得持续交付成为可能，软件能够快速上线、用户也能及时获得更新的服务，因此缺陷能被快速修复，缺陷修复的成本极大降低，大大提高了人们对缺陷的容忍度，降低了对质量的要求。但这可以大大降低测试的投入吗？

特别是像Facebook这样耀眼的公司，其实践似乎在支持“无需建立独立的测试团队”，让开发人员来承担越来越多的测试工作，甚至承担全部测试工作。还有人提议将测试团队的一半成员拿出来做开发，这样可以解决以前单元测试不足的问题。而测试团队的另一半被抽调到客户服务（Customer Care）团队中，负责需求前期调查和后期技术支持，在需求上加大投入，帮助建立软件产品的客户验收标准，让开发人员基于验收标准完成软件系统的设计和编程，从源头上提高质量，而且后期技术支持也得到了加强。

专业测试团队要不要？

一系列新的实践似乎在加剧质疑“专业测试团队的存在意义”。但在传统软件测试理念中，则强调测试的独立性和专业性，专业性越强，越需要全职人员。这些实践在传统产业的质管理实践中已得到充分的验证。传统产业的质检部门是独立的，质检人员也是全职的。如果不管三七二十一，将测试团队拆分掉，会不会带来新的问题？比如：

究竟要不要专业的测试团队？
软件测试由谁来做更有效？
专业的测试团队未来的路会是怎样？

这一系列新的问题开始困扰业界，因此我们有必要进行充分的讨论，澄清这些问题。即使不能给出令每个人都信服的答案，也要帮助测试人员获得更客观、更理性的认识。

从软件测试本质来看，测试就是对软件产品（包括阶段性产品）质量进行全面地评估，以了解产品质量当前的状态，从而为项目管理和决策提供客观的依据。在这过程中，发现缺陷、暴露产品质量风险等，都可以看作软件测试的副产品。只是因为缺乏可操作的、具体的质量标准，所以目前没有能力和手段对软件产品做到100%的客观评价，也很难通过工具对软件产品直接进行质量指标的逐项验证而给出“质量检验通过”或“质量检验不通过”的结论。而且，软件质量整体都比较差，人们也很难通过一次性的测试完成软件产品的质量评估，而是要进行持续测试或多轮的测试，其结果弱化了“全面评估软件质量”的作用，而强调软件测试是努力发现软件产品缺陷、暴露质量风险、不断提供质量反馈的过程。

如果让构建软件产品的开发人员来评价自己的产品，那么测试结果具有说服力吗？暂且不说，王婆卖瓜，自卖自夸的嫌疑。从心理学角度分析，要发现自己的问题、否定自己的实现，需要克服心理上很大的障碍，这实际上是很不容易的。更何况人天生有惰性，希望某一个团队把事情从头到尾做好，完全依赖每个成员高度的责任感和主动性，这是不现实的。监督机制不可缺失，正如建筑需要监理、警察还有督察等，独立测试缺失，质量难以保障。在敏捷Scrum开发模型中（如图1所示），开发和测试在持续构建和持续测试之后，也依旧要设立一个独立的验收测试阶段，其实就是对独立测试的一种诉求。

图1 敏捷Scrum开发模型示意图

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

如果开发人员先实现再测试，其测试的思路一定会受到实现的影响，不能达到良好的测试效果。如果先设计测试再实现产品，即采用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的支持，把测试看作侧重劣质成本控制并具有可重复标准的、旨在衡量项目进度的一项工作，测试是对产品需求的确认，每个需求都需要得到验证。
质量学派（Quality School）：软件质量需要规范，测试就是过程的质量控制、揭示项目质量风险的活动，确定开发人员是否遵守规范，测试人员扮演产品质量的守门员角色。
上下文驱动学派（Context-Driven School）：认为软件是人创造的，测试所发现的每一个缺陷都和相关利益者（stakeholder）密切相关；认为测试是一种有技巧的心理活动；强调人的能动性和启发式测试思维。探索性测试就是其典型代表。
敏捷学派（Agile School）：认为软件就是持续不断的对话，而测试就是验证开发工作是否完成，强调自动化测试。TDD是其典型代表。
标准学派和质量学派相对比较成熟，流程、过程规范等基本已建立，包括TPI、TMMi等比较成熟，虽然未来会有一些修改。而上下文驱动是比较自然的思路，其他学派也或多或少也会从上下文去考虑，也存在融合的可能性。虽然分析学派和上下文驱动学派、敏捷学派有一定对立关系，但它们相互之间又会有更多的交融，而且敏捷方法主要以实践为基础，敏捷测试不是原发性的，而是先有敏捷开发。然后人们被动地寻求测试方法和技术来适应敏捷开发。敏捷测试缺乏自己独立的理论根基，更多地依赖于上下文驱动学派的支持，包括探索式测试和自动化测试。其中自动化测试是敏捷测试主打的王牌，没有自动化测试就没有敏捷测试，而自动化测试和持续集成、持续测试也相当吻合。

虽然互联网的影响越来越大，但关键系统（如银行业务、交通控制等系统）还依旧存在，关键系统会进一步促进软件开发的各种建模技术的发展，其中也包括测试建模和形式化验证。基于模型的测试也会促进自动化测试的发展，这两者之间是相辅相成的。没有测试建模的支持，自动化测试靠完全模拟手工的操作方式来实现，其实现和维护代价将相当大，使之投入产出比（ROI）总是不够理想，阻碍自动化测试的发展。当自动化测试能够借助基于模型的测试，那么自动化测试将事半功倍、如鱼得水，ROI自然也会很高。基于模型的测试，最终也需要工具的支持，例如Pairwise、因果分析法等。如果没有工具支持，测试人员就会感觉很累而不愿应用。

对软件测试影响最大的因素是软件发布模式和软件开发技术。前面已详细描述了软件发布模式，在SaaS模式中可以持续发布敏捷测试、探索式测试受到更多的关注。同时，SaaS的发展促进了各种基于云计算的服务模式诞生，软件测试的云服务模式应运而生、快速发展起来。测试公有云提供公共的、开放的测试服务，像UTest、SOASTA、SauceLab和Testin等，可以完成手机应用、Web应用或其他应用的功能测试、兼容性测试、配置测试和性能测试等。而测试私有云是某个企业为自己建立的云测试服务，将测试机器资源、测试工具等都放在云端，公司的各个团队都可以共享所有测试资源，完成从自动分配资源、自动部署到测试结果报告生成的测试过程，而且还能将测试流程、测试管理等固化在私有云内。

在软件开发技术方面，软件开发框架、工具也对测试有直接影响。例如，对分层构造软件系统而言，软件测试也可以采用分层的自动化测试技术。但未来有什么革命性的软件开发技术还难以预料，例如未来是否产生有效的开发技术能够智能地自动完成软件设计和实现的验证。但可以肯定的是，未来依靠软件生命周期的前期努力与创新构造更高质量的产品，依靠更好的单元测试技术充分实施代码层的测试，让“质量是内建的”落实到位，并借助API、UI等不同层次的自动化测试来提高测试效率。这样，软件测试投入可以越来越少，专业的测试团队规模可以不断缩小，还能保持同样的软件产品质量水平。这样，对软件企业也是好事，企业质量保障成本越低，企业获益就越大。总之，软件测试未来可能会形成两个主流方向。

基于模型的自动化测试：以传统测试的分析学派为基础，强调从需求分析开始，为需求或用户行为构建模型，然后基于模型自动产生和执行测试用例，它更适用于关键系统的验证。这对测试人员的技术能力有更高的要求，专业测试人员会越来越精干。如果有一天，测试团队的成员是从最优秀的开发人员中挑选，测试人员只占整个研发团队的10%左右，软件开发才到了真正成熟的时代。

基于云服务的测试模式：非关键系统在前期系统架构设计和代码实现上可借助良好的开发框架与工具、单元测试和持续集成等工作，在没有专职测试团队的工作情况下，也能保证产品质量处在一个基本可用的水平。然后，利用上述的公有云服务模式来完成更深度的测试，如可用性测试、配置测试、兼容性测试、性能测试都可以在云平台上自动完成。剩余的功能测试（包括业务流测试、场景测试等）就可以交给大众，通过远程服务完成测试。这些测试人员可能是业余志愿者，也可能是在家工作的专业测试人员，按任务领取报酬。