软件测试流程管理规范

测试流程管理规范

（V02）

文件编号：BPTGLV02 文件类型： 受控状态： 文件版本：V02 发布日期： 总 页 数： 编制：李XX 审核： 批准： 日期: 2017-04-25 日期： 日期：

修订历史记录

日期 2017-04-25 2017-07-03

版本 V01 V02 作者 李XX 李XX 审核者 说明 初稿 修订

第 1 页 共 12 页

目 录

1.概要 ......................................................................... 3 1.1简要说明 ................................................................... 3 1.1.1项目管理的共性........................................................... .3 1.1.2测试简述................................................................. .3 1.1.3测试管理的特点 ........................................................... 4 1. 2 编写目的 .................................................................. 4 1.3适用范围 ................................................................... 4 2.测试团队构成 ................................................................. 5 2.1组织结构 ................................................................... 5 2.2职责划分 ................................................................... 5 2.3测试应参与及完成的工作 ..................................................... 6 3.测试过程 ..................................................................... 7 3.1测试流程 ................................................................... 7 3.2测试准备 ................................................................... 8 3.2.1文档说明 ................................................................. 8 3.2.2文档分析 ................................................................. 8 3.3测试计划 ................................................................... 8 3.4测试用例 ................................................................... 8 4测试执行 ..................................................................... 9 4.1测试申请（测试准入条件） ................................................... 9 4.2 项目测试阶段 ............................................................... 9 4.3缺陷管理 .................................................................. 10 4.3.1缺陷管理流程 ............................................................ 10 4.3.3提交缺陷 ................................................................ 10 4.3.4修改缺陷 ................................................................ 11 4.3.5关闭缺陷 ................................................................ 11 4.3.6保留缺陷 ................................................................ 11 5.测试结果分析 ................................................................ 11 6测试退出标准 ................................................................ 12 7约定规则 .................................................................... 12 8.结束语 ...................................................................... 12

第 2 页 共 12 页

1.概要 1.1简要说明

1.1.1.项目管理的共性：

1.1.2测试简述 1）测试概念：

➢ 测试是为了发现错误而执行操作的过程

➢ 测试是为了证明设计有错，而不是证明设计无错误 ➢ 一个好的测试用例是在于它能发现至今未发现的错误 ➢ 一个成功的测试是发现了“至今未发现的错误”的测试 2）测试目的：

测试的目的决定了如何去组织测试。如果测试的目的是为了尽可能多地找出错误，那么测试就应该直接针对设计比较复杂的部分或是以前出错比较多的位置。如果测试目的是为了给最终用户提供具有一定可信度的质量评价，那么测试就应该直接针对在实际应用中会经常用到的商业假设。故应综合评估产品测试的方向。 3）测试目标：-----产品的零缺陷

➢ 关注点：产品规格功能的实现，性能指标，可靠性，可测试性，易用性等。

➢ 实现的保障：产品的零缺陷构筑于最底层的设计，源于每一个函数、每一行代码、

每一部分单元电路及每一个电信号。测试就是要排除每一处故障和每一处隐患，从而构建一个零缺陷的产品。

MTBF不是计算出来的，而是设计出来的 4）测试意义：

第 3 页 共 12 页

➢ 测试并不仅仅是为了要找出错误。通过分析错误产生的原因和错误的分布特征，可

以帮助项目管理者发现当前设计过程的缺陷，以便改进。同时，这种分析也能帮助我们设计出有针对性地检测方法，改善测试的有效性。

➢ 没有发现错误的测试也是有价值的，完整的测试是评定测试质量的一种方法。 5）测试价值地位

——采购——研发——测试——生产——销售—— 测试是每项成功产品的必经环节

测试是评估产品质量的重要方法

产品质量是公司的信誉和品牌象征

公司的信誉和质量决定了公司的发展前景 1.1.3测试管理的特点：

产品质量标准不准确、任务边界模糊，如何确定何时进入测试何时结束测试，没有找出缺陷并不代表产品没有缺陷

项目或产品测试的变化控制和预警分析要求高 转测试的项目产品资料缺失或不完善

产品测试具有智力密集、劳动密集的特点，受人力资源影响最大，项目成员的结构、责任心、能力和稳定性对测试执行、产品质量影响很大

测试任务难分配

测试需求人力资源十分稳定，测试不仅是一份技术工作，而且要求对产品的功能、特性都需要非常了解。

测试人员可能在地位、待遇等方面受到一些不公平的对待

1.2编写目的

