UI自动化的策略

按照测试金字塔模型以及投入/产出比，我们得知越向下回报率越高。

所以应该使用大量的单元测试

全面的接口测试来覆盖产品提供的基本逻辑和功能

使用少量的集成（UI）测试来进行前端界面的功能验证。

上图是自动化测试方面经典的“金字塔”模型

• 越往上，越接近测试、业务/最终用户，越往下，越接近开发；
• 越往上，测试执行越慢，越往下，测试执行越快；
• 越往上，测试成本越高（越耗时，失败时的信息越模糊，越难跟踪），越往下，测试成本越低。

金字塔模型中的三类自动化测试

*从金字塔模式中引申出三类自动化

1)单元自动化测试

在计算机编程 (opens new window)中，单元测试（英语：Unit Testing）又称为模块测试，是针对程序模块 (opens new window)（软件设计 (opens new window)的最小单位）来进行正确性检验的测试工作。程序单元是应用的最小可测试部件。在过程化编程 (opens new window)中，一个单元就是单个程序、函数、过程等；对于面向对象编程，最小单元就是方法，包括基类（超类）、抽象类、或者派生类（子类）中的方法。

2)接口自动化测试

接口自动化测试，主要验证“模块”间的调用返回以及不同系统、服务间的数据交换。接口测试自动化一般在业务逻辑层进行测试。调用被测试的接口，构造相应的请求数据，得到返回值，是成功或者失败。不管输入的参数是怎样的，我们都将得到一个结果，最终断言返回的结果是否等于预期结果。如果相等，测试通过；如果不相等，测试失败。

所以，接口测试关注的是数据。只要数据正确了，功能就做成大半，剩下的无非是如何把这些数据展示在页面上。

3)集成（UI）自动化测试

UI层是用户使用产品的入口，所有功能通过这一层提供给用户，目前测试工作大多集中在这一层，这种测试更贴近用户的行为，模拟用户点击了某个按钮、在输入框里输入了某些指令。有时可能用户看到登录成功了，自动化脚本通过例如 登录成功后页面右上角会显示“欢迎，xxx”，来判断功能点。当UI自动化登录成功后，就去获取这个数据进行断言，断言如果相等，测试通过；如果不相等，测试失败。

所以，UI自动化的关注点用户操作形为，以及UI上各种组件是否可用。

小结：

1.在项目中，我们应该分层逐步实现自动化。

实现UI自动化的动机

• 公司价值上：没有UI自动化测试并不影响公司和测试团队的生存，但是会影响资源的分配

• 价值观：何应对其他部门对测试团队执行效率的吐槽？减少承接的需求、降低公司的发展速度、加人、找外包还是提高手速？自动化是这些解决方案里，对测试团队比较有利的一个

• 个人价值上：没有UI自动化并不影响找工作，但是会影响你的薪水

• 兼容性测试价值：没有UI自动化测试，兼容性测试是很难做好。当然了，很多时候我们确实依靠研发团队和用户来解决兼容性问题。

  本质只是看这几十万是怎么花的，要么是研发凭能力省下来、要么是测试凭能力省下来，要么是第三方公司凭能力挣的，要么是用户体验受损导致公司损失掉的。

• 非功能测试：内存泄漏、页面性能、弱网都需要对具体页面的访问，人手是否可以足够快的可以重复的在各种不同场景下巡回测试，或者有理由不测试，比如AB测试或者质量监控很好。

• 持续集成/持续交付：研发平均每几个小时就会打出来他觉得有信心的测试包，你如何快速的做出质量反馈。

如下场景可能导致UI自动化无用的结论

• 你的项目是一个接口服务，没有前端
• 你的产品单元测试、接口测试非常成熟，而前端团队很给力，有靠谱的研发团队在为前端质量兜底
• 你的自动化水平很差，搞自动化非但不成功还让公司损失惨重
• 你领导经过血一般的教训，接纳了UI自动化测试无用论
• 项目预算充足，能支持人肉执行足够的UI case
• 公司采取外包测试团队的策略，可以把繁重的UI包袱甩掉
• 项目属于强需求类产品，例如12306之类的垄断产品

立项的准备工作

这个阶段，需要考虑。

• 选择“正确”的自动化工具 或者 框架

• 选择合适的范围并且进行公示

