标签：ps 组装 常识 接口 excell 参数 测试 异常

 接口测试实现过程思路：

1.通过excell设置接口参数[excell里使用随机数等]，然后调用服务接口方法实现插入

ps:原来通过写死，随机，参数化的方法来造支付信息，不建议这种。如下原因

    a.通过excell后面更方面，不会写代码的人也可以操作。

    b.如果参数个数变了且是必传字段，且有不同逻辑，不用每个场景的数据组装从代码里改，如果采用excell直接添加1列就行

2.把支付信息传过来且需要人工检查的字段组装成对象，验证方法写一个即可，根据excell里面传的参数判断走特定验证逻辑。[不用写很多场景判断语句，一个参数搞定]

  自动化断言部分要考虑成功和失败

3.excell里面造不同正常场景及异常场景的数据去验证

ps:需要其他表验证

 

常见异常考虑，如下异常根据实际情况确定是否需要处理：

1.前端调用接口时，传给接口的参数是否存在为空，根据双方沟通结果写测试用例，可能前端需要返回null或者跑出异常，如果没有要求不需要处理，不报错即可

2.少传---接口必传字段，也要验证异常为空的情况【如果用户名和密码不传就不行】

3.可传---接口可选字段，传不传都要检验

4.多传---调用接口方如果传一些接口处理方不需要处理的信息，要保证没问题

ps:支付系统不传，但接口有处理，是开发的考虑，自己可以借鉴

 

接口测试用例思路:

1.根据接口文档自己分析一版[业务流程+必考虑异常+待定是否需要处理的异常+预计错误提示内容] 用例，然后把用例给开发/业务去检查是否遗漏，确认部分内容

  ps：根据等价类等的思路，去把条件和结果分类，然后同类统一处理

2.针对待确认内容【特别异常是否需要处理+必传字段校验+错误提示详细程度】，接口测试是否需要处理及处理的程度，根据大家沟通结果，接口测试目的是否是为了验证主流程，成本，时间，及测试自己决定。沟通后再完善用例

3.编写测试代码，先测主流程【测试中用例excell化，​excell中每行代表一个场景，每行添加参数列去决定走的逻辑，预期结果列用于判断】

ps:a.目前我们公司大多是主流程，不用那么细，真有问题人工去看即可

 

接口用例：功能测试场景+异常设计，从如下方面入手：

a.主功能是正常

b.逻辑业务(也包含逻辑依赖业务，去下单前要确保登陆了）

c.参数异常(1.参数为空 2.参数值不能为关键字 3.多/少一个参数在严格接口测试中会用到  4.参数在数据库中不存在)

d.数据异常(1.数据值为空 2.值为关键字如null 3.数据长度异常_提示不存在银行里不允许   4.数据错误)

e.安全

ps：

1.可选参数为空时存值为0还是存值为空

2.补充接口参数名字要严格和接口文档保持一致，区分大小写么

 

断言思路：

1.增加检验：把调用接口传过来的需要人工检查插入结果的字段组装成对象，去数据库中查询，查到就成功，否则就提示失败数据信息

2.查​检检验:查询结果组装成对象，去数据库中查是否一致

3.删除检验:调用接口后，把传过来的信息组装成对象或者拿关键字段去数据库中查询

4.修改检验:把传过来的修改前和修改后的信息组装成2个对象，调用接口后，查询2次，修改后的信息组装成的对象才可以查询出来

 

 

标签：ps,组装,常识,接口,excell,参数,测试,异常
来源： https://www.cnblogs.com/wbsbxh/p/12110821.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。