敏捷开发测试要求规范V0.1

敏捷开发测试规（试行）

2012年9月

目录

1 概述 (3)

1.1 编写目的 (3)

1.2 读者对象 (3)

1.3 术语定义 (3)

2 敏捷测试流程 (3)

2.1 需求验证 (3)

2.2 用例设计 (3)

2.3 用例审核与维护 (3)

2.4 测试计划 (3)

2.5 测试实施运行 (4)

2.6 版本控制 (4)

2.7 需求变更 (5)

2.8 迭代末期“bug大扫除” (5)

3 敏捷测试方法与策略 (5)

3.1 持续测试、持续反馈 (5)

3.2 单元测试方法策略 (5)

3.3 功能测试方法策略 (5)

3.4 性能测试方法 (6)

3.5 系统测试策略 (6)

3.6 测试驱动研发 (7)

3.7 持续集成测试 (7)

4 终端移动互联网测试 (7)

4.1 用户体验测试 (7)

4.2 平台兼容性测试 (7)

4.3 不同网络环境下测试 (8)

4.4 多事务并发测试 (8)

4.5 安装、卸载测试 (8)

5 测试工具和环境 (8)

5.1 单元测试工具 (8)

5.2 功能回归测试工具 (8)

5.3 性能测试工具 (9)

5.4 持续集成测试环境 (9)

6 测试人员要求 (9)

6.1 人力需求 (9)

6.2 测试人员能力要求 (9)

7 附录 (11)

1 概述

1.1 编写目的

ICT自主开发产品拟采用敏捷开发模式，为规ICT支撑中心项目敏捷测试流程，明确敏捷开发模式下的术语定义，明确敏捷测试方法与策略，明确移动互联网测试特有的测试容，确定敏捷开发模式下用到的测试工具以及测试环境，以及初步确定敏捷测试人力需求计算方式与对人员能力要求，特制定本规。本规适用于采用敏捷开发模式下的所有自主开发移动互联网产品。

1.2 读者对象

本规读者对象为软件开发项目管理者、项目经理、测试经理、开发经理、开发组、测试组所有人员。

1.3 术语定义

敏捷开发模式下的几种重要角色、产品文档及过程会议术语如表1-1：

表1-1

2 敏捷测试流程

2.1 验证需求和设计

敏捷测试强调问题暴露越早越好。

需求和设计具体来说一般包括：（1）由项目经理根据需求文本而编写的产品用户故事或者是产品软件需求规格说明书；（2）由开发人员根据产品用户故事而编写的迭代用户故事，或者是详细设计、数据库设计、系统方案设计、概要设计（可裁剪，根据开发系统规模决定是否裁剪。）。作为测试人员，审核重点是检查产品用户故事、迭代用户故事对用户需求定义的完整性、严密性和功能设计的可测性。

在测试初期，测试人员要学会做静态测试，做好需求分析，做好对设计逻辑的分析。测试人员要更多的思考需求的可实现性，将自身作为第一用户积极参与项目和系统的需求分析，设计和开发。更多的参与DB Design（数据库设计），框架的评审中来。积极地参与前期工作，尽早的开始测试，并迅速反馈给设计和开发其静态测试结果。

需求和设计验证产出物:测试需要提交评审结果。

2.2 用例设计与审核

开发人员根据产品用户故事、迭代用户故事，设计测试用例，测试人员负责测试用例审核。

为保证测试用例的质量和可行性，确保测试工作的顺利进行，让开发人员、测试人员迅速地了解测试的重点并给出相应的意见和建议，用例设计人员在出输出测试用例的同时，应出一份用户故事与用例跟踪表（见附件：产品故事-燃尽图跟踪表），其中注明测试用例已覆盖了哪些用户故事，具体每个用户故事对应的测试用例编号，这样其他项目组成员对测试用例进行查看的时候，能够对测试用例的覆盖率一目了然，对覆盖率不足（如某个重点用户故事的测试用例覆盖不够）的地方能够及时给出意见。测试人员负责用例审核。

2.3 测试计划

敏捷测试的测试计划不需要复杂的计划文档，写出一页纸的测试计划，将测试要点（包括策略、特定方法、重点围等）列出来即可，模板见附件。

