软硬件提测规范

软件研发中心规范提测

1. 目的

为了提高沟通效率和测试质量，使产品测试过程更顺利，保证产品测试工作的计划性与规范性，现制定并规范提测流程和过程。

1. 适用范围

本流程适用于软件研发中心向系统评测中心提交测试申请单。

1. 提测流程及要求

项目经理或提测人，在OA和禅道上向系统评测中心负责人提交测试申请单，测试中心负责人审核通过后，指派具体的测试人员，测试人员与研发人员进行对接，组织功能宣贯会，符合测试准入原则，规划测试计划，开始进行测试。第一轮测试结束，在测试任务截止日期或之前反馈测试结果。项目经理根据测试结果，审核是否需要继续测试，bug修复完成，是否需要再次测试，选择“否”，整个测试单结果，OA流程结束；bug未修复完成，是否需要再次测试，选择“是”，给出bug修复时间计划。测试人员在时间计划内完成验证bug，时间计划截止反馈测试结果，然后项目经理再次审核测试结果。如果问题一直未完成修复，如此反复迭代，直至达到测试准出原则。

详细的流程如下图所示：

1. 提交测试需要提交的流程

OA禅道需要同步提交测试流程单。定义好提测版本号，一般以项目名称缩写+提交日期为命名规则（待讨论决定）。

1. 提交申请需要提交的材料

提交测试申请单需要包含但不限以下内容：①、需求说明文档，重点业务需要重点说明，以业务清晰表达为目的，形式不限，例如：原型图；②、数据库设计图（数据库表名和字段的含义需要备注清楚）；③、接口文档，如有必要，需提交其他相关文档资料。④、提测具体内容具体的对接人，例如，前端责任人，后端责任人，多人需具体功能具体到人。⑤、部署资料。（无部署资料，需指定负责环境对接的研发人员）

1. 组织功能宣贯会

测试人员接收到任务后，尽快了解项目相关材料和系统，并组织项目功能宣讲会，与会人员应包括但不限以下人员：项目经理，参与项目的研发人员，评测中心负责人，参与项目的测试人员等。由项目组长或者开发人员对系统重要业务逻辑进行演示说明。测试人员需要再次确认提测的范围和内容。

功能宣讲会灵活组织，不强制。提测内容简单，内容少，可由测试人员与研发人员直接沟通对接。提测内容较多，内容多，大项目，尤其是新项目，需召开功能宣贯会。

功能宣贯会结束后，测试人员对系统做冒烟测试，根据测试准入原则，需给出是否介入测试的结论。

• 测试准入原则

1. 开发人员编码结束并且已在开发环境中完成单元测试，包含了数据准备、代码提交；
2. 需求所规定的功能均已实现，如未全部完成，需以文档形式提交明确的测试范围；
3. 测试人员手动冒烟测试，且测试通过；
4. 兼容性测试要求明确，安全、性能测试的范围和要求要明确；
5. 转测资料齐全（需求文档、接口文档(非必须)、部署文档、数据库表结构、提测流程OA和禅道）；
6. 部署资料正确或有明确环境指导对接人。

• 测试暂停、停止

1. 不符合准入原则任意一条，暂停测试，打回给开发并说明原因
2. 测试过程中出现产品重大变更或者研发设计变更，需要暂停测试重新评估测试范围；
3. 被测项目由于其他原因需要暂停；
4. 存在优先级更高的项目测试任务，当前测试任务需要暂停。

• 测试准出原则

1. 提测单提的内容全部进行了测试；
2. 发现的所有bug都已提交记录在禅道并修复：一、二、三级bug修复率为100%，四、五级bug修复率达到95%；
3. 所有遗留问题或后期优化的问题都有了解决方案或指向；
4. 开发和测试有争议的缺陷需要经项目产品经理、项目经理、业务方确认，若经讨论后确认可以忽略不改或因其他原因要在以后的版本中实现，则本次测试可以认为通过；
5. 性能、安全、兼容性达到要求。(根据提测要求)；
6. 禅道关闭测试单有完整的总结或有独立的完整的测试报告。

1. 测试过程要求

1. 测试人员在规划测试计划时，针对提测的内容，按模块进行测试，优先测试完成的模块，及时通知项目经理，安排研发人员优先解决；
2. 测试过程中，测试人员需每周反馈测试进度，bug解决进度。具体反馈日期由测试人员与项目经理讨论决定；
3. 测试过程中，有任何变更，如需求变更，设计变更，数据库变更，解决bug前端后端内容的变更，均需要通知测试，或者在群里发送。（防止遗漏测试）

1. BUG提交要求

1. 测试人员按提测单功能对应的人员填写责任人和指派者；
2. 测试人员提交bug，bug标题添加【测试单编号】，例如【测单377】，方便后续bug的整理，查看，统计；
3. 优化和建议的bug指派给项目经理或组长，由项目经理或组长确定是否需要优化。如果优化，项目经理或组长指派到具体的研发人员，如果不优化，项目经理或组长备注相关说明指派到测试。

1. BUG修复要求

1. 开发人员解决bug时，适当的增加备注说明，尤其是解决方案是设计如此，外部原因，延期处理，转为任务，不予解决，需由项目组长鉴定并给出合理解释。提高效率。
2. 针对有异议的bug，由三方测试、开发、产品经理一起讨论，最终达成一致，总结bug产生的，后期如何规避，提升项目效率。
3. 解决方案选择“转为任务”，需备注任务禅道地址或编号，以方便测试人员跟踪。（测试主动跟踪任务完成与否，不激活bug，让研发再次点解决，会导致激活次数增加）

1. BUG验证关闭

1. 已解决的bug要及时验证，需在一周内验证。
2. 对于解决方案变化较大，关闭问题备注解决的方案。

