研发项目测试规范

研发项目测试规范编制：贾瑞芬 日期：2007-审核： 日期：批准： 日期：

目录1. 概述 51.1 目的 51.2 适用范围 51.3 缩略语及术语解释 51.4 参考资料 62. 过程定义 63. 过程详述 73.1 制定测试计划 83.2 测试需求分析 93.3 制定测试方案 93.4 设计测试用例 103.5 开发测试程序和脚本 113.6 提交测试版本 123.7 执行测试 133.8 修复BUG 143.9 编写项目测试周汇报 143.10 编写Beta测试计划方案 153.11 编写测试总结报告 153.12 测试结束评审 174. 附录 184.1 BUG优先级与严重级别定义 184.1.1 BUG优先级(Priority)定义 184.1.2 BUG严重级别(Severity)定义 194.2 TD中角色变更BUG状态对应说明 204.2.1 测试人员可以改变的bug状态 204.2.2 开发人员可以改变的bug状态 214.2.3 项目经理可以改变的bug状态 214.3 BUG处理原则 224.3.1 测试人员处理原则 224.3.2 开发人员处理原则 224.4 无效BUG（invalid）定义 224.5 BUG产生原因定义 234.6 测试退出（codefreeze）准则 234.7 冒烟测试用例选择标准 244.8 测试执行期间版本发布原则 254.8.1 新功能版本发布 254.8.2 新功能版本+BUGFixed版本发布 254.8.3 BUGFixed版本发布 254.8.4 版本发布推进原则 26

研发项目测试规范概述目的本规范用以规范软件研发部软件测试的过程，保证软件产品质量，提高软件测试人员的工作效率。适用范围本规范适用于软件研发部所有产品研发项目。缩略语及术语解释Alpha测试：指完成集成测试、功能测试后，测试人员进入系统测试到软件发布期间的测试。Beta测试：指软件上线后，在试运营阶段，产品经理组织用户进行的线上测试。冒烟测试：指系统测试阶段开发Team每次提交新版本后，测试人员进行的主要正常测试用例执行。验证测试：开发人员修复BUG后，提交测试，测试人员在获取新版本后进行的BUG验证测试。回归测试：系统测试，目的是检测系统或系统部件在修改时所引起的故障，用以验证上述修改未引起不希望的有害效果，或证明修改后的系统或系统部件仍满足规定的需求。BUG：一般指在测试过程中，软件不满足需求或质量要求的情况下，由测试人员提出的缺陷均称为BUG。如果被测试对象不满足下面条件之一，测试人员即认为是BUG：不满足用户需求或隐含需求。与需求或设计不符合或者不一致。软件质量特性：衡量一个软件产品质量的特性，一般包括六项功能性：软件产品有提供当软件在指定条件下使用时，满足规定的或隐含的需求功能的能力。可靠性：软件按规定的条件，在规定的时间内运行而不发生故障的能力。易用性：在指定条件下软件产品被使用时，能够被理解、学习和吸引用户的能力。效率（性能）：软件产品在特定条件下与资源的使用数量情况相比较、提供适当性能的能力。可维护性：软件产品被修改的能力。修改包括在环境、需求以及特定功能改变时修正、改进或软件的改写。可移植性：软件产品从一种环境转移到另一种环境的能力。环境包括组织的、硬件的或软件的环境。参考资料CMMI－－过程集成与产品改进指南（影印版）（英文版）作者：（美）克里西斯，（美）科纳德，（美）沙恩著

出版社：清华大学出版社

出版时间：2004年02月

