好的自动化思想永远是适用的，只不过能做到的人真心不多，所以造成一个现象，大部分人做不起来 UI 自动化的理由都是维护成本太高，而不是认真分析问题。

看的心酸和感动

第一次触电，是 2014 年在山西工作，那时候是因为测试小道消息，知道的 testerhome。
为未知的梦想捐助，后来 14 年 11 月份去了广州，也不断的接触测试行业的前辈，15 年在广州期间发现 testerhome 因无力续费服务器无法访问，果断捐助 1000 元。还记得当时捐助的寄语是：“希望 testerhome 不变初衷，为梦想”。
面基思寒，15 年 7 月份来北京工作，认识了思寒，面基之后发现，这人没问题，充满了理想主义。
至今天，陆陆续续认识了 026、俊哥，还有很多未谋面的，默默为 testerhome 做贡献的小伙伴，感慨良多。
期望，未来的发展，少不了反思和感恩。也许应该感谢一下那些昨天还在，今天不在的人。

testerhome 已发展的越来越好，也希望自己的路可以越走越好。共勉之。

可以不完全同步，但是同步的信息要一致吧？比如同步半小时内的信息，那半小时内的信息就要完全同步，不能丢信息吧

嗯嗯，已提建议，多谢

哈哈，下个月开始

挺好，可以增加遍历方案的对比，哪个好用用哪个

特定时间做是否存在的判断：
1、不灵活，也不稳定，特定时间本来就是一个不确定的事情；
2、特定时间去做判断，有时间差，务必需要用循环，每隔一段时间就判断一次，耗时太多，影响主线程的用例执行
3、兼容性，并不需要所有的设备都会触发某些场景，所以不需要每个设备上运行的用例都在主线程中做判断

不会，这边每次生成的报告，都生成到了指定文件内，递增的顺序

是的，这个时间没有考虑，严格来看应该要考虑，我优化一下，多谢

什么意思啊？没看懂

嗯嗯，这个肯定的，要是实在无法相处的，那就只能走了

以前我也觉得要么干，要么滚，现在开始带人后发现，以前的自己挺傻的，很多时候换位思考，真的会不一样

有效的沟通和充分的换位思考，可以解决大部分工作痛苦的情况

没有明白这块引用别的用例有什么问题，用例独立指的是该用例可独立运行，测试框架的 testup 和用例运行前引用登录用例，效果不是一样的吗？

是的，平台做集成、调度、统计和展示会好一点

我们也是去年尝试了一年，现在全部回归手动写脚本了

百度云盘给你吧，链接:https://pan.baidu.com/s/1w8NKkLI1gDKKG2fMb1c17Q 密码:zb36

除了自动化，还有各类测试工具的开发和集成

给我个邮箱，我把源码发你

对，我们现在从 UI 自动化开始，要全部写脚本了，将写脚本的过程 UI 化是行不通的。
但是其他可以集成的工具，是需要集成到平台上的

因为还有很多数据统计、数据展示的，除了自动化，其他的专项测试封装到了 web 平台中，做得不好用，确实没人用😂

我觉得 UI 自动化平台，就像一个产品一样，产品逻辑其实没有那么简单

飞哥，有时间了，能不能写写你们的自动化平台和框架设计，特别想取取经

飞哥，有做失败用例的问题分类吗？因为我发现有时候是框架的不稳定，有时候是应用不稳定导致的。
你们的重试机制是怎么样的？我们主要是 APP，你们主要是 WEB 吗？