敏捷软件测试常见的七个误区

敏捷软件开发是从1990年代开始逐渐引起广泛关注的一种新型软件开发方法，是能够应对快速变化的需求的一种软件开发能力，它作为一种新型的开发模式，被越来越多地应用到软件项目中。

敏捷软件测试指的是在敏捷软件开发过程中跟质量相关的一系列活动，和传统意义上的软件测试有很多区别，因为敏捷软件测试的概念一直比较模糊，所以经常会有人走入误区，我曾经在瀑布型的软件开发模式下做过几年的测试人员，所以在刚刚接触敏捷项目的时候也曾有过一些误解，但是在敏捷软件开发团队工作将近5年后，对很多问题有了新的认识，以下针对几个常见的误区和大家分享一下我的理解。

不需要测试策略

测试策略关注的是目标和方法，即怎样在限定的时间内有效利用有限的资源达到提前制定的目标，一般制定测试策略时会首先明确测试目标，然后确定需要哪些测试类型，各种测试类型所占的大概比例，选择测试框架，最后规划一下软件发布前需要经历哪些测试阶段。

很多人认为，敏捷软件开发以用户故事为单元，是不是集中精力在用户故事测试就足够了？是不是根本不需要考虑测试策略？

其实这是一个很大的误解，因为敏捷软件开发通常都是迭代式的发布，周期比较短，资源非常有限，这就更需要我们统筹规划，小到一个用户故事，大到一个完整的用户特性，都需要考虑怎么合理利用测试资源，所以敏捷项目是非常需要测试策略的。

具体到实际项目中，通常团队会在项目初期（迭代0）制定测试策略，明确目标(包括功能性需求的目标以及非功能性需求的目标)，然后确定在开发阶段需要添加哪些自动化测试(包括单元测试，接口测试，契约测试，集成测试，系统级别的UI的用户场景测试)，并规定这些测试的大概比率(符合测试金字塔)，选择自动化测试框架（比如XUnit）以及需要哪些手动测试(包括探索性测试，可用性测试等)，还要规划每个发布周期需要进行的测试阶段（比如新功能测试，回归测试等），之后测试策略会对敏捷团队的开发及测试起到非常重要的指导作用，当然，每个团队因为项目的不同策略也会不同。

下图就是一个简单的敏捷测试策略介绍:

不需要测试文档

测试文档通常包括测试计划，测试用例，测试报告，测试缺陷等文档以及相对应的可以指导测试的一部分需求文档。

很多人会认为，敏捷软件测试是不需要文档的，敏捷宣言中有一句“工作的软件 高于 详尽的文档”，尽管敏捷宣言最后提到了“右项也有价值，我们更重视左项的价值”，但人们往往会忽视右项的内容，导致在很多刚开始实施敏捷开发的团队中完全否定了测试文档的作用。

首先不可否认，在实际的敏捷项目中，确实很少见传统意义上的正式的专门的需求文档和测试文档，但这并不代表敏捷项目没有文档，比如用户故事本身就是需求的载体，用户故事中的验收条件就是敏捷测试文档的一部分， 另外很多敏捷软件项目都会采用BDD的方式进行开发，将测试用例用业务人员能够看懂的自然语言描述，并结合自动化实现，形成一个融需求和测试为一体的文档，而且为了应对敏捷软件测试变化快文档更新不及时导致的问题，很多敏捷项目都在使用Living document。

纯自动化测试 or 纯手动测试

有些刚接触敏捷的人认为敏捷软件开发发布周期很短， 测试人员根本没有时间做手动测试， 所以应该采用纯自动化测试。

也有一些人认为，敏捷开发强调快速响应变化，如果投入成本在自动化测试上，那么肯定会导致维护自动化测试带来的资源浪费，所以应该采用纯手动测试。

这是两种极端的误解，虽然这两种观点所考虑到的难点确实存在， 因为在敏捷软件开发过程中， 迭代通常比较短，确实不会预留足够多的时间来做手动测试， 所以必须要有足够多的自动化测试来保障。

然而因为测试代码本身可能存在缺陷，而且有很多部分难以被自动化测试覆盖(比如界面的测试，可用性测试，探索性测试等)，所以敏捷测试也同样离不开手动测试。

至于关于自动化测试维护成本的顾虑，敏捷项目也确实存在变化比较多的特点，但通常变的都是比较接近用户的部分，所以应该尽量减少用户级别的依赖界面的自动化测试，而多增加一些不容易变化的底层的单元测试接口测试等。

推荐敏捷测试以自动化测试为主，手动测试为辅。

敏捷QA = 敏捷Tester
在很多刚接触敏捷实践的团队中，大家对敏捷QA的认识还停留在Tester的阶段，认为只要用户故事开发完成之后，QA去专职地做测试，发现缺陷就够了。