过程定义具体活动如下：制定测试计划：依据项目计划，制定测试计划，并根据项目计划变更情况及时修改维护测试计划；制定测试方案：根据软件需求和软件设计文档编写测试方案，明确测试的策略方法等；设计测试用例：根据软件需求和设计，按照测试方案的要求设计开发测试用例；开发测试程序和脚本：根据执行测试用例的需要开发测试程序或测试脚本；提交测试版本：构建产品并提交测试；执行测试：按照测试计划的要求执行测试用例并提交BUG；修复BUG：修复并反馈测试发现的BUG；编写阶段测试分析报告：记录阶段测试执行结果，并对测试结果和效率进行分析，报告测试遗留问题，记录测试过程中出现的问题并提出解决方案；测试阶段评审：评审阶段产品质量和测试质量，对提交的BUG进行回顾；编写测试总结报告：与测试计划进行对比，从产品质量、测试质量、测试进度、测试资源等方面进行分析，并总结测试的经验和教训；测试结束评审：评审项目整个测试过程的产品质量和测试质量，对提交的BUG进行回顾；

各活动之间的关系如下图所示：过程详述过程活动描述条目说明目的：本活动的意图；责任人：负责执行本活动的角色；进入准则：能够开展本活动所必须满足的因素或条件；输入：执行本活动需要使用的数据或文档；活动：将本活动的输入转化为输出的一系列行动；输出：本活动所产生的数据或文档；完成准则：标志本活动完成的因素或条件；制定测试计划目的：制定项目总体测试工作的计划，确定人员安排、测试进度、测试阶段、质量目标等，指导后期测试工作；责任人：测试经理；进入准则：需求分析完成、项目计划初步制定完成；输入：《研发项目计划》（草稿）；活动：明确项目的测试环境；计划测试所需资源；明确测试准则，质量目标；安排测试人员和进度；估算测试风险；编写测试计划；评审《测试计划》，评审组成员包括：参见SQA的评审人员名单；测试计划评审可以与《研发项目计划》评审合并；在整个项目的测试过程中，测试经理需要跟踪计划执行情况。若发现问题但不影响项目总体进度则需要及时调整《测试计划》，若发现问题影响项目总体进度则需要变更《测试计划》；若《研发项目计划》发生变更则《测试计划》也应进行变更；输出：《XX项目测试计划.doc》、《XX项目测试进度计划.mpp》《XX项目测试计划评审报告.doc》；完成准则：所有评审组成员签字确认测试计划通过评审；

测试需求分析（可与软件需求分析合并）目的：将业务需求转化为测试需求，为后期的测试方案编写做准备；责任人：测试经理；进入准则：产品设计规格说明书完成；输入：《产品设计规格说明书》；活动：分析产品设计规格说明书；将业务需求转化为测试需求明确可测试项、不可测试项（并分析原因）；项目组内review《测试需求分析》；在整个项目的测试过程中，测试经理需要跟踪业务需求和测试需求的对应关系，若发现问题但不影响项目总体进度则需要及时调整《测试需求分析》，若发现问题影响项目总体进度则需要变更《测试需求分析》；输出：《XX项目测试需求分析.doc》；完成准则：所有评审组成员签字确认测试计划通过评审；制定测试方案目的：根据软件需求和软件设计文档编写《测试方案》，明确项目的测试策略和方法以指导测试用例的设计及测试的执行；责任人：测试经理；进入准则：软件需求说明文档通过评审；输入：软件需求说明文档，软件架构设计文档；活动：明确测试对象范围和测试环境；制定测试策略和方法；估算测试用例数；编写《测试方案.doc》；编写《功能测试方案.xls》组织评审《测试方案》，评审组成员包括：参见SQA的评审人员名单；编写《测试方案评审报告》，并请所有评审组成员签署评审意见；输出：《测试方案.doc》、《功能测试方案.xls》《测试方案评审报告》；完成准则：所有评审组成员签字确认《测试方案》通过评审；

设计测试用例目的：规范测试用例设计标准，为软件测试活动提供可执行的用例；责任人：测试经理、测试人员；进入准则：《测试方案》通过评审；输入：软件需求说明文档、软件概要设计文档、测试方案；活动：测试工程师对TestDirector进行初始化配置，并由测试经理进行配置检查，参考《项目TD配置文档》；测试人员在TestDirector系统上设计并保存测试用例；用例优先级的设定参见《测试用例优先级划分》；测试组内对用例进行Review；注1：按照用例层次对每个功能点和用例进行编号；注2：在整个项目过程中当天签出的用例必须当天签回；输出：测试用例；完成准则：测试用例组内交叉review，确定与测试方案一致并全面覆盖；

