1、项目测试规范流程讲解软件项目测试规范流程奥尊公司测试部2012年 9 月修订历史记录日期变更版本变更描述作者2012/9/13新增王志芳1 概述 41 1 软件测试的目的 41 2 软件测试的原则 41 3 对软件测试的错误认识 42 软件测试过程 62 1 测试过程 62 2 角色与职责 93 关键活动定义 113 1 测试准备 113 2 测试方法设计 113 3 测试计划 113 4 计划评审 123 5 文档评审 123 6 测试用例及评审 123 7 环境准备 123 8 测试执行 133 9 缺陷汇报 /分析 133 10 回归测试 13311 随机 /异常测试 143 12 阶段
2、报告 143 13 测试报告 144 测试文档简述 144 1 开发转测试确认表 154 2 需求变更控制文档 154 3 问题修复清单 164 4 测试计划 164 5 测试脚本（用例） 164 6 问题报告 164 7 缺陷分析文档 164 8 测试报告文档 161 概述11 软件测试的目的 软件测试是为了发现错误而执行程序的过程 测试是为了证明程序有错误，而不是证明程序无错误 一个好的测试用例是在于它能发现至今未发现的错误 一个成功的测试是发现了至今未发现的错误的测试12 软件测试的原则 软件测试的原则之一： Good Enough 这是一种权衡投入产出比的原则，测试既不要不充分，也不要
3、过分。不充分和过 分都是一种不负责任的表现。Zer o-bug 是一种理想，Good- enough是我们的原则。 软件测试的原则之二： Early Best 越早发现错误，因错误而导致的损失就越小；所以测试工作必须贯穿软件开发的整 个生命周期，以期尽早发现软件中的错误。那些认为只需在软件开发完成后再进行 系统测试的观点是错误的。 软件测试的原则之三： bug 的 80%原则一般情况下， 在分析、设计、实验阶段的复审和测试工作能够发现和避免 80%的 bug，而系统的软件测试能够找出其余 bug 中的 80%。最后约 5%的 bug 只有在用户大范围、 长时间的使用后才会暴露出来。因此测试只能
4、保证尽可能多地发现错误，不能保证发现所有的错误。13对软件测试的错误认识 对测试的错误认识（一） ：完整的测试是可能的 在实际操作中，完整的测试是不可能的。 从理论上说，完整的测试也是不可能的。 对测试的错误认识（二） ：存在一个可以定义的测试终结点测试通常是在时间用完时结束测试是一份令人厌倦的工作 对测试的错误认识（三） ：测试和调试没有什么区别，除了支持调试外，测试没有别 的目的测试是查找潜在的错误，调试是定位已知的错误测试贯穿于整个软件生存期，调试主要是在软件开发过程中测试是发现问题，调试解决问题测试与调试不能相互替代，但可相互支持，相辅相成 对测试的错误认识（四） ：测试是件很简单的工
5、作，无需设计 测试是一项具有很大创造性的工作，其工作量一点也不比代码设计小 测试是需要设计的，一个好的测试计划或方案往往能达到事半功倍的效果 测试设计可以是自动的，半自动的或手工编 写2 软件测试过程21测试过程对需要测试的任何产品， 都需要有一个测试的进入标准、 测试执行的开始标准、 测试执 行的结束标准以及测试执行好坏的评价标准。 本文所定义的测试流程， 也遵循这么一条基本 主线，其过程主要包括测试的进入、执行、报告、分析、结束。测试的进入往往是在需求分 析即将结束时进行的， 这样测试过程与开发过程基本同步， 有助于尽早发现系统设计的问题； 这样做的另一好处还在于测试准备充分， 开发结束可
6、立即进入测试阶段， 有助于缩短项目进 度。测试执行前的准备工作对于测试来说是至关重要的， 这些准备工作主要包括从系统需求 分析报告和概要设计文档里面获取产品信息及产品功能特点， 并对此进行相关的分析、 总结， 然后进行测试设计：包括选择测试方法，确定测试内容、测试工具，结合产品特点确定是否 进行性能、负载、压力、安全等方面内容的测试；制定测试计划；制定详细测试执行计划及 设计测试案例。下图是测试过程的结构层次图， 通过这个图， 我们可以看到整个产品从需求到产品交付 的过程中，测试和开发之间的关系以及对应的测试过程。开发过程需求分析系统设计编码需求分析测试过程报告系统设计 说明测试准备单元测试集
7、成测试产品转测试修复 /新版产品单元测试报告集成测试报告问题修复 清单测试方法设计测试计划计划评审文档评审测试用例及评审环境准备测试计划测试用例文档评审记录测试执行回归测试缺陷汇报 /分析问题报告随机 /异常测试 缺陷汇报 /分析问题报告阶段报告阶段测试 报告从上图我们可以看出测试任务的具体工作流程：1、 系统设计阶段 测试经理开始确认测试项目，熟悉和了解用户需求，配合开发做相关资源准备。2、 编码、单元测试和集成测试阶段 根据系统设计，制定和设计大体的测试框架，包括可能用到的测试方法，测试工具，确 定测试人员， 熟悉测试产品的功能设计， 储备对应的测试需求的技术知识， 进行必要的 测前技术培
8、训，对测试任务进行大致的时间计划和人员安排。在完成上述相关准备之后， 开始进行详细的测试设计， 编写测试计划和测试用例， 并对 此进行评审。对有性能需求测试的进行性能测试设计。即：组建测试项目组，确定测试项目经理和组员 熟悉产品功能设计 分析可能实施的测试方法考虑可能需要的测试工具支持分析测试人员具备的技术需求完成初步的产品测试进度分析 按照功能模块进行人员分工 进行必要的测前技术培训编写测试计划，并进行项目内评审 编写测试脚本（用例） ，并进行开发参与的项目评审。 对有性能测试、负载测试及安全测试需求的，设计专门的测试方法和用例。3、 新版本转测试阶段 检测开发转测试的版本附属的文档是否全面
9、， 如果开发转测试文档齐全， 组织测试项目 组的成员遵照评审后的测试计划， 开始测试执行； 对发现的问题进行记录汇报； 对每个 版本发现的问题进行分析。即：检测转测试文档是否全面，并填写验收证明文档，其中应该包括： 系统设计（用户需求说明书） 需求分析报告 产品基线及说明文档 产品安装文件包 客户端、服务器、数据库安装、配置说明文件 单元测试报告及记录 集成测试报告及记录 注：以上非黑色字体文件为必须提供的文档，文档提供不全或开发拒绝协商，测试有权拒 绝该产品的测试。严格遵照测试计划和测试用例的测试执行问题记录和 BUG 报告当前版本的缺陷分析4、 修复版本巡回测试阶段测试接到修复后转测试新版
10、本， 检测对应的版本控制记录， 测试进行对应版本的回归测 试，完成相应的脚本测试， 并开始做随机测试和异常测试， 同时对发现的问题进行记录 汇报，对每个版本发现的问题进行分析。即：检测修复后转测试版本的版本控制记录完成上个版本在当前版本上的回归测试 严格遵照测试计划和测试用例的测试执行 增加多条件激发的随机测试 执行系统异常测试 问题记录和 BUG 汇报 当前版本的缺陷分析5、 验收测试 产品测试达到测试结束标准时， 停止测试， 对整个产品的缺陷进行分析； 组织相应的人 员进行验收测试，测试通过后，进行产品发布。衡定产品是否达到测试设计的结束标准对产品缺陷进行分析组织验收测试出验收测试报告22
11、 角色与职责1、 测试经理估算项目测试的工作量及时间进度与项目经理协调安排测试进度与测试人员，制定测试计划组织需求分析文档与设计文档的评审，提交评审结果组织测试案例的编写管理测试过程出具测试阶段报告、总结报告管理与归档各类测试文档2、 测试工程师根据项目需求及性质，决定测试过程所使用的测试技术、测试方法及测试工具搭建测试环境编写测试案例 编写测试程序根据测试案例进行测试并记录测试过程3、 测试员根据测试案例进行测试并记录测试过程4、 文档管理员准备文档环境汇总提交测试记录根据测试记录汇总并编排测试文档3 关键活动定义31 测试准备负责人 测试经理参与人 主要测试工程师活动形式 解读项目资料，与
12、主要开发人员交流目的 熟悉项目需求，了解项目设计思想、设计方法与设计方案；基本确定测试范围与测试方法输入 业务需求书、方案建议书、需求分析报告、系统总体设计输出 项目测试的范围与相应的测试方法过程 1、 项目经理或主要开发人员对相关测试人员进行简单的业务培训与技术培训，使之具备阅读项目资料所需的基本素质；2、 测试人员阅读项目资料， 必要时可以与主要开发人员进行短时交 流；3、 根据项目实际需求确定测试范围与测试方法。备注32测试方法设计负责人 测试经理参与人 测试工程师活动形式 根据测试需求，有针对的对测试任务进行具体的测试方法设计目的 让测试有效而简洁，尽量避免重复劳动，指导测试用例的编写
13、，从而提高效率输入 需求分析报告、系统概要设计文档输出 具体的测试方法如：临界值法、二分法、零值法、异常法等过程 1、 测试经理组织项目组成员对测试任务进行分析；2、 制定时宜的测试策略，3、 根据测试策略制定具体的测试方法备注33 测试计划负责人 测试经理参与人 测试工程师活动形式 规划测试过程；编写测试计划目的 根据项目进度要求与预算要求、测试估算值制定相对平衡的测试计划输入 需求分析报告、系统概要设计文档、测试估算值输出 测试计划过程 1、 熟悉系统需求和概要设计2、 结合测试资源，合理对测试行为进行规划安排3、 根据测试任务进行测试时间合理分配，制定好每个里程碑任务4、 产生指导整个测
14、试行为的测试计划备注34 计划评审负责人参与人活动形式目的输入输出过程4、多余无用内容测试经理项目主管高管、测试部经理、项目经理 阅读测试计划；召开评审会议；签字确认 相关部门、人员认可测试计划测试计划测试计划评审表1、 评审测试计划是否合理2、 审核测试内容是否全面3、 审核时间里程碑是否合理备注35 文档评审负责人 测试经理参与人 主要测试工程师活动形式 钻研文档、挑毛病；与设计人员探讨目的 在系统开始全面开发前找到系统设计中隐含的缺陷输入 需求分析报告、系统概要设计文档输出 文档评审记录过程 对测试相关的资源文档进行评审，找出并规避：1、 错误内容 2、误导内容 3、不可实现内容 备注3
15、6测试用例及评审负责人 参与人 活动形式 目的 输入 输出 过程测试经理测试工程师 钻研开发文档、编写测试案例；编写测试案例所需程序 完成测试过程所需测试案例的编写 需求分析报告、系统概要设计文档、测试计划 测试用例1、 对测试用例的正常功能区域的覆盖点进行评审2、 对测试用例的逻辑和结构进行评审3、 对用例中包含的异常覆盖进行评审4、 对激发条件的多重性进行评审备注37 环境准备负责人参与人测试工程师 开发工程师、系统工程师活动形式 与系统集成部人员一起进行环境安装；安装所需测试工具、测试程序目的 根据测试计划搭建测试环境输入 测试计划输出 搭建好的测试环境过程 按照测试条件协调各方资源，进
16、行测试环境搭建备注38 测试执行负责人 测试经理参与人 测试工程师、测试员、文档管理员活动形式 测试目的 按照计划与测试案例执行测试过程，寻找系统缺陷输入 测试计划、测试案例输出 测试问题记录过程 1、 建立满足测试条件的测试环境2、 根据测试用例进行测试执行3、 记录发现的缺陷并提交给测试经理确认备注39 缺陷汇报 /分析负责人 测试经理参与人 测试工程师活动形式 对版本发现的问题或者整个系统发现的问题进行汇报 /分析目的 发现产品缺陷的分布和提高产品开发质量，最大的降低维护成本输入 Clear quest 测试问题记录，版本资源文档，测试计划输出 缺陷分析报告过程 1、 对所有问题进行分类
17、、统计、分析2、 得出缺陷存在的周期曲线和分布功能区域图3、 周知项目组成员，督促提高开发质量备注310 回归测试负责人 测试经理参与人 问题发现测试工程师或项目组相关测试工程师活动形式 设定原问题发现条件，再次检测修复后的系统是否还存在该问题目的 验证问题的修复情况输入 测试案例，系统资源文档输出 回归测试记录， clear quest 中问题状态的改变过程 1、 建立原用例测试环境2、 进行验证测试执行，并记录对应的结果3、 修改问题单在 clear quest 中的状态备注311 随机 /异常测试负责人 测试经理参与人 项目相关的测试工程师活动形式 根据自己对系统的了解，设计随机测试用例
18、 目的 发现通过正常途径难以发现的隐藏问题输入 随机测试条件输出问题记录单过程1、自定义随机测试条件2、安条件进行测试执行3、 记录测试结果 备注312 阶段报告负责人 测试经理参与人 测试工程师活动形式 汇总分类测试数据；统计；根据缺陷分布找规律目的 统计分析测试记录；根据统计数据重新规划下一阶段测试计划输入 测试问题记录输出 测试阶段报告过程 1、 分析阶段测试结果，包括阶段目标的实现，阶段内的测试方法、测试发现的缺陷、测试策略等进行分析2、 得出阶段测试报告313 测试报告负责人参与人活动形式目的输入输出过程备注测试经理汇总分类测试数据；统计；根据缺陷分布找规律 统计分析测试记录；根据统
19、计数据评估软件质量与开发过程质量 测试问题记录、测试阶段报告测试总结报告1、 汇总测试数据2、 分类统计和分析这些数据，尽可能的找出其规律性3、 参考测试报告模板出测试报告备注4 测试文档简述41 开发转测试确认表开发产品名称是否具备提供者备注需求分析报告项目开发组系统设计说明书项目开发组产品安装配置说明书项目开发组单元测试报告项目开发组集成测试报告项目开发组产品基线说明配置管理组产品安装包项目开发组其它每个被测产品转到测试部，测试部需要检测产品配套的文档文件。其中包括：1、 需求分析报告2、 系统设计说明书3、 产品安装配置说明书4、 单元测试报告5、 集成测试报告6、 产品基线说明7、 产
20、品安装包 注：1、 不同的产品，提供的文件可能不同，有些文件有，有些文件没有，可以根据具体情况和 开发进行沟通，如果确实存在必备文档不能提供，测试可以考虑暂缓该产品的测试。2、 测试如果对得到的相关文档存在理解困难，需时和文档提供者保持联系，并及时解决。3、 提供的文档如果和系统本身功能存在大的差异，测试有必要和项目经理进行沟通确认。 必要时也可以考虑暂缓该产品的测试。4、 产品安装配置说明书在转测试时可以不提供，此时开发组必须辅助进行测试环境的 安装配置。5、 单元测试报告、集成测试报告在转测试时可以不提供，此时测试组应先进行产品的单元 测试、集成测试后才可以开始后续测试工作。42需求变更控
21、制文档在测试过程中， 开发对已经转测试产品的需求文档进行变更时， 必须进行变更控制记录， 并及时通知测试人员。具体需求变更控制文档模板请参阅开发过程。文档名称功能编号原内容变更为备注43 问题修复清单对开发修改后的每个转测试版本， 回归测试前开发组必须进行明确的说明， 记录对应的 服务器、数据库、客户端的修改情况和变化情况，从而避免测试的重复劳动，以便快速的回 归问题，发现因为修改而引入的其它问题，改变测试策略和方针，修复测试漏洞。版本问题号修改说明问题修改人44 测试计划 其中包括测试环境说明、测试时间安排、测试工作量估算、测试人员配置、测试方法、 测试的主要内容、测试风险及测试标准说明等。详见测试计划模版文档45测试脚本（用例）详见测试用例模板文档。4 6 问题报告该文档详细记录了 bug 的发现过程和 bug 的产生特征。 详见问题报告模板文档。47 缺陷分析文档 该文档是针对测试产品缺陷进行分析的一个文档， 主要分析缺陷产生的区域、 缺陷的类 型、缺陷引入的条件和触发者、缺陷的严重程度、缺陷的版本分布情况等，是对每个测试版 本的一个简单分析。48 测试报告文档 测试报告是对整个产品的测试情况进行分析的一份详实报告， 它从测试计划开始， 到测 试内容、测试结果、缺陷情况、版本缺陷情况等进行相关的统计汇报。
