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

敏捷开发测试规范（试行）

2012年9月

版本记录

目录

1 概述 (4)

1.1 编写目的 (4)

1.2 读者对象 (4)

1.3 术语定义 (5)

2 敏捷测试流程 (5)

2.1 需求验证 (6)

2.2 用例设计 (6)

2.3 用例审核与维护 ................................................................................... 错误!未定义书签。

2.5 测试实施运行 (7)

2.6 版本控制 (8)

2.7 需求变更 (9)

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

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

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

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

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

3.4 性能测试方法 (12)

3.5 系统测试策略 (12)

3.6 测试驱动研发 (13)

3.7 持续集成测试 (14)

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

4.1 用户体验测试 (15)

4.2 平台兼容性测试 (16)

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

4.4 多事务并发测试 (17)

4.5 安装、卸载测试 (17)

5 测试工具和环境 (18)

5.1 单元测试工具 (18)

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

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

6 测试人员要求 (19)

6.1 人力需求 (19)

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

7 附录 (21)

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）尽管这是一个测试活动，但参与者并不仅限于测试人员。项目经理，开发人员甚至于高层管理人员都应参加，如同全民动员。目的是要集思广益；（2）要鼓励各部门，领域交叉搜索，因为新的思路和视角通常有助于发现更多的Bug；（3）为调

动积极性，增强趣味性，可以适当引入竞争机制，比如当活动结束时，评出发现Bug最多，发现最严重Bug的个人，给以物质和精神奖励。（4）可以分专题展开，比如安全性、用户界面可用性、国际化和本地化等等。

3 敏捷测试方法与策略

3.1 持续测试、持续反馈

敏捷测试是持续测试、持续反馈的过程，测试人员扮演“用户代表”角色，确保产品满足客户的需求。测试报表，测试日志都能及时得到反馈。

3.2 单元测试方法策略

单元测试是对功能模块进行正确检验的测试工作，也是后续测试的基础。目的是在于发现各模块内部可能存在的各种差错，因此需要从程序的内部结构出发设计测试用例，着重考虑以下五个方面：

1）模块接口：对所测模块的数据流进行测试。

2）局部数据结构：检查不正确或不一致的数据类型说明、使用尚未附值或尚未初始化的变量、错误的初始值或缺省值。

3）路径：虽然不可能做到穷举测试，但要设计测试用例查找由于不正确的计算（包括算法错、表达式符号表示不正确、运算精度不够等）、不正确的比较或不正常的控制流（包括不同数据类型量的相互比较、不适当地修改了循环变量、错误的或不可能的循环终止条件等）而导致的错误。

4）错误处理：检查模块有没有对预见错误的条件设计比较完善的错误处理功能，保证其逻辑上的正确性。

5）边界：注意设计数据流、控制流中刚好等于、大于或小于确定的比较值的用例。

单元测试除代码走查外，敏捷团队成员要能熟练单元测试工具开展单元测试，确保代码质量。

3.3 功能测试方法策略

功能测试的目标主要包括：

?是否有遗漏需求；

?是否正确的实现所有功能/用户故事；

?隐示需求在系统是否实现；

?输入、输出是否正确；

移动互联网应用的功能测试侧重于所有可直接追踪到用例（用户故事）、业务功能和业务规则的测试需求，这种测试的目标是核实数据的接受、处理和检索是否正确，以及业务规则的实施是否恰当。

功能测试基于黑盒技术，通过图形用户界面（GUI）与应用程序进行交互，并对交到的输出或结果进行分析，以此来核实实用程序及其内部进程正确与否。

敏捷模式下的功能测试方法策略：

已经实现功能的自动化测试。对前期迭代中已经实现的功能，采用工具进行自动化测试，即功能回归自动化测试。

新实现功能的手工测试。主要验证用户故事是否正确实现，与用例是否相符。

新实现功能的探索性测试。针对新实现的功能，除验证用户故事是否实现以外，还需要拓展测试内容。测试系统是否会有其他意想不到的异常或者缺陷。