开发测试程序和脚本目的：开发测试程序或测试脚本以支持自动化测试，提高测试效率和效果；责任人：开发测试工程师；进入准则：《测试需求》通过评审，且明确了执行用例需要测试程序或测试脚本的支持；输入：测试需求活动：开发人员根据《测试需求》中用例的需要开发测试程序；测试人员根据《测试需求》中用例的需要编写测试脚本，包括功能功能测试脚本和性能测试脚本；验证测试程序和脚本；输出：测试程序文件、测试脚本文件；完成准则：测试程序或脚本的功能实现；

提交测试版本目的：提交可运行的产品供测试人员执行测试；责任人：开发经理、配置管理员；进入准则：提交的代码通过单元测试；输入：产品源码；活动：将被测代码构建为可测试产品；编写buildnotes，明确代码的Revision、发布日期、发布说明、环境部署说明；提交测试版本和buildnotes到产品库，首次提交测试还应将产品安装部署文档提交到产品库；配置管理员进行build；通知测试人员进行测试；输出：构建完成的待测产品、buildnotes；完成准则：测试人员顺利完成环境部署；

执行测试目的：执行测试用例，交叉测试及早发现不满足软件需求的BUG或缺陷；责任人：测试经理、测试人员；进入准则：测试方案通过评审，测试用例开发完成且通过组内交叉review，开发人员提交测试版本和产品安装部署文档；输入：发布的产品测试版本、测试用例、测试程序、测试脚本；活动：测试经理负责按照产品安装部署文档部署测试环境并负责环境的安全性，保证开发人员不对测试环境进行任何操作；测试经理按照测试用例优先级定义选取冒烟测试用例；如果不是新版本提交测试，冒烟测试用例选取需要增加优先级高的fixed状态的BUG；参见《测试执行中版本发布规则》；当提交测试版本后首先进行冒烟测试以验证所提交的版本是否可以正常地按照用例执行测试。冒烟测试中发现的问题不需要提交到TestDirector系统，但需要记录到《冒烟测试报告》中并发送给所有项目组成员及相关人员（包括：SQA、测试主管、部门经理、产品副总、产品项目经理）；若冒烟测试不通过则将提交的版本打回，修复后重新提交测试；冒烟测试通过后测试人员按照计划执行测试；测试人员将测试过程中发现的BUG要提交到TestDirector系统；BUG的优先级和严重级别定义见附录4.1；测试人员可以改变的BUG状态见附录4.2若测试人员明确知道BUG的来源则直接指定给该开发人员，如果测试人员不明确知道BUG来源原则上指定给开发经理，由开发经理再次分配（或由项目组自行决定BUG处理原则）；开发人员提交BUG修复版本后测试人员需要对BUG进行验证并修改TestDirector上BUG的状态；测试人员在测试执行期间测试人员必须每天提交测试日志到Daisy，记录当天的用例执行情况；测试经理（可以指配组内其他成员）每日以邮件模式发送当日测试情况给项目组成员及其他相关人员（包括：SQA、部门经理、研发副总、产品项目经理）；执行测试过程中测试人员应根据实际需要补充或更新测试用例；注：测试执行过程中的开发与测试人员处理BUG的具体原则见附录4.3；输出：BUG记录、测试日志、《冒烟测试报告》、测试情况汇报邮件；完成准则：所有BUG的状态为Closed/Invalid

