通信公司客户支撑系统-PMO-测试管理办法模版.docx

北京联通网格营销系统实施工程
项目管理组
测试管理办法

2011年3月

文件目的
本文件作为《xx集团客户支撑系统实施工程项目管理办法》中测试管理说明。

通过描述测试的策略，测试管理方法，测试管理流程以及测试管理工具。

在项目实施过程中，联合测试组将按照本文件的要求进行测试管理。也建议各小组内部测试时按照本文的管理要求执行。

文件修改历史
版本
日期
负责人
内容描述
0.1
2011/4/2
童懿
创建

目录
1 简介 5
1.1 测试管理目的 5
1.2 名称解释 5
2 测试策略 5
2.1 原则 5
2.2 测试定义 6
2.3 测试间的依赖关系 7
2.4 测试范围 7
3 测试过程 8
3.1 测试计划阶段 8
3.2 测试准备阶段 8
3.2.1 测试场景组/场景准备 8
3.2.2 测试数据准备 10
3.2.3 测试环境准备 10
3.3 测试执行阶段 10
3.3.1 制定执行计划 11
3.3.2 应用速检 11
3.3.3 测试执行 11
3.3.4 测试报告 12
4 流程和相关工具 12
4.1 测试执行管理例会和报告 12
4.2 相关流程 13
4.2.1 缺陷管理流程 13
4.2.2 应用软件更新流程 16
4.2.3 协作及分工 17
4.2.4 相关工具 17
5 组织架构 18

图表目录
图表 1 名词解释 5
图表 2 测试间依赖关系 7
图表 3 测试范围说明 8
图表 4 测试准备工作流程 8
图表 5 测试相关概念模型 9
图表 6 测试数据准备流程 10
图表 7 测试环境准备流程 10
图表 8 测试执行流程 10
图表 9 测试执行期间例行工作 12
图表 10 缺陷等级说明 13
图表 11 缺陷管理流程 15
图表 12 缺陷管理流程步骤 15
图表 13 软件更新时的缺陷状态变更 16
图表 14 软件更新后的缺陷状态变更 16
图表 15 组织架构 18

1 简介
1.1 测试管理目的
本项目中联合测试的主要目标是：集合总集、各子系统厂商、xx各方力量组成联合测试组，统一安排子系统测试检查、系统集成测试、全国联调测试、性能测试和迁移功能测试等各类测试活动，充分利用人员共享来提高整体测试效率，保障整体系统的质量，并最终达成按时按质上线的总体目标。
1.2 名称解释
英文缩写
英文全称
中文名称
解释
HotFix
HotFix
热补丁
技术上，一般来说是使用增量编译等方法进行快速的软件升级
Release Note

软件升级说明
应用软件升级时，由设计开发组长正式发布的说明文件，包括该次升级所修复的缺陷清单，新功能清单等信息
Regression Test

回归测试
在新功能或程序错误不断修正的过程中，需要针对原有并且通过了的功能再次进行测试检查，以防应用程序变更引起质量恶化
SWP
Sofeware Promotion
软件升级
在开发、测试过程中定期的软件程序更新活动，包括交付新功能，或者修正程序错误。技术上，一般来说是使用全量编译、配置等方式
Shakedown
Shakedown
速检
系统更新（环境设置，或SWP等）后，小规模的系统检测活动
Stub

