测试管理制度.docx

测试管理制度.docx

《测试管理制度.docx》由会员分享，可在线阅读，更多相关《测试管理制度.docx（28页珍藏版）》请在冰豆网上搜索。

测试管理制度

测试管理制度

前言

本制度为北京首航财务管理顾问有限公司内部使用的测试管理制度，仅用于公司内部使用禁止外传。

本管理制度适用于测试组新员工入职培训和测试组全体员工日常工作的执行标准，是测试流程执行工作的统一标准规范。

达到对工作效率的掌控和监督的作用，同时也可以规范各部门的交互合作流程，从而有效保证职、责、权的分明。

所有项目执行过程中，项目经理和开发人员要发送邮件申请测试文档，未申请的文档不予提供。

所有的项目邮件将作为工作中的重要信息保存至项目封档。

测试组的每位成员有责任和义务履行所有的测试流程，也有责任保护测试流程和测试文档申请流程。

每位员工可以根据项目的个性需要对测试流程进行适当的调整，但是必须保证测试标准严格执行，以保证项目的测试质量。

测试人员要在项目中经常联系需求和开发人员，所以，要注意礼貌和标准用语的使用。

邮箱使用统一的签名，日常交流中注意着装、商务礼貌用语和职场礼仪，直接接触客户时谈及的内容以工作为主，不得泄漏公司机密、损害公司形象，注意体现技术服务的专业水准。

每位测试人员负责的项目都要及时撰写测试计划，筛选测试用例等相关文档，根据测试情况及时将缺陷录入缺陷管理系统，指派给指定的研发人员。

同时对项目的BUG周期进行跟踪管理。

定期整理项目的缺陷比例等数据进行上报，对有价值的数据自动进行存档，并更新文档库和用例库。

所有文档规范模板见模板库。

所有申请表以WORD格式上传到SVN，每个项目的参与测试人员每天需要及时确认需求是否有更新。

对更新的需求部分需要调整测试用例。

目的 

 统一公司所有项目的软件测试标准流程； 

 提供一套适合公司所有项目的软件测试流程;

规范统一的项目测试执行标准；

 范围 

 本规范适用于测试所有的JAVA开发的B/S架构内部使用的系统软件项目； 

 本规范中集成测试、系统测试和性能测试适用于所有项目；

测试计划、用例、测试报告、缺陷报告等模板参见模板库；

第一章项目文档和用例管理

（一）项目文档

1、项目立项默认提供《测试计划》、《测试用例》、《测试过程管理文档》、《验收报告》和《测试报告》五个文档，默认提交功能测试报告，有性能测试的需求需要在申请测试文档时注明。

性能测试可提供《性能测试计划》、《性能测试用例》、《性能测试报告》；

2、如还需提供其他文档请在《测试文档申请表》详细写明，然后发送电子邮件到指定测试人员邮箱并抄送给测试组长，项目交付文档以申请邮件填写的申请表内容为准；

3、项目测试期间所有与客户和研发人员的往来邮件都要抄送给直属上级领导；

4、每个项目结束要写总结文档要对项目的缺陷数量和比例进行统计，分析BUG产生原因，提出改进建议，统计不同BUG所占比例，整理成图表文档发送给上级领导；

5、每个季度编写项目总结文档，对项目的缺陷数量和比例进行统计，分析BUG产生原因，统计不同BUG所占比例，整理成图表存档并向上级领导提交报告；

（二）项目用例

1、所有项目均可以根据项目实际需求在《通用用例库》选择相应的用例执行测试，需要写补充用例的要及时编写并录入《通用用例库》。

需求不完善的首先跟客户确认需求、帮客户设计需求，根据客户需求制定执行标准。

必要时，根据行业通用标准、公司惯例完成测试工作；

2、所有用例需要100%执行通过后才算通过；

3、在项目中遇到新的测试用例要及时录入《通用用例库》以保证用例库的更新和完善。

所有的项目邮件将作为工作中的重要信息保存直至项目留存封挡之后。

删除旧数据时需要发送邮件请示上级领导，得到许可后方可进行删除；

4、项目结束整理项目的各项数据并按季度和年度提交上级领导；

（三）测试文档申请和交付标准流程