/Later；修复BUG目的：修复发现的产品BUG或缺陷使产品功能与软件需求一致；责任人：配置管理员、开发经理、开发人员；进入准则：测试人员提交BUG；输入：BUG记录；活动：开发人员在TestDirector中受理BUG，修改BUG状态；开发人员可以改变的BUG状态见附录4.2.2开发人员修复BUG;配置管理员提交BUG修复版本；在测试交互过程中测试人员只对配置管理员提交的测试版本进行测试或BUG验证；若BUG无法解决，则需要项目经理将BUG状态置为Later，并注明原因；项目经理可以改变的BUG状态见附录4.2.3输出：BUG修复代码、复测版本；完成准则：已修复的BUG通过验证；未修复的BUG得到合理反馈；编写项目测试周汇报目的：记录周测试执行结果，并对产品质量和测试质量进行分析，报告测试遗留问题；责任人：测试经理；进入准则：测试执行阶段，周测试执行完成；输入：BUG记录、测试用例、测试日志；活动：记录本阶段测试结果；根据测试结果分析本阶段产品质量和测试质量；编写《XX项目测试周汇报.xls》；提交《XX项目测试周汇报.xls》给产品经理、项目经理、开发经理、SQA；每周项目review例会上进行汇报；输出：《XX项目测试周汇报.xls》；完成准则：所有相关人员收到邮件，项目review例会上进行了汇报；

编写Beta测试计划方案目的：明确系统的Beta测试计划、质量目标及测试策略和方法；责任人：测试经理；进入准则：所有alpha测试执行完成，且BUG状态仅为Closed/Invalid/Later；输入：BUG记录、测试日志、《阶段测试分析报告》；活动：明确测试对象范围和测试环境；计划测试所需资源；约束测试时间明确测试准则，质量目标；估算测试风险；制定测试策略和方法；编写《Beta测试方案.doc》；召集评审，评审组成员包括：参见SQA的评审人员名单；输出：《Beta测试方案》；完成准则：所有评审组成员收到《Beta测试方案》；编写测试总结报告目的：记录整个测试过程的执行结果，并对产品质量和测试质量进行分析，报告测试遗留问题，总结关于项目测试过程的经验和教训；责任人：测试经理；进入准则：所有测试执行完成，且BUG状态仅为Closed/Invalid/Later；输入：BUG记录、测试用例、测试日志、《阶段测试分析报告》；活动：记录整个测试结果；根据测试结果对比测试计划分析产品质量和测试质量；总结测试过程中的经验和教训；编写《测试总结报告》；提交《测试总结报告》给产品经理、开发经理、测试经理、SQA、产品副总、研发副总、部门经理；召集测试结束评审，评审组成员包括：产品经理、开发经理、测试经理、SQA、产品副总、研发副总、部门经理；输出：《测试总结报告》；完成准则：所有评审组成员收到《测试总结报告》；

测试结束评审目的：评审决定是否结束项目研发阶段的测试活动；责任人：产品经理、开发经理、测试经理、SQA；进入准则：《测试总结报告》制定完成；输入：《测试总结报告》；活动：对比《研发项目计划》和《测试计划》确定的质量目标评审项目整体产品质量；（BUG密度、BUG修复率）需要度量支持对比《研发项目计划》和《测试计划》确定的质量目标评审项目整体测试质量；（需求覆盖率、用例执行率、测试效率）需要度量支持进行BUGReview；根据附录4.6确定是否结束alpha测试；测试经理编写《测试结束评审报告》并请所有评审组成员签署评审意见；输出：《测试结束评审报告》；完成准则：所有评审组成员签字确认可以结束测试；

附录BUG优先级与严重级别定义BUG优先级(Priority)定义P5-urgent

最高优先级（经常发生且阻碍了继续测试或功能的使用）设定原则：此优先级别的Bug，如果不进行修改会影响到系统主要功能的使用，优先级别最高。此级别的BUG将操作中断测试不能继续进行；程序崩溃；当前版本定义的主要功能未实现；处理原则：原则上处理周期控制在BUG发布当天；P4-VeryHigh

较高优先级设定原则：此优先级别的Bug，如果不进行修改，会影响到其他主要功能的使用；次要功能未实现，优先级别较高；处理原则：原则上处理周期控制在BUG发布后的一天内；P3-High

一般优先级设定原则：此优先级别的Bug，如果不进行修改，说明系统定义的次要功能没有实现有错误，优先级别一般；处理原则：原则上处理周期控制在BUG发布后的一天内；P2-Medium

较低优先级设定原则：此优先级别的Bug，如果不进行修改，不影响主要功能，属于页面美观和易用性的问题；处理原则：原则上处理周期控制在BUG发布后的两天内；P1-Low

