1、敏捷测试流程和传统测试流程

　　软件测试是贯穿整个软件开发生命周期、对软件产品（包括阶段性产品）进行验证和确认的活动过程，也是对软件产品质量持续的评估过程，其目的是尽快尽早地发现在软件产品（包括阶段性产品）中所存在的各种问题，尽最大可能地消除软件开发过程中所存在的产品质量风险。

　　传统的软件测试：制定周详的测试计划，测试计划又可能分为单元测试计划、集成测试计划、系统测试计划，甚至验收测试计划，没有评审的测试计划，将无法开展有效的测试互动。瀑布模型的研发流程都是线性方式进行。传统的软件开发模型->瀑布开发模型如下 ：

软件测试和软件生命周期的关系如下：

比如：某个软件系统拥有20个功能，传统的瀑布模型，需先将20个功能对应的需求规格说明书编写完成，评审通过后，进行20个功能模块的概要设计与详细设计，设计评审通过后，进行20个功能的编码，20个功能的编码完成后，再组织测试团队进行20个功能的测试，通过后发布上线。

　　敏捷测试：为了顺应敏捷开发流程而提出的一种测试实践。强调团队成员间的交互，注重跟随需求不断调整的速度。

敏捷开发流程：

　　敏捷开发有几个关键的概念：迭代故事、用户故事、任务、站立会议、持续集成、最简方案、重构。

比如：Scrum则不同，20个功能，根据用户期望软件实现的商业价值，列出20个功能的优先级，根据优先级分解产品需求列表，比如先做优先级最高的5个功能，分析需求、设计、开发、测试，交付可运行的版本，再开发5个功能，依次迭代，每个迭代过程结束后均能交付增量功能，最终完成产品开发。

敏捷测试流程：

• 分析测试对象：根据待办事项列表、用户故事、需求大纲等资料，总体掌握被测对象情况。
• 分析测试需求：将用户故事或需求大纲作为测试步骤进行测试。
• 设计测试用例：可采用等价类、边界值、正交试验、状态迁移等设计方法进行。（需评审）
• 搭建测试环境：根据研发环境模拟搭建测试环境。
• 执行测试用例：首先对待测功能模块实施冒烟，再次开展测试活动。如遇不完整，及时更新测试用例。
• 跟踪处理缺陷：使用缺陷管理工具进行缺陷处理。一般进行3次甚至更多的迭代过程，多次回归，在规定时间内达到sprint结束可发布或交付的标准。
• 输入测试报告：以数据为依据，衡量被测对象的质量状况，并提交测试结果报告给项目经理或产品经理。一般功能测试报告：被测对象的缺陷数量、缺陷状态统计、缺陷分布、是否通过测试等信息。
• 实施自动化测试：对需求稳定、测试周期长、存在大量重复操作的业务实施自动化测试。
• 实施性能测试：与功能测试一样的流程。  　　　　

2、敏捷测试与传统测试的区别及注意事项

敏捷测试工作注意事项：

• 明确验收要求：在产品需求明确、细化为项目时，应明确每个用户故事的验收要求。
• 跟踪处理缺陷：化整为零、尽早接入，根据测试需求，可开展单元测试、接口测试。（具备代码阅读、检测能力）
• 及时沟通反馈：加强沟通，及时反馈。

敏捷测试与传统测试的区分：

3、敏捷开发

　　敏捷开发的精华：短、频、快。

　　敏捷开发：通俗的讲，化整为零，逐个击破，循序迭代的过程中，保证软件系统始终处于可用状态。

• 以用户需求进化为核心，采用迭代、循序渐进的方法进行软件开发；
• 弱化文档，关注用户核心价值；
• 简化流程，关注目标结果。

　　敏捷开发提倡尽早交付与持续增量提供价值的理念，主导拥抱变化，个性与交互胜过过程与工具，不再受限于条条框框，以结果为导向，持续改进，持续优化。

　　敏捷开发是一种思想，scrum模型是采用较多的敏捷开发模型，禅道遵循的就是scrum。

4、Scrum开发模型

