我们现在的 UI 自动化就是用的 robot framework，当时在调研做 api 自动化的时候也考虑过 robot framework，也做过一些 demo。
当时的考虑是我们的 api 测试涉及到大部分都是数据的处理，和 robot framework 擅长的 bdd 关系不大，反而各种数据处理是 robot framework 不擅长的。所以后来我们改用了 pytest 。

谢谢。排版这部分和之前编辑的有点出入，有空的时候我再改一改

其实 rf 已经把大部分的 selenium 常用的操作封装成了 keyword 可以直接操作，而且自己用 Python 去基于 selenium 去扩展新的关键字也非常方便；report 方面，可以用 rf 自带的 report 格式，也能通过 allure report，也是方便的。

我们团队已经基于 rf 维护了几千条用例，基于 selenium 的用例非常稳定（只要 selenium 自己没问题）；每天不同级别的 pipeline 也都很顺利地在跑。

总而言之，rf 是一个框架，它的优势是用自然语言定义关键字，用 BDD 的格式组织用例（和 cucumber 这种框架是一样的），并且基于 Python 可以快速地扩展。每个框架都有自己的优势和缺点，关键看怎么去建立适合团队的规则和工作模式。

为你们点赞

我没有继续研究这个工具了。cypress 现在应用得挺广的，肯定有很多人已经踩过了坑，你可以在论坛里搜一下。

为什么麻烦呢？每个框架都有它的优势和缺点啊，而且 rf 也有很多使用场景的，用的人也不是少数，在合适的团队里面也有它适合的土壤。

https://mp.weixin.qq.com/s?__biz=MzI0MjIyMTYwNA==&mid=2651220780&idx=1&sn=2822f55c742ac7f7bd7b6873f87f388c&scene=19&ascene=7&devicetype=android-31&version=28001c57&nettype=WIFI&abtest_cookie=AAACAA%3D%3D&lang=zh_CN&session_us=gh_02e3ae2052f9&exportkey=n_ChQIAhIQRiy45axFfmdPcE6fxBcIjhLlAQIE97dBBAEAAAAAAFRhIGtGBMkAAAAOpnltbLcz9gKNyK89dVj0fF9AYI8KKP6%2BbNKVqW%2FrnxodxiY49CVmxYEWAojoizoYY8FS%2BUKho1wcVFVTMXayOE6yfZo83HVVHXZIYAeZXuXCNWpx%2FnDL9CdJPWNw%2BMy2JbymJrSOvTp%2BgONJy6UPbtOlAdI56mWc4R0p5sqcrVsVVGQJwu4e7NwJlG2T127yb01TdMkCuVLvmby9lCNInwQGBNwXQXEB3bs%2F2wJejDMmXw2mZCfGS%2B0OcMfEwM3aM%2FpB04F03DkbJpEGP%2BE%3D&pass_ticket=AN2Bm%2BRgcwSvbgPi1BNpCpt1DxR45HmJbXO14U1IczaX7L7R0fEttZCipskI5B0q&wx_header=3

以前使用过 tsung 这个工具，好像单机发起的请求能力比较强。仅供参考，因为已经是几年前的事情了，我也没有那么高并发量的需求，所以没深入去看过。

不差钱的话买最新的吧，或者都买

Weditor 确实挺好用的👍🏻

找你们公司的财务商量好，测完之后，要么给你报销，要么直接给你退。

我们的做法是在 setup 里做处理，确保每条用例是从指定的页面开始。
在 selenium 里面就是把这个页面的 URL 保存起来，在这一步就是强制跳转到这个页面；
在 appium 里面因为没有指定页面跳转，所以一般是点返回，直到返回到了想要的根页面为止。

如果返回某个页面出错了，还会重新登录。

整个过程处理起来比较复杂，但是对提高整体的通过率是很有帮助的。

主要是要保证配置不出错，所以直接对部署后的配置文件进行快速检测可以发现大部分问题；
图像检测也是一个思路，我们也有 diff image，图片对比的方式可以快速识别出那些元素的翻译发生了变化，配合手工检查进行验证。

