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

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

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

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

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

敏捷开发流程：

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

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

敏捷测试流程：

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

敏捷测试工作注意事项：

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

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

传统测试

敏捷测试

强调测试的独立性，将“开发人员”和“测试人员”角色分得比较清楚。

可以有专职的测试人员，也可以是全民测试，即在敏捷测试中，可以没有 “测试人员”角色，强调整个团队对测试负责。

具有阶段性，从需求评审、设计评审、单元测试到集成测试、系统测试等，从测试计划、测试设计再到测试执行、测试报告等

更强调持续测试、持续的质量反馈，阶段性比较模糊。

强调测试的计划性，认为没有良好的测试计划和不按计划执行，测试就难以控制和管理

更强调测试的速度和适应性，侧重计划的不断调整以适应需 求的变化。

试强调测试是由“验证”和“确认”两种活动构成的

始终以用户需求为中心，每时每刻不离开用户需求，将验证和确认统一起来。

试强调任何发现的缺陷要记录下来，以便进行缺陷根本原因分析，达到缺 陷预防的目的，并强调缺陷跟踪和处理的流程，区分测试人员和开发人员的各自不同的责任。

敏捷测试强调面对面的沟通、协作，强调团队的责任，不太关注对缺陷的记录与跟踪。

更关注缺陷，围绕缺陷开展一系列的活动，如缺陷跟踪、缺陷度量、缺 陷分析、缺陷报告质量检查等

更关注产品本身，关注可以交付的客户价值。 在快速交付的敏捷开发模式下，缺陷修复的成本很低。

鼓励自动化测试，但自动化测试的成功与否对测试没有致命的影响

敏捷测试的基础就是自动化测试，敏捷测试是具有良好的自动化测试框架支撑的快速测试。

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

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

• 以用户需求进化为核心，采用迭代、循序渐进的方法进行软件开发；

• 弱化文档，关注用户核心价值；

• 简化流程，关注目标结果。

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

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

（1）Product Backlog （需求定义阶段），在定义用户需求时测试要做什么？测试需要考虑客户的价值大小（优先级）、工作量基本估算之外，需要认真研究与产品相关的用户

的行为模式（如 Behavior Driven Development，BDD），产品的质量需求，哪些质量特性是我们需要考虑的？有哪些竞争产品？这些竞争产品有什么特点（优点、缺点等）？

（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）任务分配，确定当天工作计划

敏捷开发的主要活动

测试活动

用户故事设计

寻找隐藏的假设

发布计划

设计概要的验收测试用例

迭代 Sprint

估算验收测试时间

编码和单元测试

估算测试框架的搭建

重构

详细设计验收测试用例

集成

编写验收测试用例

执行验收测试

重构验收测试

Sprint 结束

执行验收测试

下一个 Sprint 开始

执行回归测试

发布

发布

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)：通过点击测试用例列表中的某个具体用例，开发人员不需要中断测试人员的工作就可以重现缺陷。