为你们点赞

我没有继续研究这个工具了。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 上面。 这样在大版本回归测试的阶段，我们可以直接看到自动化已经跑通了多少用例，剩下没跑通的就通过手工测试去补充。
之前没有打通这个链路，是每个测试的同事要根据自动化的结果把用例一条一条地去标记结果，很浪费时间。

我考虑单独写一篇介绍

趁你老板不注意，偷偷把你的计划给改了

如果你纠结的是测试场的数据不够完整，那么给你半个月时间去测也不一定能发现线上一样的问题吧？

我觉得最重要还是把你们的流程梳理清楚，每次要上线的内容是不是严格控制的，版本管理是否合理，是否能快速地完成在测试场和预发布版本的针对性测试。只要这个测试是精准的，代码合并和发布的流程是正确的，再加上足够快速、通过率高的自动化测试，那么每天发布也不是什么难事。 像 Google，Facebook 这样的公司每天都不知道发布多少新代码。

看提示是初始化失败，请检查你的 selenium server 是不是正确打开了，也看下是否有成功注册到你的服务中