首页  思维导图  详情



 



测试流程SOP方法经验总结

2022-11-22 10:27:20   1  举报





AI智能生成

测试流程SOP方法经验总结

测试流程

模板推荐

作者其他创作

大纲/内容

项目启动

项目确立之后，PM需要将CR文档发给测试人员

QA抠CR需求

Kick_off_meeting中聆听PM介绍需求

QA理实现模块

聆听SA介绍项目架构和业务场景

newtap中记录

创建CR和task#，并且Assign给对应的人员

测试工作的进展

测试工作的类型

接口功能测试

原先的接口进行修改

新增的接口

接口功能测试的等级

测试①等级

测试等级1是正常的测试用例，即正常业务使用场景中的测试用例。

传入&lt;b&gt;最少&lt;/b&gt;的入参，验证DB，验证Response

传入&lt;b&gt;全部&lt;/b&gt;的入参，验证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是否正确

从提升用户体验的角度进行优化测试

比较基础的是测试基本样式，站在用户的立场，将不利于用户体验的地方进行提出来