模拟程序
遵循“分而治之”的原理，用来模拟上游或下游系统交互请求的程序
图表 1 名词解释
2 测试策略
2.1 原则
在各子系统内部开发及内部测试阶段结束后，由总集牵头各厂商参与组成联合测试组，对后继的测试工作进行统一的计划、管理、执行工作。同时组织统一的系统集成组，负责测试环境的统一规划、管理和维护，以及所有子系统应用软件在集成测试、联调测试等共用环境下的发布工作。
2.2 测试定义
ü 子系统内部测试（AT）
采用模拟数据，合理遍历检测产品和业务功能维度，也包括：子系统功能测试、用户权限测试、报表测试、应用层面的错误、用户界面等内容。该测试活动由子系统负责。
ü 应用性能测试（APT）
由子系统对各自系统内部进行性能测试，确保满足技术规范提出的非功能性要求。该测试活动由子系统负责。
ü 子系统验证测试（AVT）
针对各子系统按要求提交的产品测试报告，由联合测试组进行抽样检测，通过此项测试结果作为是否进入集成测试的依据。该测试活动由联合测试组负责。
ü 系统集成测试（SIT）
采用模拟数据对各个子系统进行的端到端跨子系统功能的验证，功能和数据覆盖面是子系统内部测试(AT)的子集。该测试活动由联合测试组负责。
ü 用户接受测试（UAT）
由最终用户根据提交的业务需求，检查集成系统是否符合要求，也包括系统可用性测试，用户界面的友好性。
ü 集成性能测试（PRT）
采用生产规模的数据，针对分析确认的性能关键点（风险点）和指标，模拟常用的业务操作，进行压力及饱和度测试，观察系统的扩展能力和稳定性，并通过修改系统配置、优化应用代码、优化第三方软件、数据库配置来提高性能。该测试活动由联合测试组负责。
ü 联调测试（UIT）
确保集客系统与外部系统（全业务服务平台、网元等）交互正确，端到端流程执行正确。该测试活动由联合测试组负责。
ü 迁移应用测试（MAT）
验证数据迁移应用程序本身的正确性以及处理时间是否满足要求。该测试活动由子系统负责。
ü 迁移集成测试（MIT）
采用迁移数据，从端到端跨系统功能的角度比对原系统到目标系统，目标系统到目标系统，验证迁移数据的正确性、一致性。功能覆盖面是系统集成测试的子集。该测试活动由联合测试组负责。
ü 操作就绪测试（ORT）
确保生产系统安装和配置正确，验证运营维护人员可以正确对系统进行维护性操作，包括：备份/恢复、归档/清理、监控告警、配置管理、HA切换、安全机制、定时任务等 。该测试活动由联合测试组负责。
2.3 测试间的依赖关系

图表 2 测试间依赖关系
各种测试之间的关系：
ü 子系统内部测试是后续所有的基础
ü 子系统验证测试是在子系统内部测试完成后，对该测试的结果进行抽样检查
ü 系统集成测试在子系统验证测试通过后才能开始进行
ü 在系统集成测试功能基本稳定的前提下，可以开始迁移集成测试和集成性能测试
ü 迁移组完成迁移应用测试后，为迁移集成测试和集成性能测试提供迁移数据。
ü 集成性能测试结束后才能进行操作就绪测试
2.4 测试范围
根据测试定义和各个测试间的依赖关系，我们可以得出以下测试范围矩阵，表明了各种测试覆盖的范围。

范围
子系统内部测试
子系统验证测试
集成测试
迁移集成测试
集成性能测试
联调测试
功能
全部
部分
部分
部分
部分
部分
产品
全部
部分
部分
部分
部分
部分
系统权限
全部
部分
部分
部分
部分
部分
子系统互联
模拟器
模拟器
全部
部分
部分
部分
外部接口
模拟器
模拟器
全部
部分
部分
部分
报表
全部
部分
部分
部分
部分
部分
异常处理
全部
部分
部分
部分
部分
部分
图表 3 测试范围说明
3 测试过程
3.1 测试计划阶段
计划阶段主要完成以下工作（即完成本文档的编写和评审）：
ü 测试方法、策略的确定
ü 测试阶段定义和每阶段主要工作文档的定义
ü 确定管理办法、流程和工具
ü 确定时间计划
ü 确定人员组织及分工
3.2 测试准备阶段
3.2.1 测试场景组/场景准备
测试场景组

根据产品或者其他分类定义测试场景组
测试覆盖矩阵

以销售、订单等功能为主要参照定义能力产品覆盖矩阵
测试场景

根据能力产
品覆盖矩阵及相关功能定义编写测试场景
测试场景检查

以跨系统流程和接口为测试场景进行检查和相应的修正

测试脚本

根据测试场景的详细信息，编写测试脚本

图表 4 测试准备工作流程

测试场景组
测试场景组是对测试场景进行分类而得出的。分组的原则主要是根据产品类型进行分类。测试场景组是测试场景的逻辑分组，每个场景组可以单独执行，对其他的场景组无任何依赖关系。下图描述了需求、测试脚本、测试场景、测试场景组间的关系。

