软件测试规范

一、测试场景设计:

1、UI测试:

①跟原型,UI设计一致;

②字体是否统一;

③字号是否符合规定;

④界面布局是否合理,整体效果如何;

2、功能测试:

①正常情况;

②异常情况;

③边界情况;

④破坏性测试;

⑤用户友好性测试;

⑥输入值测试:

a、数据类型;

b、数据长度(截取方式限制长度)

c、约束条件是否满足,是否完整;

d、枚举值停用测试(后面添加(已停用),老数据不处理,新增编辑时选择不到已停用的枚举值);

3、接口测试(根据功能是否需要做接口测试):

①业务功能正常场景,异常场景;

②输入输出边界测试,参数必填非必填;参数排序,个数,类型;参数包含特殊字符;

推荐用的接口工具:postman,jmeter

4、性能测试(根据项目排断是否需要做性能测试):

①系统的大用户压力;

②系统的并发用户压力;

③系统的数据库压力;

④系统的稳定性等;

⑤输出《性能测试报告》,主要包括:性能指标,平均响应速度,吞吐量,系统用户的压力等数据;

5、兼容性测试:

①web兼容性测试:

a、浏览器支持包括IE8/9/10/11、360浏览器、火狐浏览器、Chrome 19.0以上版本;

②APP兼容性测试:

a、根据项目要求,关注安卓,IOS系统不同版本,手机型号,屏幕大小的兼容;

6、安全性测试(根据项目需求进行测试):

①功能性的安全测试:

a、密码输入掩码;

b、密码加密传输;

c、定时强制修改密码;

d、http和https协议测试;

②攻击类的安全测试:

a、SQL注入等;

二、用例编写规范:

1、按照提供的模板,有层级的编写测试用例;

2、根据设计的测试场景全部写入用例,并且标记好用例的优先级;

3、用例里面需要写清楚数据的流向,以备后续查阅。

三、测试规范:

1、需求提测之后,测试用优先级为高的用例进行冒烟测试,冒烟测试通过之后,方可进行整个需求测试,若冒烟测试不通过,写清原因打回给开发,让开发自验修复达到提测的质量再次提测;

2、文本框长度的测试:非特殊要求,以截取的方式处理;

3、停用的枚举值测试:原数据不变,后面写加(已停用),新增编辑的时候不能选择已停用的枚举值;

4、数据类型边界值测试:前后端都需要校验,鼠标移开之后,给出提示;

5、必填校验测试:前后端都需要校验;

6、唯一性测试:后端校验;

7、导入模板:根据表头校验,数据合法性校验,并且表头要有提示信息,有模板说明;

8、导入的时间格式为XXXX/XX/XX

四、Bug级别定义标准:

严重程度

具体描述

致命

  1. 严重花屏;
  2. 内存泄漏;
  3. 用户数据丢失或破坏;
  4. 系统崩溃/死机/冻结/挂起
  5. 模块无法启动或者异常退出;
  6. 严重的数值计算错误;
  7. 数据库发生死锁或者导致连接中断;
  8. 功能设计与需求严重不符;
  9. 无法继续测试。

严重

  1. 功能未实现;
  2. 功能错误;
  3. 系统刷新错误;
  4. 数据通讯错误;
  5. 轻微的数值计算错误导致系统所提供的功能或者服务受到明显的影响;
  6. 数据库的表,业务规则,缺省值未加完整性等约束条件。

一般

  1. 操作界面错误(包括数据窗口内列名定义,含义是否一致);
  2. 边界条件显示错误;
  3. 提示语错误(包括未给出信息,信息提示错误等);
  4. 长时间操作无进度提示;
  5. 系统未优化(性能问题);
  6. 光标跳转设置不好,鼠标(光标)定位错误;
  7. 删除操作未给出提示;

细微

  1. 界面格式等不规范;
  2. 辅助说明描述不清楚;
  3. 操作时未给用户提示;
  4. 可输入区域和只读区域没有明显的区分标志;
  5. 个别不影响产品理解的错别字;
  6. 文字排序不整齐等一些小问题。

建议

1、建议或者意见。

五、Bug修复紧急程度:

1、致命:立马修复,优先级最高;

2、严重:当天修复,优先级高;

3、一般:两天内修复,优先级一般;

4、细微:本迭代内修复完成,优先级低;

5、建议:根据时间选择性修复。

六、交叉互测质量保证:

1、如何判断那些需求需要进行交叉互测(由质量负责人根据该需求的难易程度,以及业务程度进行判断)?

2、交叉互测的内容必须保证发现的BUG级别在一般或者一般以上的问题全部修复完成之后,才可以进入交叉互测;

3、交叉互测的泄漏率不能超过20%(交叉测试bug数/bug总数)。

七、需求开发质量定义:

1、质量非常好:需求功能全部实现,0个bug。

2、质量较好:需求功能全部实现,需求缺陷密度不大于0.2(bug数/用户故事);

3、质量一般:需求功能全部实现,需求缺陷密度不超过0.4(bug数/用户故事);

4、质量差:需求极小部分功能实现,需求缺陷密码不超过1(bug数/用户故事);

5、质量极差:需求大部分功能实现,需求缺陷密度大于1(bug数/用户故事)。

八、系统测试:

1、如何判断本迭代需要进行系统测试不?

①一般情况都需要进行系统测试;

②如果测试时间紧,可以根据迭代需求范围来判断,是否进行全系统系统测试还是部分模块进行系统测试。

2、系统测试力度:

①测试时间充足,可以进行所有功能测试;

②测试时间一般,可以进行未牵扯的老功能的冒烟测试,有关联关系的老功能进行系统测试;

③测试时间紧张,可以进行本迭代需求以及周边功能的系统测试。

九、部署用户环境标准:

1、一般及一般以上级别的BUG全部修复完成;

2、不存在影响使用的严重问题;

3、剩余的问题以及优化方案不影响基本功能使用,可以在优化阶段完善;

4、98%及98%以上的模块,达到“稳定”状。

十、遗留问题处理:

1、遗留的bug需要跟产品,研发主管,质量负责人进行评估,是否会影响用户使用,以及修复的时间;

2、遗留的问题如果是方案问题,产品需要提供最新方案。

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值