做棋牌网站建设哪家便宜,wordpress解决大型访问,制作短视频最好的软件,google 网站推广在做接口自动化测试时#xff0c;遇到下面这个疑惑#xff0c;然后再群里请教了大家#xff0c;讨论如下#xff0c;可以参考下#xff1a;
讨论1#xff1a;
上海—橙子探索测试 10:12:34 自动化测试中#xff0c;提现接口一般会依赖前置功能实名认证、绑卡、设置交易…在做接口自动化测试时遇到下面这个疑惑然后再群里请教了大家讨论如下可以参考下
讨论1
上海—橙子探索测试 10:12:34 自动化测试中提现接口一般会依赖前置功能实名认证、绑卡、设置交易密码等才能进行提现操作或依赖前置接口实名认证、绑卡、设置交易密码的响应数据姓名、身份证、卡号、交易密码等 这只是简单的实例可能实际场景中远比这种复杂的多所以进行提现接口测试时需先构建完成前置功能实名认证、绑卡、设置交易密码且构建前置接口的响应数据一般调前置功能接口或用sql构造前置功能数据两种方法那种方法更合理方便呢 风い 10:14:00 要保证用例独立运行的能力 只能麻烦 z 10:14:56 做成场景测试用例 天 10:19:08 上海—橙子探索测试 自动化测试中接口4依赖前置接口顺序或数据1 2 3 接口5依赖前置接口顺序或数据1 2 3 4比如提现 可能需要先设置登录密码、再实名认证才能提现所以接口4时需要构建前置接口顺序或数据1 2 3接口5时需要构建前置接口顺序或数据1 2 3 4 …… 这样的话每个接口里都存在大量重复前置sql侯建感觉太麻烦了有什么好的方法吗 上海—橙子探索测试 如果测试环境中数据不会被清理可以把参数写死。否则的话只能通过接口来造前置条件的数据来保证脚本的健壮性 上海—橙子探索测试 10:39:53 天 嗯 我目前是通过sql构建数据的 用完又清掉 所以导致每个用例都要重新构造 上海—橙子探索测试 10:40:17 z 场景的话那就是场景自动化了 不是单接口自动化 翡翠 10:41:08 直接调接口 翡翠 10:41:17 不行上容器开虚拟数据库 翡翠 10:41:20 随用随删 上海—橙子探索测试 10:41:46 调接口不稳定吧 我觉得还不如sql吧 翡翠 10:42:04 的确不如sql稳定 翡翠 10:42:19 所以我说不行上容器 翡翠 10:42:25 随用随删 天 10:43:44 你们在用docker吗 翡翠 10:43:59 我在弄 翡翠 10:44:16 还没弄好 天 10:44:59 上海—橙子探索测试 天 嗯 我目前是通过sql构建数据的 用完又清掉 所以导致每个用例都要重新构造 上海—橙子探索测试 你的sql会向服务器插入数据吗 天 10:46:34 我之前就想过用docker来实现先把数据添加到docker中的数据库中。跑自动化时就切换到docker里面的数据库执行完毕后就切换到测试环境的数据库 z 10:46:58 上海—橙子探索测试 你这本来有就依赖关系的除非你再数据库维护一组数据 专门用于测试这个接口执行完毕后把数据还原 天10:48:41 z 上海—橙子探索测试 你这本来有就依赖关系的除非你再数据库维护一组数据 专门用于测试这个接口执行完毕后把数据还原 zx 我以前也是这么想的但是没有实现 zz 10:49:22 翡翠 不行上容器开虚拟数据库 天锥树 10:49:23 数据都是在数据库中准备好的直接跑接口来验证逻辑比较麻烦的是维护数据 zz 10:49:26 这是啥意思啊 天 10:49:46 什么是虚拟数据库啊 z 10:50:30 把业务熟悉后维护起来也不是很难 翡翠 10:50:54 开个容器容器里面有数据 翡翠 10:51:09 因为数据库是假的你随便弄 翡翠 10:51:19 不考虑环境污染那些 翡翠 10:51:23 反正最后都要删 z 10:51:54 数据不一定要存储在数据库可以用文本执行前写入进去就好 z 10:52:02 执行完毕后再删掉 zz 10:56:48 意思是我们自己copy一套生产坏境的数据库 zz 10:57:10 跑case的时候 把业务服切到虚拟数据库来 翡翠 10:57:49 case就在容器里面炮 翡翠 10:57:51 跑 翡翠 10:57:58 具体你看一下docker 上海—橙子探索测试 10:58:24 天 各种sql都会的 上海—橙子探索测试 10:59:13 增删改查 zz 11:05:19 在哪里跑有什么没关系呀 zz 11:05:31 你总得连服务器啊 天 11:15:23 上海—橙子探索测试 天 各种sql都会的 上海—橙子探索测试 搞那么多sql还真不如调用接口来造数据。万一sql错了出现的问题开发肯定不认而且还会是觉得浪费他们的开发时间。如果接口造的数据有问题绝对是代码的问题开发跑不脱 天11:15:55 反正接口之前有依赖的自动化很麻烦 像风 11:17:28 sql性能高得多 像风 11:17:43 开发给你sql就行了啊 上海—橙子探索测试 11:19:11 嗯 各有利弊吧
讨论2
橙子接口自动化中前置数据大家都是怎么准备的
橙子我发现前置数据又是一个大头
H前置数据是指传参
橙子比如要提现是不是要登录、实名认证-审核、绑卡-审核、充值
橙子这只是一个示例 也许实际项目中更复杂 涉及多个系统
H这个是 挺复杂的一个而且还是必须的接口之间存在很强的依赖
橙子我们目前1个项目涉及3个系统交互的我目前走的sql单发现走sql需要对业务逻辑、表关联需要非常数据且sql之间页存在依赖有点麻烦
H1.从接口关联方面做2.通过sql方面做
橙子感觉还是sql简单点
H嗯嗯如果表关联很强不建议走sql方面除非是 把涉及的表关系理的很清楚
橙子是的 要不然数据容易错且如果表字段、业务一旦发生变化sql随时需要改动
H不过这些如果发生变化那对应的 接口 也会有变更的从接口方面走也的改 由以上总结得出
1、调业务接口构造前置功能数据更合理避免出现错误数据导致测试结果的不准确、接口会被重复调用多次
封装被调用的独立方法需要时直接调用判断是否成功如果成功进行响应数据提取进行下一步接口用例测试如果失败直接报出失败的接口不进行下一步接口用例测试
2、使用sql操作构造前置功能数据不推荐使用容易出现数据错误导致测试结果不准确或不稳定性、对业务熟悉度表关联关系熟悉度要求高
根据业务关系、表之间关系封装构造前置sql和数据清理sql再用例执行前进行前置功能数据构造调用和执行后进行测试数据清理还原保证用例可重复执行
3、根据实际情况合理选取
由于只是针对提现接口进行测试所以重点不关心实名认证、绑卡、设置交易密码模块故1和2都可以
