App UI自动化测试中，稳定性差、可维护性差、执行效率低的解决方法和应对策略

稳定性差

UI测试的不稳定性主要来自两个方面，一个是被测对象的不稳定，一个是测试代码的不稳定

另外，测试框架的不稳定，在早期阶段确实是这样，不过开源社区的发展和努力，现在测试框架已经越来越成熟和稳定，所以由此带来的不稳定性可以忽略

稳定性非常重要，不稳定的自动化测试如果一直持续，会逐渐让开发和团队成员失去信任，所以测试的稳定性直接决定成败

被测对象的不稳定

在UI自动化测试中，由于盛行敏捷管理，需求变化快，导致UI经常变化

建议：

• 准确把握介入时机，不要在项目早期介入UI自动化测试，等待版本相对比较稳定成熟后在开展UI自动化测试
• 优先实现较稳定模块的自动化测试

测试代码的不稳定

测试代码的不稳定主要体现在经常定位不到元素，从而容易失败。有时候会有莫名其妙的原因导致测试失败

建议：

• 元素查找方式使用更稳定的id，xpath等方式，使用数组方式定位查找一组元素，有可能出现数组越界异常
• 元素查找时间适当延长，应对不稳定网络情况，我一般设置全局时间是30秒
• PO设计模式的页面类的构造函数中，加入一些判断条件，确保页面加载完成再进行UI操作
• 使用适用性更广、更通用、更稳定的断言方式，尽量不依赖UI元素作为断言，例如判断处于某个界面可使用Activity
• 尽量使用逻辑验证，减少数据验证，数据验证更适合接口测试。过多的数据验证牵涉到更多的UI元素，容易导致测试不稳定。我曾经把商品订单页、确认订单页、订单详情页全部字段进行校验，有20多个字段，这是非常错误的，不仅耗费时间，而且会导致测试用例不稳定
• 更新到最新的版本Appium，更稳定
• 尽量不要用sleep，将sleep方法封装
• 保证稳定测试环境：网络、测试系统和被测系统、测试账号等。测试数据在测试完成后需要重置

可维护性差

可维护性是UI自动化测试的另一个难点，直接决定效率。为什么录制的脚本都不算自动化测试，就是这个原因

建议：

• PO设计模式
• 抽取页面公共方法，抽取测试用例公共方法，抽取常用手势操作方法
• 测试数据和测试用例分离，测试用例和业务逻辑分离，页面元素和页面操作分离
• 同一个类中测试用例链式依赖，方便增减测试用例

执行效率低

UI执行效率慢，这个倒是客观原因，因为需要模拟用户真实操作

建议：

• 科学的设计测试用例，精简价值低和效用低的用例，用例不是越多越好
• 测试用例前置条件和后置条件使用BeforeClass和AfterClass，这样一组测试用例只需要执行一次前置条件和后置条件。好处是大幅度提升测试速度，缺点是，这一组测试用例是相互依赖的，其中一个测试出错，会影响后面的测试用例。所以控制一个类中的测试用例数据量在10-20个为宜
• Appium执行器使用uiautomator2，执行时间可减少三分之一