1、项目需求自交付之日起3个工作日内提交《测试文档申请表》，该表可以在项目中期追加测试文档申请，项目起始时间和申请的相关文档以申请表为准。

其他形式的追加文档一律安排到所有项目的测试工作完成之后提供；

2、项目工期提前或延期需提前2周填写《项目延期通知单》（表3）或《项目工期提前通知单》（表4）。

经测试人员回复邮件确认项目文档交付的日期，如提交超过一次则按项目负责人最近一次提交的申请单的日期为准。

同时研发部项目组长需要给测试文档的交付预留至少1周的时间；

3、项目进行中客户对需求的修改文档都要第一时间上传到版本管理器SVN，并告知更新文档相关的研发人员，以提高工作效率。

需求修改时需要填写“需求修改确认单”（表5）

4、需要做性能测试的项目，需提前确认性能测试需求，需填写性能测试申请单，并确认测试时间和地点，需提前5个工作日确认；

5、确认时间少于5个工作日的一律自行调整项目交接时间，给测试工作和测试文档撰写争取时间；

6、如在项目后期需要追加测试文档，需提前10个工作日提交申请表，无申请表一律不予提供；

7、需要外派测试的需要提前2个工作日申请，申请邮件中需注明工作地点、乘车路线信息、外派公司接待人联系方式、外派工位申请、协商好外派公司的行政管理部等相关部门，为外派的同事处理好工作衔接；

8、测试文档已邮件形式发送，每次都要抄送给上级领导和指定关联人；

第二章测试执行流程及标准

一、测试执行标准流程

（一）角色与职责

1、角色与职责

角色

职责

项目经理

协调软件、硬件、人力资源、风险控制、项目进度和质量等；

测试经理

管理测试相关资源、分配测试工作、风险控制等，对测试工作进度把握和质量监督。

协调客户需求和开发人员的合作；

测试组长

制定测试计划、 编写测试用例、执行测试、提交缺陷、回归测试、 编写测试分析报告、性能测试计划、性能测试用例、性能测试报告、项目总结；

测试工程师

协助测试组长的工作、对负责的模块用例进行筛选、确认BUG并提交至缺陷管理系统、指派对应的开发人员修复；

测试员

执行负责模块的测试用例，提交缺陷至缺陷管理系统；

开发人员

修改缺陷、开发人员修改完缺陷后由测试人员进行回归测试，测试通过则“关闭”缺陷，检验未通过，则转给开发人员，继续修改； 

提交缺陷修改程序代码；提供必要的测试数据；

配置管理人员

管理测试需要的资源，包括软硬件环境，版本管理和缺陷跟踪管理。

建立代码基线，配合进行配置检查；

2、测试范围（根据项目实际选择完成测试类型）

系统集成后的功能性测试；  

系统集成后的容错性测试；  

系统集成后的界面测试；        

系统集成后的常用控件测试；  

系统集成后的接口测试；  

系统集成后的可用性测试；  

系统集成后的完整性测试；

系统集成后的压力测试；

系统集成后的安全性测试；

3、进入测试条件

《项目概要设计》通过评审；

单元测试通过；

冒烟测试通过；

4、退出条件

缺陷基本修复完毕、系统稳定；

《测试报告》评审通过；

项目上线，代码基线化；

线上测试通过；

二、测试的准备工作

（1）测试人员在项目的需求阶段开始介入，首先仔细阅读需求文档，然后跟研发人员一同接受需求的业务培训，参与需求评审、数据库评审，从而更全面精准的了解业务流程，针对项目周期安排进行测试工作的计划；

（2）在“需求分析”期间着手编写《测试计划》，直到“概要设计”、“详细设计”阶段，将测试计划有效的编写完成。

同时也筛选用例，将项目用例单独整理成文当。

对需要设计补充用例的模块进行设计；

（3）在软件的“代码编写”期间，完成《测试用例》的编写。

测试计划的时间规划和工作安排要与项目的整体进度吻合。

（4）安排的测试人员要与技术等级、工作量匹配，保证有效的工作进度，必要时采取加班方式增加工作量，为项目完成降低可预见的更多风险；

（5）监测需求的变化及时调整测试用例；