1. 测试结束反馈

测试结束，测试人员需在相关提测单（禅道和OA提测流程）中给出测试结果说明，说明内容包括：测试中存在的严重及以上程度问题，本轮测试是否通过的结论，并在相关工作群里提醒。

1. 测试结果审核

项目经理可根据测试人员反馈的情况，审核是否进行第二轮/n+1轮回归测试，并监督bug解决进度。反馈结果中有bug未修复完，OA流程中，是否需要再次测试，需选择“是”，并给出bug修复时间计划。测试人员在之间截止前，验证所有的bug，并反馈回归测试结果。（问题：这里针对后续的bug验证版本代码提交没有一个规范的管理，需要完善。）

1. BUG等级定义

测试人员要按BUG等级定义的规范提交bug。项目经理或研发人员按等级优先级顺序修改bug（尤其是时间紧急的情况）。研发人员对于提交bug程度有异议的，根据BUG等级定义的或者描述类似的，相近的进行归类修改，BUG等级定义中没包含的，测试人员与研发人员（或项目经理）共同讨论决定等级归类。新的分类增加到BUG等级定义表中，作为后续的参考标准。

程度	等级	Bug等级说明	分类说明	修改优先级
致命问题	1	导致整个产品无法进行测试。该级别需要程序员立即修改	模块无法加载或者启动	立刻
			系统无法启动或者异常退出
			其它导致无法测试的错误
		死机，数据丢失，主要功能完全丧失，性能差等错误。该级别需要程序员立即修改	数据无法存储与读取，保存、打开文件，导出exe、打开exe存在序列化问题	立刻
			功能设计与需求严重不符
			内存泄露
			数据丢失或者不正确，无法连接服务器
			严重的数值计算错误
严重问题	2	主要功能丧失，导致严重的问题，或致命的错误声明。该级别需要程序员尽快修改	功能未实现或者存在错误	紧急
			较小的数值计算错误
			系统所提供的功能或服务受明显的影响
			用户数据丢失或破坏
一般问题	3	次要功能丧失，不太严重，如提示信息不太准确。该级别需要程序员修改	操作界面错误（包括数据窗口内列名定义、含义是否一致）	高
			边界条件下错误（如输入边界值导致的错误）
			功能存在错误，但出现概率很低
			提示信息错误（包括未给出信息、信息提示错误等）
			长时间操作让用户等待确无进度提示
			系统未优化（性能问题）
			与标准、规范和定义不一致
		较小的问题，对功能几乎没有影响，产品及属性仍可使用。修改优先级为低，该级别需要程序员修改	界面格式等不规范	中
			操作时未给用户提示
			文字排列不整齐等一些小问题
			光标跳转设置不好，鼠标（光标）定位错误
轻微问题	4	违背正常习惯，界面不美观，控件排列、格式不统一，该级别需要程序员修改或不修改	辅助说明描述不清楚	普通
			个别不影响产品理解的错别字
			可输入区域和只读区域没有明显的区分标志
			提示信息格式不符合要求
建议	5	功能性建议，功能使用性、方便性、易用性不够	建议，提出者根据经验，对系统的使用感受和常规的使用习惯提出的完善建议。	低

1. 测试次数说明

针对每一个测试单，正常测试过程，一般包含两轮测试，第一轮功能测试，和第二轮回归测试。问题解决周期较长，回归测试则是n+1轮。

第一轮功能测试：根据提测内容，功能的宣贯，进行全面的功能性测试，业务内容测试。

第二/n+1轮回归测试：针对第一轮测试提交的问题，对已解决的问题进行验证，测试是否引出新的问题，并检查是否有遗漏测试点未测试到。

根据具体情况，两个过程可单独进行，也可交叉进行，或者同时进行。

1. 测试延期

测试人员按测试计划时间开展测试工作，若实际完成时间与约定时间有出入，需提前与评测中心负责人和项目负责人做好沟通反馈并说明延期的原因。

1. 测试结束

测试结束的定义：针对提测单提测的内容，测试通过，达到测试准出原则。

测试人员编写测试总结报告，通过邮件发送给项目负责人，抄送给双方部门经理及项目相关人员。

1. 附件

禅道提测单

项目名称		项目经理
提交人		提交时间
软件版本号	提交的测试版本号
版本内容说明	写明此次版本的内容。 1 、如为提测版本，则列明各项功能，并另外提供功能详细清单及数据库设计内容。 2 、若为bug修复版本，列明修复的问题。如过多，则列出主要修改项和问题修复数量。
自测是否通过	系统是否有自测过。
提测范围	□功能测试     □稳定性测试      □算法测试      □接口测试 □性能测试     □其它测试  (                                    )
相关文档	□需求说明书   □数据库设计图   □算法测试相关数据   □原型图   □接口文档   □自编功能说明文档   □其他(                   )
期望开始时间			期望结束时间	最终时间以双方沟通确认为准
注意事项	需说明该版本已知的、暂未修改的问题或测试应注意的问题。

     

                                                               

测试总结/报告

项目名称		测试人员
测试覆盖率	□95%以上 □95%以下	测试通过	□是 □否
一、二、三级 BUG修复率	□100% □<100%	三、四级 BUG修复率	□95%以上 □95%以下
软件版本号	提交的测试版本号
测试范围	仅提测单内容？是否有追加的提测内容。
测试总结	Bug总量：致命bug量，严重bug量，一般bug量，轻微+建议bug量。 对本次测试的总结，bug量，严重程度，修复是否及时等。
风险项	工期或者其他问题，未完成测试；不在提测范围内发现其他bug；测试过程中的重大变更的影响。
Bug列表(链接)	禅道bug链接地址。