敏捷开发测试规范V0.1

敏捷开敏捷开发测试规发测试规范 范 试试行 行 2012 年年 9 月月 版本版本记录记录 版本版本 号号 日期日期修改人修改人描述描述 V0 12012 9周本文V0 1 目录 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 术语中文说明 Product Owner PO 产品所有者 相当于项目经理 产品经理 产品负责人 产 品用户故事编写负责人 Scrum Master SM 敏捷开发组 织者 组织项目敏捷开发 负责协调 沟通 协助解 决团队内部非技术问题 Product Backlog 产品需求产品待开发的功能项 用户需求 Sprint Backlog 迭代需求每个迭代需实现的功能项 产品需求细化 User story 用户故事从用户角度提出的需求 Burndown chart 燃尽图产品需求 迭代需求完成的进度显示图 Plan Meeting 计划会 迭代计划会 组织讨论下个迭代开发内容 PO 需参加讲解产品需求 Standup Meeting 每日立会 每日立会 早上时间 主要讨论每人当天工作 内容 Review Meeting 迭代评审会 每个迭代结束时召开 展示迭代成果 听取 PO 意见 建议 表 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 根据项目特点 可选择其他持续 集成工具 适用测试类型 每个迭代持续集成版本 每日构件版本 最终验收版本