自动化用例设计和开展自动化测试的一些原则。

原帖地址：https://testerhome.com/topics/20396

原则一：每个自动化用例可以独立运行

每个自动化用例应该是没有依赖关系的，可以独立运行的，比如测试一个电商网站， 第一个测试用例是用户登录，第二个是添加商品到购物车，需要用户登录，并且依赖第一个测试用例， 这样的用例设计是有问题，因为违反了我们说的独立运行原则。

那如果我的测试用例重点不是测试登录，而是添加商品到购物车，需要先登录，此时登录就是一个前置条件， 这个时候需要用到自动化框架基本都会自带的一个功能模块，setup 和 teardown。

原则二：测试用例之间不应该有包涵关系

如果用例 A 包含用例 B，那么用例 B 已经冗余了，不需要重复执行。冒烟测试用例除外。

原则三：测试数据应该自动创建和销毁

自动化测试需要的测试数据包括测试坏境也应该尽可能的自动创建和销毁。

有条件话可以尝试采用 Docker 容器化的方式运行自动化用例。

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

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

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

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

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

自动化测试的本质是减少回归测试的重复劳动，提高测试效率，对于大部分中小公司来说， 一上来就想吃成个胖子，全部自动化是不可能的，刚开始开展自动化可以分析每次测试流程的时间瓶颈， 到底是环境安装配置，还是数据准备，还是执行用例最花时间，从最能提高效率或者受益最大的部分开始， 简而言之就是手动 + 自动化的方式。

同时还要考虑团队人员的技术水平，而不是花大量时间精力为了自动化而搞自动化， 结果最后发现比手动测试成本还高，就很尴尬了。