测试敏捷化 vs 敏捷测试

测试敏捷化 vs 敏捷测试

本文首发于网站【 林子的空间 】

大家可能关注到双态IT联盟前一阵发布了一个 测试敏捷化成熟度评估模型 ，不断有小伙伴问到我关于这个成熟度评估的问题，我发现大家很自然地把这个跟敏捷测试成熟度画上了等号，不过这不是Thoughtworks开发的，我也不是很清楚。为此，我特地进行了一番调研，希望我这篇文章的解读能解答大伙大部分的疑问。

我们先尝试从字面意思来理解一下，对于以下两个术语大家都比较熟悉：

这两个例子，相信大家都能理解没有问题。关于测试敏捷化，类似地，从字面意思可以这样理解：

那么，“敏捷的测试”是否等同于“敏捷测试”呢？从字面意思来看，似乎是等同的。但事实如何，需要对两者有深入的理解才可以下定论。

为了更好地解释，有必要先介绍什么是敏态与稳态。

在数字化转型时代，企业一方面需要适应数字化时代快速变化的市场需求，另一方面需要保持关键业务的安全可靠和稳定性，传统的IT需要同时适应这两种业务形态，面临很大的挑战。为了应对这种挑战，Gartner公司提出 双模IT（Bimodal IT） 的理念：

传统企业数字化转型的常规做法是可预见性的业务使用传统瀑布式开发，称之为 稳态 ；探索性的业务使用敏捷开发，称之为 敏态。Thoughtworks洞见安辉的文章 《敏捷转型中的敏态与稳态》 对此有比较详细的介绍。

当然，稳态和敏态的这种做法在业界也存在争议。Thoughtworks数字化专家肖然在文章 《数字化时代的科技双模，双模IT成为过去式》 中指出：

尽管如此，传统企业转型过程中，基本都会长期经历敏态和稳态共存的阶段，对转型有着积极的意义。从长远来看，最终还是需要转型到组织级的敏捷，实现真正的全流程端到端敏捷的。

关于敏捷测试，引用Wikipedia的两段话：

从Wikipedia的定义可以看到：

同时，Thoughtworks的资深QA们基于多年敏捷团队开发实践经验提炼出的 敏捷测试宣言 ，非常清晰的表述了敏捷测试的价值观：

敏捷测试是 基于敏捷价值观“快速高效地交付更大的价值”这个目标 ，所开展的所有质量相关活动，是从团队的角度去思考如何实现这个目标，而不再是以测试这个活动/角色的角度出发，不能简单地理解为“敏捷的测试”或“敏捷地测试”。

关于敏捷测试的更多详细内容，欢迎参考刘冉老师的 《Thoughtworks的敏捷测试》 文章和我的 《敏捷测试》系列 文章。

测试敏捷化这个概念来自于双态IT联盟发布的 《测试敏捷化白皮书》 （以下简称“白皮书”），这里直接引用该白皮书中的内容来解释测试敏捷化。

从前面引用的内容来看，测试敏捷化是将测试作为 独立主体 ，从测试的角度出发来考虑优化和改进。

基于白皮书的内容，双态IT联盟还发布了相应的成熟度评估模型，这个成熟度评估也是 基于测试的几个维度 进行的：

到此，我们可以比较清晰地看到测试敏捷化是围绕测试在解决问题，考虑的更多是测试价值的体现。

了解了概念，再来从背景、目标、主体、关注点和适用范围这几个维度集中对比一下测试敏捷化与敏捷测试：

从上表我们不难看出测试敏捷化与敏捷测试具备较大差异：

敏捷测试是产生于敏捷软件开发模式，在这种新型开发模式下需要考虑如何满足质量保障的需求，自然而然产生了敏捷测试。敏捷测试是遵循敏捷价值观的，其目标也是跟敏捷开发一致，那就是快速高效地交付更大的价值。

测试敏捷化则是在数字化转型过程中敏稳两态共存的情形下，传统IT稳态模式的测试团队面临转型挑战，旨在帮助测试团队实现转型。因此，测试敏捷化的目标主要是为了体现测试的价值，提升测试团队的敏捷能力。

