敏捷测试流程
来源：http://www.testclass.net/software_test/
敏捷测试的一个核心是迭代，在每个时间点上，所有项目人员都是有事可做的。
下面是我理解中的敏捷测试流程图：

第一阶段：
通过上面的流程图，对于一个月的需求分析，在敏捷中，可能三五天就确定下来。这个需求定得会很模糊，但整体框架确定。
产品对其中某一模块功能确认，开发人员开始对确认的功能编码，开发人员编码的过程中，测试进行功能分解，因为根据模糊的需求很难写出具体的用例，所以，只能尽量对功能进行分析得细些，标注需要验证的内容。
第二阶段：
开发完成后交给测试人员进行测试，开发人员继续开发新的功能。那么测试人员发现的问题怎么办呢？会从开发团队中抽出一个人员来用于解决测试发现的问题。但开发进度并没有因为测试而停止。
流程分析：
在这个流程中弱化了文档，强调了各个人员的沟通，通过这种迭代的方式，三个月的项目，可以能两个月和两个半月就会完成。
但这种流程并非完美，假如一个功能在需求分析阶段就是错误的，因为它是一个迭代渐进的过程。也只能一路错下去。
对测试问题的处理
上面的图更能清晰看出对问题的处理过程。
第一块面板中是开发人员未实现的功能，
第二块面板中是开发完成功能，测试人员对其进行测试，
发现不通过的就放回未开发的面板中，测试通过的将放到第三块面板中。 

敏捷测试流程
一．敏捷迭代概述
二．项目阶段
三．测试流程
四．迭代任务
五．测试过程
六．测试任务

一．敏捷迭代概述

二．项目阶段
1．立项与规划阶段

建立Product Backlog，确定整个项目的需求清单，同时完成需求、设计评审，并成立项目组，为后面迭代阶段做准备

2．迭代阶段

创建项目→需求评审→迭代计划（分配任务）→研发&测试阶段（每日例会）→验收产品→发布产品→演示会→项目总结
三．测试流程
1．立项与规划阶段

（1）需求评审，进行需求分析；

（2）参与UI评审，设计评审；

（3）熟悉并理解《概要设计说明书》；

（4）设计并输出《测试方案》；

2．迭代阶段

（1）根据需求评估工时；

（2）创建并分配测试任务；

（3）编写测试用例；

（4）用例评审；

（5）分配开发自测用例；

（6）执行测试用例；

（7）跟踪缺陷（监控bug）：发现bug，提bug单，验证bug，关闭bug；

（8）反馈测试进度；

（9）输出测试报告；

（10）项目经验总结；
四．迭代任务
（1）项目需求评审

（2）建立项目；

（3）启动项目；

（4）任务分解；

（5）任务录入禅道；

（6）执行任务
五．测试过程
（1）单元测试（功能测试）

（2）集成测试

（3）系统测试

（4）验收测试
六．测试任务
（1）项目启动前期准备工作

新项目需求的搜集；

确定项目目标和任务；

确定人力及其他相关资源；

确定项目时间节点；

确定项目周期，迭代周期；

确定项目需求及各项功能；

对任务需求进行优先级排序；

确定整个项目的各项活动；

确定项目依赖项，协调相关事务；

确定项目风险项；
（2）项目中

确认需求（需求评审）；

设计测试方案；

设计测试用例；

编辑测试用例；

功能测试；

系统测试ST1；

系统测试ST2；

放行测试；

（3）项目发布

公测报告；

测试报告；

（4）项目结束

项目总结；

缺陷BUG分析；

客户反馈问题处理；

常见问题解决方案；

（5）其他

对技术支持进行培训；

编辑相关文档：使用操作手册（详细） && 快速使用指南（图文并茂，可以做成ppt或word，对外部客户用）

安全认证：使用360和金山给程序进行安全检测；

千锋教育软件测试：敏捷测试流程
千锋教育的王晓军老师在对敏捷测试做出介绍的时候与现行的瀑布式测试流程做出过对比：
对于一个三个月的项目说，产品把需求分析完了给开发，然后产品就没事儿了；开发开发完成之后给测试，然后开发人员也不忙了。测试完成之后上线。那么在产品分析的阶段，开发和测试都是没事干的（这里只对单一项目）。开发阶段，产品和测试也基本没事儿。同样在测试阶段，产品与开发也是没什么事儿的。
这不是一个该有的测试态度！
　　敏捷测试的一个核心是迭代，在每个时间点上，所有项目人员都是有事可做的。
1、下面是敏捷测试流程图：
 
第一阶段：
　　通过上面的流程图，对于一个月的需求分析，在敏捷中，可能三五天就确定下来。这个需求定得会很模糊，但整体框架确定。产品对其中某一模块功能确认，开发人员开始对确认的功能编码，开发人员编码的过程中，测试进行功能分解，因为根据模糊的需求很难写出具体的用例，所以，只能尽量对功能进行分析得细些，标注需要验证的内容。
第二阶段：
　　开发完成后交给测试人员进行测试，开发人员继续开发新的功能。那么测试人员发现的问题怎么办呢？会从开发团队中抽出一个人员来用于解决测试发现的问题。但开发进度并没有因为测试而停止。 
流程分析：
　　在这个流程中弱化了文档，强调了各个人员的沟通，通过这种迭代的方式，三个月的项目，可以能两个月和两个半月就会完成。
但这种流程并非完美，加入一个功能在需求分析阶段就是错误的，因为它是一个迭代渐进的过程。也只能一路错下去。
2、对测试问题的处理
      需要说明的是，敏捷测试在国外很流程，在内容，雷声大雨点小，推行的人很多，真正有公司引入的不多。我们所在公司千差万别，测试流程也可能有很大的不同。希望大家不要被思想局限，所以，请努力冲破一个又一个的局限吧——这正是我们这一行业的魅力啊！
     王晓军老师，正是这样一位看中测试者态度的软件测试工程师。