• 为自动化项目准备测试环境和数据

• 沟通获取开发、项目支持

• 确定测试可交付成果（量化结果）

关于框架选型

当下最保险的UI框架选型

UI测试【Selenium】【appium】

*移动端和web端的UI测试，目前主流的就是selenium和二次开发selenium的appium

自动化框架的类型*

一、记录回放的方式流行于商业工具之中，无需编程技能即可快速上手。然而这种方法相对脆弱，一旦UI变化测试就会受到影响，分散的脚本不可重用且难以维护，而且系统在测试前必须可用。因此这种方法并不适合大型自动化测试。

二、线性脚本允许使用各种语言来编写非结构化脚本，脚本直接与被测系统交互。能够快速上手，灵活性强。但是编写脚本需要编程技能，系统中一个改动会影响所有脚本，没有经过模块化或重用的大量脚本难以维护。因此这种方法适合简单任务，不适合大型自动化。

三、模块化脚本由两部分组成：驱动脚本执行测试，测试库函数完成与被测系统交互。驱动脚本编写起来非常简单，这样可以更快地建立新测试，容易维护。然而需要花时间和编程技能建立测试库，并将测试数据嵌入脚本，建立新测试就需要新的测试脚本。因此，只要拥有编程技能，这种方法还是适合大型项目，但不适合非编程人员。

四、数据驱动方法，将数据与测试脚本分离，基于模块化的测试库，一个驱动脚本可以执行多个相似测试，这样非常容易建立新测试。维护工作可以分离，测试人员负责数据，程序员负责写测试库。然而，不同类型测试仍需要新的驱动脚本，初始建立数据解析器和重用组件需要花人力。这种方法适合大型项目，只需要较少的编程技能。

五、关键字驱动，将数据与关键字结合来描述如何使用数据执行测试。这种方法具备数据驱动的优势，同时非编程人员也能建立新类型测试。所有测试由同一个框架来执行，无需不同的驱动脚本。然而初始成本很大，适合长期、大型项目。

关于测试范围的注意事项

1.自动化测试需要关注可测性。自动化最难的部分是与被测系统交互，特别是GUI层。确保系统容易被测试，比如给GUI元素增加标识、输出易于解析的文本、提供自动化后门等。

2、系统一般可以分为前端（GUI层）以及后端(GUI之下)的业务层。GUI层测试需要调用与普通用户同样的接口，但是某些GUI技术缺乏好的技术/工具支持，会使测试变得脆弱、较慢、不稳定。这时候人工测试相对容易，执行快。UI自动化可以只进行到，某个逻辑的入口(正确传参)。不过要注意，有时候前端也有业务逻辑。例如输入框校验通常由前端控制

3.一般来说、核心业务逻辑（主流程）、回归测试、兼容性测试、稳定性测试、冒烟测试属于“不会失败”的UI自动化范围

关于UI自动化所需要的技术

一般来说，包括

Python/Java:用来编写case和实现各种逻辑

XPath/CSS：用来进行UI元素定位

JavaScript：用来补充xpath和python对UI层的操作能力，可以找前端支援

SQL：用来进行落库检查、伪造数据等

版本控制：自动化测试需要版本控制将测试和代码放在一起，像管理代码一样管理测试脚本

持续集成：持续集成是全方位自动化的关键，当测试或代码有所改动立即执行测试。如果测试运行时间比较长，也可以定期运行

关于设计case的策略

• 使用分层（ui、接口、单元）测试策略，控制UI自动化测试规模
• 少数核心用例交给自动化测试
• 大部分的基础回归测试交给自动遍历
• 新功能测试交给人工测试
• 使用PageObject模式，对自动化case本身进行分层

结论

现在的软件开发最大的特点就是快——产品需要不停的迭代，迭代时间基本在15天左右。

UI自动化测试的优点是，能够实际模拟真实用户的行为，直接验证软件的商业价值；

缺点是用例的维护和执行代价很大。另外，UI自动化测试的稳定性问题，是长期以来阻碍GUI测试发展的重要原因。

在快速迭代的情况下，页面的改动可能会很频繁，而UI自动化测试本身基于页面元素，前端小小的改动可能需要测试的大大改。

所以我们工作的核心是，“写有用的UIcase，提高ROI”