图表 5 测试相关概念模型
能力-产品覆盖矩阵
以销售、订单等功能为主要参照定义能力-产品测试覆盖矩阵。
测试场景
测试场景是一系列端到端业务功能的组合，每个测试场景包括一个或多个测试脚本，每个测试脚本使用特定的测试数据。不同的测试场景应可以平行执行，因此在定义测试场景时应尽量避免测试场景间的依赖。
测试脚本
根据功能/需求列表，得出测试必须覆盖的测试脚本集合。每一个测试脚本对应一个或多个功能点/需求点。每个测试脚本都有相应的测试数据定义。在整个的测试执行阶段是以测试脚本为基础的，测试脚本是评估、监控测试执行阶段的最小单位。测试脚本中应包括如下内容：
ü 测试步骤
ü 测试数据
ü 预期结果
ü 执行完毕后的实际结果
当所有测试脚本执行完毕后，测试执行阶段可以认为基本结束。此时，测试人员应更多的关注测试中发现问题的解决。
3.2.2 测试数据准备

测试数据范围
根据测试场景及各系统情况，确定测试数据范围
静态数据定义
动态数据定义

静态数据准备
动态数据准备
测试数据汇总
测试数据分组
测试数据汇总

图表 6 测试数据准备流程
在测试脚本执行过程中，测试数据是必不可少的。每个测试步骤使用的数据，在脚本创建时已经定义。测试数据的不同可能会导致测试步骤和测试结果发生变化。
3.2.3 测试环境准备
测试环境设计
主机划分
目录规划
命名规范
权限设计
硬件环境准备
硬件安装调试
网络配置
系统软件安装
应用软件安装
软件版本确认
应用软件部署
应用速检
模拟器准备
各个测试环境所需的模拟器准备和安装调试

图表 7 测试环境准备流程
3.3 测试执行阶段
制定执行计划
测试周期定义
测试任务分配

应用速检
通过速检过程检查系统功能和测试环境达到就绪状态
测试执行
执行计划以及缺陷的情况执行测试

测试汇总报告
测试情况汇总
测试结果分析
报表
遗留问题说明
缺陷跟踪及处理（缺陷处理、缺陷评审）
测试过程监控（ 测试监控报表、状态报告 )
配置管理（SWP、Hot Fixes、配置变更）

图表 8 测试执行流程
3.3.1 制定执行计划
测试周期
测试脚本除了归属于测试场景外，还将被按照功能种类划分成测试周期。每个测试周期包括一个系统功能的集合。划分测试周期有利于测试任务的分解、测试执行进度的监控、以及存在问题最多功能域的定位。在测试执行的初期，建议采用较细粒度的功能域划分测试周期，如：客户资料管理，订单管理，产品管理等。
测试任务分配
由测试组长定期将测试任务通过测试管理平台分配给测试人员。测试人员按照测试任务指定的时间和内容进行测试执行工作。
3.3.2 应用速检
速检过程的目的是确保在测试执行正式开始前，关键的业务能够正常执行，基本的应用功能能够就绪，降低由于关键功能有缺陷而被迫暂时中断测试执行的风险。预计Shakedown的时间大约在15~30分钟左右。通过Shakedown还可确保各个系统的连通性是基本正常的。
3.3.3 测试执行
屏幕截图
对于前端界面将测试结果的屏幕截图保存，做为测试通过的依据。
日志文件（Log Files）
一般由应用系统的后台程序产生，通过收集在测试执行阶段产生的Log文件可以帮助开发人员分析、定位问题。对于执行成功的脚本，log文件也可做为证明测试通过的依据之一。
测试结果检查
测试结果检查过程主要是指将测试获得的实际结果与期望结果进行比对的过程。当测试结果与期望结果存在差异时，测试人员应该咨询测试组长，由测试组长确认是否需要新建缺陷。
过程监控报表
测试的时间表定义的非常紧凑。为了确保所有的测试脚本能够按时完成，必须随时监控测试执行的进度，提前发现会导致测试进度延误的风险。
衡量测试执行进度的关键指标是测试脚本完成的数量。另外，还有一些指标可以帮助我们监控集成测试执行的进度和质量。具体如下：
下列指标用来体现测试进度：
ü 测试脚本数量（未开始、进行中、已完成（存在缺陷）、已完成）
ü 缺陷的数量
下列指标用来体现缺陷修复的质量和效率：
ü 缺陷从创建到修复（或当前状态）的时间
ü 重新开启缺陷的数量
在测试全部完成之后可以通过下列指标进行进一步的问题分析：
ü 缺陷的数量
状态报告
测试小组将每周定期的提交状态报告，报告中包括如下内容：
ü 过去一周主要完成的工作
ü 下周计划完成的工作
ü 反映测试进度的相关指标数据
ü 问题汇总
ü 潜在的风险
3.3.4 测试报告
在计划的所有测试场景全部执行完毕，所有测试执行周期结束后。测试小组的人员将测试情况进行总结、报告。测试报告的主要内容是汇总在测试执行阶段发现的重要问题及相关重要信息，如果存在没有修复的问题，需要进行问题的移交。测试报告的用户评审结束，标志着测试的工作全部完成。
4 流程和相关工具
4.1 测试执行管理例会和报告