为了实现目标，敏捷测试以全功能的敏捷开发团队为主体，关注软件开发全生命周期的质量相关活动。敏捷测试不再是以测试这个检验环节/活动为主，不会强调某个独立角色，而是要求团队整体为质量负责，实现测试左移、持续测试和测试右移，快速获取反馈，从而真正实现软件产品的质量内建。

而测试敏捷化是以测试作为独立主体，以测试的角度出发考虑优化改进，主要关注点包括测试需求、测试计划、测试设计、测试执行等测试过程，以及环境、数据、技术、工具等测试的支撑。

如上面数字化转型示意图所示：

敏捷测试产生于敏捷开发模式，必然适用于纯敏态的开发团队。同时，敏捷测试的一些方法和实践，也可以被稳态团队所借鉴并适当采用。

测试敏捷化由于背景、目标、主体和关注点都不同于敏捷测试，是不宜用于敏态开发环境的，只适用于稳态环境。

数字化转型的确给传统测试团队带来很大的挑战，一方面要配合敏态团队实现测试开发融合，另一方面还要面临稳态测试如何优化改进的问题。

测试敏捷化虽然在一定程度上帮助转型中的稳态测试团队，但是不能从根本上帮助转型的实现。另外，前面提到敏稳双态共存模式不过是转型中的一个过渡阶段，是否要为这种过渡时期的稳态模式投入较多精力，请深思而前行。

测试要实现转型以适应敏捷开发模式，不能只是测试人员的转型、也不能只是测试工作方式的转型，只有改变文化理念和认知方式、调整组织架构和沟通方式、优化流程和策略、采用有利于快速反馈的工具与实践，按照由内而外的“道”->“法”->“术”->“器”方向实现彻底的转型，才有可能实现真正的敏捷测试。这个内容我在文章 《数字化转型背景下的测试转型》 里有非常详细的介绍，请移步阅读。

敏捷测试不是“敏捷的测试”，也不是“敏捷地测试”，而测试敏捷化是“敏捷地测试”，两者不等同。

由于测试敏捷化的背景、目标、主体和关注点都不同于敏捷测试，是不宜用于敏捷开发模式的，只适用于传统企业的稳态模式，也不能帮助稳态团队实现敏捷转型。而敏态、稳态共存本身就是数字化转型的过渡阶段的产物，因此在稳态测试团队采用也需要谨慎前行。

传统测试的真正敏捷转型需要遵循“道”->“法”->“术”->“器”方向、实现由内而外的转变才能实现。

敏捷测试与传统测试的区别

首先敏捷测试(Agile testing)是测试的一种，敏捷测试的理念是，和编码一样，测试是开发的一个关键部分。在敏捷中，测试被直接集成到软件开发过程中，以便尽早、频繁地发现bug。因此，测试人员可以在开发过程的每一个节点上发现问题，从而使产品快速走向发布。

敏捷测试的特点有以下几点：

传统测试即基于瀑布模型开发的测试，瀑布模型将软件生命周期划分为 制定计划、需求分析、软件设计、程序编写、软件测试 和 运行维护 六项基本活动，其过程是将上一项活动接收的工作对象作为输入，当该项活动完成后会输出该项活动的工作成果，并将该项成果作为下一项活动的输入。该模型规定这六项基本活动自上而下、固定相互衔接的次序，如同瀑布流水，逐级下落。从本质上讲，它是一个软件开发架构，开发过程是通过一系列阶段顺序展开的，从需求分析直到产品发布和维护。如果在其中某个阶段有信息未被覆盖或有问题，那么就得返回到上一个阶段，并对这些阶段进行适当的修改才能进入下一个阶段，这样每个阶段都会产生循环反馈，开发过程从一个阶段“流动”到下一个阶段，这也是瀑布模型名称的由来。

瀑布模型的优点如下：

增量迭代应用于瀑布模型，迭代1 解决最大的问题，每次迭代产生一个可运行的版本，同时增加更多的功能，但每次迭代必须经过严格的质量和集成测试。

