有个疑问，对于第三点提到的场景，第一个环境点完了，后面的可以直接回归。但不同环境数据乃至账号都不一样，怎么确保录制的脚本在数据不同的情况下还能正常回归？
另外，录制的脚本，对于界面关键元素展示的校验，应该还是得手动加上的吧？

由于翻页后，元素未来得及刷新就开始获取了

人肉是如何确认元素刷新完的？把这个标志也引入到自动化里面作为确认刷新完成的标志？不用 sleep 的话必须找到合适的标志表明刷新完毕。你现在问题是找到的标志不可靠。

另外，也可以换个思路，只要出现 IndexError ，那么就捕获这个异常，并在捕获异常后的逻辑里二次校验此刻表示界面共有多少条数据的标志是否等于当前 index +1（这个时候如果这个标志还没刷新，可以直接给研发报 bug 了）。如果是，那就直接吃掉这个异常当做用例成功就好。虽然有点坏味道（把异常当做业务逻辑处理），但这个场景下这种方法会比较简单

但是每次线上出 bug 的时候 下意识的第一个想法 都是 这个测试是不是不靠谱啊

这种情况，就得在线上出问题后复盘时，测试一起参与甚至主导了。先得要明确，线下的测试无法发现线上所有缺陷，有的缺陷确实是测试环境无法复现，或者测试成本极高的（比如必须要用线上的数据才能出现）。另外，要引导说明，预防这个问题再次出现，测试、开发甚至产品需要做什么。让老板知道，解决问题不只是测试要干活，开发、产品都要干，意味着他们都有责任。

不过有一个基础要做好，不要出现那种很简单就能发现而且是 P0、P1 级别功能的 bug，并且造成不小的损失。出现这类问题，不管怎么说测试都有责任的。

但是公司只会换测试而不会去换开发

那可以预见换多少个测试都没用，因为 bug 都是开发写的。。。

开发技术越弱的团队测试地位越低

不一定呀，只要测试指出了这个点，并且去各种推动开发提升自己技术和质量，那测试地位就不比开发低。如果说测试只会在出问题后后知后觉，那地位肯定高不到哪里去。

最后多少几句，如果说老板本身的态度就是 “测试是为了保障系统不出问题的，出问题都是测试没做好”，那就要明确，要做到确实没问题可以，成本增加 2 倍甚至 3 倍。就像同一个代工厂，可以生产高质量的 iphone，也可以生产低质量的山寨机，只取决于你的质量标准多高，愿意付出多少成本去覆盖不良品和检测成本。老板们都不笨，所有缺陷和故障背后都有 roi 的，比如一个服务器机房造成的故障，作为公司要彻底解决那可能得多地灾备或者搬另一个机房，但如果这个缺陷其实造成的损失不大而且出现频率不高，最后其实还是会保持现状的。

另外，感觉你有点悲观，观点里有许多 “不现实” ，“不可能” 。积极点看，应该是 “很难” “几乎不可能”，但概率绝不是 0。确实个体力量很难扭转大局，但从自己做起，由己及人，积沙成塔，也是能产生不小的影响的。莫以事小而不为，只要觉得正确，就去干吧。

我也不大清楚，没怎么用过。只是直觉上觉得这个选项和重复执行场景有比较大关系。

提示无法找到该用户，你注册钉钉用的是这个邮箱吗？

建议说服开发开给你就好了，没必要为了一个几分钟加个开关 + 切 webview 就能解决的事情，想各种曲线救国

既然开始做 ui 自动化了，就得想办法拉上开发给你提供便利，高大上点说就是为了可测性进行调整。曲线救国会明显降低 roi，引入更多工具也会让自动化变复杂、变慢和更不稳定，而且后面总会遇到没法曲线救国的地方，这时候才找开发人家已经习惯你单干，不一定愿意帮你

可以通过沙龙等活动，认识一些朋友呀

社区也可以，不过一般还是线下活动效果更佳。

这个就要和老板沟通了，否则测试永远都没地位。
不过一般至少 CTO 级别的还是了解测试是不可缺的，cto 控制好也可以。

所以开干前，做好充分调研很重要。多找一些志同道合的人，遇到这种情况可以沟通商量下，有助于扩展视野和少走弯路。

不过沉淀记录好你这次踩过的坑和解决方案，其实也不亏。以后总归会遇到没法 vnc 或者虚拟机的情况，到时候就能用上了。

试下把这个重置改为 true ？

