软件项目测试验收流程V3

一、Bug分类的界定：

（一）bug严重程度分类：

紧急---重大功能bug、block核心功能的bug, 严重性能问题，内存泄露；阻碍开发或测试工作的问题；

严重---导致程序模块未实现；用户需求未实现；

一般---发现影响被测功能正确实现的问题，或一般性错误或者功能实现不完善等； 次要---一些建议性和界面的问题。

（二）严重程度具体分类：

1、jira「紧急」 （1）系统崩溃

（2）导致程序重启，死机或非法退出 （3）死循环 （4）数据丢失或异常 （5）安全问题 （6）响应时间过长 2、jira「严重」

（1）功能不符合用户需求 （2）因错误操作迫使程序中断

（3）功能实现不完整，如删除时没有考虑数据关联 （4）程序接口错误

（5）业务流程、审批流转错误 （6）数据计算错误 3、jira「一般」

（1）存在与系统无关的logo或文字标题 （2）内容或格式错误 （3）提示信息不准确 （4）兼容性问题 （5）功能性建议

（6）光标定位、鼠标变小手等

（7）回车键无法进入、Tab键无法切输入框等 （8）必填项和非必填项需加以区别 4、jira「次要」

（1）辅助说明描述不清楚

（2）界面字段、按钮、提示语的文字未采用行业术语 （3）可输入区域和只读区域没有明显的区分标志 （4）其他建议性问题

二、验收流程：

（一）验收流程图：

外包方修改启动验收验收失败检查验收报告不通过通过不通过冒烟验收不通过正式验收验收通过

验收时，一旦发现0类bug和1类bug就立马打回，由此造成项目延期由外包方负责。 从此阶段开始算起，截止到产品正式发布后三个月内，在这期间被乐视方发现的bug

数总和就算漏测bug数,咱们命名Z=漏测数/总的bug数，如果Z<5%,需赔付甲方__%的赔偿金。如果5%验收中每个阶段都需完成才能进入下一阶段，否则都是验收失败，由PM提交给外包方修改后重新启动验收：

（二）启动验收

外包方提交正式验收版本时，需要给出完整的验收标准报告，验收报告各项指标全部达标（100%按照验收标准，如有不符合，须经PM同意）才预示可以进入验收阶段，否则将直接打回，通知PM和相关人员。外包方再次提交验收报告经检查无误后再介入。 1、冒烟验收

类似于smoke test，PM对站点或者app进行30分钟～1小时的功能确认，工作重点在核心功能、逻辑和异常情况。验收流程如下：

（1）进行30分钟～1小时的功能确认，如通过则进入5，否则进入2

（2）验收失败，打回给外包方修改，通报给相关邮件组，暂停验收，要求外包方给出自测list和修复时间，由此带来的项目延期由外包方承担，如有必要，我方可提供自测list。

（3）外包方修改后再次提交版本，需要提供自测报告，标注bug产生的原因、修复方法以及修复带来的功能影响；

（4）再次冒烟验收，如通过进入5，否则进入2 （5）正式验收 2、正式验收

验收主要进行如下几方面：

 PM执行功能验收中“正常功能确认”部分  QA执行：

（1）功能性验收测试 （2）兼容性验收测试 （3）稳定性验收测试 （4）性能验收测试 （5）安全性验收测试 （6）本地化验收测试

3、验收通过

验收通过后，QA通知PM和外包方，然后由PM发起上线流程。产品的质量由QA提供验收结果，PM决策用户影响，最终确定是否可以上线。

4、验收失败打回

验收过程中任一环节失败，都进入验收失败打回阶段。为了控制项目周期和再次提交的版本质量，针对验收失败以及提交新版本做了如下规范： 验收失败时 乐视行动 PM提交buglist给外包方，如有必要，提供自测list，同时通报相关人员知晓 提交新版本时 优先验收bug修复和相关功能回归，如发现未修复或引入bug的比例超过修复bug数量的20%或者引入crash问题，打回，并通报相关人员，由此带来的风险由外包方承担； 修复bug时 无 标注bug原因、修复bug方法和影响面，要求严重问题的修复周期不得超过24小时，一般问题修复周期不得超过48小时。

5、项目验收分级

➢ 全新项目或者2.0大版本更新： 进行全流程测试

详见「准入质量标准V5 - 外包验收（新项目）.xlsx」

➢ 新功能或者优化的，主要模块无更改： 只进行变更部分的功能、UI、用户体验的

测试

详见「准入质量标准V5 - 外包验收（功能优化或新增）.xlsx」

BUG修复： 只做BUG的验证和回归测试

外包方行动 明确bug修复时间、自测时间及测试报告、再次提交版本的准确时间 提供自测报告、修复bug的方案和影响的功能list，要求修复所有反馈的问题