首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >浅谈自动化测试模型

浅谈自动化测试模型

作者头像
赵云龙龙
发布2021-05-10 15:28:12
7060
发布2021-05-10 15:28:12
举报
文章被收录于专栏:python爱好部落python爱好部落

自动化测试模型可以看作自动化测试框架与工具设计的思想。随着自动化测试技术的发展,演化为以下几种模型:

  • 线性测试
  • 模块化驱动侧式
  • 数据驱动测试
  • 关键字驱动测试

线性测试

线性测试较为简单。一般简单的录制,都是线性结构。 线性测试的每个脚本都是相对独立的(不产生其他依赖和调用),所以任何一个测试用例脚本拿出来都可以单独执行。

优点:每一个脚本都是完整且独立的,如果是录制的话,写case效率高。对入门者门槛低。

缺点:* 代码冗余度高。测试用例之间可能会存在重复的操作。 * 维护成本高。因为测试用例之间存在重复操作,所以当这些重复操作发生变化时,需要对它们逐一更改。

模块化驱动测试

由于线性测试的缺点太过于明显,因此我们需要新的模型来代替它。做法很简单,借鉴编程语言中的模块化思想,把重复的操作独立成公共模块(公共方法),当脚本需要时我们就可以调用该公共模块。 常用的方法,就是PO模式,同一个页面的操作,封装到一起。 优点:

  • 提高了开发效率,不用重复编写相同的操作脚本。
  • 简化了维护的复杂性,重复操作的脚本发生变化时只需要修改公共模块的部分。

缺点:

  • 写case速度不快,有的时候层层调用,过度封装,代码可读性不高。

数据驱动测试

我们可以通过读取定义的数组、字典,或者是外部文件(excel、csv、txt、xml等),都可以看作是数据驱动,从而实现数据与脚本的分离,进一步增强脚本的复用性。

数据的改变从而驱动自动化测试的执行,最终引起测试结果的改变。 将测试数据参数化,解决测试数据改变而影响数据驱动测试,解决脚本重复问题同时增加脚本可重用性和可维护性 装载数据的方式可以是列表,字典或是外部文件(txt,csv,xml,excel),实现脚本与数据分离

使用ddt执行数据驱动测试 ddt的库可以将测试中的变量进行参数化,包含一组类和方法用于数据驱动测试。 可用如下命令下载与安装ddt:pip install ddt 为了创建数据驱动测试,需在测试类上使用@ddt装饰符,在测试方法上使用@ddt装饰符。@ddt装饰符把参数当做测试数据,参数可以是单个值,列表,元组,字典。对于列表,需用@unpack装饰符把元组和列表解析成多个参数。 @data(a,b)a和b各运行一次用例 @data([a,b],[c,d])如果没有@unpack那么[a,b]当成一个参数传入用例运行,如果有,那么[a,b]被分解开,按照用例中的两个参数传递

关键字驱动测试

在数据驱动的基础上,我们把“数据”转化为“关键字”后,通过关键字的改变从而引起测试结果的变化。 为何我要在这里说明是“浅谈”呢?在关键字驱动测试中,我们可以将测试的对象、满足条件、传输值、断言等,甚至是所需要读取的外部文件以及外部类库,所有的相关条件存储在文件中(典型的关键字驱动工具:UFT)。我们可以将关键字以“填表格”形式写入文件中,从而降低脚本的编写难度。 正因如此,采用关键字驱动测试来编写同样的脚本需要较高的学习成本。同样,这样的框架越到后期越难维护,可靠性也会变差。 关键字驱动框架是一种功能自动化测试框架,它也被称为表格驱动测试或者基于动作字的测试。关键字驱动的框架的基本工作是将测试用例分成四个不同的部分。首先是测试步骤(Test Step),二是测试步骤中的对象(Test Object),三是测试对象执行的动作(Action),四是测试对象需要的数据(Test Data)。

以上四个部分,都可以使用Excel表格进行维护:

Test Step:是一个小的测试步骤的描述或者测试对象的一个操作说明。

Test Object:是指页面对象或元素,就像用户名、密码,

Action:指页面操作的动作,打开浏览器,点击一个按钮,文本框输入一串文本等。

Test Data:是任何对象操作时所需要的值,就像用户名、密码进行输入时的输入内容。

其实我们做关键字的驱动的思想,就是把编码从测试用例和测试步骤中分离出来,这样对于不会编码的人员更容易理解自动化,从而让手工测试人员也可以编写自动脚本。

OK, 聊完了设计模型,哪种模型更好?更适合做自动化测试框架呢? 这里没有孰优孰劣,只有是否适合。要根据国情来。 如果你天天被业务测试弄得脱不开身,只需要简单的重复操作,那么线性的录制,也许能帮上忙。 如果想做一个长久一点,大家共同参与的,可维护的框架,那么结构化的也许更适合。 如果数据比较多,业务差不多的情况下,数据驱动是最适合不过了。 如果公司推行敏捷,而且人人需要参与,关键字或者BDD是最适合不过了。这种只适合规模小一点的项目,如果特大型的,用这种方法,估计得让你怀疑人生。

本人做自动化测试的时候,一般喜欢混搭。可以用线性录制来提高写case效率。 然后用结构化的,page object模式,来实现代码的公用。 最后用数据驱动的模式来管理数据。

个人是没有完全的套路。

对一个武者来说,招式是决胜的关键,招式是有高低,优劣之分的,这里我把它分为以下几个境界

第一种境界,无招而有形,换句话说就是普通人打架,乱打一通,没有招式,但形态明显,破绽最多,稍懂武功的人,都可以轻易取胜。 就如同我们的线性模式的录制。

第二种境界:套路的运用 每一招每一式,都有严紧的套路,或灵活或轻巧,或威猛,或严密,一招一式,一板一眼,如各大门派的招式,然而因为过于讲究套路,所以也有破绽,遇到真正的高手,就难以取胜了。 如同我们的单独的PO,数据驱动或者关键字驱动。

第三种境界:无招无形 这种招式,融合种武功的特点,往往以奇或速,如倚天里的波斯使者,小龙女的双手玉女剑法,岳阿姨的辟邪剑法,武当派的太极剑法,这种招式以奇特和快速为主,令人防不胜防。 这种就是我常用的混搭。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2021-04-24,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 python粉丝团 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 线性测试
  • 模块化驱动测试
  • 数据驱动测试
  • 关键字驱动测试
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档