探索性测试说明：探索性测试是一种测试风格，不是具体的某种测试技术，强调个人

自由与职责，将测试相关学习、测试设计、测试执行与结果分析三者相互支持和并行执行。

3.4 性能测试方法

性能测试一般包括负载测试、强度测试/压力测试、稳定性测试/可靠性。

负载测试是在一定的硬件、软件及网络环境下，通过模拟不同的用户，执行一种或多种业务，观察系统在不同负载下的性能表现。在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。

负载测试的目标是确定并确保系统在走出最大预期工作量的情况下仍能正常运行。

此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。

强度测试是性能测试一种，实施和执行此类测试的目的是找出因资源不足或资源急用而导致的错误。如内存或磁盘空间不足，测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源（如数据库或网络带宽）而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。

稳定性测试评价系统在一定负荷情况下，长时间的运行情况。在一定的软硬件及网络环境中，通过模拟大量的用户执行多种业务处理大量数据，使系统在极限环境下长时间运行，目的在于寻找系统的失效点。

性能测试一般在系统版本稳定后即可开展。移动互联网产品的性能测试，可借助以下测试工具：LoadRunner，Monkey工具。

3.5 系统测试策略

敏捷开发模式下的系统测试也就是迭代末期的“bug大扫除”，这种测试是由项目团

队内部开展，系统测试目的是在于验证软件的功能和性能及其他特性是否与用户的要求一致，主要包括类型的测试：

1）用户界面测试：测试用户界面是否具有导航性、美观性、行业或公司的规范性、是否满足设计中要求的执行功能。

2）性能测试：测试相应时间、事务处理效率和其他时间敏感的问题。

3）强度测试：测试资源（内存、硬盘）敏感的问题。

4）容量测试：测试大量数据对系统的影响。

5）容错测试：测试软件系统克服软件、硬件故障的能力。

6）安全性测试：测试软件系统对非法侵入的防范能力。

7）配置测试：测试在不同网络、服务器、工作站的不同软硬件配置条件下，软件系统的质量。

9) 安装测试：确保软件系统在所有可能情况下的安装效果和一旦安装之后必须保证

正确运行的质量。

3.6 测试驱动研发

测试驱动开发（英文全称Test-Driven Development，简称TDD），以用户故事为基准，包括产品用户故事与迭代用户故事，驱动研发逐步实现所有产品用户故事以及每个迭代中的用户故事。它要求在编写某个功能的代码之前先编写按照用户故障编写出测试用例，然后通过测试用例验证来推动整个开发的进行。测试驱动研发总体分为二大步：1．测试用例设计。开发、测试人员从设计文档、用户故事着手，参考客户需求看看用户故事是否已经覆盖客户的要求，对有疑问的地方与文档设计人员、PO沟通清楚。当搞清楚整个设计思路以及所有用户故事以后，再来进行测试用例设计。

测试用例设计由开发人员完成，测试人员审核。测试用例需共享给项目组其他成员，因为其他成员开发的时候需要参照到这些测试用例，避免出现未考虑到的地方。

2．测试用例执行。当某个用户故事开发完成后，测试人员开始测试，验证用户故事是否实现，是否满足用例预期结果。测试前或者测试中，测试人员及时与开发需随时进行讨论，讨论这个用户故事测试覆盖点。之前测试用例已经写完了，但是这个测试用例是基于原有设计用户故事的，实际的功能怎么样子，并不非常清楚。而现在实际功能做出来了，对于一个测试人员而言，就能得到基本的测试点。而讨论的目的就是尽可能全的把测试点覆盖全。开发根据讨论结果，更新测试用例，测试人员审核通过后作为后期测试验收用户故事的依据。

3.7 持续集成测试

持续集成测试是指开发团队中的每个成员都尽量频繁地把他们所做的工作更改合入到源码库中，并且还要验证新合入的变化没有造成任何破坏。这里的源码库指的是版本控制工具（比如：CVS或者SVN）管理的软件源代码储存地。这里的频繁程度和团队所开发的软件类型有关，但是一般来说频度应该不大于1个小时。