王晓军老师，是百度联想企培负责人，具有10年以上年从业经验，硕士学位。曾任某上市集团测试部门主管，中航集团开发部技术主管，具备多年开发及测试工作经验。在性能测试、自动化测试及软件质量管理等方面的人才培养上具有较高的建树。
现在，王晓军老师已经为广大软件测试爱好者和入门从业者录制了全栈软件测试工程师教学视频，供大家学习。
 

 

与传统测试组织相比，敏捷开发团队不再细分小组，敏捷开发团队构建时即确定了测试工程师，因此，敏捷测试中不存在测试团队构建环节。

 

同时，因产品规划期间已经设定了具体的实现目标，大部分软件公司不再要求测试工程师编写测试计划与方案，或者编写的计划与方案相对简要，因此，敏捷测试流程中，通常只具有以下几个节点，如图1- 7所示。

 



图1- 7软件测试工作流程图

 



 

敏捷开发团队中的测试工程师，接受任务分配后，需熟悉被测需求，其获得待办事项列表、用户故事集、需求大纲等资料，通过阅读从总体上掌握被测对象情况，便于开展后续的需求分析、用例设计等工作。

 



 

测试工程师熟悉相关需求后，根据测试管理需要，可将用户故事、需求大纲以测试人员视角提取出来，便于后期的用例设计与执行。

 

因用户故事或需求大纲在某种程度上已经表述较为清晰，测试工程师可直接将用户故事或需求大纲作为测试步骤进行测试。

 

如果用户故事或需求大纲存在较多验证信息，则可根据测试用例设计的需要，细化测试需求，并利用需求管理工具进行，如本教程采用的禅道项目管理平台。

 

以ECShop登陆功能为例，用户故事表述如下：

 



 

注册用户输入正确的用户名和密码，可登陆系统，以便于他们进入系统执行其他操作。

 



 

注册用户输入错误的用户名或者错误的密码，系统拒绝登陆，并给出“用户名或密码错误”的提示，以保证系统的安全。

 

User Story1、User Story2两个案例表明了角色期望通过什么操作达到什么效果，获得什么价值，这样的用户故事较容易理解，如果开发团队不要求编写用例，测试工程师则可利用上述用户故事的表述直接进行验证，从而检测被测对象是否实现用户需求。

 

如果需要编写用例，则可将用户故事编写到禅道中，作为测试需求，便于后续的测试用例设计。通常情况，产品经理或产品需求开发工程师会编写用户故事，测试工程师只需引用即可。

 



 

如果敏捷开发团队要求设计测试用例，则测试需求分析提取完毕后，经过敏捷开发团队评审通过后，测试工程师开展测试用例设计活动。

 

测试用例设计可采用等价类、边界值、正交试验、状态迁移等常用的设计方法进行。

 

测试用例文档可使用Word、Excel等形式管理，也可使用ALM、禅道等工具进行管理。测试用例设计完成需经团队评审才可使用。

 



 

测试版本发布，开发工程师申请测试时，如需搭建测试环境，测试工程师应从开发工程师处提取测试版本，根据开发工程师提供的测试环境搭建单进行测试环境搭建。测试环境搭建需要测试工程师掌握与被测对象相关的硬件、软件知识。

 



 

测试环境搭建完成、测试版本发布后，测试工程师进行测试用例执行。根据前期设计并评审通过的测试用例，测试工程师先对待测功能模块实施冒烟测试。

 

冒烟测试通过后，开展正式的测试活动。执行测试用例过程中，如果发现有遗漏或者不完善的测试用例，应当及时更新。用例执行过程中如果发现了缺陷，则需按照缺陷管理规范提交缺陷。

 



 

常用缺陷管理工具有Bugzilla、ALM、禅道等。大多数公司都有自己的缺陷管理流程规范，开发团队成员需根据缺陷管理流程开展缺陷跟踪处理工作。

 

缺陷处理阶段，大多数情况下需进行3次甚至更多的迭代过程，多次进行回归测试，在规定时间内达到Sprint结束可发布或交付的标准。

 



 

测试完成后，如有需要，测试工程师将对被测对象做一个全面的总结，以数据为依据，衡量被测对象的质量状况，并提交测试结果报告给项目经理或产品经理，从而帮助项目经理、产品经理及其他利益相关方了解被测对象的质量情况，以决定下一步的工作计划。

 

功能测试报告主要包含被测对象的缺陷数量、缺陷状态统计、缺陷分布、是否通过测试等信息。

 

自动化测试、性能测试活动很多时候属于单独的测试环节，很多团队将手工功能测试、自动化及性能测试报告分开总结。

 



 

如有必要，开发团队可对需求稳定、测试周期长、存在大量重复操作的业务实现自动化测试。敏捷开发中，对自动化测试要求较高，并且大多数基于接口实施自动化测试。

 

自动化测试一般分为基于UI与接口两种类型。基于UI层面的自动化测试代表工具有UFT、Selenium、Appium等，接口方面则是Jmeter、Postman、SoapUI等。

 

自动化测试对测试工程师的技能要求较高，需掌握如JAVA、JavaScript、Python等编程语言。

 



 

一般在功能测试完成后，根据用户需求开展性能测试工作。与功能测试一样，性能测试实施之前，需要进行性能测试需求分析、指标提取、用例设计、脚本录制、优化等一系列设计过程，然后再进行场景执行、结果分析等。

 

目前行业内使用一些自动化工具进行性能测试是目前实施性能测试的主要手段，常用的性能测试工具有LoadRunner、Jmeter等。