测试管理制度.docx

测试管理制度.docx

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

测试管理制度

测试管理制度

前言

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

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

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

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

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

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

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

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

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

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

同时对项目的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遗留