什么是敏捷软件测试

什么是敏捷软件测试

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

测试敏捷化 vs 敏捷测试

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

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

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

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

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

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

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

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

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

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

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

从Wikipedia的定义可以看到：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

敏捷测试的流程

1.需求分析：依据需求文档提取测试点

通过分析需求描述中的输入、输出、处理、限制、约束等，给出对应的验证内容，并分析各个功能模块之间的业务顺序，和各个功能之间的传递信息和数据，对存在功能交互的功能项，给出对应的验证内容（功能交互测试）。同时需要考虑到需求的完整性，要充分覆盖软件需求的各种特征，包含隐形需求的验证，比如界面的验证，账号唯一性验证（界面、易用性、兼容性、安全性、性能压力）。

2.编写测试计划和测试用例

为项目需求而编制的一组测试步骤，测试数据以及预期结果，以便测试某个程序是否满足客户需求，测试用例需关联到对应的issue或者story，测试计划的内容包含迭代内的全部开发任务。

3.用例评审：确认用例是否覆盖到各个场景，以及用例是否符合需求

用例评审主要是产品、开发和测试人员，针对测试用例能否用于项目的测试而做的工作。主要是为了减少测试人员执行阶段做无效工作（提交无效问题等），以避免三方需求理解不一致。评审按用例的优先级，功能的复杂程度进行；先对优先级高，功能复杂，疑问多的用例进行评审，再评审功能简单，优先级低的功能点。评审过程中尽量做到思路清晰，用最简洁的语言阐述每一个功能点。对于评审过程中，超过5分钟无法确定结果的问题，可以记录下来，作为会后讨论跟进的重点。

4.测试执行

测试执行是执行所有或部分选定的测试用例，并对结果进行分析的过程。测试执行活动是整个测试过程的核心环节，所有测试分析、测试设计、测试计划的结果将在测试执行中得到最终的检验。

5.转化测试后的bug

将执行完的有bug的测试用例关联敏捷协作中的缺陷。在敏捷协作中一个缺陷可以快速定位到测试用例，帮助开发者快速获取测试结果，实现测试闭环。

6.回归bug测试

通过敏捷中的迭代规划，制定团队的回归方案，积极跟开发人员沟通问题原因、修复的方案和影响。整体的回归bug测试进度计划中需要包含所有回归测试和自动化回归测试时间，同时预估好每天的工作量，与实际完成的工作量进行对比，尽早知道测试进度是正常还是延期，提早控制好风险，从而达到团队能更好地交付价值的目的。

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

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

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

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

瀑布模型的优点如下：

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

瀑布模型有以下缺点：

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

上述内容就是小编整理的什么是敏捷软件测试相关信息。关注学分高考了解更多相关知识！（本文共7932字）