下载掌阅APP，畅读海量书库
立即打开
在第1章中我们介绍了敏捷开发模式和瀑布模型的特点有很大的区别。如果在敏捷项目中还是使用瀑布模型的测试方法和实践，那么测试人员将会面临非常大的困境。我曾经遇到过这样一个例子。
几年前，当我在某国际著名IT公司领导测试中心的时候，为了掌握项目现状，我组织了各项目的测试骨干召开座谈会。在座谈会上，我询问大家：“目前在项目上碰到了什么棘手的问题？”其中一位同事有些沮丧地回答：“目前，我们的项目正在采用敏捷开发模式，但我觉得实施敏捷后，我们的测试人员更累了。以前在迭代开发时，在每个版本上线后，测试人员至少可以有一两天的时间稍作休整，但是采用敏捷之后每天都在赶时间、赶进度，很疲惫。”我听了之后有些好奇，追问道：“为什么呢？”他回答：“我们每两周迭代一次，开发人员经常在第二周的周三才统一提测，测试人员根本测不过来！”
这个例子就是典型的使用瀑布模型的思维方式执行敏捷项目的案例，它存在的问题是，在Sprint迭代内还划分了开发阶段和测试阶段，开发人员在某个时间点统一提测给测试人员，这种被称为“迷你瀑布”的方式并不是真正的敏捷，其结果是使测试人员的测试时间被严重压缩，而让测试人员在这么短的时间内完成所有测试是非常痛苦的，最终只会得出“敏捷无用”的结论。
传统测试在敏捷环境下究竟存在什么问题？归根结底，其主要面临以下4个方面的挑战。
敏捷强调快速，一般一个迭代周期为2～4周，有些项目甚至只有1周时间。在如此短的周期中，除去前面的Sprint计划会、后面的Sprint评审会和Sprint回顾会、中间的程序设计与代码开发，以及下次迭代需求梳理等过程，留给测试的时间寥寥无几。如何在短时间内保质保量完成测试任务，对测试人员来说是一个极大的考验。
敏捷的特点是轻文档，这就意味着测试人员能看到的文档信息内容不会太详细。而在传统测试中，详细的需求规格说明书等文档对于测试人员来说是非常重要的输入，也是测试人员衡量测试是否能通过的依据。因此，在缺乏详细文档的情况下，如何进行测试用例设计及判断测试执行是否通过，将是测试人员面临的巨大挑战。
敏捷强调拥抱变化，所以在软件开发过程中存在不断变更的可能。在传统模式中，频繁的变化对于测试人员来说，无论是做测试计划还是执行测试，都会带来很大的挑战。特别是在测试过程中，如果遇到变更，不仅意味着在测试环境中可能存在多套测试版本，版本管理和环境管理具有极大的复杂性，而且很可能会使之前已经做了一半的测试工作付诸东流，所以，测试人员在敏捷项目下如果还使用瀑布模型，将会举步维艰。
敏捷项目提倡跨功能团队，并且淡化专职测试人员这一角色。敏捷团队已经不可能像传统项目一样按3：1或4：1配比开发人员与测试人员，很多时候，在一个7～9人的敏捷团队中只有1个功能测试人员。在测试人员极少的情况下，如何保障整个项目按时保质完成，已经成为测试领域非常棘手的课题。
所以，在敏捷环境下，如果还执行传统的测试方法，测试人员一定会焦头烂额、无所适从。一个很好的比喻是如果整个项目都采用敏捷开发模式，如每两周迭代一次，但测试人员还在执行传统的测试方法，就好像存在两个不同转速的齿轮，二者根本无法匹配，因为两周的时间根本无法按部就班地完成所有测试。因此，必须使用新的测试方法和实践来取代原有的模式，更好地适应敏捷的快节奏的特点。
既然在敏捷环境下不能再按照传统的方式执行测试，那么就需要使用一套适合敏捷环境的新的测试实践，我们称其为敏捷测试。
什么是敏捷测试？敏捷测试是遵从敏捷软件开发原则的一种测试实践。敏捷开发模式把测试集成到整个开发流程中，而不再把它当成一个独立的阶段，因此，测试变成了整个软件开发过程中非常重要的环节。敏捷测试需要由具备专业测试技能的人员组成的跨职能团队组织进行，该团队能更好地交付价值，满足项目的业务、质量要求和实现项目的进度目标。
根据上面的定义，敏捷测试的核心内涵主要有以下4点。
（1）敏捷测试遵从敏捷开发的原则，强调遵守。敏捷价值观和敏捷宣言遵循的12条原则同样适用于敏捷测试。
（2）测试被包含在整个开发流程中，强调融合。敏捷开发的过程不再像传统项目那样存在开发阶段和测试阶段之分，开发和测试将被当作一个整体过程看待。在敏捷环境中，所谓的“开发完成”并不是开发人员编码完成，而是开发完成且测试和验证通过，才算真正开发完成。
（3）跨职能团队，强调协作。众所周知，“跨职能团队”无论是在敏捷中还是在DevOps中都被频繁提及，跨职能意味着团队不再按照传统的职能型部门的组织方式组织，而是将具备不同专业技能的人才组成一个团队，彼此之间互相协作、互相帮助，每个人都在团队中发挥自己的优势，使团队绩效最大化。
（4）敏捷测试是为了交付业务价值，强调价值。为客户带来业务价值是敏捷的目标，也是敏捷测试的目标，所以要避免为了敏捷而敏捷，杜绝流于形式的做法，一切以客户所需为导向，实实在在地为客户提供业务价值。
以上是敏捷测试最重要的4点核心内涵，也是区分传统测试和敏捷测试的4条最基本的核心准则。只有真正理解了敏捷测试的内涵，才能在敏捷项目的测试过程中更好地运用敏捷测试的知识指导工作。
在第1章中，我们已经清楚地介绍了著名的敏捷软件开发宣言和所需遵循的12条原则，那么，敏捷测试是否也存在相应的敏捷测试宣言呢？国外两位敏捷专家Karen和Samantha在 Growing Agile：A Coach’s Guide to Agile Testing 中提出了敏捷测试宣言，如图2-1所示。
图2-1 敏捷测试宣言
接下来将详细解读这5条敏捷测试宣言。
在传统的瀑布模型中，测试作为单独的一个阶段存在，并且一般存在于开发阶段之后、上线阶段之前，如果在敏捷中，开发已经进行了改进，如完成的开发单元更小了，但是测试仍然在最后阶段才进行，那么其实没有从根本上改变测试的方式。在敏捷项目中如何判断测试是否被当成一个阶段来处理呢？方法很简单，我们可以查看项目的任务板，如果任务板中有一个单独的“测试”列（分栏），如图2-2所示，就表示测试可能仍然被认为是一个阶段，或者有可能变成“小瀑布”，如2.1节中所举的例子。
图2-2 含有“测试”列的任务板
相比之下，测试在敏捷开发中被看成一种活动，它与编写代码等活动没有太大区别。《Google软件测试之道》中写道：“当你把开发过程和测试放到一起，将它们像在搅拌机里一样混合搅拌，直到不能区分彼此的时候，你就得到了质量。”
如何把测试当成开发过程中的活动？秘诀是在开发工作开始之前，先想清楚有什么测试任务可以做，然后把它们展示在任务板上。在任务板上，可视化的一个关键是不要有单独的“测试”列，而是使用不同颜色的便利贴，把测试任务粘贴在“待办”列中，把包括开发任务在内的所有任务放在一起做，这样处理的好处是能够确保在测试任务完成之后，整个用户故事才算开发完成。
另一个技巧是设置“评审”列，把它放在“处理中”列之后、“完成”列之前。大多数团队都会对每个用户故事进行代码评审、文档评审，以及测试用例评审。设置“评审”列背后的思想是，一旦任务完成，就对每个任务进行评审，如果任务很小，这些微评审可能只需几分钟。这至少确保了一点，即团队中至少有两个人已经查看了每一项工作，这种方式有助于更早地捕获和修复问题。不包含“测试”列的任务板如图2-3所示。
图2-3 不包含“测试”列的任务板
传统上，人们认为测试的目的是发现缺陷（Bug）。一些组织甚至基于测试人员发现（或没有发现）的缺陷数量来衡量他们的工作效率，这种思维上的局限性会强化“测试是最后阶段才会开展的事情”这一想法。
敏捷测试的目的是在开始编写代码之前就查找和消除所有假设和未知，以防止缺陷出现，其目的是确保从客户到开发人员，再到测试人员，每个人对需求的理解都完全相同。防止出现缺陷的最佳方法是提问，并且通过沟通来消除彼此理解上的差异。需要注意的是，不要忽略一些大家都认为答案“显而易见”的问题。
传统的测试人员通常不喜欢敏捷，因为缺少详细的规范文档使他们无从下手。测试人员认为自己的工作就是检查被测系统是否符合需求规范，并报告存在差异的地方，认为自已唯一要做的就是检查开发出来的产品是否严格遵守需求规范。实际上，他们对产品本身的质量并未加以关注，只重点关注了产品是否真的满足用户需求。
我们称这项工作为检查。其实最擅长做检查的应该是计算机而不是人，检查1+1=2对计算机来说非常容易且不会出错，因为它永远不会感到无聊、疲倦或注意力分散。在敏捷测试中，简单的检查应该被自动化，这样就可以将测试人员从中解放出来，转而投入计算机无法处理的工作，如探索式测试或可用性测试。
在敏捷中，测试人员需要成为客户的代言人，每当客户要求增加一个功能时，可以询问测试人员：“你将如何测试它？”或“你怎么判断它是可工作的？”这有助于理解客户所期望得到的实际结果。同时，还需要把它翻译成验收标准给团队，确保团队能够开发正确的产品。
在传统模式下，测试人员采用的是破坏性思维，这种思维使开发人员和测试人员之间产生了隔阂。开发人员构建系统，然后测试人员试图破坏系统，这是在强化在传统思维模式下测试仅作为一个阶段存在的观念。
敏捷思维认为测试人员应该帮助构建尽可能高质量的系统，而不应该等到缺陷出现后再去发现它，以显示测试存在价值。事前预防远比事后控制重要。对于敏捷测试人员来说，更应该在开发之前尽力帮助团队构建正确的系统。
在传统模式下，只有测试人员或测试团队对质量负责，一个产品是否能够发布，他们拥有最终的决定权。这种思维意味着只有测试人员关心质量，也只有测试人员肯花时间确保质量。
而在敏捷中，整个团队都要对质量负责，这有助于团队意识到测试是一种活动，他们都需要参与其中，并且将测试贯穿整个工作过程。如果客户在产品中发现了问题，没有人会质问测试人员为什么没有发现，相反，整个团队会讨论如何共同防止这种情况再次发生。一旦采用了这种思维，测试人员就不再是上线前唯一忙碌的人，整个团队都会参与其中。
既然我们已经知道了敏捷测试是一种新的测试实践，那么它到底有什么特点呢？我认为可以用5个“更”来归纳总结。
在传统的开发模式中，大部分的沟通模式是“n”型模式。例如，开发人员有事情需要测试人员帮忙处理，他们不是第一时间找测试人员，而是先向自己的开发主管提出配合申请，再由开发主管与测试主管协调，测试主管再把事情传达给测试人员并指示配合，这种“n”型模式的沟通效率有多低可想而知。当然，出现这种问题的根源是职能型组织架构不合理。而敏捷强调的是跨职能团队，团队内部既有开发人员，又有测试人员，他们在同一个团队中有更多的协作，工作也更加紧密，并且喜欢面对面沟通，而不是通过邮件、文档反复沟通，所以效率自然就提高了。
在传统的开发模式中，一般测试阶段的周期都是按月计算并计划的，比如，系统测试2个月、用户验收测试1个月等。但是在敏捷中，需求验证或测试的周期不再按月计算，而是按天，甚至按小时计算。同时，用户验收测试也不在最后阶段才进行，而是在每次Sprint的结尾都会进行。整个测试被分割成多个小的测试活动，并且分布在每一个Sprint迭代周期中，而每个迭代周期中的测试就变得非常短。
敏捷宣言强调响应变化，敏捷测试同样也需要拥抱变化。测试计划不再像传统模式一样，由测试经理编写一份非常详细的文档，然后放入文档管理配置库中，最终变成“死”文档。在敏捷测试中，测试计划在最初阶段接受粗粒度文档，因为敏捷项目在开始时，自身的需求并不清晰，而在需求不明确的情况下很难制订一份具体且详细的测试计划。当然，随着时间的推移，我们也需要不断地更新优化，根据业务价值的交付顺序灵活调整测试计划，所以测试计划应该是渐进明细且刚好够用（Just-In-Time）的。
相比传统测试，自动化在敏捷测试中扮演了极其重要的角色，是在实现快速交付的同时又能确保质量的一种非常有效的手段。传统测试由于测试的周期较长，测试的资源相对充足，所以通过大量的手工测试人员进行“人海战术”是可行的。但在敏捷测试中，在短时间内仅依靠人工测试来保障产品质量，只会让测试人员疲于奔命，承受巨大的压力，最终带来质量风险和隐患。自动化通过机器代替人工执行操作过程，可以帮助测试人员减少人工操作，将其从重复烦琐、枯燥单调的测试操作中解放出来，让他们更专注于容易出错、存在质量盲区的地方，如通过探索式测试确保整个软件的质量。
在敏捷环境中，测试人员只执行测试是不够的，因为敏捷团队中的角色职责已经变得模糊。通过1.3节的介绍，我们知道在开发团队中没有明确区分开发人员、测试人员等，所以如果出现开发人员做测试、测试人员做开发的情景也不要觉得奇怪。敏捷环境要求具备复合型的跨领域测试专家，而对于复合型人才，目前听到比较多的称呼是“T”型人才，也就是说，除了纵向有一个钻研得比较深的主打领域，还要发展横向的跨领域技能。对于测试人员来说，除了测试领域，还可以发展如业务能力、开发能力或敏捷DevOps能力等，用一个词来形容就是“一专多能”。
敏捷测试与传统测试相比，有相同之处，也有不同之处。相同之处在于无论是传统测试还是敏捷测试，其基本的测试方法和测试技术是一样的，如白盒测试方法和黑盒测试方法都可以在敏捷测试中使用，等价类、边界值、错误猜测等测试技术也同样适用于敏捷测试。但是，传统测试和敏捷测试在很多方面也存在差异，可以从测试发生的时间节点、团队沟通、自动化测试等10个重要维度进行对比分析，如表2-1所示。
表2-1 传统测试与敏捷测试的差异
在敏捷项目中，一方面，我们不得不转型为敏捷测试，不能继续使用传统开发模式下的测试方法；另一方面，敏捷测试本身也具有特定的价值。
敏捷测试可以帮助加快上市时间（Time-to-Market），从而缩短价值交付的周期。首先，敏捷把产品开发划分为多次迭代，并且在每次迭代交付潜在可用的、有价值的产品给客户，没有经过测试的产品不能发布给客户。敏捷测试确保每次迭代都有测试活动，从而保证每次迭代的有价值输出都是经过测试的，以便尽早达到发布条件，让最终用户尽快得到最小可行产品（Minimum Viable Product，MVP），尽快获取业务价值。其次，敏捷测试对自动化的要求更迫切，可以通过全栈式的自动化测试提高测试效率，从而缩短测试周期。最后，更早、更频繁地测试，及时修复缺陷，避免所有的问题都堆积在最后的测试阶段，造成“大爆炸”（Big-Bang）式的灾难性后果，同时降低整体返工的可能，避免在缺陷修复循环中打转，缩短价值交付周期。
质量是构建出来的，不是测试出来的。敏捷测试强调，质量是团队所有人的责任，除了测试人员，包括开发人员、产品负责人在内的所有团队成员都有义务对产品的质量负责，这样才能确保项目的整体质量。敏捷团队判断一个需求特性被完成的标准不再是开发人员把代码编写出来，而是开发完成且测试确认没有问题后才算完成，这样才能提高整体的产品质量。
首先，敏捷测试不要求详细的测试计划和测试文档，也没有定义繁复冗长的测试流程和缺陷管理流程，在测试管理方面完全遵循敏捷思想中的轻量级管理模式，从而为测试人员减少了不必要的负担，节省了工作量及成本。其次，敏捷测试提倡尽早测试，越早发现缺陷，修复的代价越低，以此有效降低了不良质量成本（Cost of Poor Quality，COPQ）。最后，敏捷测试分小批量迭代执行，可以有效地应对变更带来的影响，减少变更造成的浪费，从而节省变更成本。
本章讨论了传统测试在敏捷环境下面临的挑战，并且对敏捷测试进行了介绍，包括敏捷测试的定义、敏捷测试宣言、敏捷测试的特点与价值等。同时，还介绍了敏捷测试与传统测试的差异，使测试人员能够通过敏捷测试与传统测试的比对，对二者有更全面地了解。
本章的主要内容如下。
（1）传统测试在敏捷环境下会面临时间极短、文档极少、变更极频繁、资源极缺的挑战。
（2）敏捷测试是一套遵循敏捷软件开发原则的软件测试实践。敏捷开发将测试集成到开发过程中，而不是将其作为单独的阶段。因此，测试是核心软件开发的一个组成部分，并且融入软件开发过程。
（3）敏捷测试宣言包括测试是一个活动胜于测试是一个阶段；预防缺陷胜于发现缺陷；做测试者胜于做检查者；帮助构建最好的系统胜于破坏系统；团队为质量负责胜于测试者为质量负责。
（4）敏捷测试具有更强的协作、更短的周期、更灵活的计划、更高效的自动化、更广泛的技能要求等特点。
（5）敏捷测试的价值包括缩短价值交付周期、提高整体产品质量、节省成本等。