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

　　敏捷软件开发带来的困惑

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

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

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

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

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

　　专业测试团队要不要？

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

　　● 究竟要不要专业的测试团队？

　　● 软件测试由谁来做更有效？

　　● 专业的测试团队未来的路会是怎样？

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

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

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

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