《敏捷开发测试规范v0.1》由会员分享，可在线阅读，更多相关《敏捷开发测试规范v0.1（17页珍藏版）》请在金锄头文库上搜索。
1、敏捷开发测试规范（试行） 2012年9月版本记录版本号日期修改人描述V0.12012/9周本文V0.1目录1 概述31.1 编写目的31.2 读者对象31.3 术语定义32 敏捷测试流程32.1 需求验证32.2 用例设计32.3 用例审核与维护32.4 测试计划32.5 测试实施运行42.6 版本控制42.7 需求变更52.8 迭代末期“bug大扫除”53 敏捷测试方法与策略53.1 持续测试、持续反馈53.2 单元测试方法策略53.3 功能测试方法策略53.4 性能测试方法63.5 系统测试策略63.6 测试驱动研发73.7 持续集成测试74 终端移动互联网测试74.1 用户体验测试74.
2、2 平台兼容性测试74.3 不同网络环境下测试84.4 多事务并发测试84.5 安装、卸载测试85 测试工具和环境85.1 单元测试工具85.2 功能回归测试工具85.3 性能测试工具95.4 持续集成测试环境96 测试人员要求96.1 人力需求96.2 测试人员能力要求97 附录111 概述1.1 编写目的ICT自主开发产品拟采用敏捷开发模式，为规范ICT支撑中心项目敏捷测试流程，明确敏捷开发模式下的术语定义，明确敏捷测试方法与策略，明确移动互联网测试特有的测试内容，确定敏捷开发模式下用到的测试工具以及测试环境，以及初步确定敏捷测试人力需求计算方式与对人员能力要求，特制定本规范。本规范适用于
3、采用敏捷开发模式下的所有自主开发移动互联网产品。1.2 读者对象本规范读者对象为软件开发项目管理者、项目经理、测试经理、开发经理、开发组、测试组所有人员。1.3 术语定义敏捷开发模式下的几种重要角色、产品文档及过程会议术语如表1-1：术语中文说明 Product Owner（PO）产品所有者相当于项目经理、产品经理、产品负责人。产品用户故事编写负责人。Scrum Master （SM）敏捷开发组织者组织项目敏捷开发，负责协调、沟通、协助解决团队内部非技术问题。Product Backlog产品需求产品待开发的功能项（用户需求）Sprint Backlog迭代需求每个迭代需实现的功能项（产品需求
4、细化）User story用户故事从用户角度提出的需求Burndown chart燃尽图产品需求、迭代需求完成的进度显示图Plan Meeting计划会迭代计划会，组织讨论下个迭代开发内容，PO需参加讲解产品需求。Standup Meeting每日立会每日立会，早上时间，主要讨论每人当天工作内容。Review Meeting迭代评审会每个迭代结束时召开，展示迭代成果，听取PO意见、建议。表1-12 敏捷测试流程2.1 验证需求和设计敏捷测试强调问题暴露越早越好。需求和设计具体来说一般包括：（1）由项目经理根据需求文本而编写的产品用户故事或者是产品软件需求规格说明书；（2）由开发人员根据产品用户
5、故事而编写的迭代用户故事，或者是详细设计、数据库设计、系统方案设计、概要设计（可裁剪，根据开发系统规模决定是否裁剪。）。作为测试人员，审核重点是检查产品用户故事、迭代用户故事对用户需求定义的完整性、严密性和功能设计的可测性。在测试初期，测试人员要学会做静态测试，做好需求分析，做好对设计逻辑的分析。测试人员要更多的思考需求的可实现性，将自身作为第一用户积极参与项目和系统的需求分析，设计和开发。更多的参与DB Design（数据库设计），框架的评审中来。积极地参与前期工作，尽早的开始测试，并迅速反馈给设计和开发其静态测试结果。需求和设计验证产出物:测试需要提交评审结果。2.2 用例设计与审核 开发
6、人员根据产品用户故事、迭代用户故事，设计测试用例，测试人员负责测试用例审核。为保证测试用例的质量和可行性，确保测试工作的顺利进行，让开发人员、测试人员迅速地了解测试的重点并给出相应的意见和建议，用例设计人员在出输出测试用例的同时，应出一份用户故事与用例跟踪表（见附件：产品故事-燃尽图跟踪表），其中注明测试用例已覆盖了哪些用户故事，具体每个用户故事对应的测试用例编号，这样其他项目组成员对测试用例进行查看的时候，能够对测试用例的覆盖率一目了然，对覆盖率不足（如某个重点用户故事的测试用例覆盖不够）的地方能够及时给出意见。测试人员负责用例审核。2.3 测试计划敏捷测试的测试计划不需要复杂的计划文档，写
7、出一页纸的测试计划，将测试要点（包括策略、特定方法、重点范围等）列出来即可，模板见附件。2.4 测试实施运行敏捷开发模式中，测试与研发紧密结合在一起。测试主要有两种：单元测试和验证/接收测试。单元测试一般是由开发人员来完成的，接收测试是由客户代表来完成。由于客户通常无法在现场，一般由测试人员做验证测试，最后由客户进行接收测试。在每个版本发布给客户之前必须由测试人员进行测试，发布版本之后由客户做接收测试，提出需要修改的地方。需要修改的地方将在下后面的迭代中完成。 单元测试在每日构件版本给测试前，开发首先要做单元测试，提前告知软件中的薄弱环节，帮助测试人员调整测试重点。做单元测试的好处是可以提高版
8、本质量，减轻测试的工作量，减少浅层次的bug的发生率，使测试人员能够将更多的精力投入到寻找深层次的bug上面。 验证测试测试人员的验证测试从总体上说就是将测试用例按计划付诸实施的过程，以及验证故障修复是否会引入新的故障。这一阶段的测试必须在周密的计划下进行。这种计划性首先体现在开发和测试的相互协调配合，根据产品的架构和功能模块的依赖关系，按照项目的总体计划共同推进。从测试的过程来看，测试执行的一开始可以是针对部分用户故事的，之后可以逐步扩展。接着开始采用迭代的过程完成测试任务，即将测试任务划分为多个周期，一开始可以做些关键的功能性/用户故事测试，可以对代码中的可复用部分（组件，构件）做完整的测
9、试。接着的迭代周期可以做边缘化的功能测试和其他测试，最后的几个迭代应该用于完整的回归测试，和关键的性能和稳定性测试。 每日构件版本测试敏捷开发过程中除每个迭代中持续集成版本以外，还会有每日构件版本，每日构件版本测试用以验证前天修复的故障，以及测试故障修复是否会引入新的故障。2.6 版本控制敏捷开发强调快速开发，持续集成。版本包括每日构件版本、持续集成版本、验收测试版本三种类型。1）版本号约定每日构件版本号约定：PXXV0.0.0D0823 (D后面是日期)持续集成测试版本号约定：PXXV0.1.0B01（从B01开始递增）验收测试版本号约定：PXXV1.0.0B01（从B01开始递增）说明：P
10、XX为项目名，V0.0.0为每日构件版本，V0.1.0为集成阶段，V1.0.0为系统测试阶段。2）版本发布规则每日构件版本。每日发布每日构件版本，用于验证当天解决的故障，验证故障修改是否会引入新的故障。持续集成测试版本。每个迭代周期发布一个持续集成测试版本，如迭代周期为二周的，每个迭代周期可发布二个版本，由项目经理、测试经理协商决定。验收测试版本。项目开发后期迭代发布验收测试版本，每个迭代发布一个验收测试版本（项目经理和测试经理协商决定）。3）版本发布说明版本每次发布必须提供发布说明（Release Note）使客户对发布的版本情况一目了然。Release Note中主要包括三方面的内容：Fi
11、xed，New Features，Known Problems。其中，Fixed部分写明此版本修复了上个版本中存在的的哪些比较大的bug；New Features部分写明此版本新增加了哪些功能；Known Problems部分写明此版本尚存在哪些比较大的问题，有待下个版本改善；或者列出需求不太明确的地方，有待客户给出明确答复意见，在下个版本中完成。2.7 需求变更采用敏捷开发模式的项目中，客户对于需求的变更很频繁。因此，需求管理是十分必要和重要的工作。整个项目进行过程中，对不断变化的需求，一定要作跟踪，每次的需求变更都要有相应的历史记录，方便后期的管理和维护工作。可将每次的变更整理记录到产品故
12、事-燃尽图跟踪表（见附件），并使该文档始终保持最新更新的状态，与需求的变化保持同步。同时更新项目管理系统上面的产品用户故事与测试用例。2.8 迭代末期“bug大扫除”在项目开发的迭代末期，可以开展“bug大扫除”活动。划出一个专门的时间段，在这期间所有参与项目的人员，集中全部精力，搜寻项目的Bug。注意以下要点：（1）尽管这是一个测试活动，但参与者并不仅限于测试人员。项目经理，开发人员甚至于高层管理人员都应参加，如同全民动员。目的是要集思广益；（2）要鼓励各部门，领域交叉搜索，因为新的思路和视角通常有助于发现更多的Bug；（3）为调动积极性，增强趣味性，可以适当引入竞争机制，比如当活动结束时，
13、评出发现Bug最多，发现最严重Bug的个人，给以物质和精神奖励。（4）可以分专题展开，比如安全性、用户界面可用性、国际化和本地化等等。3 敏捷测试方法与策略3.1 持续测试、持续反馈敏捷测试是持续测试、持续反馈的过程，测试人员扮演“用户代表”角色，确保产品满足客户的需求。测试报表，测试日志都能及时得到反馈。3.2 单元测试方法策略单元测试是对功能模块进行正确检验的测试工作，也是后续测试的基础。目的是在于发现各模块内部可能存在的各种差错，因此需要从程序的内部结构出发设计测试用例，着重考虑以下五个方面：1）模块接口：对所测模块的数据流进行测试。2）局部数据结构：检查不正确或不一致的数据类型说明、使
14、用尚未附值或尚未初始化的变量、错误的初始值或缺省值。3）路径：虽然不可能做到穷举测试，但要设计测试用例查找由于不正确的计算（包括算法错、表达式符号表示不正确、运算精度不够等）、不正确的比较或不正常的控制流（包括不同数据类型量的相互比较、不适当地修改了循环变量、错误的或不可能的循环终止条件等）而导致的错误。4）错误处理：检查模块有没有对预见错误的条件设计比较完善的错误处理功能，保证其逻辑上的正确性。5）边界：注意设计数据流、控制流中刚好等于、大于或小于确定的比较值的用例。单元测试除代码走查外，敏捷团队成员要能熟练单元测试工具开展单元测试，确保代码质量。3.3 功能测试方法策略功能测试的目标主要包
15、括： 是否有遗漏需求； 是否正确的实现所有功能/用户故事； 隐示需求在系统是否实现； 输入、输出是否正确；移动互联网应用的功能测试侧重于所有可直接追踪到用例（用户故事）、业务功能和业务规则的测试需求，这种测试的目标是核实数据的接受、处理和检索是否正确，以及业务规则的实施是否恰当。功能测试基于黑盒技术，通过图形用户界面（GUI）与应用程序进行交互，并对交到的输出或结果进行分析，以此来核实实用程序及其内部进程正确与否。敏捷模式下的功能测试方法策略：已经实现功能的自动化测试。对前期迭代中已经实现的功能，采用工具进行自动化测试，即功能回归自动化测试。新实现功能的手工测试。主要验证用户故事是否正确实现，与用例是否相符。新实现功能的探索性测试。针对新实现的功能，
