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