2.4 测试实施运行

敏捷开发模式中，测试与研发紧密结合在一起。测试主要有两种：单元测试和验证/接收测试。单元测试一般是由开发人员来完成的，接收测试是由客户代表来完成。

由于客户通常无法在现场，一般由测试人员做验证测试，最后由客户进行接收测试。在每个版本发布给客户之前必须由测试人员进行测试，发布版本之后由客户做接收测试，提出需要修改的地方。需要修改的地方将在下后面的迭代中完成。

·单元测试

在每日构件版本给测试前，开发首先要做单元测试，提前告知软件中的薄弱环节，帮助测试人员调整测试重点。

做单元测试的好处是可以提高版本质量，减轻测试的工作量，减少浅层次的bug的发生率，使测试人员能够将更多的精力投入到寻找深层次的bug上面。

·验证测试

测试人员的验证测试从总体上说就是将测试用例按计划付诸实施的过程，以及验证故障修复是否会引入新的故障。这一阶段的测试必须在周密的计划下进行。这种计划性首先体现在开发和测试的相互协调配合，根据产品的架构和功能模块的依赖关系，按照项目的总体计划共同推进。从测试的过程来看，测试执行的一开始可以是针对部分用户故事的，之后可以逐步扩展。接着开始采用迭代的过程完成测试任务，即将测试任务划分为多个周期，一开始可以做些关键的功能性/用户故事测试，可以对代码中的可复用部分（组件，构件）做完整的测试。接着的迭代周期可以做边缘化的功能测试和其他测试，最后的几个迭代应该用于完整的回归测试，和关键的性能和稳定性测试。

·每日构件版本测试

敏捷开发过程中除每个迭代中持续集成版本以外，还会有每日构件版本，每日构件版本测试用以验证前天修复的故障，以及测试故障修复是否会引入新的故障。

2.6 版本控制

敏捷开发强调快速开发，持续集成。版本包括每日构件版本、持续集成版本、验收测试版本三种类型。

1）版本号约定

每日构件版本号约定：PXXV0.0.0D0823 (D后面是日期)

持续集成测试版本号约定：PXXV0.1.0B01（从B01开始递增）

验收测试版本号约定：PXXV1.0.0B01（从B01开始递增）

说明：PXX为项目名，V0.0.0为每日构件版本，V0.1.0为集成阶段，V1.0.0为系统测试阶段。

2）版本发布规则

每日构件版本。每日发布每日构件版本，用于验证当天解决的故障，验证故障修改是否会引入新的故障。

持续集成测试版本。每个迭代周期发布一个持续集成测试版本，如迭代周期为二周的，每个迭代周期可发布二个版本，由项目经理、测试经理协商决定。

验收测试版本。项目开发后期迭代发布验收测试版本，每个迭代发布一个验收测试版本（项目经理和测试经理协商决定）。

3）版本发布说明

版本每次发布必须提供发布说明（Release Note）使客户对发布的版本情况一目了然。Release Note中主要包括三方面的容：Fixed，New Features，Known Problems。其中，Fixed 部分写明此版本修复了上个版本中存在的的哪些比较大的bug；New Features部分写明此版本新增加了哪些功能；Known Problems部分写明此版本尚存在哪些比较大的问题，有待下个版本改善；或者列出需求不太明确的地方，有待客户给出明确答复意见，在下个版本中完成。

2.7 需求变更

采用敏捷开发模式的项目中，客户对于需求的变更很频繁。因此，需求管理是十分必要和重要的工作。整个项目进行过程中，对不断变化的需求，一定要作跟踪，每次的需求变更都要有相应的历史记录，方便后期的管理和维护工作。可将每次的变更整理记录到产品故事-燃尽图跟踪表（见附件），并使该文档始终保持最新更新的状态，与需求的变化保持同步。同时更新项目管理系统上面的产品用户故事与测试用例。

2.8 迭代末期“bug大扫除”

在项目开发的迭代末期，可以开展“bug大扫除”活动。划出一个专门的时间段，在这期间所有参与项目的人员，集中全部精力，搜寻项目的Bug。

注意以下要点：（1）尽管这是一个测试活动，但参与者并不仅限于测试人员。项目经理，