这是一个很大的误解，首先QA(Quality Assurance/Analyst)，不是单纯意义的测试人员，通过这个角色的名称我们可以看的出来敏捷QA强调的是质量保障和分析，而不单纯是测试产品。

在实际的项目中，敏捷QA通常会从需求分析阶段就开始参与整个软件开发过程，通过在不同阶段和团队中的不同角色合作，帮助整个团队对质量达成共识，并通过在不同阶段的确认和验证做到缺陷预防，而不是等到软件开发完成后再去发现缺陷，所以对于敏捷QA来说，其目标是软件开发完成后能够发现的缺陷越少越好，而对于Tester来说，发现越多的缺陷证明工作做得越优秀。

非功能性测试不重要

非功能性测试指的是针对非功能性需求（软件本身满足用户需求所必需的功能性需求以外的一些特性，比如安全，性能，可用性，兼容性等）的测试，通常包括安全测试，性能测试，可用性测试，兼容性测试等。

在敏捷软件项目中，需求被切割成了很小的单元，在切割的过程中，非功能性需求是最容易被人忽略的一部分，而这导致的问题就是非功能性测试经常被团队忽略，久而久之，就会形成这样一个误解，认为非功能性测试是不重要的。

这个观点非常不对，首先非功能性测试的重要性并不会因为软件开发模式的不同而有所不同，尤其安全测试和性能测试的重要性正越来越多地被重视起来，因为很多产品必须考虑到用户敏感信息的安全以及性能导致的用户满意度，在敏捷项目中由于软件会尽早发布，如果这些非功能性需求出现问题，就会更早地造成影响，很可能在软件刚步入市场就损失掉大多数的用户。

所以非功能性的测试和功能性测试同等重要，在实际的项目中，比较好的做法是将这些非功能性需求也加入到用户故事的验收条件中，在整个敏捷开发流程中对这些非功能性需求进行验证。

质量是QA的事儿
受传统观念的影响，很多人还是会认为质量是QA的事儿，如果产品发布后质量不好是QA的问题，其他角色和质量没有太大的关系。

首先这种认识太高估了QA对质量的作用，软件的质量是在软件开发过程中逐步形成的， 从需求分析阶段是否真正的了解到了客户想要的功能，到开发阶段是否增加了足够多的自动化测试保障，是否写了足够健壮的产品代码，到最后测试阶段是否测试了功能引入后整个系统的可用性，不同用户路径是否能正常工作等等，这些都是软件质量的组成部分。

可以看得出来，在整个过程中，软件的质量离不开敏捷团队各种角色的付出，其中有业务分析人员对需求的准确把握，有开发人员对产品代码的高标准实现，对自动化测试覆盖率的保障，还有QA在整个过程中对质量相关活动的实施和保障，包括需求分析阶段从QA的视角对业务的补充，开发阶段对自动化测试的审查，以及探索性测试可用性测试等对产品质量的进一步保障。

所以在敏捷测试中更多时候我们会淡化角色的概念，强调团队人人都为质量负责，这样更有助于团队的每一位成员都把质量作为非常重要的一部分，而不是依赖于某个人或者某个角色。

开发可以写测试，不再需要QA了

因为敏捷团队强调人人都为质量负责，开发人员会采用TDD等方式写大量的自动化测试，那么是不是就不需要QA了？

对于这个观点，在社区有过很多激烈的讨论，比如这篇文章《我们需要专职的QA吗？》就曾经引起了很大的争议，其实个人认为这篇文章里提到的QA指的是Tester，具体两者的区别可参考前面的观点；抛开这个，作者的某些观点其实是很有价值的，比如作者最后提到了质量不是测出来的，要通过软件生命周期各个阶段相关活动的保障，而这些活动都离不开QA的参与。

首先需求分析阶段，QA可以从不同的视角对于需求提出疑问，补充，修改，因为QA特有的技术背景，对于软件的可用性等有更深入的理解，所以往往可以提出不同于业务分析师和开发人员的观点；开发阶段，QA也会审查开发人员写的自动化测试，通过QA的专业测试背景帮助开发人员写更有价值的测试，比如我们在项目中曾经发现开发人员写了很多没有业务价值的测试；测试阶段，探索性测试，可用性测试，安全测试，性能测试等都是QA们在做的事情。

当然，如果业务分析师从各种视角把业务分析的透彻完美，开发人员可以写非常有价值的测试，也可以做各种类型的手动测试，那么去掉专职QA也不是不可以，那样的话不是不需要QA，而是人人都是QA。

结论

以上列出来的七点是刚刚接触敏捷测试时很容易进入的误区，甚至有的观点在一些已经施行敏捷很长时间的团队中仍然存在，这些观点很容易导致敏捷测试走上弯路，以上是结合实际项目经验个人的一些思考，希望对大家有所帮助。

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取