您的当前位置:首页正文

缺陷等级划分及打回准则

2022-03-23 来源:榕意旅游网


缺陷严重等级细分标准

致命:

定义:导致运行中断(应用程序崩溃),导致整个程序不能使用,或者存在重大风险、隐患。

场景:

1.客户端、服务器死机或者不响应

2.数据库死锁

3.客户端异常退出

4.客户端无法正常连接服务器

5.需求未实现,或者实现的功能与需求完全不符

6.核心功能出现异常:

A.数据备份时,漏备份表

B.日终流程报错,无法继续正常运行

C.日终数据处理时,对不该处理的数据进行了处理,对应该处理的数据没有进行处理

D.核心菜单或功能按钮一点就报异常,导到无法继续进行操作或提交申请;

E.引起用户无法登录的问题,如验证码无法获取.一进入登录页面就报客户异常.用户输入正确的信息也不能正常登录.

F.多导出或导入申请数据或少导出或导入申请数据;

G.页面上缺少关键功能按钮,导到申请不能提交或不能查询;

7.严重的数值计算或插入数据表错误

A.金额,份额,申请日期,清算日期,划款状态,扣款状态,基金帐号,交易帐号等关键字段值写入数据库错误

8.提交的测试包问题

A.后台服务不能正常启动

B.程序无法正常编译通过

9.页面问题

A.A基金公司的页面或提示信息或签订的协议内容上出现了B基金公司的名称

严重:

定义:预期的功能没有得到实现,测试工作无法继续进行等,导致某些重要功能不能使用,或可能带来一些安全性问题

场景:

1.实现的功能与需求不符

2.核心功能的性能较差

3.非核心功能出现异常

A.查询或报表一点就报错;

B.导入,导出的数据信息总数正确,但数据信息中的数据错误.如业务代码转译,交易帐号重新获取等;

C.传给接口的数据不正确;

4.安全性问题

5.轻微的数值计算错误

6.脚本问题

A.脚本漏提交;

B.脚本运行报错;

C.脚本运行后,将数据库中的数据修改错误;

7.页面或界面问题

A.页面显示混乱,如大篇幅的文字或图片重叠.头尾位置颠倒等

B.页面数据显示与数据库中的不一致;如金额,份额,清算日期,申请日期,扣划款状态等;

C.页面或界面上的数据出现乱码.

一般:

定义:影响某些功能的使用,功能实现不完善,对产品使用影响不大.

场景:

1.非核心功能的性能较差

2.核心功能的TAB键顺序不对

3.容错性差

在应该输入数字的地方输入了字母,系统没有给出提示,导致最终的操作失败

4.易用性差

下拉框中的数据有成百上千个,程序可以过滤一些无效数据而未进行过滤,造成用户操作不方便

5.显示不完整

字段的显示宽度不够,不能完整显示信息

6.界面问题

A.文字描述混乱,用户无法做出合理的判断

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

8.删除操作未给出提示

次要:

定义:界面显示/相关提示信息/文字描述等有误,且不影响产品功能使用,

场景:

1.非核心功能的TAB键顺序不对

2.长操作没有进度提示

3.输入区域和只读区域没有明显区分

4.提示信息不准确,显示格式不规范

5.颜色刺眼

6.文字在高亮之后看不清楚

7.页面或界面问题

A.页面上控件不对齐

B.数据显示不对齐

C.报表数据写到表格外,但不影响阅读

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

优化:

定义:建议,不存在错误,但在功能、实用性、美观性等方面需要完善

场景:

1.界面风格不统一

2.布局不合理

3.字体与界面不协调

4.图片和图标的含义不明确

5.按钮大小不一致

6.文字的对齐方式不合理

7.数据显示的先后顺序不合理

缺陷打回准则

3个一般缺陷或者1个严重易现缺陷

需求不明确,需求与设计不符合或者其他影响测试的情况

修改内容不清晰不完整或者与设计需求不符合

要进行代码审核的单子未执行代码审核

约定开发组要进行内部联测的修改单没有同步提交相应联测说明

修改单测试建议退回准则

场景:1)需求、设计、测试建议及附件文档无法形成完整的测试资料,导致测试项遗漏或需确认才清晰;

2)测试建议遗漏、错误和存在误导;

3)需求、设计、测试建议,存在不符合情况,但并未作说明。

对重大修改,缺乏测试建议或者相关说明,测试建议不规范,缺少相关说明

自测内容说明不完整的可以打回

实行:以[测试建议退回]为标题发邮件给开发人员并抄送组长,修改单不做操作

修改单标准

发现一个由此修改单引起的小缺陷及以上即置为N

集成退回标准

CRM开发组缺陷修复规范

非发版周统计规则:

1. 周一上班前,缺陷数量不得超过4个,否则给程序员丢鸡蛋一个;

2. 周一上班前,截至上周四(8月13日)前新增的修改单,下周一上班前必须处于待集成状态,否则,审核退回的、集成退回、测试打回的给修改人丢鸡蛋一个,待审核给代码审核人鸡蛋一个。

3. 修复缺陷须生成修改单,下周一上班前进行统计,未填写修改单的丢鸡蛋一个

1. 发版周缺陷控制规则:

i、周一早上统计不能超过4个,否则丢鸡蛋1个。

ii、周二早上统计不能超过2个,并且不能有严重缺陷,否则丢鸡蛋1个。

iii、周三早上统计不能超过1个,并且不能有“一般”及以上的级别缺陷,否则丢鸡蛋1个。

iv、周四早上统计不能超过1个,并且不能有“一般”及以上级别的缺陷,否则丢鸡蛋1个。

v、周五早上统计不能超过1个,并且不能有“一般”及以上级别的缺陷,否则丢鸡蛋1个。

vi、缺陷未提交修改单的丢鸡蛋一个。

注: 1. 出于人性化考虑,统计日期前一个工作日下班后提出的缺陷不计入统计范围。

因篇幅问题不能全部显示,请点此查看更多更全内容