实现持续集成测试的几部分的工作：

1、将所有的源代码保存在单一的地点，让所有人都能从这里获取最新的源代码（以及以前的版本）；

2、支持自动化创建脚本，使创建过程完全自动化，让任何人都可以只输入一条命令就完成系统的创建；

3、测试完全自动化，要求开发人员提供自测试的代码，让任何人都可以只输入一条命令就运行一套完整的系统测试；

4、确保所有人都可以得到最新、最好的可执行文件。

持续集成测试最基本的优点就是：它完全避免了开发者们的"除虫会议"--以前开发者们经常需要开这样的会，因为某个人在工作的时候踩进了别人的领域、影响了别人的代码，而被影响的人还不知道发生了什么，于是bug就出现了。这种bug是最难查的，因为问题不是出在某一个人的领域里，而是出在两个人的交流上面。随着时间的推移，问题会逐渐恶化。通常，在集成阶段出现的bug早在几周甚至几个月之前就已经存在了。结果，开发者需要在集成阶段耗费大量的时间和精力来寻找这些bug的根源。

如果使用持续集成测试，这样的bug绝大多数都可以在引入的同一天就被发现。而且，由于一天之中发生变动的部分并不多，所以可以很快找到出错的位置。如果找不到bug究竟在哪里，你也可以不把这些错误的代码集成到产品中去。即使在最坏的情况下，你也只是不添加引起bug的特性而已。所以，持续集成可以减少集成阶段"捉虫"消耗的时间，从而最终提高生产力。

4 移动互联网终端测试

4.1 用户体验测试

移动互联网终端应用用户体验测试从视、听、触、反应速度、可用性、易用性几个方面出发，来测试终端应用的用户体验。

“视”是指应用界面UI布局是否合理、视效是否美观、颜色搭配是否协调、不同分辨率下是否可以正常运行。

“听”是针对具有音频播放功能的应用，应用使用的各种音频听起来感觉是否悦耳、使人舒畅，有没有杂音、电流音、刺耳的高音等。

“触”是指应用的使用触感，与终端屏幕、键盘有一定相关性。应用中的各种窗口控件、

对话框触击使用时触感是否使用愉悦。

“反应速度”是指终端应用使用过程中，点击某个功能按钮、菜单后，应用的反应速度有多快，是否满足用户使用习惯。通常一个操作反应时间超过2秒，用户便能够感知到慢。如果超过3秒，容易使用户感到不满。超过4秒，用户则不愿意接受。

“可用性”测试是指终端应用功能是否可用，有无缺陷。除基本功能实现以外，是否有其他明显影响使用的缺陷，是否满足正常操作习惯。

“用户体验易用性”测试主要是检测用户在理解和使用系统方面到底有多好，是否存在障碍或难以理解的部分。

用户体验易用性的测试方法，一般是通过用户访谈，或邀请内测、小范围公测等方式进行，通过不同实验组的运营结果来判断是否存在易用性缺陷。注意用户体验易用性测试由于缺乏有效的测试工具，必须大量的测试样本才能获得比较真实的测试数据，投入资源较多，测试周期较长。

4.2 平台兼容性测试

兼容性测试是核实测试对象在不同的软件系统、硬件配置中的运行情况，测试系统在各种软硬件配置，不同的参数配置下系统具有的功能、功耗、性能和用户体验。移动互联网终端应用的兼容性测试包含内容：

操作的兼容性：覆盖智能机三个主流操作系统，iOS, Android和Windows Mobile。

硬件兼容性：不同分辨率下的兼容性测试。

4.3 不同网络环境下测试

验证不同网络环境下，终端应用功能与性能方面是否正常(数据业务是否会中断，业

务模块是否出现异常)。网络环境包含：

3G强信号

3G中强信号

2G强信号

2G中强信号

4.4 多事务并发测试

移动互联网终端应用有自身的特殊性，终端上支持的应用很多，许多应用事务会并发产生（同一时间产生或者某一应用使用过程并发其他应用事务）。终端应用使用过程通常会有以下一些并发事务：