（6）性能测试指标及方案需要在项目撰写测试计划时预估性能测试工作量并预先安排工作时间，根据项目实际情况和客户需求制定性能测试计划和测试指标，编写性能测试报告；

三、测试执行进程

（一）需求

（1）参加立项会议，查看需求文档，接受业务培训详细了解业务流程。

我们是外包公司为客户提供服务为主营业务。

在接受客户指定项目负责人提供的（以下简称客户）直接的需求文档，由研发部项目负责人先接受需求培训，然后组织相项目经理、研发经理、人员、开发人员、环境管理人员、测试人员和其他相关人员进需求评审，确保达成一致意见。

对系统连接测试需求分析和集成测试需求分析进行评定，确保系统连接测试需求和系统集成测试需求通过评审。

对于内部测试需求分析中导出的内部测试需求，应由研发中心测试组组织相关业务人员、开发项目组进行评审，执行统一标准，形成合作默契。

所有评审文档确认后都要上传到SVN；

在整个项目研发过程中与客户进行需求变更的细节沟通，项目结束后也要随时帮助客户解决项目问题，体现人和创建员工的高素质、高服务意识，维护公司的良好形象。

另一种是第三方提供需求，除了等同客户需求的工作之外，要特别注意：

第三方对需求的确认状态和修改次数。

不能简单的、一味的、直接接受第三方的想法，必要时要求对方立即与客户确认，做好需求的修改记录。

在修改需求时与第三方的文件传输要每次都抄送上级和相关负责人，邮件正文中注明邮件目的、传输文档数据属性和发送原因。

所有评审文档确认后都要上传到SVN；

（2）单元测试

开发人员完成代码编写后首先进行单元测试。

其中，编写《单元测试计划》，设计单元测试用例、执行单元测试过程、记录单元测试缺陷、编写《单元测试报告》等工作由白盒测试人员完成。

根据项目组具体情况安排，目前本部开发人员自行完成单元测试，而且不提供任何相关文档给测试人员。

（二）功能测试和性能测试指标

（1）新项目的首次功能测试是从“冒烟测试”开始。

新项目交接到测试部，首先进行“冒烟测试”通过后进行功能测试，如测试结果为：

“不通过”将不予测试，打回重做。

冒烟测试合格的项目基本的功能测试可以使用完整的流程，比如正常使用会员管理系统，可以进行会员注册、登录、会员信息修改、退出、管理员查询、统计、冻结/删除和修改会员信息等基本功能。

期间没有异常退出系统、挂机、报黄页、安装和卸载无异常等主要功能流程可以正常实现。

也就是，被测试程序能完整实现基本功能的流程，软件基本功能正常，可以进行后续的正式测试工作。

即为冒烟测试通过，反之则没有通过，不予测试，退回开发项目组负责人。

升级版的项目也需要进行冒烟测试，在Web测试和负载测试中，冒烟测试时间短，工作量也小。

使用冒烟测试是为了在运行功能测试或压力测试之前，确保一切都已配置正确并可按预期运行。

（2）冒烟测试用例选择标准 

 1）新功能版本发布 

 测试人员接到新版本后首先需要对新功能进行冒烟测试。

冒烟测试主要验证所提交的功能重点模块是否按需求开发完、是否进入测试阶段、是否可以按照正常测试用例执行测试。

选择主要功能的正常用例做为冒烟测试执行的用例，一般选择《测试用例》中优先级别低的用例；

2）含有旧的BUG未修复的新功能版本

 新功能开发完成后，如果依赖于某个功能模块且该功能模块中存在未修正的BUG，则不接受新版本部署测试。

选择新功能正常测试用例和优先级为“高”级别以上，并且已经修复的BUG做为冒烟测试执行的用例。

 项目组成员可以用分配好的用户名和密码登录缺陷管理系统实时查看缺陷情况。

3）BUG 修正版本发布 

 选择优先级为“高”级别以上，并且已经修复的BUG，以及主要功能的正常测试用例做为冒烟测试执行的用例。

 项目组成员可以用分配好的用户名和密码登录缺陷管理系统实时查看缺陷情况。

（2）功能测试

冒烟测试合格可以进行功能测试。

项目可以正常运行完整的流程，而且系统没有A级缺陷，并且能达到系统功能完整度总通过率不低于80%，回归测试BUG遗留不超过40%，才可以进行下一轮测试。

