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

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

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

　　不需要测试策略

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

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

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

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

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

　　不需要测试文档

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

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

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

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

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

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

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

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

原文转自：http://insights.thoughtworkers.org/agile-testing-misunderstanding/?utm_source=tuicool&utm_medium=referral