测试管理新规制度.docx

测试管理制度

序言
本制度为北京首航财务管理顾问内部使用测试管理制度，仅用于企业内部使用严禁外传。本管理制度适适用于测试组新职员入职培训和测试组全体职员日常工作实施标准，是测试步骤实施工作统一标准规范。达成对工作效率掌控和监督作用，同时也能够规范各部门交互合作步骤，从而有效确保职、责、权分明。全部项目实施过程中，项目经理和开发人员要发送邮件申请测试文档，未申请文档不予提供。全部项目邮件将作为工作中关键信息保留至项目封档。

测试组每位组员有责任和义务推行全部测试步骤，也有责任保护测试步骤和测试文档申请步骤。每位职员能够依据项目标个性需要对测试步骤进行合适调整，不过必需确保测试标准严格实施，以确保项目标测试质量。测试人员要在项目中常常联络需求和开发人员，所以，要注意礼貌和标准用语使用。邮箱使用统一署名，日常交流中注意着装、商务礼貌用语和职场礼仪，直接接触用户时谈及内容以工作为主，不得泄漏企业机密、损害企业形象，注意表现技术服务专业水准。

每位测试人员负责项目全部要立即撰写测试计划，筛选测试用例等相关文档，依据测试情况立即将缺点录入缺点管理系统，指派给指定研发人员。同时对项目标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、 测试范围（依据项目实际选择完成测试类型）
系统集成后功效性测试； l 
系统集成后容错性测试； l 
系统集成后界面测试；       l 
系统集成后常见控件测试； l 
系统集成后接口测试； l 
系统集成后可用性测试； l 
系统集成后完整性测试；
系统集成后压力测试；
系统集成后安全性测试；

3、 进入测试条件
《项目概要设计》经过评审；
单元测试经过；
冒烟测试经过；

4、 退出条件
缺点基础修复完成、系统稳定；
《测试汇报》评审经过；
项目上线，代码基线化；
线上测试经过；

二、测试准备工作
（1）测试人员在项目标需求阶段开始介入，首先仔细阅读需求文档，然后跟研发人员一同接收需求业务培训，参与需求评审、数据库评审，从而更全方面正确了解业务步骤，针对项目周期安排进行测试工作计划；
（2）在“需求分析”期间着手编写《测试计划》，直到“概要设计”、“具体设计”阶段，将测试计划有效编写完成。同时也筛选择例，将项目用例单独整理成文当。对需要设计补充用例模块进行设计；
（3）在软件“代码编写”期间，完成《测试用例》编写。测试计划时间计划和工作安排要和项目标整体进度吻合。
（4）安排测试人员要和技术等级、工作量匹配，确保有效工作进度，必需时采取加班方法增加工作量，为项目完成降低可预见更多风险；
（5）监测需求改变立即调整测试用例；
（6）性能测试指标及方案需要在项目撰写测试计划时预估性能测试工作量并预先安排工作时间，依据项目实际情况和用户需求制订性能测试计划和测试指标，编写性能测试汇报；

三、测试实施进程
（一）需求
（1） 参与立项会议，查看需求文档，接收业务培训具体了解业务步骤。
我们是外包企业为用户提供服务为主营业务。在接收用户指定项目责任人提供（以下简称用户）直接需求文档，由研发部项目责任人先接收需求培训，然后组织相项目经理、研发经理、人员、开发人员、环境管理人员、测试人员和其它相关人员进需求评审，确保达成一致意见。对系统连接测试需求分析和集成测试需求分析进行评定，确保系统连接测试需求和系统集成测试需求经过评审。对于内部测试需求分析中导出内部测试需求，应由研发中心测试组组织相关业务人员、开发项目组进行评审，实施统一标准，形成合作默契。全部评审文档确定后全部要上传到SVN；
在整个项目研发过程中和用户进行需求变更细节沟通，项目结束后也要随时帮助用户处理项目问题，表现人和创建职员高素质、高服务意识，维护企业良好形象。
另一个是第三方提供需求，除了等同用户需求工作之外，要尤其注意：第三方对需求确实定状态和修改次数。不能简单、一味、直接接收第三方想法，必需时要求对方立即和用户确定，做好需求修改统计。在修改需求时和第三方文件传输要每次全部抄送上级和相关责任人，邮件正文中注明邮件目标、传输文档数据属性和发送原因。全部评审文档确定后全部要上传到SVN；