否则交由研发部将缺陷修复后重新进行测试。

第二轮测试，系统没有A级、B级和C级缺陷，并且用例通过率不低于90%，回归测试BUG遗留不超过30%，可以进行第三轮测试。

第三轮测试，系统没有D级以上缺陷，同时用例通过率达到100%，回归测试BUG遗留不超过3%。

集成回归测试时，如回归测试全部通过，该项目测试通过，出具测试报告。

此时可以着手开展性能测试的工作。

首先要达到的普遍标准：

1、通过冒烟测试后的项目才可以确认开始功能测试；

2、确认兼容的系统、浏览器版本和环境等信息；

3、准备测试机，搭建测试环境，保证环境正常有效；

4、测试页面上的：

静态页面、动态获取、色差、像素值、图标、图片、文字、符号、背景、链接、留白等是否兼容；

5、将测试结果及时录入缺陷管理系统，完成缺陷分配信息；

6、完成缺陷分类、图文并茂的直观描述BUG，使用语言简洁准确，内容较复杂时使用排序方式描述，如1，2，3...；

7、测试JS脚本和其他插件是否对系统和环境兼容，基本的弹出窗口是否正常，记录同上；

8、及时查看缺陷信息，对已经修复的缺陷及时回归，完成集成回归测试；

9、界面测试：

多窗体、单窗体以及资源管理器风格；

其次，参考测试标准文档：

1、《界面测试执行标准》；

2、《常用基本控件测试用例》；

3、《通用用例库》

4、《测试方案》

5、《测试计划》

6、《测试评审表》

7、《缺陷报告》

8、《缺陷统计》

9、《测试过程管理》

10、《测试报告》

11、《验收报告》

12、《项目操作手册》

13、《性能测试需求申请单》

14、《性能测试用例》

15、《性能测试报告》

（3）软件性能测试中的性能指标和实施方法　

各种软件在系统实施过程中，需要满足客户的一些特殊要求。

如果软件系统没有经过测试和优化，软件系统将无法满足用户的需求，还会给软件在实际应用中带来很大的风险。

性能测试是整个软件测试中一个重要方面，能测试软件的稳定性和承受较大数据量时系统的运行能力。

性能测试目的是验证软件系统是否能够达到用户提出的性能指标，同时发现软件系统中存在的性能瓶颈，优化软件，最后起到优化系统的目的。

性能测试工程师技能要求：

Ø熟悉软件测试基本理论；

Ø掌握软件测试常用方法；

Ø熟悉一门编程语言； 

Ø熟悉一种数据库管理系统； 

Ø熟悉Web服务器，如IIS、Apache等；  

Ø熟悉常见网络协议，如Http；  

Ø掌握性能测试理论； 

Ø熟练使用一种性能测试工具；

Ø实际工作中需要的其他技能（性能调优除外）；

包括以下几个方面：

1、评估系统的能力，测试中得到的负荷和响应时间数据可以被用于验证所计划的模型的能力，并帮助作出决策。

2、识别体系中的弱点：

受控的负荷可以被增加到一个极端的水平，并突破它，从而修复体系的瓶颈或薄弱的地方。

3、系统调优：

重复运行测试，验证调整系统的活动得到了预期的结果，从而改进性能。

检测软件中的问题：

长时间的测试执行可导致程序发生由于内存泄露引起的失败，揭示程序中的隐含的问题或冲突。

4、验证稳定性、可靠性：

在一个生产负荷下执行测试一定的时间是评估系统稳定性和可靠性是否满足要求的唯一方法。

定义：

性能测试类型包括负载测试，强度测试，容量测试等。

负载测试：

负载测试是一种性能测试指数据在超负荷环境中运行，程序是否能够承担。

强度测试：

强度测试是一种性能测试，他在系统资源特别低的情况下软件系统运行情况。

容量测试：

确定系统可处理同时在线的最大用户数

观察指标：

　性能测试主要是通过自动化测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。

负载测试和压力测试都属于性能测试，两者可以结合进行。

通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。

压力测试是通过确定一个系统的瓶颈或者不能接收的性能点来获得系统能提供的最大服务级别的测试。