瀑布模型有以下缺点：

搞清楚了什么是敏捷测试，什么是传统测试，最后我们来对比一下他们之间的区别，整理如下：

敏捷测试0：开发和测试打架，怎么办？

开发和测试是怎么打架的？

线上出了 Bug 召集会议复盘，开发指责测试没测出来，没把好质量关；测试抱怨开发不做单元测试，要不早发现了。

结果往往是大家写个改进报告，测试保证添加相关测试用例并补充到回归测试集，开发承诺以后做好自测，提交了事。
这就是我工作中经常遇到的事情，怎么破？

用敏捷测试的方法来解决。具体怎么解决，我们以后说。

什么是敏捷测试？

究竟什么是“敏捷测试”？敏捷测试是指敏捷开发模式下的一套完整的软件测试解决方案。它强调“与开发协作”、“自动化测试”、“客户思维”和“动态的测试策略调整”。

不变的是它的价值观、理念以及思维方式；变的是持续改进的敏捷测试方法、技术和工具。

敏捷测试课程主要内容有哪些？

一、什么是敏捷测试

二、如何管理敏捷测试中的人

三、如何搭建敏捷测试框架

四、如何逐步实施敏捷测试

从今天开始记录敏捷测试课程学习笔记，用输出倒逼输入。

现实世界中出现问题了，我这里有个解决方法，我将从四个方面为你讲述这个方法。
如果你也遇到这种问题了，那过来一起学习吧！

什么是敏捷软件测试

