自动化测试工程实践之路
1.前端Web自动化测试方面，是在Windows环境下还是说其他环境下跑
实际项目会在Windows上跑，但是实际是不区分系统，我们也调研过Linux系统的支持，但是没有用户基数的支持，所以没有制定Linux下的策略。
2.有哪些好的分布式集成器推荐
我们主要是通过jenkins集成操作，不会通过测试工具的分布式。我们会通过在Jenkins中拉起一个任务，去执行相应操作。
3.UI自动化是以代码的形式存在还是平台的形式存在，以及使用了哪些技术栈。
因为我们需要顾虑到成本的问题，所以不会首先考虑测试平台的形式，UI自动化主要还是通过代码的形式。我们先把框架本身的技术建设好之后，再做一些平台，例如说任务管理，设备资源管理这样一些调度。
UI框架本身用的是Python，平台的话是Python和go。权限控制会通过OA系统对接，避免重复造轮子。
4.UI自动化的维护量和维护成本太大，有什么好的解决方案
我们从实践的经验来看，我们会把一个框架推给不同的业务团队，有的业务团队他们本身很复杂，但是他们的自动化效果会很好，另外一些团队可能业务量没有那么复杂，但是维护量会造成一个无法维护的状态。其实这两种团队的差别在于第一个做自动化测试的这个人是否具有好的意识，如果在写自动化的过程中去做一些优化，让后期的成本更小。或者说，是否有一个好的把关人来把控成本的问题，这些其实可以从人的层面来解决，没有办法说通过技术手段去解决。
5.如何去学习全新的框架，例如可能不支持Pytest，文档不全的情况
其实源码是最好的老师，或者通过调用接口层来分析关键信息，底层支持则通过查看底层接口。例如费曼学习法，可以讲明白一件事，就是最好理解一个框架的方式。
6.app多语言自动化测试
这也是我们的痛点问题，我们现在的方案是把多语言的文案交给产品和运营去维护，不会一开始就写死在代码。他们在平台上维护的时候会有一个文案id，然后我们在测试的时候把文案id扫描出来。例如我们进行英语测试，控件信息的拉取会是英语的那一版文案。然后因为我们已经把控件信息和业务逻辑抽离出来，业务逻辑不受语言影响，只受控件本身的文案影响，这也是前期我们做了架构设计后，后期维护成本降低的一个具体例子。