一、测试场景设计:
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、建议或者意见。 |
五、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、系统测试力度:
①测试时间充足,可以进行所有功能测试;
②测试时间一般,可以进行未牵扯的老功能的冒烟测试,有关联关系的老功能进行系统测试;
③测试时间紧张,可以进行本迭代需求以及周边功能的系统测试。