【编者按】敏捷的理念已经深入人心，开发过程已经渐入佳境，测试的处境却稍显尴尬。测试从业者应该何去何从，怎样才能拥抱敏捷，体现出自己新的价值呢？InfoQ特地邀请了来自Google的敏捷测试专家段念，为读者答疑解惑，希望所有测试从业者可以从中得到自己的答案。更多关于敏捷测试的内容，请访问InfoQ中文站敏捷测试相关内容。在与不少测试从业人员讨论到敏捷的时候，被问得最多的大约是两个问题：到底？，敏捷软件开发还需要测试工程师吗？。前一个问题是对于敏捷测试本身定义的疑问，第二个问题则是对敏捷开发将测试工程师排除在外的担心。其实，在探寻这两个问题答案的过程中，我们可以更清晰的了解敏捷软件开发中测试的工作定义，测试价值观，以及敏捷开发中开发与测试工程师的配合。鉴于这两个问题的意义，在本敏捷测试专栏的第一篇文章中，本人尝试从自己的实践出发，尽可能清楚的回答这两个问题。确实，相对于敏捷开发红遍大江南北的状况而言，对敏捷测试的讨论则低调得多。敏捷联盟定义了敏捷的4个价值声明，以及伴随的12条支持原则，这12条原则中没有一条单独提到测试。这是不是意味着测试在敏捷开发中并不重要呢？实际上，如果仔细研读敏捷的12个原则，以及各种不同的敏捷实践，就会发现，测试在敏捷开发中占有非常重要的地位。无论是原则中的频繁交付，还是对可工作的软件的度量，或是敏捷开发实践中的测试驱动开发，行为驱动开发，都离不开测试的支持。在本人看来，敏捷开发中不把测试单独拿出来描述的原因，恰恰是因为在敏捷开发中，测试不再是一个单独的、和开发独立的过程，而是变成了驱动开发、衡量产出的主要的手段，成为了敏捷开发中所有工程师在工作时必须时刻考虑和实践的一个部分。简而言之，敏捷软件测试更多的是一种理念，而非过程。既然是这样，为什么我们还要在这个专栏中专门来讨论敏捷软件测试？本人接触过不少软件开发和测试工程师，他们所处的组织有的正在努力向敏捷开发转型，有的已经实践了一段实践的敏捷开发，但由于由来已久的工作习惯，他们中的绝大多数并不能自觉的认识到测试在敏捷开发中的关键作用，而是有意无意的将测试仍然看作是与开发截然分开的下一个阶段，导致在实践敏捷开发的过程中遇到种种问题：要么是忽略了代码质量，导致在频繁的迭代过程中，每一个迭代的问题层出不穷；或是沿用原有的方法安排对系统的系统测试，导致测试团队疲于奔命，却总也赶不上开发所要求的进度。在这种情况下，专门来讨论敏捷软件开发中的测试，也就是敏捷软件测试的话题，对这些工程师应该会有一些帮助。那么，到底？很难给敏捷测试下一个精确、完善的定义，在本人看来，接纳了敏捷的核心价值观（沟通，简单，反馈，勇气，尊重），在敏捷软件开发过程中开展的测试就可以被称作是敏捷软件测试。因此，敏捷软件测试并不是一个与敏捷软件开发同一层次的划分，而是敏捷软件开发中的一部分，与传统的测试不同，敏捷软件测试并不是一个独立的过程，相反，它与整个敏捷开发中的其他活动交织在一起，处处都能看到它的影子。由于敏捷软件测试并不倾向于一个单独的过程定义，本人拟从敏捷软件测试与传统测试观点的比较、敏捷软件测试中采用的方法、测试工程师在敏捷软件测试过程中的工作等方面来阐述之。在这篇文章中，我们主要从宏观的角度来描述敏捷软件测试，而在本专栏的后续文章中，我们将对敏捷软件测试中采用的方法、工程师在敏捷软件测试中的工作内容等进行进一步的描述。使用Dashboard、燃尽图等方式展示当前工作与可交付产品之间的距离建立单元测试覆盖率等度量指标共享质量目标意味着质量责任由所有工程师共同承担开发测试应该建立一定的测试覆盖率标准，例如，在单元测试这个级别上，建立60%或80%的覆盖率要求通过使用TDD、BDD等技术，保证产品和代码的可测试性建立足够多的自动化测试，保证测试能够满足快速迭代的要求检查表提到了团队、反馈、质量文化和开发测试四个方面的内容，在本人看来，这四个方面体现的就是敏捷软件测试与传统软件测试的最大的不同。传统软件测试关注的是通过尽可能完备的覆盖去发现尽可能多的问题，把测试和开发当成是两个独立的过程，测试是对开发阶段产生成果的验证。而敏捷软件测试则建立了一种不同的质量文化：测试的目的是为了保证产品快速发布，也就是对生产率本身的提高。基于验证的出发点必然会要求测试与开发的独立，以及尽可能客观和完备的度量产品质量；而基于生产率的出发点则要求建立敏捷的团队，要求测试与开发尽可能紧密，要求建立具有高度可测试性的软件，以及基于这些的高度自动化测试。在检查表列出的所有项目中，质量文化是基础，团队是敏捷软件测试得以实施的条件，反馈和开发测试则是敏捷软件测试的具体方法。当然，你可以可以从敏捷的核心价值观来阶段这些项目：团队关注的是沟通与尊重；反馈直接对应于反馈；质量文化基于勇气（承担质量责任的勇气）与尊重；而开发测试则是反馈与简单的具体体现。另一个在本文最初提出来的问题是：敏捷软件开发还需要测试工程师吗？，对这个问题，业界有不同的观点。有人认为需要，因为总有一些是需要测试工程师的技能完成的工作；当然，也有人认为不需要，因为敏捷开发中的测试注重开发测试与自动化测试，开发工程师就可以自己搞定与测试相关的工作。在实践中，那些大规模实践敏捷开发的公司（例如Google），倾向于在组织中设置数量较少的测试工程师，在项目中分配较少的测试资源，甚至对某些项目，完全不使用测试工程师。就我的个人实践经验，对大部分的项目，尤其是为明确的客户开发的项目，需要在敏捷开发团队中设置专职的测试工程师，因为：测试与开发具有不同的思维方式：测试更注重全面的验证和检查一个系统，而开发工程师往往很难在大的范围内建立这样的思维方式。因此，无论是从系统的层面验证产品，或是从应用系统的角度发现值得测试和验证的点（access point），专职的测试工程师都更有效。专职的测试工程师能够更关注于测试基础，建立测试需要的基础架构：由于测试工程师具有更好的对测试的理解，通常他们能够更多的考虑测试的需求而开发适合项目的测试基础架构（自动化测试框架），而开发工程师可以使用这些框架来建立面向功能或代码的测试。但是，不得不说的是，敏捷开发对开发和测试工程师都提出了更要的要求，尤其是对测试工程师而言，传统的只能精确模拟用户操作的测试工程师，因为不能为产品带来生产率的提升，在敏捷开发的团队中，很难有所作为。在本专栏的后续文章中，我们会进一步讨论测试工程师在敏捷软件开发中的工作和任务。关于作者段念：Google中国高级测试经理，毕业于华中科技大学，先后在通讯、嵌入式软件、互联网等多个行业的国内外知名公司中从事软件开发与测试工作。对软件测试中的技术和管理工作有独到见解，对软件测试团队管理、自动化测试、性能测试与开发测试有较多研究。

