自动化测试高手课
柳胜
原甲骨文高级开发经理
16849 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 34 讲
开篇词 (1讲)
自动化测试高手课
15
15
1.0x
00:00/00:00
登录|注册

19|排兵布阵:自动化测试的编排、扩展与重构

你好,我是柳胜。
通过前面两讲,我们一起推导了一个自动化测试 Job 元数据模型。接下来,我不但会把这个 Job 模型用到自动化测试设计里,还要“点石成金”,让你充分体会到这个模型的强大力量。
在讲解设计过程之前,我想先和你聊聊,现在的自动化测试设计有什么问题。
如果你做过自动化测试开发,对现有设计一定不陌生。通常做法是创建一个 TestSuite,它包含多个 TestCase,每个 TestCase 完成一个测试任务,然后顺序跑下来,测试就执行完了。就像下面这样。
传统做法
我相信,很多自动化测试开发人员刚入行的时候,就是这么学习和组织自动化测试案例的,一直到现在。
但你有没有想过,这种测试案例的组织方法是来源于单元测试。它的方法论是,有一个开发方法,就需要有一个对应的 Test 方法,两者一一对应。因为先有开发的代码存在,那么 Test 方法有多少个,都负责干什么事,这些都一眼到底,几乎不需要测试设计,往 Test 方法里填充代码就可以了。
这种自动化测试开发方法,我叫它“轻设计,重实现”的方法。不过,这种方法反过来也会潜移默化地影响自动化测试人员的思维方式。不想好自动化测试的设计,上来就先写代码,结果代码写出来又长又冗余。
而自动化测试已经发展了这么多年,早就不再局限于开发阶段的单元测试了,有 API 测试、UI 测试等等。这些高层面的自动化测试案例,其设计往往以功能为入手点,对业务进行分解,进行自动化建模。在这个过程中,就不能像单元测试那样,有现成的开发方法做对标和参考了。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文介绍了自动化测试设计的重要性和方法。作者提出了“重设计,轻实现”的自动化测试开发方法,强调了概要设计的重要性,并详细阐述了如何通过抽象Job的设计来梳理测试需求。在详细设计阶段,作者提出了3KU法则,确定了每个Job在金字塔的哪一层来完成,并指导了具体的工具和框架选择。文章还讨论了扩展和重构的能力,以及微测试Job模型的设计流程。该方法论能够分解复杂的测试场景,降低和工具框架的耦合。整体而言,本文深入浅出地介绍了自动化测试设计的重要性和方法,对于测试架构师和自动化测试设计人员具有一定的指导意义。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《自动化测试高手课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(8)

  • 最新
  • 精选
  • 七星海棠
    之前项目做的自动化思路大概也是这个样子,运用了srp和ocp原则,但没有这么系统地思考和总结,看了这篇后,思路上更清晰了,以后跟别人介绍的话措词上可以更专业了

    作者回复: 这说到点子上了,能做也要能说。知行合一才是真学到了。

    2022-05-24
    2
  • jogholy
    如果testjob最后根据roi分配到了不同层去做自动化,又怎么做到互相咬合的呢?不同层的实现工具都不一样,数据结构也没有共用,是需要自己搭建一个分层自动化的大平台打通层次之间吗?

    作者回复: 在链接工具一讲里提到了这个思路,让工具的归工具,让框架真正起到超越工具的作用!

    2022-05-16
    2
    1
  • Sarah
    当前项目是纯前端,我觉得是跟testJob 类似的思想,也是采用分层的方式,也是测试设计先行的原则。但是由于不需要验证后端逻辑,所以只分了2层,UT和E2E,在实现上,这两个层是相互独立没有交互的。 有点难理解老师所说的不同子job之间相互咬合的情景,求解惑🙏

    作者回复: 非常理解!讲这个Job模型设计,是一个新的设计方法论,需要从各个方面来介绍,就像盲人摸象一样,最后得出一个全面的理解,你不妨看完后面章节,再感受一下。可以加我微信,sunshinelius。

    2022-05-02
  • ifelse
    学习打卡
    2024-02-23归属地:浙江
  • Sophia-百鑫
    在定稿的设计图里,个人认为下订单的job 应该可以去掉。即整个订单测试步骤 是 登录job->创建订单job->验证订单job ,这3个job属于同级并有前后依赖关系,验证订单job可再拆分成快递号验证,短信验证,UI 验证, 其他验证等Job。下订单job去掉的理由如下: 下订单job 的描述不够专业或不够清晰,不符合单一职责原则,此外放在那里使链路可读性差。 请老师看看是这样吗?
    2023-09-15归属地:上海
  • linxs
    之前做的api自动化,是自己封装了脚手架,input包含测试数据,重试超时机制,以及一条流程的配置信息,然后脚手架去解析执行这条流程,然后输出日志和结果,然后每个测试场景写一份配置文件即可执行
    2023-09-06归属地:广东
  • 鑫宝
    之前做的都是框架里面。 testcase 里面套步骤。 第一次接触老师的 test job 理念,还是挺新的。但是不太理解,看来得多看几遍才能明白了
    2023-07-11归属地:上海
  • Geek_225ad6
    我理解:手工测试当然也是适用的,而且这里也可以手工和自动化结合,将大的Job细分之后,部分的Job自动化,大的Job不能完全自动化部分,手工执行,和自动化部分合并输出结果 Job方法本质是一种抽象表述分析的方法
    2023-04-25归属地:陕西
收起评论
显示
设置
留言
8
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部