（2） 单元测试
开发人员完成代码编写后首优异行单元测试。其中，编写《单元测试计划》，设计单元测试用例、实施单元测试过程、统计单元测试缺点、编写《单元测试汇报》等工作由白盒测试人员完成。依据项目组具体情况安排，现在本部开发人员自行完成单元测试，而且不提供任何相关文档给测试人员。
（二）功效测试和性能测试指标
（1）新项目标首次功效测试是从“冒烟测试”开始。新项目交接到测试部，首优异行“冒烟测试”经过后进行功效测试，如测试结果为：“不经过”将不予测试，打回重做。
冒烟测试合格项目基础功效测试能够使用完整步骤，比如正常使用会员管理系统，能够进行会员注册、登录、会员信息修改、退出、管理员查询、统计、冻结/删除和修改会员信息等基础功效。期间没有异常退出系统、挂机、报黄页、安装和卸载无异常等关键功效步骤能够正常实现。也就是，被测试程序能完整实现基础功效步骤，软件基础功效正常，能够进行后续正式测试工作。即为冒烟测试经过，反之则没有经过，不予测试，退回开发项目组责任人。
升级版项目也需要进行冒烟测试，在Web测试和负载测试中，冒烟测试时间短，工作量也小。使用冒烟测试是为了在运行功效测试或压力测试之前，确保一切全部已配置正确并可按预期运行。

（2）冒烟测试用例选择标准 
 1)新功效版本公布 
u  测试人员接到新版本后首先需要对新功效进行冒烟测试。冒烟测试关键验证所提交功效关键模块是否按需求开发完、是否进入测试阶段、是否能够根据正常测试用例实施测试。选择关键功效正常见例做为冒烟测试实施用例，通常选择《测试用例》中优先等级低用例；
2) 含有旧BUG未修复新功效版本
u  新功效开发完成后，假如依靠于某个功效模块且该功效模块中存在未修正BUG，则不接收新版本布署测试。选择新功效正常测试用例和优先级为“高”等级以上，而且已经修复BUG做为冒烟测试实施用例。 项目组组员能够用分配好用户名和密码登录缺点管理系统实时查看缺点情况。
3）BUG 修正版本公布 
u  选择优先级为“高”等级以上，而且已经修复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.测试退出前测试经理主导召开最终一次BUG Review，全部和会人需要签字确定是否能够退出测试；

（6）升级版本测试退出准则 
1. 完全满足《新产品测试退出准则》；
2.系统目前线上运行版本中功效、性能未出现新BUG;

(7)Patch（修复BUG）版本测试退出准则 
1. 需要修复BUG已经修复； 
2. 系统原有版本（指目前线上运行版本）中功效、性能未出现新BUG； 
3. 测试退出前完成一次实施全部测试用例回归测试及优先等级为“高”BUG回归； 
注：测试退出前测试经理主导召开最终一次BUG Review，全部和会人需要签字确定是否能够退出测试；

（8）测试实施期间版本公布标准 
开发人员处理全部BUG均需要输入bug列表，修正BUG需要说明问题发生原因及怎样处理，处理后是否对其它相关模块有影响；其它状态BUG均需要说明理由。 

1）新功效版本公布 
按正常公布版本步骤公布测试版本。接到新版本测试人员要对新功效进行冒烟测试，关键验证所提交功效点是否按需求完成，能否实施测试用例。冒烟测试过程中如出现重大BUG阻碍下一步测试，则冒烟测试不经过，不接收测试。待开发人员进行修复后再布署版本进行测试。 
冒烟测试中实施测试用例只标示“运行”状态，不报BUG。实施过程中测试用比假如实施失败则关联BUG。 