软件方面 

 1、响应时间 

 反映系统处理效率指标 

 响应时间是从开始到完成某项工作所需时间的度量。

在客户/服务器环境中，通常是从客户方测量响应时间。

响应时间通常随负载的增加而增加。

 2、吞吐量 

 反映系统处理能力指标 

 吞吐量是单位时间内完成工作的度量，在客户/服务器环境中通常是从服务器方进行评估。

随着负载的增加，吞吐量往往增长到一个峰值后，然后下降，队列变长。

在如客户/服务器这样的端到端系统中，吞吐量依赖于每个部件的运行。

系统中最慢的点决定了整个系统的吞吐率。

通常称此慢点为瓶颈。

3、日访问量 

常用页面最大并发数：

分为广义并发和狭义并发，没有特定标明一般指广义并发。

可以通俗理解为，在同一个时间点有一批用户在使用某一功能。

当然，同时也有另外一批用户在使用其他功能。

同时在线人数：

在某一时间段有登录操作的用户，有上传、下载、支付款项、页面浏览等的所有用户人数。

也可以按照session的个数来决定。

响应时间：

从发出请求到服务器响应返回到请求页面的时间。

4、资源利用：

率反映系统能耗指标

5、创建测试场景、执行场景，根据“测试脚本”，得到“测试脚本运行结果”。

测试实施人员根据“测试脚本运行结果”，写出《性能测试报告》。

第三章缺陷级别和缺陷状态定义

（一）缺陷级别定义

A级

不能完全满足系统要求，基本功能未完全实现；或者危及人身安全。

系统崩溃或挂起等导致系统不能继续运行。

 包括以下各种错误：

1.由于程序所引起的死机,非法退出 

2.死循环 

3.数据库发生死锁 

4.因错误操作导致的程序中断 

5.重大功能错误 

6.与数据库连接错误 

7.数据通讯错误

B级

严重地影响系统要求或基本功能的实现，且没有更正办法（重新安装或重新启动该软件不属于更正办法）。

使系统不稳定、或破坏数据、或产生错误结果，或部分功能无法执行，而且是常规操作中经常发生或非常规操作中不可避免的主要问题。

 包括以下各种错误：

1.程序接口错误 

2.因错误操作迫使程序中断

3. 系统可被执行，但操作功能无法执行（含指令） 

4. 单项操作功能可被执行，但在此功能中某些功能（含指令参数的使用）无法被执行（对系统非致命的） 

5. 在功能项的某些项目（选项）使用无效（对系统非致命的） 6.业务流程不正确 

7.功能实现不完整，如删除时没有考虑数据关联 

8.功能的实现不正确，如在系统实现的界面上，一些可接受输入的控件点击后无作用；对数据库的操作不能正确实现 

9. 报表格式以及打印内容错误（行列不完整，数据显示不在所对应的行列等导致数据显示结果不正确的错误）

C级

严重地影响系统要求或基本功能的实现，但存在合理的更正办法（重新安装或重新启动该软件不属于更正办法）。

系统性能或响应时间变慢、产生错误的中间结果但不影响最终结果等影响有限的问题。

 包括以下各种错误：

1.操作界面错误（包括数据窗口内列名定义、含义是否一致） 

2.打印内容、格式错误（只影响报表的格式或外观，不影响数据显示结果的错误） 

3.简单的输入限制未放在前台进行控制 

4.删除操作未给出提示 

5.虽然正确性不受影响，但系统性能和响应时间受到影响 

6.不能定位焦点或定位有误，影响功能实现 

7. 显示不正确但输出正确 

8. 增删改查功能，在本界面不能实现，但在另一界面可以补充实现。

D级

使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。

界面拼写错误或用户使用不方便等小问题或需要完善的问题。

包括以下各种错误：

1.界面不规范

2.辅助说明描述不清楚

3.输入输出不规范

4.长时间操作未给用户提示 

5.提示窗口文字未采用行业术语 

6.可输入区域和只读区域没有明显的区分标志

7.必填项与非必填项应加以区别 

8.滚动条无效 

9.键盘支持不好，如在可输入多行的字段中，不支持回车换行；或对相同字 段，在不同界面支持不同的快捷方式 