最低优先级设定原则：此优先级别的Bug，不影响主要功能，只是页面上的文字错误或者需要改进的建议；处理原则：原则上处理周期控制在BUG发布后的两天内；

优先级=问题出现的可能性+问题的严重性问题出现的可能性划分：K1为随机出现，且出现几率比较低，暂且约定一个测试周期出现一两次。K2为随机出现，且出现几率加大，10次操作出现3次以上。K3为毕现，但仅在极端使用条件下出现，例如打开文档数量超过30个，新建500个白板等；或复杂的操作步骤、复杂的使用场景、某个操作时点才出现（如状态同步问题）等。K4为毕现，但操作步骤较复杂，实际应用环境存在但不多。K5为毕现，操作步骤简单，均属于正常操作范围。严重等级<=3时，可能性权值要进行换算，换算公式为Kn*3/5，按照向上取整的原则计算。BUG严重级别(Severity)定义S5-urgent类严重错误，主要现象包括：由于程序所引起的死机,非法退出死循环导致数据库发生死锁数据通讯错误严重的数值计算错误S4-VeryHigh类较严重错误，主要现象包括：功能不符数据流错误程序接口错误轻微的数值计算错误S3-High类一般性错误，主要现象包括：界面错误(详细文档)打印内容、格式错误简单的输入限制未放在前台进行控制删除操作未给出提示S2-Medium类较小错误，主要现象包括：辅助说明描述不清楚显示格式不规范长时间操作未给用户进度提示提示窗口文字未采用行业术语可输入区域和只读区域没有明显的区分标志系统处理未优化S1-Low类微小缺陷测试过程中站在用户角度提出一些易用性，人性化等更利于系统优化的建议（非系统缺陷）；TD中角色变更BUG状态对应说明测试人员可以改变的bug状态New：测试中新报告的软件缺陷；Invalid：描述的问题不是一个bug(输入错误后，通过此项来取消)；对于开发人员置为“Duplicate”且经过确认的BUG测试人员将后提交的BUG置为该状态；Open：测试人员验证fix状态的bug，发现bug没有修订好；Closed：错误已被修复；开发人员可以改变的bug状态Fixed：开发人员已完成修正，等待测试人员验证；Byspec:开发人员认为测试人员对需求理解有误；WORKSFORME:不能重现这个bug,查看源代码也不知道为什么会出现这样的bug现象,如果以后有更多的关于这个bug的线索,重新接受这个bug；Duplicate：所提交的bug是一个重复的bug，且需要注明重复的BUGID；项目经理可以改变的bug状态

Later：描述的问题将不会在产品的这个版本中解决，注明原因；

