敏捷测试

简介

敏捷测试是伴随着敏捷开发双双出现的，先说说敏捷开发的最大特点：积极响应客户需求，快速高质量的交付软件。
所以在一个敏捷的项目流程中，首先会将需求按照用户的需求程度分为多个迭代，而每个迭代都可视为小的版本周期。

敏捷测试的流程，主要专注于两方面：
一是新功能的测试：从需求评审开始，到最终上线，测试人员需持续关注迭代的新功能，针对新功能进行足够的测试，保证新功能验收。
二是原有功能的测试：这一点也是敏捷测试提高效率所在，一般这个过程会通过自动化的回归测试。

由于敏捷流程的迭代周期短，测试人员要做到尽早开始测试，这个过程包含前期需求评审，开发设计评审，以及测试用例评审；敏捷测试最重要的是能及时、持续的对软件的质量进行反馈。简单的说，敏捷测试就是持续的对软件问题产生及时反映，一个 bug 被隐藏的时间越长，修复这个 bug 的代价就越大。

一般来说，一个大的需求经过敏捷流程会被分解成如下：

敏捷测试什么时候介入？该做些什么？

1.story需求评审
要求全部人员参加，预先尽早发现遗漏的功能点和对其他模块的影响点，主要是需求人员讲解，其余人员头脑风暴，从各自对需求的理解提出问题。
此阶段的输出有：需求验收标准（有利于后期测试用例的测试点编写）
2.接口设计评审
参与开发人员的api评审，结合需求针对接口提出问题。
此阶段的输出有：api接口文档，文档对于接口自动化非常重要
3.用例评审
测试人员根据需求评审中的标准进行测试用例的设计和编写，交于相关人员主要是开发人员，进行用例评审，一般情况下会有各种遗漏和修改，甚至会发现更大的影响点，小编曾经碰到一个潜藏测试点，之后不得不重定测试计划[捂脸]；最后针对修改的再过一遍，最终上传到用例库，如禅道之类。
此阶段的输出：测试用例文档
4.分配用例
由于敏捷流程中倡导的是全民测试，一些基础功能用例，可以分配给开发人员等
5.执行用例
测试人员执行测试用例，并对发现的问题分P级提交bug，待开发修改后，根据影响点及时回归问题，最后关闭bug。
此阶段的输出：bug
6.分析问题
分析问题产生的原因，找出是流程中哪个环节遗漏，然后针对相关阶段进行补救，以防下次出错。比如测试用例设计遗漏，则下次用例评审中针对用例深挖；如果是老版本遗留问题，则针对bug进度规范修改；如果是修改引起的联动性问题，则从执行用例过程中，以及分析自动化回归没有覆盖等方面分析。
7.质量报告
针对上述分析，输出质量报告，从发现问题的多少，P级各占百分比，与上期对比，bug的严重性给出评价。对出现问题的原因进行分析，如何改良流程，避免再现，并提出合理化的意见。