课程简介
近几年，Scrum、SAFe 等相关的敏捷转型活动在各大 IT 企业和组织中如火如荼得进行着。随着敏捷转型的深入，与敏捷开发相匹配的 QA 活动引起了业界的思考和探讨。
一般来说敏捷转型共分三步走，即：
- 第一步：玩熟敏捷管理；
- 第二步：保证敏捷自动化测试效果；
- 第三步：确保一体化管理和工具平台各就各位。
这样才能保证敏捷组织和团队的工作效率持续得到提升。
如何开展敏捷测试目前仍困扰着很多敏捷组织和团队，为此，特别推出本达人课，作者根据近7年来实际的敏捷转型实践和咨询经验，总结了敏捷测试的一套理论和实践方法，希望对敏捷测试感兴趣的同学在理论学习和工作时间中有所帮助。
通过本达人课，您将获得：
- 全面的测试管理和技能知识体系；
- 测试需求分解法；
- UI 自动化测试分析与代码编写技能；
- 接口测试分析与代码编写技能；
- 单元测试分析与代码编写基本技能；
- 行为驱动开发（BDD）的理论与运用；
- 一体套自动化测试框架源码。
作者介绍
杜铁绳，企业级敏捷顾问，敏捷管理平台和自动化测试研发经理。曾经担任首席测试业务架构师和外企高级测试经理。
课程内容
导读：敏捷测试的价值
敏捷项目管理如火如荼已流行了10多年，例如 Agile、Scrum 和 SAFe。无论是哪个理论最终都离不开技术落地，都要先后进行需求分析、软件设计、编码实现、单元测试、集成测试、验收测试。当然也会换换名字，例如需求分析换作用户故事拆分。原来大堆的设计和说明文档（依据 CMMI 等理论管理的所谓较正式的项目中大多这样）变得少些，但是编写代码、单元测试、集成测试、验收测试等等该做的还是要做，这些活动只是在时间先后、任务颗粒度大小方面进行了重组。那么敏捷项目和敏捷项目中的敏捷测试的意义和价值在哪里呢？在进入咱们的正式话题敏捷测试之端到端的自动化测试之前，先从整体上简单介绍一下为什么要敏捷测试，敏捷测试为谁服务？先知道“为谁辛苦，为谁甜”。
咱们先从企业的愿景说起，怎么要从企业愿景说起呢？要做一个好的测试人员特别是敏捷团队里面的测试人员不仅要懂测试技术、掌握编程技能，也要了解公司的业务。测试出的产品最终是给客户用的，这个客户有可能是外部客户，也有可能是内部客户。客户要使用我们测试人员测试的软件来做什么？客户为什么愿意使用我们的软件，客户为什么愿意为我们的软件付费呢？那就是我们的软件为客户提供价值，这个价值既可以是提高效率，也可以降低成本，也可以是增加收入等等。这就是精益理论的一个核心思想，是企业敏捷的一个重要思想。
互联网企业或者软件企业的传统的产品导入方式如图1所示。
初看上去，这个新产品导入模式似乎对企业研发新产品特有帮助，有利无害。它说明了怎么一步步把新产品交付到客户手中的。业务部门或企业创始人（小企业或初创企业产品概念一般由老板提出，大型企业才会有业务部门提出）形成企业商业模式概念，并根据该概念和愿景来构想所需要的产品。对于互联网企业或软件企业来说就是形成对一个网站或应用的想法。想法描述给研发人员或部门就开始规划产品，网站应用建设和软件应用开发是一个系统化的工程，经过需求收集、需求分析、概要设计、详细设计、开发编码、单元测试、集成测试、用户验收测试（请见图2）。对于企业级的应用工作量可不小，完成网站或应用建设时间跨度小的几个季度，大的若干年。我曾经历过一家大型国企的金融核心系统开发长达3年之久。如果您是这个产品的负责人，当您的产品经过这么长时间的开发首次准备上线交付给客户时，突然发现没有客户群体!产品特征不是用户想要的!竞争对手在您这么长的开发周期当中已经有2.0产品了又有了巨量的用户群!此时您的感觉如何？如何面对投资人？情何以堪!？
一筹莫展之后，给大家介绍一个理论和模式——愿景驱动开发（Vision Driven Development，简称 VDD），它以精益思想和敏捷理论进行客户开发、应用（Application）研发和部署运维。咱们要讲的敏捷测试就是愿景驱动开发的大开发环中应用研发环（这里应用可以是网站、软件、APP 等等）中的测试环。请见图3愿景驱动开发环。
由于本达人课的主体是敏捷测试，对于客户开发、敏捷开发和部署运维的 DevOps 不详细讲解，只简单介绍以免有的童鞋有点生疏。对这些话题感兴趣的童鞋可以关注后续推迟的相关课程。咱们争取把整个愿景开发知识体系和实践讲完。
客户开发
客户开发总共包括四个步骤，它们是客户探索、客户验证、客户生成和企业建设（对于已成立企业也可以是产品推广）。
第一步，客户探索。把创始人（产品负责人）的愿景转化为一系列商业模式假设，开发一套测试客户反应的方案。例如低保真最小可行产品（Low-fidelity），这需要研发、测试童鞋用尽量短的周期提交出演示或试用产品。
第二步，客户验证：将在客户探索阶段产生的最小可行产品演示给客户，或将使用结果进行总结和分析，看看创始人（产品负责人）提出的商业模式是否具备可重复性和可升级性。如果不可以就返回客户探索阶段重新开始。
第三步，客户生成：这个步骤负责建立最终的用户需求（搞明白用户需求），导入销售渠道，实现企业或产品的扩张。
第四步，企业建设。这个阶段标志着企业或产品的商业模式已经经过验证，可以按照探索出来的商业模式来建设企业或运营产品了。
敏捷研发
敏捷研发理论有很多，愿景驱动开发框架下推荐的是 Scrum 敏捷研发管理，Scrum 敏捷研发管理方式采用短期冲刺定期验收演示的方式快速形成最小可行产品。敏捷研发过程里面咱们测试的同学就要上阵了，要和开发同学一起把产品做得快又好，就要做好测试管理、测试规划设计、从单元测试、集成测试到 UI 端测试，尽量采用自动化提高测试效率。
持续部署
应用开发（网站/软件/APP）开发完成、测试完成就要进行部署，传统部署方式动辄几天，使用 DevOps 方式可以分分秒秒完成，这才是愿景驱动开发的方式，软件部署之前要想保障软件的质量，当然要测试完成，少了测试童鞋的工作，有几个大拿敢说自己编写的软件可以直接部署生成环境不被用户骂个狗血淋头呢？再次强调了敏捷测试不能少哇！
敏捷测试该怎么做？说起来很简单，做起来不易。例如玩玩 BDD（行为驱动开发），玩玩 TDD（测试驱动开发）。前提是测试质量如何保证？测试童鞋该拥有什么样的技术才能做起来？需求老师（产品经理）、研发童鞋、测试童鞋该如何一起玩才能 Happy 的完成工作？
本文先给出个思路，接下来的课程内容将一步一步带领各位童鞋玩下去，在正式开始学习之前，先带大家整体看下本课程的整体思路与内容结构。
导读：敏捷测试价值
本部分主要对敏捷项目的管理过程和相关理论进行介绍，让学习相关课程的同学对敏捷研发和测试的过程有整体了解。
第01课：管理篇——敏捷测试中的人、技术与过程管理
本部分主要对如何管理敏捷测试当中的要素：人、技术和过程进行介绍，让学习相关课程的同学理解并初步学会如何进行敏捷测试管理。
第02课：设计篇——敏捷项目中用户故事分析与验收条件设计
本部分主要对敏捷项目的需求分析技术进行讲解，让学习相关课程的同学学会如何对敏捷故事进行验收测试设计。
第03课：设计篇——验收测试设计及 UI 自动化测试
本部分主要对用户故事验收的自动化测试设计进行讲解，让学习相关课程的同学学会对用户故事进行自动化测试验收，保证用户故事的验收测试范围和测试质量。
第04课：设计篇——接口测试设计及自动化测试
本部分主要对接口测试设计技术进行讲解，让学习相关课程的同学学会以面向服务（SOA)的方法学会接口测试设计。
第05课：设计篇——单元测试设计及自动化测试 本部分主要对单元测试的覆盖和断言设计进行讲解，让学习相关课程的同学理解高质量单元测试的方法。
第06课：设计篇——持续集成中的自动化测试
本部分主要对敏捷测试与持续集成（CI)相结合的方法进行说明，让敏捷测试真正提高效率。
第07课：技术篇——使用 Junit 实现单元测试
本部分主要对如何利用 Java 技术实现单元测试进行讲解，将涉及目前流行单元测试工具介绍和使用。
第08课：技术篇——WebService 接口测试
本部分主要对接口测试的常用规范和协议以及常用的接口测试框架和工具（如 SOAP UI、HttpClient 和 Rest-Assrued）进行讲解，让学习相关课程的同学学会自动化接口测试。
第09课：技术篇——使用 Selenium 实现 UI 自动化测试
本部分主要对 UI 测试技术进行介绍，并举例说明如何利用 Selenium 实现自动化接口测试。
第10课：方法论篇——行为驱动开发
本部分主要对目前在敏捷测试领域比较流行的测试理论和方法进行介绍，让学习相关课程的同学既了解该理论的特点也能够在具体实践中运用。
第11课：附录——自动化测试源代码
本部分将提供本课程中的全部自动化测试框架代码，让学习本课程的同学可以立马动手实践，真正符合敏捷思想中的"Make your hands dirty"！
相信各位童鞋跟完本达人课都想跃跃欲试。如果有的童鞋所在公司或项目组没有玩敏捷开发和测试这个套路，也可以把学到的知识和技能用到传统的软件测试里面去。敏捷和传统不是水火不容，它们当中的很多技能是可以互通的，它们不是既生瑜何生亮哦。敏捷和瀑布只是指导思想和套路不一样，学会了《易筋经》《九阳神功》，无论什么套路都是绝顶高手！
下面开始咱们的套路：测试准备（做好管理规划），做好测试设计，设计用户验收测试、设计集成测试、设计单元测试，编写单元测试、编写集成测试、编写用户验收测试自动化代码，持续集成 & 部署玩起来就大功告成！
第01课：管理篇——敏捷测试中的人、技术与过程管理
清朝陈澹然在《寤言二·迁都建藩议》中说：“不谋万世者，不足谋一时；不谋全局者，不足谋一域。”对于我们测试来说，要做好测试，达成测试目标，也需要谋划谋划。首先需要了解我们的测试需求是什么？我们需要测试什么样的系统？这个系统对缺陷的容忍度是怎样的？测试过程需要使用什么样的技术？一个信息管理系统和一个银行账务系统对缺陷的敏感度是不一样的。我们有多少资源可以用于达成目标？例如我们有多少测试人员，有多少设备（手机、POS 机、金卡键盘、苹果电脑等等），有多少测试环境可用？我们有多少有效时间可以用于测试？我们测试需要有多少轮次？如何回归测试已发现缺陷？
我们先假设目前面对的是一个新项目或者说是一个新产品，为了增加带入感，也方便解说整个敏捷项目的敏捷测试工作如何进行，我们先从一个故事开始。我们用这个故事贯穿整个课程，让童鞋们跟着这一故事主线完完整整的体验一个完成的敏捷项目是如何完成测试工作从而成功交付的。
我们的主人公小明童鞋是一家电子商务公司的测试经理，主要工作是带领测试小组完成公司电子商务软件的测试工作。2018年2月22日刚过完春节上班的第一天，老板把销售、市场、需求、研发等部门的负责人和骨干童鞋都叫到了公司大会议室开会。老板说：“童鞋们，市场竞争越来越激烈，飞机票代订业务也越来越难做。董事会要求我们今年的营业额要比去年增加20%，成本要降低10%。今天召集大家开会的目的就是请市场部、销售部和研发的童鞋一起献计献策，群策群力完成今年的业务目标……（此处省略老板为鼓舞大家达成目标出口成章，意气风发的演讲1万字）”
销售部和市场部的童鞋分别提出了电子商务网站增加在线推广和售票的业务需求。为了达成以上目标经老板同意专门成立了“华山论剑项目组”。项目组包括2个 Scrum 团队，和1个系统验收团队。小明童鞋所在的 Scrum 团队为“战狼”队，负责服务端开发，其组织架构为产品负责人1名、敏捷教练1名、研发童鞋4名、测试童鞋2名。这是一个典型的 Scrum 敏捷团队。小明同学有幸参加了这个团队，并负责主导团队测试工作，如图1为敏捷研发团队成员组成。
项目需求（产品需求）确定后，测试的同学该做哪些事情呢？测试管理中贯穿整个测试过程的是人员、技术和过程管理。在测试准备时首选是对测试需求的了解，根据测试需求确定测试范围，规划测试过程，确定所需要的资源和培训需求。在我们这个故事中，小明童鞋是测试负责人，在测试准备阶段，项目开始前他应该做哪些事情呢？举例如下：
- 人员需求培训和学习。作为敏捷团队的一员，测试人员应该熟悉自己所测试的产品需求。如果不了解需求很难完成测试目标。
- 技术准备。敏捷项目应该尽可能使用工具和自动化测试提高测试效率。最基本的测试应该考虑接口自动化测试技术。因此小明童鞋应该评估是否需要相关的技术培训或安排自学。
- 环境与设备准备。准备测试所需的服务器（虚拟机、云服务），准备搭建测试所需的应用环境。如果需要其它设备，例如移动 App，测试童鞋应该考虑用于测试的不同型号手机是否具备。如果环境和设备不具备应该考虑申请相关设备和资源，或者提出采购等等。有时采购过程需要一些时间，因此为了不影响测试进度，应该提前申请采购。
- 测试过程规划。敏捷项目一般采用冲刺的方式完成开发任务。测试过程应该与冲刺规划保持一致。单元测试、接口测试等相关活动应适应整个敏捷项目的节奏，并给每个测试任务分配合适的工作时间。
我们应该根据软件开发的整个规划过程来规划测试过程。在小明童鞋的故事中，软件开发使用的是 Scrum 敏捷开发。我们先谈论团队级别的 Scrum 敏捷开发。如果需要再谈论企业级的 SAFe 敏捷开发。由于 SAFe 敏捷开发涉及到系统验收团队、架构团队等等需要专门的课程讲解。咱们这里先从团队级别开始介绍。由于小明童鞋是团队级别的测试负责人，由这个开始也比较合适。如图2为 Scrum 流程图。
产品列表梳理（Product Backlog）：产品负责人与敏捷团队一起梳理产品列表。作为测试团队成员应该从测试的角度考虑梳理出的产品列表是否可测试。应该如何描述才能方便测试验收。
冲刺规划(Sprint Planing)：产品负责人与敏捷团队一起安排冲刺的时间跨度和本轮的冲刺内容。测试人员根据项目（产品）冲刺规划安排自己的测试节奏和内容。
冲刺列表（Sprint Backlog)：产品负责人与敏捷团队一起确定本轮测试需要完成的用户故事，确定 DOD（Defined OF Done）条件。测试人员根据用户故事编写测试用例和自动化测试代码。在 BDD 中，这时就可以开始编写自动化测试代码了。
每日例会（Daily Scrum）：一般早上开始工作时进行每日例会。回顾昨天完成工作，规划当天工作内容和向小组通报遇到的问题。对于测试人员来说测试工作节奏应该和用户故事的粒度和开发工作的节奏相适应。例如开发人员4个小时完成开发工作，测试人员一般应在1-4个小时内完成测试工作，以便当天用户故事达到 DOD 状态方便交付。
冲刺评审（Sprint Review）：产品负责人与敏捷团队一起评审本轮冲刺的产品增量（Product Increment）是否满足用户故事的 DOD 条件，是否可以发布。测试人员一般在冲刺评审过程中作为演示人员向产品负责人和敏捷团队演示可发布的软件产品。
冲刺回顾（Sprint Retrospective）：敏捷团队回顾本轮冲刺的过程，总结经验教训。测试人员可以在这个阶段看看测试工作存在哪些问题，有哪些方面可以提高等等。
在测试管理方面，测试过程、人员、技术设备等确定后，接下来我们就可以根据梳理出的产品列表开始测试需求分析了。
第02课：设计篇——敏捷项目中用户故事分析与验收条件设计
第03课：设计篇——验收测试设计及 UI 自动化测试
第04课：设计篇——接口测试设计及自动化测试
第05课：设计篇——单元测试设计及自动化测试
第06课：设计篇——持续集成中的自动化测试
第07课：技术篇——使用 Junit 实现单元测试
第08课：技术篇——WebService 接口测试
第09课：技术篇——使用 Selenium 实现 UI 自动化测试
第10课：方法论篇——行为驱动开发
第11课：附录——自动化测试源代码
阅读全文: http://gitbook.cn/gitchat/column/5aebe3ea4eb5f845a0773ddb