敏捷开发检验示范V0.docx

敏捷开发检验示范V0.docx

《敏捷开发检验示范V0.docx》由会员分享，可在线阅读，更多相关《敏捷开发检验示范V0.docx（13页珍藏版）》请在冰豆网上搜索。

敏捷开发检验示范V0

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

2012年9月

版本记录

版本号

日期

修改人

描述

V0.1

2012/9

周本文

V0.1

1概述

1.1编写目的

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

本规范适用于采用敏捷开发模式下的所有自主开发移动互联网产品。

1.2读者对象

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

1.3术语定义

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

术语

中文

说明

ProductOwner（PO）

产品所有者

相当于项目经理、产品经理、产品负责人。

产品用户故事编写负责人。

ScrumMaster（SM）

敏捷开发组织者

组织项目敏捷开发，负责协调、沟通、协助解决团队内部非技术问题。

ProductBacklog

产品需求

产品待开发的功能项（用户需求）

SprintBacklog

迭代需求

每个迭代需实现的功能项（产品需求细化）

Userstory

用户故事

从用户角度提出的需求

Burndownchart

燃尽图

产品需求、迭代需求完成的进度显示图

PlanMeeting

计划会

迭代计划会，组织讨论下个迭代开发内容，PO需参加讲解产品需求。

StandupMeeting

每日立会

每日立会，早上时间，主要讨论每人当天工作内容。

ReviewMeeting

迭代评审会

每个迭代结束时召开，展示迭代成果，听取PO意见、建议。

表1-1

2敏捷测试流程

2.1验证需求和设计

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

需求和设计具体来说一般包括：

（1）由项目经理根据需求文本而编写的产品用户故事或者是产品软件需求规格说明书；

（2）由开发人员根据产品用户故事而编写的迭代用户故事，或者是详细设计、数据库设计、系统方案设计、概要设计（可裁剪，根据开发系统规模决定是否裁剪。

）。

作为测试人员，审核重点是检查产品用户故事、迭代用户故事对用户需求定义的完整性、严密性和功能设计的可测性。

在测试初期，测试人员要学会做静态测试，做好需求分析，做好对设计逻辑的分析。

测试人员要更多的思考需求的可实现性，将自身作为第一用户积极参与项目和系统的需求分析，设计和开发。

更多的参与DBDesign（数据库设计），框架的评审中来。

积极地参与前期工作，尽早的开始测试，并迅速反馈给设计和开发其静态测试结果。

需求和设计验证产出物:

测试需要提交评审结果。

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）版本发布说明

版本每次发布必须提供发布说明（ReleaseNote）使客户对发布的版本情况一目了然。

ReleaseNote中主要包括三方面的内容：

Fixed，NewFeatures，KnownProblems。

其中，Fixed部分写明此版本修复了上个版本中存在的的哪些比较大的bug；NewFeatures部分写明此版本新增加了哪些功能；KnownProblems部分写明此版本尚存在哪些比较大的问题，有待下个版本改善；或者列出需求不太明确的地方，有待客户给出明确答复意见，在下个版本中完成。

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性能测试方法

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

负载测试是在一定的硬件、软件及网络环境下，通过模拟不同的用户，执行一种或多种业务，观察系统在不同负载下的性能表现。

在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。

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

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

强度测试是性能测试一种，实施和执行此类测试的目的是找出因资源不足或资源急用而导致的错误。

如内存或磁盘空间不足，测试对象就可能会表现出一些在正常条件下并不明显的缺陷。

而其他缺陷则可能由于争用共享资源（如数据库或网络带宽）而造成的。

强度测试还可用于确定测试对象能够处理的最大工作量。

稳定性测试评价系统在一定负荷情况下，长时间的运行情况。

在一定的软硬件及网络环境中，通过模拟大量的用户执