本文共 1847 字，大约阅读时间需要 6 分钟。
首先，敏捷测试(Agile testing)是测试的一种，原有测试定义中通过对被测试系统（SUT）执行测试从而发现问题。
敏捷测试（Agile Testing）是遵循敏捷宣言的一种测试实践：
1）强调从客户的角度，即从使用系统的用户角度，来测试系统。
2）重点关注持续迭代地测试新开发的功能，而不再强调传统测试过程中严格的测试阶段。
3）建议尽早开始测试，一旦系统某个层面可测，比如提供了模块功能，就要开始模块层面的单元测试，同时随着测试深入，持续进行回归测试保证之前测试过内容的正确性。
敏捷测试意味着“聪明的”工作而不只是“低头辛苦的”工作。
这一点主要是强调测试：
1）不是按部就班的进行，在Sprint迭代中更早的介入测试；
2）采用更加灵活的测试技术和方法；
3）要激活测试者的主观能动性
4）测试者需要和开发者密切合作
因此，当每个团队以协作的方式完成任务时，能够以最有效的方式促进产品的持续交付。
测试是在开发周期中进行的，以确保可交付成果应处于稳定状态，以便测试人员可以从不同的角度测试主要功能。
整个开发过程被划分为更小的Sprint迭代，在给定的时间框架内交付给客户。
它促进了测试人员和开发人员之间的有效关系，以获得所需的成果。这也增强了个人适应工作流程所需的变化的能力。
敏捷测试不像传统技术那样是连续的，而是一种连续的机制。
在一次Sprint迭代中发现的所有错误或问题都由敏捷团队在该迭代中纠正。这简化了测试和修复缺陷的任务。
测试团队持续提供反馈，以确保持续的进展。
1）探索性测试（Exploratory Testing）
在探索性测试中，测试设计和测试执行是同时进行的。在这种情况下，测试人员通过使用不同的用户行为来进行每次点击和尝试来破坏系统。没有向测试仪提供详细的文档。他们根据自己的经验专注于高风险场景。
2）基于风险的测试（Risk-based Testing）
在这种方法下，测试任务的优先级是基于风险的。对风险较大的较关键领域首先进行检测和整改。这些区域中的任何故障都可能导致重大损失或服务器崩溃等复杂问题。相对不太关键或较小的区域保留到最后，即使这些区域中有任何错误或故障，损失是名义上的，问题可以很容易地得到纠正。
3）FIT Tests（Framework Integrated Test，FIT Tests）
FIT代表框架集成测试。顾名思义，这种方法是分析师、测试人员、开发人员甚至客户任务的集成。当使用这种方法时，测试的结果有三种颜色，红色、黄色或绿色，它们描述了软件的质量水平。
4）行为驱动开发（Behavior Driven Development ，BDD）在这种方法中，测试是基于系统应该如何工作来进行的。业务分析人员和测试人员在开发过程之前进行交流，以了解和理解彼此的利害关系，并据此设计软件。
测试场景以Gherkin给定的/When/Then语法的格式编写。场景文档有助于构建在初始阶段可能失败的测试，以便进一步构建使这些场景通过的软件功能。
5）验收测试驱动开发（Acceptance Test-Driven Development，ATDD）
这些测试基于客户对软件如何工作的观点。因此，这些验收测试展示了用户的概念，因此它确保了软件按照创建它的需求工作。
敏捷测试与普通测试的区别
1）项目进行中相当于开发与测试并行，项目整体时间较快。
2）新开发功能提交较快，测试时较有压迫感，感到测试时间不足。
3）工作任务划分清晰，工作效率较高。
4）项目规划要合理，不然测试时会出现复测的现象，加大工作量。
5）发现问题需跟紧，项目中人员都比较忙，问题很容易被遗忘。
6）耗时、或较难解决对项目影响不大的问题一般会遗留到下个迭代（Sprint）解决。
7）发现Defect能够很快的解决，对相关的功能特性的测试影响比较小。
8）版本发布比较快，影响到测试的速度。
9）测试者与开发者，甚至运营和Infrastructure团队沟通明显增多。
10）当发生版本更新时，或者变更时，需要及时更新/维护测试用例或者测试脚本（Automated testing scripts）。
11）测试人员几乎要参加整个项目组的所有会议。
转载地址：http://dtvdi.baihongyu.com/