短信并发

彩信并发

来电并发

闹钟、日程并发

蓝牙事务并发

传感器事务并发

其他第三方应用事务并发（如天气预报）

4.5 安装、卸载测试

安装测试验证应用程序安装包/APK安装包能否成功安装到移动终端上，以及安装后能否正常打开使用。

卸载测试验证已经安装的应用程序/APK包是否能成功地卸载。

Android终端应用程序安装、卸载测试可借助MonkeyRunner工具来开展。

4.6 安全性、接口测试

安全性测试侧重于安全性的两个关键方面：

1．应用程序级别的安全性，包括对数据或业务功能的访问。

应用程序级别的安全性可确保：在预期的安全性情况下，不同权限用户只能访问特定的功能或用例，或者只能访问有限的数据。例如，可能会允许所有人输入数据，创建新账户，但只有管理员才能删除这些数据或账户。如果具有数据级别的安全性，测试就可确保“用户类型一”能够看到所有客户消息（包括财务数据），而“用户二”只能看见同一客户的统计数据。

2. 系统级别的安全性，包括对系统的登录或远程访问。

系统级别的安全性可确保只有具备系统访问权限的用户才能访问应用程序，而且只能通过相应的网关来访问。

接口测试指测试应用与终端本地其他应用的接口，主要测试接口功能是否实现，是否会引起本地其他应用异常。本地其他应用主要包括：音频模块，视频模块，蓝牙模块，联系人，短信，彩信，通话记录等。

5 测试工具和环境

5.1 单元测试工具

工具名称：Junit（java），Qunit(JSP)，Visual Unit(C/C++)。

适用测试类型：单元编码完成

输出物：单元测试报告

5.2 功能回归测试工具

工具名称：QTP，MonkeyRunner。

适用测试类型：稳定模块功能回归测试，适用每日构件版本，持续集成版本。

输出物：测试报告

5.3 性能测试工具

工具名称：LoadRunner，Monkey

适用测试类型：迭代持续集成版本（选择性执行），最终验收版本。

输出物：测试报告

5.4 持续集成测试环境

工具名称：CruiseControl，Eclipse，SVN，Junit （根据项目特点，可选择其他持续集成工具）

适用测试类型：每个迭代持续集成版本，每日构件版本，最终验收版本。

输出物：测试报告

6 测试人员要求

6.1 人力需求

根据ICT自主研发产品的特点及目前现状，采用敏捷开发模式，开发人员与测试人员总体按照1.5 ：1的比例，来配置测试人。配置比例计算如下：

一个典型的敏捷开发团队人员共7人：PO 1人，Scrum Master 1人，开发人员3

人，测试人员2人。其中测试开发人员1名，主要工作内容包括单元测试，负责单元测试及协助研发修改单元测试发现的故障，测试工具开发、测试用例设计以及测试环境搭建。工具使用、测试执行人员1名。

备注：采用敏捷开发模式，测试与研发是紧密结合的一个团队，无界限划分，测试与研发有时可以相互调换、替补。测试人员行政管理上面属于测试团队。

6.2 测试人员能力要求

敏捷测试对测试人员能力要求非常高。要有很强的编码功底，丰富的项目经验与编码经验，开发过程中既能帮助开发人员发现故障，又能协助开发人员修复故障，甚至替补开发人员修改故障。

1）测试开发人员能力要求

掌握常的用例设计方法，如等价类划分，边界值分析，错误推测法，场景设计方发等。

有2年以上的测试经验，2年以上用例设计经验。熟悉至少一种数据库基本操作。

有2年以上Java/C++/网页编码经验，测试工具开发经验，掌握一种以上单元测试工具，能熟练搭建持续集成测试环境。

2）执行人员能力要求

有1年以上Java开发经验，熟悉主流开发工具，2年以上测试经验，有用例设计经验。熟悉数据库基本操作。

熟练使用常用的功能回归、性能测试自动化工具，如QTP，LoadRunner，Monkey 等。

熟悉项目应用程序工作流程，有移动互联网产品测试经验。