对于业务流场景测试，我觉得很有必要，甚至做得好，单接口巡检都可以忽略，因为业务流中差不已经覆盖了，只是业务流的场景用例需要用脚本去实现，代码量相对比较大，如果有一个更好的平台来支撑组装用例，可能会更通用，减少编码的成本

赞同

楼主在哪，来我公司吧😄，我最近在考虑一个问题，想做一个类似与这样的平台，先只实现业务流的接口测试，感觉有难度，比如一个用例可能需要十多步操作，一个测试集可能多个用例，变量的传递这块还没弄清楚

我也想做一个这样的平台展示数据，可能就是前端不太熟吧😄，有点心有余而力不足的感觉，楼主你说学点基础就能搞成这样，很不错了~

我现在有家庭在这边，目前不在深圳，谢谢了，有需要再联系你咯~~

这样做接口才有意义，我现在业务流覆盖功能测试 1000 多条用例，覆盖率 60%

我觉得你超级牛🐮了

如果有些项目需要构造数据，这个恐怕不好弄吧，目前看好像很多要写死参数？

这个相当于是低层 selenium 实现，然后把用例表格化么？我做了几年 UI 自动化，确实代码量太大，如果这样感觉写用例起来快很多，就是不知道是否稳定？还有多个浏览器及窗口切换支持么？

薪资范围太大，要求不算高，就看年终是二个月还是 6 个月，哈哈

不错了，再优化下报告，就更完美了

jira 不是有现成的 filter 么，支持导出各种格式

这里都是满满的正能量，想法挺不错的，给个赞

我觉得还不如直接自己写一个 excel 报告来得直观

不错，有空我也看一下

如果一个 py 包含多个 testcase 好像只能执行一个，去掉 return result 就好了

前提是看你实现的是哪一种接口测试，楼主说的是单个接口的测试，目前就拿我们公司项目来说，之前还对单个接口做设计过用例，后面觉得意义不是特别大，就算发现一小部分提示问题，开发也不愿意改，测试这边重视度也不够，索性目前只做基于业务逻辑的覆盖测试，这样即测试到了 API 接口（当然，这里纯碎是验证一种传参的情况，不考虑异常等情况），也覆盖到了相应的逻辑，我觉得这样也是可以的，关键还是得结合自己的实际业务和项目。

python

工作 6 年，受益非浅，前辈讲得很有道理~

工作 6 年，受益非浅，前辈讲得很有道理~

只可惜在上海

appium 写错了