BUG处理原则当变更BUG状态时，开发、测试人员均需要填写Comments，填写之前点击“addcomments”按钮然后填入内容。测试人员处理原则报告BUG后测试人员主动与开发人员沟通他们是否需要以邮件通知的模式通知BUG；BUG描述需要尽量做到清晰、易懂，对于可以重现的BUG开发人员能够按照描述步骤重现BUG；测试执行中发现BUG必须直接报入TD系统中，无须与开发人员沟通；报告BUG时除将BUG发现步骤描述清楚外，还需要提供测试数据、系统日志、截图等有助于开发人员分析、解决BUG的相关文件；测试人员Open一个bug的时候必须和开发人员沟通并获得同意；填报BUG或者转给他人BUG是否需要Email通知根据不同项目决定，但是所有转给产品人员的BUG均需要同时发送Email通知；开发人员处理原则开发人员在下班之前，必须没有任何NEW状态的bug；开发人员BySpec一个bug，必须首先和测试人员沟通并获得同意；开发人员Duplicate一个bug，必须首先与测试人员沟通并获得同意；对于标识为可重现的BUG开发人员必须按BUG描述步骤自己重现BUG，如果描述不清楚才可以要求测试人员配合重现；开发、测试人员将一个bug转给他人之前，必须进行沟通并获得同意；Bug的优先级别遵循测试人员的设定；任何bug都不应该被删除，但是可以被置为invalid；开发人员修复一个BUG后需要在Comments中详细描述BUG产生的原因及修复的文件；无效BUG（invalid）定义产品定义不明确，如产品定义了一个管理员管理某个组数据，如果将管理员所管理的组删除后，管理员进入系统查询组时将会出现什么样的结果未被定义，而由此产生的BUG则可以选择此项；产品原有BUG，如某个项目的升级版本出现BUG，经查是原版本已知的BUG则可以选择此项；测试人员误操作（包括但不限于：测试人员需求理解错误、测试环境中毒、测试人员粗心大意、测试人员缺少专业知识、测试人员重复提交已经存在的BUG）引起的BUG；需求在报BUG之后发生了变化导致BUG无效；BUG产生原因定义产品定义不明确，如：产品定义了一个管理员管理某个组数据，如果将管理员所管理的组删除后，管理员进入系统查询组时将会出现什么样的结果未被定义，而由此产生的BUG则可以选择此项）产品原有BUG，如：某个项目的升级版本出现BUG，经查是原版本已知的BUG则可以选择此项粗心大意单元测试不足对程序设计语言不熟悉软件设计缺陷未遵从编码规范需求理解错误业务知识缺乏由其他BUG引起，如：调用了一段代码，该段代码存在BUG，则选择此项）相关系统BUG（如：ACTools项目出现ACM系统的BUG；ACM系统出现Summit平台的BUG，则选择此项）无效BUG，如：由于测试人员操作有误或者由于测试环境出现问题产生的BUG，则选择此项测试退出（codefreeze）准则新产品测试退出准则所有功能均符合用户需求并已经通过确认；BUG趋势出现明显收敛状态达到两个版本以上；a)明显收敛的定义：当前测试版本发现的BUG占此项目总BUG数的0%—3%，根据项目规模大小不同可以在这个范围内选择，但最大不能超过3%；测试退出前完成一次执行全部测试用例的回归测试及优先级别为High（包含）以上BUG回归；测试退出前一个版本的测试定为稳定期，在此期间无优先级别为Urgent,Veryhigh的BUG存在；注：测试退出前测试经理主导召开最后一次BUGReview，所有与会人需要签字确认是否可以退出测试；升级版本测试退出准则所有新增功能均符合用户需求并已经通过确认；系统原有版本（指当前线上运行版本）中的功能、性能未出现新的BUG；新需求产生的BUG趋势出现明显收敛状态达到两个版本以上；a)明显收敛的定义：当前测试版本（build版本）发现的BUG占本次升级版本的总BUG数的0%—3%，根据项目规模大小不同可以在这个范围内选择，但最大不能超过3%；测试退出前完成一次执行全部测试用例的回归测试及优先级别为High（包含）以上BUG回归；测试退出前一个版本的测试定为稳定期，在此期间无优先级别为Urgent,Veryhigh的BUG存在；注：测试退出前测试经理主导召开最后一次BUGReview，所有与会人需要签字确认是否可以退出测试；Patch（修复BUG）版本测试退出准则需要修复的BUG已经修复；系统原有版本（指当前线上运行版本）中的功能、性能未出现新的BUG；测试退出前完成一次执行全部测试用例的回归测试及优先级别为High（包含）以上BUG回归；注：测试退出前测试经理主导召开最后一次BUGReview，所有与会人需要签字确认是否可以退出测试；冒烟测试用例选择标准新功能版本发布测试人员接到新版本后首先需要对新功能进行冒烟测试，冒烟测试主要验证所提交的功能点是否按需求完成，是否可以按照正常测试用例执行测试。选择主要功能的正常用例做为冒烟测试执行的用例，一般选择用例库中主要功能优先级别为P1的用例。新功能版本+BUGFixed版本发布新功能开发完成后，如果依赖于某个功能模块且该功能模块中存在未Fixed的BUG则不接受新版本部署测试。选择新功能正常测试用例和优先级为high（包含）级别以上已经Fixed的BUG做为冒烟测试执行