标准测试流程
2019-05-28 14:21:17 0 举报
AI智能生成
标准的测试流程
作者其他创作
大纲/内容
项目启动
项目确立之后,PM需要将CR文档发给测试人员
QA抠CR需求
Kick_off_meeting中聆听PM介绍需求
QA理实现模块
聆听SA介绍项目架构和业务场景
newtap中记录
创建CR和task#,并且Assign给对应的人员
测试工作的进展
测试工作的类型
接口功能测试
原先的接口进行修改
新增的接口
接口功能测试的等级
测试①等级
测试等级1是正常的测试用例,即正常业务使用场景中的测试用例。
传入<b>最少</b>的入参,验证DB,验证Response
传入<b>全部</b>的入参,验证DB,验证Response
传入的某个入参,不能与DB中重复
举个例子:需求中规定手机号/身份证/openid必须全库唯一
请求的手机号在DB中已经存在,验证代码判断并抛出
传入的某个入参,一个入参影响别的入参
举个例子:需求中规定若同意邮件联系,则必须传入邮箱
请求中传入的邮箱opt为同意,验证不传邮箱地址,代码判断并抛出
测试②等级
测试等级2 是异常测试用例中较为常见的测试用例
考虑变量的长度
说明文档中的每个参数的长度,是否超过DB中限定的最大长度
请求中传入的变量长度超过文档中规定的长度
考虑变量的必传
说明文档中的必传参数,请求的时候未传,验证代码进行判断并抛出
说明文档中的必传参数,请求的时候传空字符串(String类型),验证代码进行判断并抛出
说明文档中的必传参数,请求的时候传null(int类型),验证代码进行判断并抛出
测试③等级
测试等级3 是异常测试用例中较为常见的测试用例,一般前后端架构中前端能避免一些值的传入的
请求中字符串的首尾空格
请求中变量的字符类型
请求中的特殊格式
举个例子
① 说明文档中规定的是日期格式,要求的是string类型,除了考虑符合匹配的日期格式外,还需要考虑日期合理性,比如20190229这个字符串,如果代码不判断,而DB中要求是datetime类型,遇到这个类型会跑数据库的异常
考虑值的范围
举个例子
① 说明文档中规定的是int类型,要求只有两种类型1和2,比如常见的性别判断,或者注册绑定解绑标记,传入性别需要考虑传入1和2之外的数字3,代码是否能够捕获并抛出异常,目的是为了确保数据库中数据的质量
测试④等级
测试等级4是异常测试用例中较为少见的测试用例,有助于前后端分离中前端能快速定位问题
请求的格式
JSON格式
① 一般来讲,我们目前的请求体是JSON格式,可以构造JSON格式不正确的请求体进行请求
请求方式
② 一般来讲,接口说明文档中已经规定了请求的方式,比如GET/POST,或者基于 RESTful的PUT/HEAD等,可以将请求方式和规定的不符合进行请求,查看处理结果
测试⑤等级
测试等级5接口的幂等性校验,一般来讲这个在高并发系统中比较重要,但看SA的架构吧,有的开发人员不了解,就不能做到保持接口的幂等性
幂等性:就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的,不会因为多次点击而产生了副作用。
幂等性主要需要验证的是新增数据的请求接口,在增删改查4个操作中,尤为注意就是增加或者修改,查询对于结果是不会有改变的,删除只会进行一次,用户多次点击产生的结果一样。修改在大多场景下结果一样。增加在重复提交的场景下会出现。
举个例子:会员注册接口,接口中要求会员手机号在DB中不存在,或者openid不存在、身份证不存在,在功能测试中,单侧运行,请求传入的手机号已经存在,接口返回手机已经存在,但是用工具可以测试,将同样的20条手机一起进行注册,发现20条数据全部注册成功,数据库中生成20条手机号码相同的会员。这就违背了幂等性设计原则
存储过程测试
原先的存储过程进行修改
新的存储过程
适用场景
积分导致的升降级
取数发送Campaign
同步更新会员信息
页面UI测试
对基本功能进行测试
将所有的功能验证一遍,包括能否向下执行,数据存入DB是否正确
从提升用户体验的角度进行优化测试
比较基础的是测试基本样式,站在用户的立场,将不利于用户体验的地方进行提出来
从Web安全角度进行测试
短信验证码无限发送
任意修改其他会员的ID信息
横向鉴权和纵向鉴权
UAT联调测试
UAT测试是在内部功能测试完成之后进行的
通常占一个head count,对外沟通的人需要进行数据检查和处理
API接口的性能测试
性能摸底
性能调优
CloverETL测试
不涉及逻辑的,都不要去测试
测试对外输出测试用例
测试用例
测试编号
1,2,3,4
测试对象
接口名称
存储过程名称
测试描述
请求中传入的手机号在DB中已经存在
用例等级
一般分为1,2,3三个等级,对应高中低
测试预置条件
在DB中造一条手机号已经存在的数据
预期结果
DB中数据的检查
返回体的检查
接口测试用例的Sample
开发转测
接口的转测
打包和部署
根据项目的异同,目前常见的Springboot框架代码,需要开发人员将代码提交到gitlab,由测试人员去进行打包和部署。
若打包和部署中遇到错误,开发人员需优先查看。否则测试人员无法继续向下进行工作。
若项目涉及和牵扯的端比较多,测试人员一人无法部署,需要开发将包部署好,并提供swagger-ui.html路径给测试人员
转测邮件
接口名称
正确的入参请求Sample
接口中使用到的R表
接口中受影响的基本表
接口中涉及的日志表
自测通过
存储过程的转测
转测邮件
新的存储过程,将Proc作为附件贴在邮件中
修改的存储过程,将old和new存储过程作为附件贴在邮件中
明确导出表的表名称
存储过程涉及的主要的表
新增加的表,介绍表的名称和表的主要字段
自测通过
Bug的处理
没有争议的Bug
提交Bug系统做记录
开发Fix后回归测试
测试通过后关闭Bug
有争议的Bug
找SA确认,确认之后最好有邮件
影响极小的Bug
提交Bug系统做记录
测试资料的保存
测试任务和测试用例提交测试平台进行保存
https://coe.acxiom.com.cn/bug/login
存在自动化脚本
测试平台日后将做更新和完善,支持上传各个项目的脚本
0 条评论
下一页