本文档是测试团队的日常工作规范，主要侧重测试工作流程的实施和控制，明确项目工程的各阶段测试应参与和完成的工作。并且对测试团队中测试架构、职能、成员职责进行必要的说明，通过建立规范的测试流程，测试团队架构，同时明确小组任务、目标、各小组成员的具体职责，对部门测试工作的正常展开起到规范指导作用，同时确保项目产品在保证质量前提下按时交付、降低开发测试管理成本、减少客诉，提升我司利润和形象。

1.3适用范围

本过程适用于测试过程中所有活动，即适用于参与项目的所有人员。

第 4 页 共 12 页

2.测试团队构成 2.1组织结构

2.2职责划分

角色名称 相关主要任务 规划、建立、维护测试管理流程 制定、改进和维护测试规范和标准 评审和批准产品测试计划，用例和报告 测试经理 指定测试组长，分配测试任务 同其它部门沟通协调，为测试提供内外部资源 掌握项目进度，对测试团队进行指导和监督 全权负责所分配的测试任务 小组内成员指派分配测试任务 协调组内相关工作 对组内成员进行工作上的指导监督 测试组长 代表测试组与其它角色组进行沟通 划分模块，分解任务，完成测试用例概要设计 参与测试计划制定，负责部分用例编写 实施测试用例，执行测试，提交测试记录 编写产品总结性测试报告 参与测试计划制定，负责部分用例编写 测试实施实施测试用例，执行测试，提交测试记录 工程师 提交测试日报、周报 检查跟踪缺陷处理情况及结果 注： 1.考虑到测试人手问题，原则上每个测试小组只负责单一项目，依 实际情况也会做调整负责一个以上项目，但各项目进度必须要错开 2.依据项目紧急情况，测试经理可临时从其它组或其它部门协调人员给予测试支持，保证项目测试顺利有序进行，正常展开。

第 5 页 共 12 页

2.3测试应参与及完成的工作

测试人员的主要职责是对项目及产品的整个开发过程进行监督和检验，使之能够达到满足客户的需求，因此对于企业来讲是十分重要的岗位。在国外，一般测试人员与产品开发人员的岗位设置比例是1：1，像微软在开发windows2000时候使用的软件开发人员是1700名，而专业的测试工程师有3200名，测试开发人员比例高到1.7：1，由此可见测试岗位重要性的不一般。

测试在一家企业中担当的是“质量管理”角色，及时发现产品问题并及时督促更正，确保产品的正常运作。测试是产品开发过程中的重要组成部分，肩负着如下责任：

1.参与项目的需求评审、概要设计、详细设计等阶段并对文档进行评估，从用户体验和测试的角度提出自己的看法。

2.编写测试计划，仔细阅读项目规格说明、设计文档、使用说明等，充分掌握产品的性能、特点、使用方法、业务流程等，制定项目的测试计划，保证产品测试工作的计划性与规范性，并与项目整体计划有机地整合在一起。

3.编写测试用例，按照测试流程、计划以及对产品特性的把握，沟通确认测试的范围、 重点，考虑逻辑、数据完整性等要求，详细规定测试的要求，策划、编写测试用例，设 计测试用数据及预期结果，做好测试前的准备工作。

4.搭建测试环境，保证测试环境的和维护测试环境的更新，做好测试前的准备工作， 确保测试环境的稳定和版本的正确。

5.测试执行，根据测试计划及测试用例有效执行测试，并根据产品特点及测试要求，实施系统测试、回归测试、验收测试等，及时发现产品缺陷，评估产品的特性与性能。

6.进行缺陷验证，准确地定位并跟踪问题，推动问题及时合理地解决，与开发、项目管理等部门反复沟通测试情况，督促解决问题，修正测试中发现的缺陷，完善产品功能。 7.进行测试日报、测试周报等相应文档编写与输出。

8.编写测试报告，对测试结果分析，通过测试，掌握产品具有的能力、缺陷、局限等， 对产品质量给出评价性的结论与意见，整理测试文档，填写产品测试报告,编写测试总 结，为产品开发和项目成果提供总结性意见。

9.归档项目资料、测试总结、测试经验与技术，分享经典缺陷。

10.对测试技术的研究，开发合适的测试工具或自动化解决方案，提高测试效率。 11.参与产品架构和代码的评审工作，并提出改进意见。

第 6 页 共 12 页

12.参与定制项目开发，包括但不限于：负责测试计划编写，测试用例设计，测试执行和报告，编写必要的测试工具等。

13.完成上级及部门其他领导交办的临时任务等。

3.测试过程

3.1测试流程及各阶段点输入输出的文件

