@seveniruby 百度网盘 Chrome 不让下载，直接报病毒！

@monkey 不准备再发帖了！刚去读了一些精华文章，比如那个海豚自动化测试系统，感觉过于牛了。我发贴就是班门弄斧了。

真是 666666，大赞. 想问两个问题

1. 回放功能的稳定性如何？经过大用例实践后是否能足够稳定的回放？ 2.类似于 .tap("#index-channel > ul:nth-child(1) > li:nth-child(2) > span", { usePageDiff : true, waitTime : 2000 }, function(elem){}) 这样的录制脚本，可维护性还可以提高吗？总感觉 (1)(2) 这样的玩意儿是可维护性的敌人。

#5 楼 @m13890 目前只是刚刚搭建起来，正如我写的，还有很多功能需要开发，还有很多用例需要创建，才能完全支持公司的业务。所以现在还无法给出数据。不过可维护性和易用性还不错。后期会根据自己的想法和各位的建议持续更新效果。

@seveniruby jsonpath 我只是扫了一遍文档，发现就算是他最最基本的功能都能满足我大部分的验证需求，所以就选择了。具体复杂点的用法还没尝试过呢。慢慢试试看。 我想到 jsonpath 是当时总在想自己写一些逻辑去作接口返回的 json 验证。后来我想在用 webdriver 或者 appium 的时候都可以用 xpath 解析,有没有一种叫 jsonpath 的东西呢？于是 google 一搜，还真是有！

@monkey @seveniruby 第一次发帖不够详细，下次会注意！ 补充了一些东西！

我如何能加入到这个团队中来

#26 楼 @jason +1

个人认为 UI 自动化绝对不适合所有的企业，当然也不是所有企业都不适合。是否开展 UI 自动化应该从一开始就有一个基本的判断；如果实施，重中之重就是不能有过于刻板的生产线。否则就会出现题主数据中所反应的问题。

#19 楼 @oscarxie

大神们，其他我不敢妄言，但是关于 Flaky，你们的流程是怎样的呢？难道一旦 UI 级别的自动化报了错抛了异常，就直接丢给开发？例如 Web 的 UI 自动化，Chrome 和 Firefox 在表现上必定有差异，那么不同的浏览器执行的脚本必定是有细微差别的两套。假设用 Firefox 跑了 Chrome 的脚本导致失败，第一层次的把关人员应该是测试人员——去确定问题是由软件造成的（回归测试发现 Bug）还是 Case 本身的不稳定性。手工复现脚本中的步骤应该永远是第一步——打开 Firefox 确认 Bug。我相信作为测试人员——脚本的开发者应该很容易确定是否 flaky，对吧？

1. 似乎只有在这里才能看到一些关于这个行业的肺腑之言

2. 33 岁我必定能超越你，因为我 25 岁就看到了这篇文章

3. 评论翻页能否不要让滚动条回到页首

4. 还是信奉那句话：一流的测试就是一流的开发，一流的开发就是一流的测试。我们不只是测试人，也是 IT 技术人

为何大家都用 Excel？个人觉得比较臃肿。我目前在用 Java 开发接口自动化，思路和你一样，不过用虚拟机搭一个小型的 Web 加一个小数据库，方便实在，输出也可以写到静态页面在 web 上展示。这样不好吗？