问答 自动化用例分层的问题

tester · 2024年02月04日 · 最后由 sc6288 回复于 2024年03月01日 · 9575 次阅读

1: 大家用例都存在哪里呢,是直接放在用例方法中,还是放在 yaml 或者 excel 文件中呢?
2:如果系统比较复杂,常常都是一个大模块里层层嵌套多个小模块,那大家的用例应该怎么分层呢?

共收到 14 条回复 时间 点赞

大家的自动化用例来源是什么,我们公司是手工用例翻译为 python 代码,一个脚本覆盖一条手工用例(领导这样要求的),这样做合理吗

绝不能存放在 yaml 和 excel,你可以一个接口对应一个 py 文件用例

前面我还在多接口用例集成在一个脚本内,最近想优化框架发现难度陡增,然后就一个脚本一个接口的处理了

林森 回复

木有合不合理,只能说参数化可以降低工作成本和维护工作量

  1. 我们的用例是以 json 形式来表达,里面会包含用例描述、用例优先级、用例编号、用例入参、用例断言等相关信息。如果你觉得用例有必要做参数化处理,你就考虑把用例单独拎出来存放,大前提是这些用例共享同一套运行逻辑,或者框架能很好解读用例并执行;否则就是在增加无效工作量,尤其是用例数量不多时(比如只有两位数)
  2. PO 模式,自行百度。建议结合用户操作视角,以及业务聚合视角一起来分层。比如一个接口是获取订单信息,这个接口的用例可能放在订单页模块下,这个模块下又聚合了订单页相关业务的上下游接口。

别想太多,先跑起来再说

先跑起来,哪里不舒服就改哪里,别怕没有设计模式太简单,能起到作用才是王道

API 测试 可以参考 flask 蓝图
用例编写 - 发布运行 - 结果自动保存
(对上可以汇报为: 自动化测试平台化😀 )

语义化关键词驱动的用例,存在数据库里,一条记录就是一个用例,包含名称,前置条件,步骤,预期,及其他维护字段

做一个自动化平台,写数据库里

我是把接口不同方法封装成 py 文件,然后把接口相关信息抽离到 execl,用着还可以啊! 所以你们说的 execl 缺点是什么?

1、存储一直用的 excel,也尝试过使用纯文本的 yaml 或 json 一类存储,但是编辑效率比 excel 低太多了,只能作为项目配置文件。数据库也可以,不过同样是二维表结构其实和 excel 也没有实质上的区别,而且还要维护前端。

我个人感觉,excel 最主要的问题是二进制文件版本管理时不方便比较历史差异。其他方面都还好

2、层级多可以使用 文件目录 - 文件-sheet 页 - 自定义字段来区分

林森 回复

华为的机器视觉部门的自动化用例也是直接把手工用例翻译成 python 代码

写多了用例脚本耦合模式就知道数据驱动的好
写多了数据驱动就知道关键字驱动的好
写多了关键字驱动就知道 po 模式的好
写多了 po 模式就知道智能维护的好

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