其实还有一个文件夹，用来写压测脚本，log文件夹中的path以及data都是直接可以在locust中使用的，省了构造数据的时间；
哎，苦命啊，前端赶紧进行插桩操作，报错日志上传起来；鄙人只能放大招了，拾起了爬虫思路，自动遍历吧；
这里是默认加上token的，但是并不是所有接口都是需要token，解决思路：再加个configHttpNormapy。
鄙人一介小测试，一手承接产品，一手面对开发，项目经手了5批人，鄙人是第5批的测试，规范没有，前人积累没有，天崩开局/(ㄒoㄒ)/~~。
之后优化思路：将regression_testing里面的方法改成test_*，写一个run方法，加上测试报告，邮件通知
老规矩，下方直接执行，可以进行单接口的相关验证。
case：用例文件夹,敏捷模式中开发提测基本上都是单接口提测，而且同一个模块下的接口分给了不同的开发，为了方便定位到开发，所以我将平台所有的接口都写了过来╮(╯▽╰)╭，
common:公共方法文件夹，最省事配置：日志封装，请求封装
regression_testing顾名思义，回归测试ing，只有进行时，没有完成时……
老规矩，上：
相信各位也看了很多的接口自动化测试框架，我上面的应该没有多少新意，下面就是不同点；
上是使用unittest框架进行的，用例之间传参用法其实就是我上面展示的一部分；
毕竟服务间的调用是复杂的，将各个接口封装起来，对应的py文件里面创一个main方法，用于单个接口入参以及返回值之间的验证，至于接口之间的串联，那就放到下面，辅以逻辑处理，大部分的流程还是可以自动化实现的。
怎么，是不是有一种UI自动化里面的POM思想？没错，这正是这个思路在API自动化里里面的一个体现。
鄙人将前端的业务逻辑通过接口层模拟了过来，做了许久之后，不禁产生了怀疑：这都是哪位鬼才设计的？没有被开发XX了吗？
这个不直观，下面我来展示这个抽象的片：
其实这个文件夹下不适合使用unittest框架，因为通过用例之间的巧妙设计，虽然可以将业务之间的调用状态都模拟出来，但是由于脏数据的存在，某些bug没有在这些测试过程中表示出来。
对于同一个系统中需要多个用户参与的过程，这时候就需要配置文件里面再多一位用户的账号密码了，再加一个login()方法并赋值，下面的对应的基础请求封装里面要再多一个参数：is_other_one,默认为false，一但给true，下面headers就要换参数中的值；
文章为作者独立观点，不代表股票交易接口观点
相关文章
股民评论