敏捷测试流程 Scrum敏捷测试
什么是敏捷测试 敏捷测试的定义
首先敏捷测试是敏捷一种测试，原有测试定义中通过执行被测系统发现问题，通过测试这种活动能够提供对被测系统提供度量等概念还是适用的。在传统的测试定义上，还需要添加
敏捷测试是遵循敏捷宣言的一种测试实践:
l 强调从客户的角度，即使用系统的用户的角度，来测试系统
l 重点关注持续迭代的测试新开发的功能，而不再强调传统测试过程中严格的测试阶段。
l 建议尽早开始测试，一旦系统某个层面可测，比如提供了模块功能，就要开始模块层面的单元测试，同时随着测试
1
深入，持续进行回归测试保证之前测试过内容的正确性。 什么是Scrum,
Scrum是一个敏捷开发框架，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是2到4周。在Scrum中，使用产品Backlog来管理产品的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，我们称它
为Sprint backlog。在每个迭代结束时，Scrum团队将递交潜在可交付的产品增量。 Scrum起源于软件开发项目，但它适用于任何复杂的、创新性的项目。
Scrum由三个角色、六个时间箱和四个工件组成: 三个角色
1. 产品负责人(Product Owner) 2. Scrum Master 3. Scrum团队 六个时间箱 2 1. Sprint
2. 发布计划会议(Release Planning Meeting)可选 3. Sprint计划会议(Sprint Planning Meeting) 4. 每日站会(Daily Scrum Meeting)
5. Sprint评审会议(Sprint Review Meeting) 6. Sprint回顾会议(Sprint Retrospective Meeting)
四个工件
1. 产品Backlog(Product Backlog)
2. 发布燃尽图(Release Burndown Chart)可选 3. SprintBacklog
4. Sprint燃尽图(Sprint Burndown Chart)
Scrum最早由Jeff Sutherland在1993年提出，Ken Schwaber 在1995年OOPSLA会议上形式化了Scrum开发过程，并向业界公布。目前Scrum是应用最为广泛的敏捷方法之一
SCRUM理论基础
Scrum是以经验过程控制理论作为理论基础，通过迭代、增量的方法来增强产品开发的可预见性，并控制风险。Scrum经验过程控制理论的实施由三大支柱支撑: 第一:透明性(Transparency)
透明度是指，在软件开发过程的各个环节保持高度的可见性，影响交付成果的各个方面对于参与交付的所有人、管理
3
生产结果的人保持透明。管理生产成果的人不仅要能够看到过程的这些方面，而且必须理解他们看到的内容。也就是说，当某个人在检验一个过程，并确信某一个任务已经完成时，这个完成必须等同于他们对完成的定义。 第二:检验(Inspection)
开发过程中的各方面必须做到足够频繁地检验，确保能够及时发现过程中的重大偏差。在确定检验频率时，需要考虑到检验会引起所有过程发生变化。当规定的检验频率超出了过程检验所能容许的程度，那么就会出现问题。幸运的是，软件开发并不会出现这种情况。另一个因素就是检验工作成果人员的技能水平和积极性。
第三:适应(Adaptation)
如果检验人员检验的时候发现过程中的一个或多个方面不满足验收标准，并且最终产品是不合格的，那么便需要对过程或是材料进行调整。调整工作必须尽快实施，以减少进一步的偏差。
Scrum中通过三个活动进行检验和适应:
每日例会检验Sprint目标的进展，做出调整，从而优化次日的工作价值; Sprint评审和计划会议检验发布目标的进展，做出调整， 4
从而优化下一个Sprint的工作价值;
Sprint回顾会议是用来回顾已经完成的Sprint，并且确定做出什么样的改善可以使接下来的Sprint更加高效、更加令人满意，并且工作更快乐。
Scrum三个角色及其职责介绍
每个Scrum团队包括3个角色: 产品负责人(Product Owner), ScrumMaster和 Scrum 团队。
产品负责人 产品负责人的职责:
? 确定产品的功能，负责维护产品Backlog。 ? 决定产品的发布日期和发布内容。 ? 为产品的投资回报率(ROI)负责。 ? 根据市场价值确定功能优先级。
? 在每个Sprint开始前调整功能和调整功能优先级。 ? 在Sprint结束时接受或拒绝接受开发团队的工作成果。
产品负责人是一个人，而不是一个委员会。可能会有一些委员会向产品负责人提出建议或影响他的决策，但要想改变某条目的优先级必须先说服产品负责人。实施Scrum的企业可能发现这样会影响他们制定优先级和需求的方法。
5
为保证产品负责人的工作取得成功，企业中的所有人员都必须尊重他的决定。任何人都不得要求团队按照另一套优先级开展工作，团队也不允许听从任何人带有威胁恐吓性的指令。产品负责人所作的决定需要通过产品Backlog内容和优先级使其可视化。这种可视化要求产品负责人全力以赴，同时也使其成为一个费心费力但又值得去做的角色。
ScrumMaster
ScrumMaster 作为Team Leader和Product owner紧密地工作在一起，他可以及时地为团队成员提供帮助。他必须:
保证团队资源完全可被利用并且全部是高产出的。 保证各个角色及职责的良好协作。
解决团队开发中的障碍。
做为团队和外部的接口，屏蔽外界对团队成员的干扰。
保证开发过程按计划进行，组织每日站会、Sprint计划会议、Sprint评审会议和Sprint回顾会议。
ScrumMaster 除了主持每日站会(Daily Scrum Meeting)之外，还有三个主要职责:
ScrumMaster 需要知道什么任务已经完成，哪些任务已经开始，哪些新的任务已发现，和哪些估算可能已经发生变化。ScrumMaster 需要根据以上的情况更新反映每天完成的工
6
作量以及还有多少没有完成的燃尽图(Burndown Chart)。
ScrumMaster 还必须仔细考虑同时在进行开发的任务数，同时进行的工作需要做到最小化，
以实现精益生产率的收益。
该ScrumMaster 需要找出阻碍团队的障碍和依赖。他们需要的优先次序和跟踪。根据优先级指定计划解决这些障碍。其中有些问题可以在团队内部解决，有些则要团队之间的协调，还有的要管理层的介入来解决，甚至有些是公司的问题阻碍了团队达到他们的生产力。比如:一个电信公司最近实施了Scrum，但后来发现只有两个问题和Scrum Team有关，其他的全是公司的问题需要管理层关注。
最后但并非最不重要， ScrumMaster 可能会注意到，个人问题或冲突在Scrum里是需要解决的。这些都需要被澄清，或通过内部的沟通解决，或向管理层和HR
寻求帮助解决。ScrumMaster 必须注意去确保团队资源完全可被利用并且全部是高产出的。
Scrum 团队
Scrum团队的职责是在每个Sprint中将产品Backlog中的条目转化成为潜在可交付的功能增量。
7
Scrum团队的一些特点:
1. Scrum团队的规模控制在5-9个人。
如果成员少于5人，那么相互交流就减少了，团队的生产力也会下降。更重要的是，团队在Sprint中可能会受到技能，从而导致无法交付可发布的产品模块。如果成员多于9人，那么成员之间就需要太多的协调沟通工作。大型团队会产生太多复杂性，不便于经验过程控制。对于大型项目来说，可以采用多个小的Scrum团队，通过Scrum of Scrums
解决团队间的沟通协调问题。 2. Scrum团队是跨职能的团队。
团队成员必须具备交付产品增量所需要的各种技能。团队成员常常具备如编程、质量控制、业务分析、架构、用户界面设计或数据库设计等的专业技能。在Scrum团队中没有头衔的概念，每个人都必须尽心尽力完成Sprint目标。团队中不允许包括测试或业务分析等在特定领域工作的子团队。
3. Scrum团队是自组织的。
任何人，包括ScrumMaster都没有权利规定团队如何将产品Backlog转化成可交付的功能增量，而是由团队自己确定。每个团队成员利用自己的专业技能，解决遇到的问题。这种协同配合提高了团队整体效率。
8
团队的构成在Sprint结束时可能会发生变化，每次团队成员的变化，都会降低通过自组织而获取的生产力。因此，改变团队构成时务必要谨慎。
敏捷测试的挑战
参考:Bret Pettichord 的《Agile Testing - What is it? Can it work?》和《Agile Testing Challenges》 我们从上下文驱动测试的七大原则
(www.context-driven-testing.com)可以看出，上下文驱动测试倾向于快速的反馈和适应变化的环境。所以上下文驱动测试的很多原则和做法可以应用到敏捷开发的软件测试中来。
什么是敏捷开发,
敏捷开发是递增式的、迭代的、不断调整的开发模式。我们逐渐地建立起软件系统，能看到系统在成长，能展示进度。通过多次发布或项目的阶段检查点，每一次都比上一次靠近目标。 西、反馈以及商业机会而调整。
在敏捷开发中，工作被分解成“故事”，也叫特性或用例， 9
组合成任务分派给不同的程序员。定义好接受标准，开发直到单元测试和接受测试通过才算完成。
敏捷开发讲求合作，结对进行编程，避免个人拥有专门的知识，代码属于项目组共有。
在敏捷开发中不存在回退，讲究持续地集成，单元测试(通常使用测试驱动的开发方式)，持续地进行回归测试。
为什么以前的开发模式不再适用,
以前的开发模式要求有详细的测试计划，但是缺乏足够的时间来写，而且测试计划受很多因素的影响经常改变。
以前的开发过程会专门留出一个阶段来测试，但是你不能定义进入和退出的标准，测试阶段会随之而过。
以前的开发模式强调变更控制，但是现在的软件需求变更非常频繁，变更成了家常便饭。
以前的开发模式要求测试要对软件做出权威的判断，但是测试很难做出权威的关于软件正确性的判断。
10
百度搜索“就爱阅读”,专业资料、生活学习,尽在就爱阅读网 92to.com,您的在线图书馆! 11