图表 9 测试执行期间例行工作
4.2 相关流程
4.2.1 缺陷管理流程
缺陷等级说明
严重等级
修复时间要求*
定义
1 – 严重
4小时
缺陷影响了核心业务的处理，所有的主要业务操作不能进行。阻碍了大量测试场景无法执行
2 – 高
1天
缺陷影响了一些非核心或者核心的业务功能，但是其他业务功能仍然可以正常运行
3 – 中
2天
缺陷影响非核心业务运行，但其他业务运行仍可以继续，同时存在替代的解决方案可以暂时绕过此问题
4 – 低
4天
不影响任何系统功能，例如操作界面的外观或错误的提示信息等
图表 10 缺陷等级说明
注：
* “修复时间”是指从“Wait for Fixer Assignment”到“Fixed – Ready to promote”的时间，对于严重问题，测试组长或小组长需要立即与相关开发组长沟通并确定缺陷负责人，即将缺陷的状态设置为“Fix in Progress”
* 关于“修复时间要求”，针对特殊的具体问题，可以根据缺陷评审会上所达成的一致意见进行调整
问题（SIR）状态说明
缺陷的处理状态分为以下几种
ü 新建(Open)：测试者在测试某个业务场景发现新的系统缺陷时，应进行记录，状态设为“Open”。
ü 等待分派开发者(Wait Fixer Assignment): Test Lead 指派开发组接口人或开发组长,并更改缺陷的状态为“Wait Fixer Assignment”。
ü 已分派(Fix in Progress)：各开发小组长会将当日的缺陷分派给系统开发者修复，此时状态应更改为“已分派”。开发组长每天会随时的检查，是否有新提出的未分派的缺陷，并进行处理。另外，当测试人员发现紧急问题时会立刻找到开发组长要求其进行缺陷的指分派。
ü 驳回(Reject)：如果该缺陷被开发组鉴定后，并不是系统缺陷，而是测试者操作错误或测试脚本错误，则缺陷的状态可由测试组长和开发组长讨论同意后更改为“驳回”。
ü 暂缓(Deferred)：如果缺陷不是会影响本阶段客户需求实现的系统修改，缺陷的状态可由测试组长和开发组长讨论同意后设为“暂缓”。
ü 已修复–等待版本升级(Fixed –Ready to Promote)：在开发者完成对系统缺陷的改进之后，缺陷的状态应由开发者更改为“已修复-等待版本升级”以等待系统集成组人员发布修改的代码/配置到测试环境。
ü 升级完毕–等待重新测试(Promoted – Ready for Retest): 在系统集成组把代码部署到测试系统中，缺陷的状态应由系统集成组更改为“升级完毕–等待重新测试”。测试组就能着手对相应的业务场景进行重新测试以确认系统缺陷已被消除。
ü 重启 (Reopen): 测试者在重新测试之后发现原有的缺陷仍有问题存在, 需要进一步改进, 此时测试者应将处理状态改为重启。
ü 关闭(Close)：在测试组重新针对缺陷相应的业务场景测试，并确认原有的问题已不存在，可将缺陷的状态改变为“关闭”。

缺陷管理流程

图表 11 缺陷管理流程
步骤
描述
责任人
测试人员创建缺陷
当缺陷被发现时，测试人员应在缺陷管理系统中创建一个新的缺陷，并填入如下信息：
测试场景编号、测试脚本编号、状态、应用开发小组、严重级别、提交日期、详细描述、提交人等
测试人员
缺陷评审会
1. 测试组长和开发组负责人每天都会召开一个缺陷的审核会议。审核缺陷的有效性，包括问题的描述是否清晰等，同时审核问题的严重级别，以及相关的应用开发小组。
2. 决定此缺陷是通过何种方式修复：Hotfix或每周的定时升级时间窗口
3. 审核正在解决缺陷的状态
测试组长
开发组长
指派缺陷修复责任人
在审核会上应用开发小组将为每个缺陷指定修复责任人
开发组长
缺陷修复
开发小组调查问题原因并进行修复，修复完毕后进行测试。
开发小组
HotFix/SWP
测试组长通知系统集成组进行Hotfix或SWP
测试组长
重新测试
系统集成人员将修改后的应用部署到测试环境后，测试人员重新进行测试
测试人员
重新开启
重新测试后问题仍然未解决，测试人员需要重新开启问题
测试人员

