然而最终还是弃用 rf 了，

觉得异步在接口测试框架中用处不是很大，接口本来就很快，而且往往需要借助 pytest 等单测框架一起使用，http 接口一般用 requests 比较方便，如果用 py 异步的话就不得不考虑用一个不成熟的库以及与单测框架是否兼容的问题。

用例交给手工测试一起完成

接口测试是单接口测试，你这样写用例是用接口覆盖业务了，一个接口一两条用例足够

个人觉得测开还是开发，只是客户是测试甚至是研发团队，需要熟悉业务，知道痛点，思维和业务开发不同，要具有测试和开发双重思维

大佬，请教一下，为什么大部分人封装 requests 都会封装 json.loads（）？为什么不先判断返回的状态码是否正确？还有您用例里考虑的这几个参数就足够了吗，会不会有一些参数没有考虑进去啊

命令不一样

周六登录了网页微信，再打开这个网站，开始还以为被微信劫持了，小程序里打开的页面

你是说 rf 吗，能详细说说为啥用例多 rf 就没法维护了？

嗯嗯，其实想继续问下如何做出一个让大家都觉得效果不错的框架呢，在开发之初就应该考虑的东西？而不是做完了发现很难用，而且准确率不高，效果差。目前想到的是写完一个模块要和手工联调，问问他们的意见

回帖楼层被吞掉了，只能收到消息提示，楼层没有显示

主要是想请教如何将情怀落地，也就是真正做出有效果的工具让大家使用。而不是自嗨。最后做出的东西没有用，这个过程需要注意哪些地方，比如开发某个模块和经验丰富的手工多交流？每做一点有个评审？你们是怎么处理的呢·

第一点 RF 也只是试点，而且做出来问题很多，可以说基本没用，老大也说只是个人做着玩玩，没有实际用在工程项目上
第二点推 RF 的人在一个部门，不过不在一个组，其他几个自动化测试都是新来的，他们明确支持我使用的框架，因为可定制度高
第三点老大和部门经理都比较支持我，推广出去的意思是让手工来一起联调，提意见，帮助转化自动化测试用例，毕竟贴近业务才是有用的。要让手工模块负责人放心这部分模块可以交给代码去做。
第四点我这个框架本来就是要做在与之前 RF 不同的全新的业务线上，而且协调其他自动化测试在这个业务线上统一用这个框架，老大说过的

具体说说呢，之前他们跑 ui 自动化一万条用例用 rf 似乎很痛苦，我想听听你的经历，更有说服力

已提交，调查问卷多久出结果呢

pytest4.0 哪里和 allure 不兼容呢，感觉 ids 就在 allure 上没有展示

楼主大大，我加了 ids，为何 allure 上不显示哇

大佬的年终总结什么时候出来哇，期待脸

yaml 是不是更好的选择，既可以有利于维护和解读，也不用读表格

其实我想说，读取数据文件进行测试是为了方便写测试用例的人和写工具的人分开，毕竟直接在代码里改测试用例风险比较大，开发者自己有时候都可能手贱改残代码，何况是两个人合作开发

selenium3 显示等待是不是有坑哇，设置显示等待很长时间还是大部分时间点不到右键菜单内容，静态等待一秒要好很多

能大致说下理由吗，我也隐约觉得表格限制很大，正在改用 yaml，就是不知限制到底有多大

不忘初心，方得始终，也许社区不应该是一个优秀文章集散地，更应该是一个组织，组织才有强有力的号召力

我觉得社区开源精神和借助社区隐形收费还是要规范一下，不能在暗地打广告，大佬们商量一下如何平衡一下开源和商业的界限，社区还是纯粹一点好，不然新人一来一看还以为是 51tester 翻版

对，我认识的大牛为了技术都想跑美帝，半夜睡觉做梦想起来有个好点子都会兴奋的爬起来敲代码实现它