引子

最近在查看同事写的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容器化的方式运行自动化用例。

原则四：自动化应该优先覆盖需要重复测试的核心功能

一般情况下，新功能是来不及做自动化测试和覆盖的。需求变化快的模块也是不适合做自动化的。覆盖产品的核心功能，也就是优先从冒烟测试开始做自动化测试。

原则五：自动化开展顺序应该是自底而上

项目的自动化开展顺序应该是从单元测试开始，然后才是API测试，模块测试，最后才是UI自动化。很多团队本末倒置了，一上来就搞UI自动化，然后发现成本太高，进度太慢，然后下个结论，我们项目不适合做自动化。殊不知单元测试的自动化才是效率最高收益最高的，UI自动化应该是最后一步了。这里借用网上一个图来说明自动化测试的经典的金字塔模型。越往上，越接近用户，自动化测试效率越低，成本越高，反之，越往下，越接近开发，自动化测试效率越高，成本越低。

原则六：不要一开始就想所有东西自动化

自动化测试的本质是减少回归测试的重复劳动，提高测试效率，对于大部分中小公司来说，一上来就想吃成个胖子，全部自动化是不可能的，刚开始开展自动化可以分析每次测试流程的时间瓶颈，到底是环境安装配置，还是数据准备，还是执行用例最花时间，从最能提高效率或者受益最大的部分开始，简而言之就是手动+自动化的方式。同时还要考虑团队人员的技术水平，而不是花大量时间精力为了自动化而搞自动化，结果最后发现比手动测试成本还高，就很尴尬了。

最后小编在学习过程中整理了一些学习资料，可以分享给做软件测试工程师的朋友们，相互交流学习，需要的可以加入我的学习交流群 164549428 或加微dingyu-003即可免费获取Python自动化测开及Java自动化测开学习资料（里面有功能测试、性能测试、python自动化、java自动化、测试开发、接口测试、APP测试等多个知识点的测试资料)

自动化测试用例设计及原则相关推荐

【转】自动化测试用例设计的原则
很多公司在实施自动化测试的过程中,往往会把所有的手工测试用例作为自动化测试用例,并且直接进行脚本的开发工作,甚至有些公司不写自动化测试用例,直接想当然地开发测试脚本,这些都是极其不规范的做法,甚至很有 ...
自动化测试用例设计的原则
1.自动化测试用例范围往往是核心业务.流程或者重复执行率较高的. 2.自动化测试用例的选择一般以"正向"为主. 3.不是所有手工用例都可以使用自动化测试来执行. 4.手工测试用例往 ...
自动化测试用例设计原则
自动化测试用例设计原则:每一个用例都是一个闭合的业务操作.用例之间要保持独立 ,不要有操作上的依赖关系,就算有也是测试数据上的依赖.第二个用例依赖第一个用例产生的数据. 转载于:https://w ...
自动化测试用例设计原则（接口自动化用例设计的基本原则）
自动化测试用例设计原则: 1.一个脚本是一个完整的场景,从用户登陆操作到用户退出系统关闭浏览器. 2.一个脚本脚本只验证一个功能点,不要试图用户登陆系统后把所有的功能都进行验证再退出系统 3.尽量只做 ...
三. 自动化测试用例设计
1. 主要内容: 2. 手工测试用例与自动化测试用例区别目前自动化测试更多的时候是定位在冒烟测试和回归测试: 冒烟测试执行的是主体功能点的用例. 回归测试执行全部或部分的测试用例. 3. ...
自动化测试用例设计（四）自动化测试用例设计实例
自动化测试用例设计(四)自动化测试用例设计实例编写自动化测试用例的原则: 1.一个脚本是一个完整的场景,从用户登陆操作到用户退出系统关闭浏览器. 2.一个脚本脚本只验证一个功能点,不要试图用户登陆系 ...
自动化测试用例设计原则（转）
内容摘自:http://www.cnblogs.com/jshtest/p/6362677.html 一.自动化测试存在的真正意义: 主要用来保证产品主体功能正确完整和让测试人员从繁琐重复的工作中解脱 ...
接口自动化测试用例设计方法
一.接口参数覆盖接口测试通过输入使用参数组合,获取服务器返回值,根据预先设定的规则判断是否符合预期值.在接口测试中根据接口的功能不同,需要侧重检测方面不同,主要从以下几个方面考虑设计用例 1)参数类 ...
测试用例设计通用原则

自动化测试用例设计及原则

引子