这。。。你钉钉多少，我拉你？

你这个定位的 xpath 不大对吧，标题的截图里，这个 input 元素明显是在 td/div 里面的，但你 c3 对象对应的 xpath 只是到了 tr 级别，所以对应的并不是 input 元素。

另外，既然开发能让你从控制台（console）拿到值，那是否可以考虑直接用 execute_script() 方法执行那个控制台（console）能拿到值的代码？

toB 产品，一般乙方应该可以提供需要兼容的浏览器版本清单吧？

toC 才是采集用户数据，因为用户没法主动告诉你。

INTERNALERROR>   File "/data/longfor_oa/conftest.py", line 149, in _capture_screenshot
INTERNALERROR>     driver.save_screenshot(screen_path)
INTERNALERROR> AttributeError: 'NoneType' object has no attribute 'save_screenshot'

把 /data/longfor_oa/conftest.py 这个文件的内容发上来吧，从日志上看，直接原因是调用 save_screenshot 时，driver 对象还是没被初始化，还是最初的 None 。但具体为啥是 None ，不看你写的代码看不出来的。

当领导问你：你怎么确定你测试过的的数据是对的

我理解你说的这个，是测试出来的结果和数据使用方的数据口径是否一致的问题，类似一般功能里的 “是否满足需求” 问题？
也想听下你的想法。

信息太笼统了，至少把相关 stf 服务的日志、手机 Logcat 、你这台手机的详细信息发一下？

补充一个点，如果是在你说了你的期望薪酬后问这个问题，基本就是说明你提的薪酬期望比他们预期的高了，他们想借这个问题卡你一下，好找理由把薪酬降一下。属于比较套路的问题。

对于你提到的这两个问题，我曾经呆过公司里看到的情况是，大数据团队都是自测上线，靠计算结果的数据监控来发现问题和修正问题的。测试团队基本不介入这部分测试。

所以我是基本认同飞哥的观点，不了解背后的技术或者复杂的业务，是做不好大数据测试的，至少很难让大数据研发团队信服你的结果。

另外，谷歌了下 test oracle ，有对应中文名称，叫做 测试准则 。不过这个词的解释我看了好久也没看明白，它涵盖的范围有点大。所以也很少用。

终于看完了，大数据只了解皮毛，勉强能跟上

好奇问一个点，这里提到测试是否有达到数据一致性的方法，是注入故障。那具体怎么注入才能保障能做到文中期望的端到端上每个点的 exactly once 做到位，避免遗漏？

同意一楼说法，了解他们要什么，你匹配了什么，然后直接讲就是了。

一般能聊到薪资这一步，说明你还是匹配他们需要的。

按以前对 appium 底层 dump 元素用的 uiautomator 原理看，用 locator 定位，前提是要能拿到完整的元素树。但元素持续高频变动，那元素整个树的结构就不稳定，导致很难 dump 出来（dump 基本要从根节点开始向下递归，会有一定耗时）。这个原理决定了比较难用 locator 定位。

相对坐标这个方法还是挺不错的，如果担心由于设备屏幕大小不同导致坐标要适配，可以考虑用图像元素识别类的定位方法。

写有什么是比上一年做得好的，甚至是从零突破的。

乐观积极是好事，确实测试开发的技术潜力是挺大的。

但有些点想要纠正一下：

首先，不是学会一点技术就容易上升，是做出成绩才容易上升。任何时期，任何公司基本都一样。只是刀耕火种的时候，做出成绩会相对 “简单”。而且刀耕火种的时候，技术其实反而复杂，门槛反而高，比如没有类似 antd design 或者 element-ui 这类前端框架的时候，大家直接撸 html+css+ 原生 js，还得关注各种浏览器下的兼容性（比如万恶的 IE6），比调用模板复杂多了。能做到在这种情况下提取成框架并且经受住业务考验，一点都不简单，只是现在你都知道答案了，会觉得简单。

另外，测试开发大概是 15 年左右开始兴起的概念，现在我理解应该不至于是混沌探索了，比如 UI 自动化和接口自动化的框架，已经基本是一个百花齐放的阶段。当然，机会还是挺多的，但不是那种简单学学技术就能上升的了，得有业务落地的能力才行。

不错的文章，加个精

建议目录加一下中篇和下篇的地址，并且说明下原文出处？

邮件是怎么发的？jmeter 和 ant 应该都没有自动发邮件的能力吧。

只要有源码，没啥是改不了的。