• 使用接口造数也可以,但有几个问题:

    1、你使用的是上层业务结构,还是底层原子接口

    2、一个业务场景的数据会涉及到多个结构,因此一个业务场景的造数,使用接口的话,会有多个接口的调用顺序与上下文管理的问题

    3、如果造数在中途失败,产生的 “半截” 脏数据应该如何处理

    5、接口造数,那么接口的参数如何管理和动态更新维护。

    欢迎和我探讨~

  • @Lihuazhang 申请加个精

  • 是的,易用性在一定程度上面需要提升,我也在考虑提供 SDK 来方便其他框架的调用

  • 针对第 4 点的内容:

    在现在的设计中其实已经体现了:
    1、数据模板中可以存在多个步骤,每个步骤根据真实情况设置具体的内容,可以是纯生成,可以是还原,等等
    2、一个数据工人中可以有多个数据模板,一个生产线中可以有多个功能。随意拼搭。

    但在我的规划中其实还是希望在数据模板中的多个步骤之间存在语义逻辑处理,可以简单的理解为:if else 或 for 。这样可以更加灵活的处理造数过程中的逻辑

  • 我觉得你的提议很好,和我的规划有不谋而合的地方:

    针对 “数据池”:
    在现有的功能的中"变量"其实就是狭义的 “数据池”。
    但我理解配合 “数据池” 的概念中还需要有两部分内容 “数据结构定义” 和 “使用策略”
    在功能层面的理解更类似下图

  • 我觉的你说的很正确。

    之所以我在实践过程中构造出了 “变量” 这个功能,目的其实就是将通用、常用的数据抽离出来。数据模板只是一个架子,在生产数据的过程中,通过变量往架子中填充数据,后期数据层面有说变动,只需要改变对应变量中的内容。

    数据模板是固化下来的,但是这个固化会有一个过程,其实是一个滚雪球的过程,伴随项目迭代的时间越长,用的人越多,数据模板会越来越多,到时候测试人员之间只需要分享各自的数据模板和变量就行。

  • 接口当然也是可以的,但是接口存在以下问题:

    1、接口分上层接口和底层原子接口,例如在微服务领域模型下,bff 层通常提供的是业务聚合接口,如果使用这种接口造数,那么接口本身对其他业务数据会有依赖,会导致接口依赖接口的情况。

    2、如果是底层原子接口,通常并不会在网络上暴露,服务和服务直接通常都是通过走服务发现的方式相互调用和依赖,如果为了测试需要暴露大量底层接口,可能开发层面也不是特别的方便。

    关于怎么和测试脚本关联起来的问题,我把你说的测试脚本理解成自动化相关的脚本
    在文章中有提到生产线的概念,每个生产线都有对应的 id,造数工厂提供了一个对外调用的 API,可以传入对应的生产线 id 和验签参数,这样在你的脚本的 methd setup 方法中直接调用对应生产线来生产你测试脚本依赖的场景数据。

    😀

  • 遇到啥问题我们可以在这里讨论~

  • 算下来我做了 8 年左右的测试工作,从小厂到大厂,如果你把测试工作划定在功能检验上,那么只能说是你自己对测试工作的内容和测试工程师的定义理解上有偏差。

    简单说几点:
    1、测试工作你是划定在开发完成后的测试阶段,还是软件系统的整个生命周期内容,这两者的工作内容差别巨大。
    2、测试工程师职责你是仅仅划定在根据 PRD 的内容进行功能验收还是软件系统的质量保障上。这两者对工程师的要求一个是天一个是地。
    3、测试工程师技术范畴仅仅只是点点点?仅仅只是会使用各种自动化框架?仅仅只是会使用各种性能、接口、安全的测试工具?要做好质量保障,思考你一点,你是否具备 “预见质量风险的能力”,说明白点,你是否能对测试对象的技术实现和业务场景做到完全了解。从技术实现角度来看你是否对采用的技术了解,为满足需求这些技术是否存在质量风险,开发技术设计评审时你是否能一眼看出设计带来的当前和未来的问题。从业务场景出发,你是否能发现技术实现方式和业务场景不匹配的情况,或者业务场景本身存在矛盾的地方。
    4、另外就是测试设计能力,这个能力不是指的根据 PRD 进行测试用例设计,指的是软件系统整个生命周期质量保障的设计能力,从需求到来,到开发测试,到上线运营,到迭代更新,到系统下线的整个生命周期的质量保障设计能力。

  • 简单列举几个:
    1、产品,开发,测试对同一个数据指标的计算口径未达成一致。
    2、数据指标加工过程未对加工逻辑进行分层,数据源到最终指标形成只使用了一个 SQL,没有任何中间表,比如一个指标加工 left join,full join, inner join, right join, union 等使用了 N 张表进行复杂加工,没有中间表的存在会导致测试过程中无法快速找到问题数据来源于哪张中间表,哪段数据加工逻辑。
    3、精度问题,我遇到一种情况,数据加工过程中采用 hive sql 的预发进行四舍五入,hive sql 加工完的数据写入 click house 这种列式存储数据库后,java 业务层做数据查询时,按照不同维度聚合数据时又使用了 click house sql 的预发做了四舍五入,最后在 java 代码中因为一些特殊原因又对数据做了精度处理。最终导致界面展现数据和加工出的数据存在偏差。