2）新功效版本 + BUG修正版本公布 
新功效开发完成后，假如依靠于某个功效模块且该功效模块中存在“未修复”BUG则不接收新版本布署测试。

3）BUG 修正版本公布 
测试实施过程中，在测试人员进行了第一轮测试后，开发人员需要对BUG进行修改，标准上修改BUG达成以下标准后才能公布第二轮测试版本，如遇紧急情况另行处理。 l 
1.高优先级Bug修复要求 
2.努力争取目标：对优先级大于等于C级BUG需要全部修复； 
3.最低目标：对优先级大于等于C级BUG假如不能全部修复，则影响到下一步实施测
试BUG必需全部修复；并对不能修复BUG给说明。 
4.低优先级Bug修复要求 ：对优先级小于C级BUG需要修复80%。 对于不修改或拒绝BUG进行说明；不修改BUG需要项目经理将其置为“Later”状态。 
5.除以上情况外“紧急公布情况”需要开发经理提交项目经理和测试经理评定，评定经过后即可公布测试。 
6.针对不一样开发语言QA做不一样版本公布规则。

4）版本公布推进标准 
测试人员提交BUG后发送Email通知开发人员。开发人员依据BUG优先级进行修复，如遇BUG描述不清立即和测试人员沟通，以确保BUG立即修复。

第四章 附表
全部表格和相关文档上传至SVN，项目指定专员填写项目测试文档需求表格并自行下载。请将使用表格单独复制保留成WORD文档进行填写；

××项目测试文档申请表--- 表1

申请人

项目名称

版本号

提供项目文档明细

申请测试文档明细

申请日期

开始测试日 期

结束测试日 期

项目责任人

项目延期

是/否

升级版本信 息

测试者

提醒文档提交日期

文档提交日期

确定提供文档清单

回执日期

回执人

审核结果

备注

××项目测试文档接收单---表2
（写完测试文档，提交给指定责任人表格）

文档接收者

项目名称

版本号

项目概况

（项目名称及进度等信息）
已接收测试文档

接收日期

升级版本信 息

是否延期

文档提交者

全部接收
（全部接收/部分接收）

文档交接完 毕
（是/否）

××项目测试文档延期通知单--表3

文档申请者

项目名称

版本号

提供项目文 档

所需测试文 档

延期原因

（写明原因和延长日期）
测试确定

××项目工期提前测试申请单 -- 表4

文档申请者

项目名称

版本号

提供项目文 档

所需测试文 档

提前原因

（写明原因和具体日期）
测试确定

需求修改确定单--表5

需求提供人信息
（姓名电话）
项目名称及版本号

文档作者

填写日期
必填，正确到几点几分，采取24时制
模块名称
模块具体
修改日期

历史修改

更新内容

模块1（填写模块名称）
功效数量

按钮个数

按钮功效

输入数据

输出数据

预估数据量

列表功效

备注

模块2（填写模块名称）
功效数量

按钮个数

按钮功效

输入数据

输出数据

预估数据量

列表功效

备注

模块3（填写模块名称）
功效数量

按钮个数

按钮功效

输入数据

输出数据

预估数据量

列表功效

备注

模块4（填写模块名称）
功效数量

按钮个数

按钮功效

输入数据

输出数据

预估数据量

列表功效

备注

模块5（填写模块名称）
功效数量

按钮个数

按钮功效

输入数据

输出数据

预估数据量

列表功效

备注

模块6（填写模块名称）
功效数量

按钮个数

按钮功效

输入数据

输出数据

预估数据量

列表功效

备注

模块7（填写模块名称）
功效数量

按钮个数

按钮功效

输入数据

输出数据

预估数据量

列表功效

备注

模块8（填写模块名称）
功效数量

按钮个数

按钮功效

输入数据

输出数据

预估数据量

列表功效

备注

模块9（填写模块名称）
功效数量

按钮个数

按钮功效

输入数据

输出数据

预估数据量

列表功效

备注

模块10（填写模块名称）
功效数量

按钮个数

按钮功效

输入数据

输出数据

预估数据量

列表功效

备注