自动化工具 浅谈自动化用例设计

阿东 · 2019年09月01日 · 最后由 测试人生路 回复于 2020年12月30日 · 632 次阅读

引子

最近在查看同事写的 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
    

    log:
    enter description here

  • 第二种:Testcase setup/teardown 测试用例层面。每一个 case 的开始和结束都会去执行的步骤。一般预置条件和数据准备放在 setup,数据销毁放在 teardown。

先来看一个组用例:

测试用例 前置条件 测试步骤
添加购物车 用户登录 添加购物车
购买商品 用户登录 添加购物车,确认购买
从购物车取消商品 用户登录 添加购物车,从购物车取消

针对这组测试用例,我们发现每组测试用例前置条件都是用户登录,于是我们可以把用户登录这个关键字抽出来,放到 Testcase setup 的地方,这样减少我们用例代码的冗余.

Test Setup        Open Browser To Main Page
Test Teardown     Close All Browsers                      #测试结束之后执行关键字

log :
log2
这时候我们发现 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 自动化应该是最后一步了。这里借用网上一个图来说明自动化测试的经典的金字塔模型。越往上,越接近用户,自动化测试效率越低,成本越高,反之,越往下,越接近开发,自动化测试效率越高,成本越底。
automationTest

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

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

欢迎大家补充~

最佳回复
在路上 回复

他意思是第二条用例要紧接着第一条用例后面才能执行,也就是第二条用例依赖于第一条用例

共收到 34 条回复 时间 点赞

赞一个

请教一下,如果按照独立原则,那么 APP 自动化的每个单独的用例执行完,是需要关闭 APP,
那么这样的话每次执行下一个用例都要重新启动 APP,拉长了测试时间,是否有好的方法优化这个问题

匿名 #3 · 2019年09月02日
秦岭 回复

可以分布式并行测试啊

hi,是一部分手机跑这一部分用例,另一部分手机跑另外一部分用例,同时进行吗,谢谢 1

手动点赞,这种测试基础知识希望在社区里面更多一些,对大家很有帮助

道理都明白,但是实现起来还是会有很多问题;
如果能结合你们的业务讲一下实践经验就更好了😀 👍

道理都明白。。。下面的人连接口测试都不知道。。。抓了一个多月还是这样。。。有妙招吗

匿名 #8 · 2019年09月02日
秦岭 回复

是啊

可以分享下你的方法吗,
是 docker 隔离的吗,
还是两台机器上构建两个 job 同时执行两套,每套对应不同的用例,谢谢!

markdown 表格好像有点问题,开头表格就没显示出来,再优化一下?

先来看一个组用例:
***这里需要空一行***
| 测试用例 | 前置条件 | 测试步骤 |
|--|--|--|
| 添加购物车 | 用户登录 | 添加购物车 |
| 购买商品 | 用户登录 | 添加购物车,确认购买 |
| 从购物车取消商品 | 用户登录 | 添加购物车,从购物车取消 |

用例自己写?我们都是那人工的用例写脚本的,导致很多前置条件需要我们自己补充

用例自己写?我们都是那人工的用例写脚本的,导致很多前置条件需要我们自己补充

没有明白这块引用别的用例有什么问题,用例独立指的是该用例可独立运行,测试框架的 testup 和用例运行前引用登录用例,效果不是一样的吗?

在路上 回复

他意思是第二条用例要紧接着第一条用例后面才能执行,也就是第二条用例依赖于第一条用例

阿东 #15 · 2019年09月03日 Author
秦岭 回复

个人观点,测试用例可以独立执行,表示每个用例可以独立执行,没有依赖。具体情况要考你的每个测试用例的测试重点和策略。比如你说的 APP 测试,不一定要每次都关闭应用退出,就好像在 web 测试,不是每个用例都需要关闭浏览器,但是每个用例可能都需要登录和注销。设计测试用例时候还要考虑这个是否是用户使用的高频场景。

阿东 #16 · 2019年09月03日 Author
simple 回复

谢谢鼓励😀

阿东 #17 · 2019年09月03日 Author

用例很多时候,分布式执行也是一种策略👍

阿东 #18 · 2019年09月03日 Author
Morris Li 回复

谢谢提醒,已经更正。

阿东 #19 · 2019年09月03日 Author
干饭狂人 回复

可以自己写,也可以由更熟悉业务的手工测试团队写用例。每个公司模式不一样,情况不一样,大公司可能分工会更细一些。

阿东 #20 · 2019年09月03日 Author
arrow 回复

谢谢你的建议~

阿东 #21 · 2019年09月03日 Author
pan 回复

可以尝试从一个点突破,做一个很小的 demo,让团队看到实际的效果,比如测试效率的提升~

22楼 已删除

到现在也没有看到一本介绍自动化特别精辟的书

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

如果:
评论模块有发表评论,修改评论,查询评论,删除评论 4 个接口
那么这 4 个接口设计成 1 个场景不是更方便吗,如果按照用例独立的的方式设计,光造数据这个就会麻烦很多吧

阿东 #25 · 2019年09月16日 Author
liky 回复

可以从实践中多总结。论坛也是学习和交流地方~

阿东 #26 · 2019年09月16日 Author
william 回复

这个就是看你设计这个用例的目的。如果是冒烟用例,这么过一遍没有问题。如果你的重点是某一个点,比如查询评论,那你一个用例是不够的,还需要用多个不同场景来覆盖,那么这个时候你每个测试可能还是需要造数据和销毁数据。还有,注意看原则 2,如果已经出现了包涵关系,你也可以放到一个用例里面。

很受启发👍

没懂你想要用例能够单独运行的意义在哪里?
我揣测的给一个答案:
A 用例能够独立运行,B 用例需要依赖 A 用例,那我们直接视(A+B)为一个用例不是也是相对独立的吗?
你可能想表达的意思是,我们把 A 用例封装起来,其他用例如果想要获取一个登陆 token 的时候则去调用 A 用例获取,是吗?

LZ 举例的原则应该是理想的设计方法,实际应用中还要根据使用场景的频率和依赖进行设计。

阿东 #30 · 2019年09月20日 Author
Karaser 回复

你说的对,所以原则二已经写了,如果有包涵关系,写成一个用例。
可能我解释不够清楚,独立运行的意义是,作为执行人员,我可以任意选一个测试用例运行,而不是按照某种顺序去运行用例,这样解释能理解么?

先 Mark,后面看

这种基础的实用只是对我的测试自动化工作的开展,真是受益良多啊,少了很多弯路。
不过我做游戏的,一般大家都是 UI 自动化的~少有单元和接口自动化

阿东 #33 · 2019年11月12日 Author
渐渐 回复

谢谢鼓励,你们用的什么方案做游戏 UI 自动化?

阿东 回复

python+airtest+jenkins。
现在我们遇到的问题是项目是五年前的项目了,所以引擎版本比较旧,不支持 poco 框架,只能用 airtest,但是识别率不稳定,且很多断言都不好做~

接口测试工具可以试用一下国产的接口测试和接口文档生产工具 apipost:https://www.apipost.cn/?dt=2020

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册