敏捷开发(Scrum)与敏捷测试
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、敏捷开发中主要的测试活动
|
敏捷开发的主要活动 |
测试活动 |
|
用户故事设计 |
寻找隐藏的假设 |
|
发布计划 |
设计概要的验收测试用例 |
|
迭代 Sprint |
估算验收测试时间 |
|
编码和单元测试 |
估算测试框架的搭建 |
|
重构 |
详细设计验收测试用例 |
|
集成 |
编写验收测试用例 |
|
执行验收测试 |
重构验收测试 |
|
Sprint 结束 |
执行验收测试 |
|
下一个 Sprint 开始 |
执行回归测试 |
|
发布 |
发布 |
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)：通过点击测试用例列表中的某个具体用例，开发人员不需要中断测试人员的工作就可以重现缺陷。
