最近在查看同事写的 robot 自动化用例时候，发现一些问题。没有搞清楚一个完整自动化用例的标准是什么。把自动化用例前置准备工作也算作一个自动化 case。根据自己理解谈谈自动化用例设计和开展自动化测试的一些原则。
每个自动化用例应该是没有依赖关系的，可以独立运行的，比如测试一个电商网站，第一个测试用例是用户登录，第二个例子是添加商品到购物车，需要用户登录，并且依赖第一个测试用例，这样的用例设计是有问题，因为违反了我们说的独立运行原则。那如果我的测试用例重点不是测试登录，而是添加商品到购物车，需要先登录，这个登陆的前置条件应该放在哪里呢？这个时候需要讲解一下自动化框架基本都会自带的一个功能模块，setup 和 teardown。接下来我们借助自动化测试框架 RF（Robot Framework）来进行讲解。
第一种：Suite setup and teardown 测试套件层面。所谓测试套件（suite）就是一组测试用例集合，在 RF 里面就是一个 Robot 文件。也就是说这个层面的 setup 和 teardown 只发生在一组测试的开始前和结束后。并且 RF 最终 teardown 的 log 也是在最前面的。所以根据 log 没法看出关键字执行顺序。
Suite Setup Open Browser To Login Page
Suite Teardown Close All Browsers
log:
第二种：Testcase setup/teardown 测试用例层面。每一个 case 的开始和结束都会去执行的步骤。一般预置条件和数据准备放在 setup，数据销毁放在 teardown。
先来看一个组用例:
| 测试用例 | 前置条件 | 测试步骤 |
|---|---|---|
| 添加购物车 | 用户登录 | 添加购物车 |
| 购买商品 | 用户登录 | 添加购物车，确认购买 |
| 从购物车取消商品 | 用户登录 | 添加购物车，从购物车取消 |
针对这组测试用例，我们发现每组测试用例前置条件都是用户登录，于是我们可以把用户登录这个关键字抽出来，放到 Testcase setup 的地方，这样减少我们用例代码的冗余.
Test Setup Open Browser To Main Page
Test Teardown Close All Browsers #测试结束之后执行关键字
log ：
：
这时候我们发现 setup 和 teardown 是按照执行顺序出现得了。
Overridden setup
[Documentation] Own setup, teardown from setting table
[Setup] Open Application App B
Do Something
如果 A 用例包含 B 用例，那么 B 用例已经冗余了，不需要重复执行，冒烟测试用例除外。
自动化测试需要的测试数据包括测试坏境也应该尽可能的自动创建和销毁。有条件话可以尝试采用 docker 容器化的方式运行自动化用例。
一般情况下，新功能是来不及做自动化测试和覆盖的。需求变化快的模块也是不适合做自动化的。覆盖产品的核心功能，也就是优先从冒烟测试开始做自动化测试。
项目的自动化开展顺序应该是从单元测试开始，然后才是 API 测试，模块测试，最后才是 UI 自动化。很多团队本末倒置了，一上来就搞 UI 自动化，然后发现成本太高，进度太慢，然后下个结论，我们项目不适合做自动化。殊不知单元测试的自动化才是效率最高收益最高的，UI 自动化应该是最后一步了。这里借用网上一个图来说明自动化测试的经典的金字塔模型。越往上，越接近用户，自动化测试效率越低，成本越高，反之，越往下，越接近开发，自动化测试效率越高，成本越底。
自动化测试的本质是减少回归测试的重复劳动，提高测试效率，对于大部分中小公司来说，一上来就想吃成个胖子，全部自动化是不可能的，刚开始开展自动化可以分析每次测试流程的时间瓶颈，到底是环境安装配置，还是数据准备，还是执行用例最花时间，从最能提高效率或者受益最大的部分开始，简而言之就是手动 + 自动化的方式。同时还要考虑团队人员的技术水平，而不是花大量时间精力为了自动化而搞自动化，结果最后发现比手动测试成本还高，就很尴尬了。
欢迎大家补充~