（2）Sprint Backlog（阶段性任务划分和安排），这时候需要明确具体要实现的功能特性和任务，作为测试，这时候要特别关注“Definition of Done”，即每项任务结束的要求—— 即任务完成的验收标准，特别是功能特性的设计和代码实现的验收标准。ATDD（使用验 收测试驱动开发）的关键一步也体现在这里，在设计、写代码之前，就要将验收标准确定 下来。一方面符合测试驱动开发思想，最初就要把事情做对，预防缺陷；另一方面持续测 试和验收测试的依据也清楚了，可以快速做出测试通过与否的判断。

（3）在每个迭代（Sprint）实施阶段，主要完成 Sprint Backlog 所定义的任务，这时除 了测试驱动开发（TDD）或单元测试之外，应该进行持续集成测试或通常所说的 BVT（Build Verification Test）。而且开发人员在设计、写代码时都会认真考虑每一组件或每一代码块 都具有可测试性，因为测试任务可能由他们自己来完成。如果有专职的测试人员角色，一 方面可以完善单元测试、集成测试框架，协助开发人员进行单元测试；另一方面可以按照 针对新实现的功能特性进行更多的探索式测试，同时开发验收测试的脚本。如果没有专职的测试人员角色，这些事情也是要完成的，只是由整个团队共同完成。虽没有工种的分工，但也存在任务的分工。

（4）验收测试可以由自动化测试工具完成，但一般情况下，不可能做到百分之百的自动化测试。例如易用性测试就很难由工具完成。即使对性能测试，是由工具完成，但还需要人来设计测试场景，包括关键业务选择、负载模式等。敏捷的验收测试和传统的验收测试不同，侧重对“Definition of Done”的验证，但基本的思想和传统开发是一致的，任何 没有经过验证的产品特性是不能直接发布出去的。

4.1 Scrum角色

Scrum开发流程主要涉及3个角色：产品负责人、开发团队和Scrum Master.

4.1.1 产品负责人

　　产品负责人，一般是产品经理，负责市场调研、分解用户需求，实现用户价值。scrum流程中，产品负责人是管理产品待办事项列表的唯一负责人，其根据用户需求、市场需求规划产品，输入并管理产品待办事项列表。产品待办事项列表管理主要包括以下几点：

　　1）以用户视角，清晰表述产品待办事项列表条目，细化每个条目所体现的用户价值。

　　2）确定产品待办事项列表条目优先级，便于更有效地实现用户需求

　　3）确保产品待办事项列表对产品团队成员及其利益相关方透明、公开

　　4）确保开发团队对产品待办事项列表中的条目能够理解并理解一致。

4.1.2 开发团队

　　开发团队成员主要包括项目经理、架构设计、开发、UI设计和测试等专业人员，负责在每个sprint的结尾交付可发布、应用的产品增量，保证每个sprint迭代完成。

　　敏捷开发团队有以下几个特点：

　　1）团队决定谁做什么？

　　2）团队决定如何做，如何实现目标，即团队做技术决策

　　3）团队需要在确保目标的前提下制定团队内的行为准则

　　4）团队有义务保持过程的透明性

　　5）团队其实没有角色之分，只有工作内容的区别

　　6）团队监督和管理他们的过程和进度

一个结构合理的开发团队成员人数在6~9个人左右，包括产品经理及Scrum Master。

4.1.3 Scrum Master

　　Scrum Master负责确保Scrum模型被产品团队高效、一致理解并有效实施。Scrum Master服务于敏捷团队，根据不同的服务对象，其主要工作大致包括以下几个方面：

　　1）服务于产品经理

　　A.辅助产品经理提取、细化并优化产品待办事项列表

　　B.协助产品经理传达产品目标，清晰用户价值

　　C.帮助产品经理理解并实践敏捷，从而推动整个团队掌握敏捷流程

　　D.在管理者的明确授权下，按需推动Scrum活动，优化研发体系。

　　2）服务于开发团队

　　A.指导开发团队构建自组织和跨职能的团队

　　B.教导并领导开发团队迭代实现用户价值

　　C.解决敏捷过程中可能出现的问题，并保证流程是正确的