图表 12 缺陷管理流程步骤
由于测试执行的时间非常有限，因此在测试过程中发现的所有缺陷必须在合理的时间内进行调查、解决。如果在缺陷审核会上相关方不能就如何解决问题达成统一意见，需要升级提交到各项目组长一起做出仲裁，如果仍然不能达成一致，立即上报PMO进行最终决策。
另外，在功能开发组发布新功能时应以缺陷的方式提出，以提醒相关人员，做为变更跟踪的记录，同时体现在release note中。
4.2.2 应用软件更新流程
软件更新包括应用软件更新和配置数据更新。在子系统验证测试结束后，系统集成测试前应用软件的基线已经建立。基线建立之后的软件版本发布应通过版本发布的规范流程管控 和版本控制工具SVN管理。只有系统集成组人员才具备在集成测试、联调测试等环境的发布应用权限。
有两种软件更新方式：
· 每周定时更新
· 每日紧急更新Hotfix
每周定时更新
建议每周四20:00前完成每周的定时更新操作。周三晚上应该将这次版本变更的内容编译、部署完成。部署时产生新的软件版本，同时编写release notes。Release note应说明本次变更主要修复哪些问题，如何部署应用，部署哪些应用等。
软件更新过程中的缺陷状态管理

图表 13 软件更新时的缺陷状态变更

当软件Promote到测试环境后，接下来的处理流程如下：

图表 14 软件更新后的缺陷状态变更
Hot Fixes流程
对于在测试过程中发现的严重问题需要的紧急修复，需通过Hotfix流程进行。建议每天指定固定的时间（12：00－13：00）进行Hotfix，这样对正常的测试执行影响最小。哪些缺陷应该通过Hotfix修复取决于缺陷的严重级别和对测试执行进程的影响。
测试组长负责确认哪些缺陷应该在下次Promote之前必须被修复，这些缺陷的修复就需要通过Hotfix方式进行。
一旦决定进行Hotfix，那么应用开发组必须在正式hotfix执行之前一小时完成问题的修复，并通过测试，修复后缺陷的状态设置为“Ready to Hot Fix”。负责hotfix的相关人员会在执行hotfix前查询所有状态为“Ready to Hot Fix”的缺陷，在hotfix后将这些缺陷的状态设置为“Hot Fix -Ready for Retest”。
测试人员将重新测试，确认缺陷是否修复。如果确认已经修复，还需要将缺陷的状态设置为“Ready to Promote”，这样可以确保在下次Promote时的新版本包括本次的hotfix。
4.2.3 协作及分工
缺陷评审参与人及职责
测试组负责人职责：
ü 与开发组负责人沟通，审核发现的问题
ü 负责记录缺陷的分派结果，追踪缺陷的处理情况，以及对缺陷处理时间进行监控
应用发布人职责：
ü 确定发布的时间和策略
开发商负责人职责：
ü 对测试组提出的缺陷进行分析、定位、指派相应的开发人员
PMO、项目组各组长：
ü 对在缺陷评审会中产生分歧的问题进行仲裁
缺陷解决质量要求
ü “严重”级别的缺陷修复时间在4小时以内
ü “高”级别的缺陷修复时间在24小时以内
ü 各开发组每周累计re-open 缺陷的数量：2个为事故，4个为重大事故
ü 各开发组每周累计break-regression数：2个为事故，4个为重大事故
ü 每周SWP累计延时：超过4小时为事故，8小时为重大事故，包括由于系统集成组操作错误、开发组release note错误，开发组版本管理错误等引起的SWP问题。不包括由于第三方厂商及时不支持引起的问题。
ü 紧急情况需要发布时，系统集成人员到场时间小于1小时（包括下班后、周末等）
ü 每个开发组的缺陷协调人、测试协调人、应用发布协调人必须有Backup
ü 开发组组长未经联合测试组负责人，或争议问题仲裁小组，或对方开发组组长同意，不允许re-assign 缺陷
4.2.4 相关工具
采用工程管理平台中的测试管理子系统进行测试的准备、执行和报告。
采用Jira进行缺陷的管理。
采用工程管理平台任务单管理模块进行发布流程管理。
采用SVN进行源代码管理。
5 组织架构

图表 15 组织架构