敏捷团队中的测试策略

这篇文章主要总结了我对于敏捷项目中总体测试策略的理解，主要来自于工作上的实践和思考。

先看下维基百科上关于 test strategy 的定义

归纳上面的定义，我们可以得出测试策略的最终目的是通过定义项目会采用的测试活动，尽可能得暴露和消除产品缺陷，减轻产品风险。除此之外，由于软件开发时常伴有交付压力，测试的时间和资源都是无法保证甚至可能被压缩的，所以测试策略还会从最低成本揭露产品质量风险出发，选择出最合理的测试方法和测试过程。

基于上面的定义，可见测试策略解决了两个大问题：

在详细点就是：

要说不同，先看定义上的不同。

由上可见，其实测试策略的内容已经被包含在测试计划里面了。测试策略定义应该做什么样的测试而测试计划包含所有关于测试策略该如何执行的信息，这些信息在测试计划里面被很好的组织起来。

一个公式可以进一步说明他们的关系 test plan = test strategy + test logistics。所以test strategy可以被看做是test plan的一部分。Test logistics 是指测试环境设置以及人力资源等等。

在James Bach的博客 A Question about Test Strategy 中，他把三者描述如下

让我们先来看下QA在敏捷项目中的主要工作，如下图所示

那你可能问“咦，怎么没有测试策略相关内容呢”。其实，整个开发测试流程就体现了测试策略的内容。上图所示的迭代开发流程里面包含了"Automated Acceptance Tests" & “Story Testing” & “System Testing”这些测试活动，那么为什么项目需要这些测试活动？这些活动如何具体如何开展？分别在哪一个项目阶段进行？这些问题都属于测试策略的范畴，是由测试策略定义和落地的。

敏捷开发模型下，迭代式的开发具有周期短和交付压力大的特点，对于如何快速响应新需求，保障新需求的质量以及已实现需求的回归测试都将是测试的挑战。如果没有一个匹配项目上下文，合理规划了测试活动的测试策略，这些挑战就会持续困扰着团队，所以标题的答案是当然需要。测试策略在敏捷开发模型下，通过详细定义项目的测试活动，能够更加合理地利用测试资源和统一项目对测试的认知。

此外，测试策略也是敏捷项目质量保障体系中重要的一节。

在传统瀑布开发模式下，测试计划test plan被认为是项目测试流程的关键部分，因为它指导着整个测试活动的开展，既然被认为是项目中的一个must have，于是有人会花很多时间很多精力去把测试计划给写好写完整。那么我们真的在敏捷开发模式的项目里需要一份测试计划吗？这真的能给项目质量带来价值吗？

敏捷宣言说过：