参与需求分析，了解项目需求内容 收集项目资料 制定测试计划 编写测试用例 回归问题单 执行测试用例 提交bug，开发进行修改 修改补充测试用例 提交测试总结报告 第 7 页 共 12 页

3.2测试准备

3.2.1文档说明

项目产品设计完成需提交《需求文档》、《概要设计》、《详细设计》、《开发进度表》 开发文档

开发或项目管理人员提供给测试人员的开发文档至少包括以下几种：需求文档，概要设计，详细设计，用户手册，开发自测试等。 测试文档

测试文档包括测试计划、测试用例说明、测试日报，以及测试执行后的测试报告等。测试文档由测试人员编写并维护。

3.2.2文档分析

测试人员、开发人员以及项目管理人员均应参加需求评审、设计评审。对《需求说明书》、《硬件设计说明书》和《软件设计说明书》等进行阅读和审查，与产品经理、项目经理、测试经理沟通，根据系统功能复杂度，系统业务复杂度估算开发时间和有效测试执行时间，为项目总计划和测试计划的制定提供参考和依据。

通过对文档分析，分解各功能模块，各功能点，为测试用例设计提供数据依据。

3.3测试计划

根据需求文档和项目计划制定测试计划。测试计划旨在说明各测试阶段任务、人员分配、时间安排、测试要点、测试环境、测试工具、工作规范等。测试计划在策略和方法方面说明如何计划、组织和管理测试项目。测试计划完成后需在组内进行评审。

3.4测试用例

测试用例是为实施测试而向被测试系统提供的输入数据、操作或各种环境设置以及期望结果的一个特定的集合。解决要测什么、怎么测和如何衡量的问题。

依据用户需求分析说明书、概要设计文档和开发详细设计说明书来设计测试用例，发现需求与设计中的问题后，与需求作者及时沟通确认。 3.4.1测试用例设计方法

设计测试用例可以基于以下方法设计：等价类测试、边界值分析、基于判定表的测试、基于因果图的测试、基于状态图的测试、基于场景的测试，并结合项目需求、周期、成本、测试类型方法以及测试资源合理制定。

第 8 页 共 12 页

3.4.2测试用例维护更新

1、 设计用例采用公司统一模板，严格按照用例模板进行设计及后期维护

2、 在测试期间，发现用例描述不清，或需求变更，或用例设计有误，及时在统一的文

档中记录。待本轮测试结束后，更新基线用例。

4测试执行

4.1测试申请（测试准入条件）

开发或PM向测试负责人（TM或TL）提交《测试申请表》或规范的转测邮件并附上各类交付件（需求，特性，参数，开发自测报告等），并给出适当的测试建议（如：说明应测特性，和暂不测试特性，重点测试哪些，需要注意什么，测试环境要求，最新变更后的计划周期等）

4.2 项目测试阶段

测试人员依据测试计划和测试用例进行测试活动。 测试一般分为两个阶段及多轮次

1、 测试执行阶段：该阶段测试人员测试出bug后将缺陷提交至缺陷管理库。 2、 测试跟踪阶段：测试的问题缺陷需持续跟踪直至解决。 3、 回归问题单：开发修改完bug之后，测试进行验证回归。

第 9 页 共 12 页

4.3缺陷管理

4.3.1缺陷管理流程

4.3.2 缺陷等级说明

1）A类：致命缺陷，最严重的等级，缺陷会导致产品的任何一个主要功能完全丧失，用户需求没实现，设计严重性错误，产品使用中造成事故等。

2）B类：严重缺陷，产品的主要功能部分丧失、产品的次要功能完全丧失，产品所提供的服务和功能受到明显的影响。

3）C类：一般缺陷，产品的次要功能没有完全实现，但不影响用户主要功能的正常使用。

4）D类：提示缺陷，使用的友好性有影响，外观结构布局稍不合理，在使用体验过程中给用户带来一定的不方便和操作难度。

4.3.3提交缺陷

一般测试到问题要记录好结果，对比数据，拍照或视频保留凭证并随问题描述一起上传到缺陷管理系统。

第 10 页 共 12 页

针对概率性问题要多次反复模拟测试（如测试10次出现几次）。

对不确定是否为问题的可与其它产品对比测试或请教资深测试人员、开发人员等。 针对以前没遇到过的新问题或不易复现的问题需要保留问题现场让开发或项目管理人员看一下，确认分析问题。