　　D.在管理层、产品经理的明确授权下，按需推动Scrum活动，优化开发模型

　　F.培训开发团队，推进Scrum实践　　

4.2 用户故事

　　用户故事，Scrum敏捷开发模型中将用户需求，表述成用户故事。用户故事从终端用户的角度描述用户期望实现的业务过程。用户故事主要包含3要素：角色(role)、（Activity）活动、得到什么商业价值(Business Value)。

　　角色：明确功能或业务流程的使用对象。如作为一个测试负责人，需统计测试团队每个成员每天发现了多少个新的缺陷；作为一个店主，需知道每天每种商品的销售情况等。

　　活动：表述角色期望实现的功能或业务流程，定义为具体的目标结果，如统计成员每天发现新缺陷的数量；统计某件商品当天的销售量。

　　商业价值：用户通过活动，希望得到什么的价值体现，如作为一个测试负责人，需统计测试团队每个成员每天发现了多少个新的缺陷，以便于我了解当前的版本质量。

4.3 Sprint

　　Scrum是一种持续迭代、增量式的产品开发方法，将产品实现分解成若干个Sprint迭代。一个Sprint是指一个1-4周工作周期的迭代开发项目。Sprint最终输出结果是可运行的、可用的、实现用户价值可发布的产品增量。新的sprint在上一个sprint完成发布之后立即启动迭代。

　　一般很多公司将sprint分解成3周，第一、第二周进行设计、开发，第三周进行测试、回归，同时制定第二个sprint内容，以此类推，不断迭代。

4.4 每日站立会

　　Scrum敏捷模型中，要求敏捷团队中进行每日站会。每日站立会，即敏捷开发团队所有成员，采用每天固定时间、固定地点、站立开会的形式，通常不超过15分钟。一旦预定时间达到，则停止会议，从而从时间上限制会议时间，从形式上见减少会议环节，尽量避免冗余的主题讨论、问题解决，甚至是争论。同时每日站立会应该根据任务分配来召开会议，即以任务驱动，而非角色驱动。敏捷开发模型更强调的是个体交互过程和工具，注重面对面的沟通。每日站立会常规的会议内容包括以下几点：

　　1）总结过去，发现问题，提出改进措施

　　2）了解现状，明确下一步目标

　　3）任务分配，确定当天工作计划

5、敏捷开发中主要的测试活动

6、敏捷开发中的测试人员素质和职责

1、敏捷开发过程中测试人员的素质

　　敏捷开发过程中测试人员在不同组织中定位不同：测试开发(Test Developer)、质量分析员(Quality Analyst)、软件质量工程师(Software Qulity Engineer)等。

• 具有质量检测和编写代码的能力–> 测试开发
• 具有防止缺陷 (Quality Assurance) 和质量控制 (Quality Control) 的能力–> 质量分析员
• 具有开发和执行测试程序的能力 -> 软件质量工程师

2、敏捷开发过程中测试人员的职责

• 定义质量 (Define Quality)：这应该是软件测试人员的基本职责。敏捷方法鼓励测试人员在 Sprint 计划的时候直接与客户交流，从自己的经验出发，共同为产品功能制定质量要求。
• 交流缺陷（Communication）：敏捷过程强调团队中的交流。开发人员经常会专注于重要而新奇的功能，测试人员应该抓住细节，寻找设计中的“missing door”；另外，开发人员使用单元测试来保证产品的基本质量，测试人员可以使用验收测试（Acceptance Test）来鉴定客户需求与实际成果之间的不一致性。
• 及时反馈 (Feedback): 敏捷过程强调简单而高效。测试人员需要及时反馈产品目前的质量问题。这样一来，团队才可以立刻着手解决。如果传统的流程是一周汇总一次状态的话，敏捷流程要求每天汇总质量问题。在我们的项目中，内部的测试报告会以网页的形式显示在内部站点上。每个团队成员能够随时获取。另外，我们的测试框架提供自助测试 (Self-assistant Test)：通过点击测试用例列表中的某个具体用例，开发人员不需要中断测试人员的工作就可以重现缺陷。