在敏捷项目中，产品范围也就是发布内容在spring进行之前就被讨论，所以QA们对于测试对象和测试范围一直都是清楚的，不需要特别地花时间去写一个详细的文档来阐述。同样地，agile ceremony会让QA们清楚地知道测试对象是什么，范围是什么，重点是什么，测试环境是什么而不需要一个单独的文档来进行详细的描述。甚至，所有关于测试的信息还可以被记录被故事卡中。在开发进行编码实现功能的时候，QA们会进行测试用例设计以及自动化测试编写，因为时间的紧迫，QA除了这两项测试活动，再去写一个详细测试计划是不经济的且价值不大，这两项测试活动才是敏捷项目中价值最高的，况且随着迭代的进行，测试计划的维护还需要时间精力。

综上所述，在敏捷项目中因为时间紧迫和避免重复劳动，价值不高的测试计划不是一个must have，个人甚至认为也不是一个nice to have。但是这并不是代表我们不需要"planning"，而是不是需要"document planning"，"planning"的实施发生在迭代中的各类活动。

最终我们还是需要一个“计划”来指导迭代中的测试流程和方法，这就是测试策略是一个must have的原因。在敏捷项目中，“小而精”的测试策略比起“大而全”的测试计划而言，最大的优势就是测试策略定义的内容(“怎么测”)是不会轻易受影响改变的，并且在迭代中没有类似的重复活动。

具体到项目里，测试策略推荐在项目刚启动的时候制定。测试策略需要在项目早期就制定下来，用来指导项目的测试活动和方法，从而确定需要的测试资源和保证质量体系的建立。但也不能在产品和技术都还没有确定的时候就制定，因为只有在产品需求范围，技术架构和交付计划大致确认的情况，测试策略才能更加准确，从而减少维护成本。

因为测试策略会涉及到很多具体的测试技术和方法，也会要求制定人员具有对质量和测试非常深的理解，所以QA在敏捷团队中应该承担制定测试策略的主要责任，但是这并不意味“只有”QA来编写制定测试策略，测试策略的制定是一个团队活动，QA需要从不同角色收集到不同的信息

从多方收集信息能够保证业务、技术和质量三者对齐，避免误解和冲突，共同发挥最大的作用。

当测试策略制定完成以后，还需要给项目团队进行讲解，确保团队所有相关人员对项目中的测试活动和测试方法有着一致的理解,这样才能保证实施阶段的顺利。

接下来会涉及到QA制定测试策略的具体活动及流程。总的来说，大体流程可以如下

上面提到了QA可以从不同角色收集到不同的信息，除此之外，使用启发式测试计划语境模型 Heuristic Test Planning Context Model和启发式测试策略模型 Heuristic Test Strategy Model也是一个有效的渠道。具体如何使用这两个模型，请参考 htsm 和 htcpm。

通过分析 htsm 中“项目环境”和“产品元素”的关键词和启发式问题，QA可以了解关于产品和项目的各类信息来帮助制定测试策略。htcpm 也提供了大量的关键词来启发QA去分析了解产品需求、项目环境、测试小组和测试资源。

可以收集的信息大致可分类如下

只有从不同的维度收集到足够的项目信息并且很好的理解这些信息对项目质量和测试活动的影响，才能帮助我们少走弯路，制定出适合项目和团队的测试策略。

在具体思考“怎么测”之前，我们需要确定项目的质量目标。这个质量目标会对齐项目所有相关人员对于项目质量的理解和期望，明确质量范围也就是测试策略会覆盖的范围。同时，质量目标也要与产品目标对齐，因为质量的最终目的也是保证产品的成功。根据产品在不同阶段都有不一样的目标，质量目标有会随之变化。

那质量目标如何设定？主要是参考软件质量特征列表和软件质量模型，建立符合项目上下文的产品质量模型，从而确定项目质量目标

要建立项目产品的质量模型首先就需要先知道一个软件产品的质量属性或特征分别有什么，对应的质量模型是什么样的。幸运的是现在已经有很多可以参考的模型了

ISO/IEC_25010的质量模型大致如下：

从上面的质量特征列表或是模型可以看出，一个软件产品的质量由多个质量特征或标准组成，每个质量特征又可以进一步分解为子特征。通过这些已有的质量模型来启发哪些质量特征是对项目产品重要的，哪些质量标准适用于本项目产品，最后得出符合项目上下文的产品质量模型。