测试人员将缺陷填写到缺陷管理库，提单要规范，要写清楚问题标题、问题分类、操作步骤、预期结果、实际结果、并附上测试数据，对不好描述或发生概率性较小的问题可拍视频及截图，将缺陷指派给对应项目的PM， 了解问题后PM会再指派给对应的开发人员分析解决。

开发人员分别对自己收到的缺陷进行核对后，如果对提交的缺陷有疑问，可以与提交人确认。如果缺陷初次分配的开发人员无法修改该缺陷，初次分配的开发人员可以将缺陷再次分配给其他开发人员。

如果开发对测试提出的bug不理解或者不能重现时，可以要求测试复现bug。

4.3.4修改缺陷

开发人员对已确认的缺陷进行修改，填写修改记录，修改缺陷状态为“已修改”或其他状态。修改完后开发应对修改后会影响的其他功能模块做个说明，还需对缺陷产生的原因和解决方法做个备注，以便日后追溯。

经开会讨论认为该缺陷可以不予修改或者不是缺陷的，开发可与测试人员协商后将状态改为“已否决”或由测试人员直接关闭缺陷并要注明原因。

4.3.5关闭缺陷

测试人员对已修改的缺陷进行验证。如果已修改完成，测试人员将缺陷状态设置为关闭。如果没有修改或引起回归问题，将修改缺陷状态为“激活”或新增缺陷，由开发人员继续修改。

4.3.6保留缺陷

对于有争议的缺陷进行开会讨论最终决定是否修改。如果缺陷是由于技术原因、版本原因等不能修改，则保留该缺陷下次解决并加以注释（根因分析、影响分析、目前避规措施）。

5.测试结果分析

测试结果分析是对测试结果的一个综合评估，主要描述有测试中各个等级的缺陷数量，缺陷分布情况，缺陷修改情况、回归测试提交缺陷数量、缺陷的趋势等情况。

第 11 页 共 12 页

输出项目总结、经验总结、bug分享、测试日报、测试报告。

测试日报、测试报告由测试人员编写并提交给项目各成员。测试报告需要经项目组评审。

6测试退出标准

（1） 功能、性能需求覆盖100%；1、2级用例执行率100%，3、4级用例执行率80%以上； （2）测试结果中所有A级、B级的问题都已经解决，同时90%的C级问题已经解决

（3）缺陷的趋势是收敛的，缺陷率达到测试质量标准且遗留问题符合公司定义的质量标准

7约定规则

（1）没有收到《测试申请表》或《转测邮件及相关交付件》，原则上不给予测试。

（2）功能执行关键测试用例不能通过，需求没有实现，问题回归不通过，则测试人员有权

利中止测试。待开发修改完并自测确定无阻塞性问题后再提交测试。

（3）开发人员做的任何产品上的改动（非针对明确写出的BUG时）需明确注明并及时知会

到相关人员。

（4）开发人员有责任和义务及时解答测试人员提出的相关问题及疑惑。

（5）开发人员对指定的问题修复后需写清根因分析，对未修复的问题还要写上影响分析、

避规措施等，并写明下次修改计划。 （6）开发有责任和义务定期给测试人员讲解培训相关知识 。

8.结束语

测试的价值就在于我们的专业,在我们每一份专业的产出文档，每一句专业的话语或建议，每一次专业的测试，专业才能产生价值，专业才能赢得别人的尊重，专业才能生存。大家看电视或电影时那些律师，或者飞行员为什么显的那么帅气，因为他们专业。所以作为一个测试人员要不断提高的自己的专业度，各种的测试理论啊，专业的技能啊，利用工作或业余的时间学习，学习再学习，即能在工作中切实指导自己的工作，也能充实自己，更能在交流的时候甩出些深奥的专业名词把别人震撼的一愣一愣的，然后看着别人崇拜或迷惘眼神，作无可奈何状。

另外很重要的是，当有了矛盾出现的时候，测试人员一定要坚持自己的立场和原则，要据理力争，不能动摇。测试有时候是最容易被牺牲掉的角色，为了赶项目进度，会很容易砍掉测试的时间，甚至在测试还没完成的时候就因为市场或者其他的原因逼着一定要出货，这时候是对测试人员的考验，这时候也是我们吵架的时候到了，老虎不发威，你就以为是hello kitty啊， 不要害怕吵架，不要害怕矛盾，该争的就争，该和上一层的领导同志反馈的直接反馈，坚持自己的专业原则不动摇，一味的好商量是没有任何意义的，真的出了问题后该负责的还是你自己。当然了也不要太楞了，如果真的是公司的决策，那就服从，但一定要把该提的问题提出来。

第 12 页 共 12 页