Rf 本质上也是调用的 selenium 库进行测试，所以你先查一查服务器上面的 Chrome 是不是可以正常被调起的，比如写个简单的 Python 脚本直接调 selenium 去启动

你是要工作日报还是项目的测试日报？

如果是工作日报，就写你做了什么，有什么后续跟进，遇到什么困难；
如果是项目日报，要分几个部分

1. 项目总况。当前测试准备，测试执行，回归测试的进度分别是多少，总体状态是良好还是高风险；进度最好有计划的进度和实际进度进行参考。
2. 如果状态是非良好状态，要写明是什么原因导致的（比如有什么环境问题或者缺陷阻碍测试，或者开发交付延迟），以及需要怎么样才能回归到正常状态（问题什么时候之前就要解决，或者是否需要延期或者加班赶进度）。另外写清楚对应的责任人是谁，哪天是 due date。
3. 当天的更新内容，比如今天完成多少用例的测试，完成多少故事，提了多少 bug； 因为什么问题导致测试被阻碍了多长时间，谁在跟进或者需要谁的支援解决。
4. 具体的测试内容状态。比如用例执行的状态表，缺陷的状态表，等等。

搜一下有没有现成的资料？ 今天公众号刚刚推送了这条

https://testerhome.com/topics/34598

我们已经用了三年多了，web 用 seleniumlibrary，mobile 用 appiumlibrary

没错，我们的自动化其实就都遇到过，有些是账号配置有问题，跑着跑着被其他 job 给踢了；另一种情况也遇到过，就是某些接口其实没有做 token 的刷新，导致有效时间没有重置，也就发现了某些 bug

如果对用例管理，或者执行统计，燃尽图之类的有需求，可以考虑一起加进去。
我们针对用例部分的效率提升，除了是和自动化用例挂钩之外，还有一个就是将 xmind 的测试点转换成 jira 的 Excel 模板格式用例，达到批量用例上传的效果，提高用例的转换效率。

你们用的是什么框架？
我们这边是在原来的 pytest+allure 的 api 测试上面加入了 pytest-xdist 插件来做并发执行，对结果没有什么影响，allure 里面还是能正常看到每条用例的日志和输出。

公司很少会招应届生做测试，所以没什么面试校招的经验；不过感觉和社招的面试还是很像。

写出来了，推广得怎么样呢？ 有什么效果跟踪，优化增强？ 实际上的使用效果和反馈怎么样？

简单来说： 写过=完成了吗？

token 的过期时间，体现在业务层面就是：

1. 如果我已经离开，或者结束操作了，会不会在一个安全的时间内，把我的 token 给失效了，以防止有人盗用？
2. 如果我一直在操作，或者没有退出并且距离上次操作的时间不那么久，会不会 token 失效导致我需要重新登录，打断我的操作体验？

所以这两个场景是相关联的，既要保证有效时间内继续保活，也要保证超过有效时间之后能正确失效。

按楼主的例子，如果你的用例一直在执行，等同于客户一直在操作，那么到了后面突然失效了，就是没有保障到第二点，就有可能是 bug 了。

1. 你们 token 不会自动延长有效时间吗？也就是说如果有请求把这个 token 带过来，就会把它的有效时间重置为默认时间（一般都是 30 分钟）？ 这样如果你的用例都是一直正常在跑，除非有些用例等待时间超过了三十分钟（这样的话要考虑换成异步处理），否则不应该出现超时的问题。
2. 用例过多，可以考虑 pytest 的插件改造成并发运行，提高执行效率。

我们在自动化用例的注释上面会加上对应用例的 jira ID，pipeline 会在跑完自动化用例之后会自动收集执行结果，然后调用 jira 的 api 把结果更新到对应的 cycle 上面。 这样在大版本回归测试的阶段，我们可以直接看到自动化已经跑通了多少用例，剩下没跑通的就通过手工测试去补充。
之前没有打通这个链路，是每个测试的同事要根据自动化的结果把用例一条一条地去标记结果，很浪费时间。

我考虑单独写一篇介绍