10.界面不能及时刷新，影响功能实现。

E级

测试过程中站在用户角度提出一些易用性，人性化等更利于系统优化的建议。

1. 光标跳转设置不好，鼠标（光标）定位错误

2.  一些建议性问题。

（二）缺陷状态定义

OK：

测试结果无差异

NOK：

测试结果大部分正确

NG：

测试结果有较大的错误

NT：

由于各种原因本次无法测试

redmine缺陷状态：

新建：

新发现的BUG等待解决；

进行中：

正在修复中；

已解决：

已经修改过的BUG等待返测；

反馈:

经开发人员、需求人员和测试人员等一致同意不需要修复的BUG；

已关闭：

由于各种原因不再需要进行任何操作的BUG；

重新打开：

根据实际情况需要，将修复过的BUG再次打开，重新进行修改和测试；

复测通过：

开发修改后经测试人员测试通过；

已投产：

已经更新到生产环境，即：

已上线；

（三）BUG处理原则

当变更BUG状态时，开发、测试人员需要确认bug表单。

（1）测试人员处理原则 

 提交BUG后主动与开发人员沟通，需要以办公管理软件、即时通讯工具或邮件通知BUG； 

 BUG描述需要尽量做到清晰、易懂，对于可以重现的BUG开发人员能够按照描述步骤重

现BUG；

测试执行中发现BUG直接写入缺陷管理系统的BUG列表中，描述BUG时要将BUG发现步骤描述清楚，还需提供测试数据、系统日志、截图等有助于开发人员分析、解决BUG的相关数据； 

填报BUG或者转给他人BUG是否需要Email通知根据不同项目决定，但是所有转给产品人员的BUG均需要同步发送Email通知，并保留发送记录以备日后查询； 

（2）开发人员处理原则 

1. 开发人员去除一个BUG，必须修改缺陷管理系统中的缺陷状态，方便进行回归测试； 

2. 对于标记为“可重现”的BUG，开发人员必须按BUG描述步骤自己重现BUG，必要时请测试人员配合重现；

3. 开发、测试人员将一个BUG转给他人之，必须发邮件给接受人和测试人员进行说明，接受人回复同意交接才可继续；

4. Bug的优先级别遵循测试人员的设定； 

5. 任何BUG都不应该被删除，但可以被置为“拒绝修改”或“关闭”； 

6. 开发人员修复一个BUG后需要在缺陷报告中详细描述BUG产生的原因及修复的文件；

（3）无效BUG定义 

1. 产品定义不明确：

如删除了某会员后该会员登录系统后是什么状态没有定义，而由此产生的BUG则可以选择此项； 

2.产品遗留的BUG：

如某个项目的升级版本出现BUG，经查是原版本已知的BUG； 

3.测试人员误操作：

包括但不限于：

测试人员需求理解错误、测试环境中毒、测试人员技较差、测试人员重复提交已经存在的BUG等引起的BUG；

4.需求在报BUG之后发生了变化导致BUG无效；

（4） BUG产生原因定义 

1.产品定义不明确，对操作的逻辑定义不完善；

产品原有BUG，如：

某个项目的升级版本出现BUG，经查是原版本已知的BUG则可以选

择此项；

2.粗心大意、单元测试不足、对程序设计语言不熟悉、软件设计缺陷、未遵从编码规范、需求理解错误、业务知识缺乏 ；

3.由其他BUG引起，如：

调用了一段代码，该段代码存在BUG，则选择此项） 

4.相关系统不兼容引起的BUG；

5.无效BUG，如：

由于测试人员操作有误或者由于测试环境出现问题产生的BUG，则选择

测试退出准则 

（5） 新产品测试退出准则 

1. 所有功能均符合用户需求并已经通过确认； 

2. BUG趋势出现明显收敛状态达到两个版本以上。

明显收敛的定义：

当前测试版本发现的BUG占此项目总BUG数的0%—3%，根据项目规模大小不同可以在这个范围内选择，但最大不能超过3%； 

3. 测试退出前完成一次执行全部测试用例的回归测试。

对优先级别为“高”BUG回归； 

4. 测试退出前一个版本的测试定为“稳定期”，在此期间无优先级别为A级、B级的BUG存在； 

5.测