比如 我们创建的产品质量模型可以包含以下粗粒度特征：

上面的质量模型定义了产品质量特征和标准，而这些特征和标准就是我们应该完成的目标！除了上面说到的质量模型，一些具体的metrics也可以被引入来保证项目质量，成为项目质量目标的一部分。举个例子

上面提到的标准都是可以通过集成到持续集成流水线的质量工具或测试框架来实现。

此外，还有团队也会使用测试策略目标宣言来打造团队文化。

有了质量目标，接下来我们要考虑要怎么达成这个目标了！也就是说，我们应该有哪些测试类型来覆盖每一个质量目标？

测试类型按照不同维度可以有很多种分类，比如说

当然，上面只是列出了一部分。

此外，HTSM中的 Test Techniques 提供了九种通用的九种测试技术来启发对可应用的测试类型的思考。敏捷测试四象限也提供了敏捷项目可以参考的测试类型,这个测试技术分类系统可以帮助我们快速定位某测试类型在软件开发中的位置，根据项目产品情况选择合适的测试类型。
就以我们上面假设的质量目标为例，我们来看看可以应用哪些测试类型

值得注意的是，并不是每一个项目都需要覆盖上面所列出的测试类型。我们应该根据产品的目标和特点以及其他实际情况选择与之对应的测试覆盖类型，也就是说，不同项目根据测试类型的不同，测试广度是不一样的。同事，根据测试的难点和重点，测试深度也是不同的。所以，一切都要基于项目的上下文来思考和制定。

自动化测试金字塔用来指导敏捷项目中自动化测试的策略。

根据金字塔理论，项目应该在底层的单元测试和集成测试(API测试)投入更多的精力。

自动化测试项目会被集成在持续集成流水线里面，由上游项目自动触发。为了减少持续集成的反馈时间，一个普遍的做法是把庞大的自动化测试套件集依据重要性优先级放在不同的流水线里面，可以被上游项目触发也可以定时触发，下面描述了一个比较好的实践：

确定测试类型之后，我们就知道了整个项目的测试活动会有哪些。对于某些测试类型，特别是自动化相关的测试，我们需要对应的测试工具或是框架来支撑我们的测试。所以我们需要对每一个测试类型都去思考下如何进行测试，是否需要相应的测试工具和框架的支持。

拿一个web程序来举例

这个环节我们需要确定在项目开发生命周期的每个阶段做什么样的测试，使得测试类型与项目的开发流程充分结合，这样就能最大发挥所有测试活动的效果来达到我们的质量目标。因此，我们可以做出类似下面这样的表格来表现每个阶段的测试类型及其实施方法。

至此，测试策略解决的两个问题“测什么”和“怎么测”都可以找到大致答案了。

那如何衡量测试策略的有效性呢？质量度量可以告诉我们产品的质量情况和用户满意度，从而反应出测试策略是否有效和高效。

软件质量的度量没有什么最佳实践，也没有最准确和科学的度量，有的只是项目上积累的成功经验；但是这些成功经验又由于项目差异化太大而变得复用性很差。所以根据项目的上下文，我们需要制定出自己的质量度量标准。结合本文敏捷项目的背景，我们可以大致使用下面常用的度量：

同时，实例化的质量目标也是很好的项目质量的工具。对于质量模型，我们可以看下每一个质量元素我们是否做到；对于具体的指标metrics，要随时监控反馈。

一旦测试策略被确定，一般来讲不会经常变化，因为测试策略设置了一些测试标准。如果测试标准频繁地变动，这会让具体计划的执行变得困难，同时带来更多的资源浪费，最终影响了项目的质量。

在项目中我们会经常遇到“变化”：比如说

这些变化对测试的影响是被测对象的范围以及项目资源的调配。对于项目的质量目标、测试类型、测试阶段影响不大。所以，测试策略一旦被制定出来，变化不会太大。

不过这不代表测试策略的一成不变和缺乏改进，QA需要在每个迭代中观察测试策略实施的效果来决定当前的测试类型和实施手段是否满足项目需求。比如当项目集成测试(API Testing)经常fail，且协调工作耗时费力，QA可以考虑采用契约测试来代替现有的集成测试，提高整个项目组的生产率和质量；比如发现Internet Edge突然用户量增多且有关于Internet Edge的production bug被raise，QA需要把Internet Edge加到兼容性测试中，并且设置相关的测试环境；比如测试进度落后，交付压力增大，QA需要及时调整测试范围和测试重点，进行风险分析。

在实际项目中，往往会出现各种各样的问题来阻碍测试策略的顺利落地和执行。这些问题有些是测试策略自身的问题，但也有项目带来的问题。这时候，风险分析显得格外重要。

对于测试策略的风险分析，这个是应该贯穿整个测试策略制定周期里面的，我们需要通过项目风险清单提前识别项目中可能阻塞测试的风险，并通过风险优先级(风险暴露的概率*风险暴露的损失)来评估风险，最终基于风险调整测试策略，把测试重点放到风险高优先级高的地方。

测试策略是影响质量的重要因素，但不是全部，下面列出了部分会影响质量的因素作为参考，在此文中不会展开来讲

上面详细阐述了我如何理解敏捷项目中的测试策略以及制定测试策略的具体步骤。由于IT项目的多样性和复杂性，这个总结不可能适用于有着不同上下文的项目，因地制宜地制定测试策略才能保证测试策略在项目中的可用性和合理性。

敏捷测试的指导性原则

           1） 产品的质量不是测试出来的，是软件生产出来就是这样的。

            2）但现实很残酷，上线前最紧张的还是QA，我们也很无奈...
1.QA就是一个角色。

    团队中任何一个人被赋予这个角色就要承担QA的职责，承担QA要做的事情，eg:BA 也可以被赋予这个角色。

2.能力要求
                                                                                                -----学习自《ThoughtWorks》

怎么做敏捷测试人员？

1、敏捷测试人员的定义
我们这样定义敏捷测试人员：专业的测试人员，适应变化，与技术人员和业务人员展开良好协作，并理解利用测试记录需求和驱动开发的思想。敏捷测试人员往往具有优秀的技术能力，知道如何与他人合作以实现自动化测试，同时也擅长探索性测试。他们希望了解客户在做什么，以此更好地理解客户的软件需求。
谁是敏捷测试人员？她是驱动敏捷测试的团队成员。我们知道许多敏捷测试人员刚开始的时候在从事其他工作。开发人员可能会爱上测试而超越单元测试的范畴。习惯以敏捷方式工作的探索型测试人员也会被敏捷团队吸引。其他角色的专业人士，比如业务或者功能分析师，也可能具有同样的特质并做同样的工作。
技能很重要，但态度更值得关注。Janet总是说：“如果态度不好，那么技能则一无是处”。既然我们要为敏捷团队招募大量的测试人员，那么必须慎重考虑这一点，并与敏捷社区的其他朋友进行相关讨论。测试人员往往可以总览全局。他们更多时候是以客户的角度看待应用程序，这意味着他们一般以客户为中心。
2、敏捷测试思想
如何使一个团队变得“敏捷”？对我们而言，敏捷团队持续关注如何最出色地工作并发布最优秀的产品。根据我们的经验，这需要大量的训练、学习、时间、实验和协同工作。这并不适合所有人，但是对那些希望自己团队充满活力并关注持续改进的人来说非常适合。
成功的项目总是因为优秀的人才完成了出色的工作。在敏捷团队中做一名成功的测试人员所需要的特质可能与在任何团队做一名高水平的测试人员所需要的相同。
敏捷测试人员不会把自己看作是质量管理办公室的主管以保护客户避免受到缺陷代码的伤害。她会乐于收集和分享信息，与客户或者产品负责人协作以帮助他们充分展示自己的需求，从而得到他们需要的功能，同时向所有人提供项目进展的反馈。

（来源：学分高考 https://www.xuefen.net）文章共14190字