注意哦

企业微信的回调 API 都是有限流的哦

提供两种思路：

1、你可以调查一下 “chrome://inspect/#devices” 和 “微信端调试 H5 页面” 这两个内容

2、文章中其实重点是提供的度量前端性能的维度和指标，所以对于测试人员来说，这里有个很重要的东西就是 “有没有人人能够指出在做前端性能测试的时候应该从哪些维度来度量，这些维度是否合理”，如果这些维度合理的话，至于怎么提取就很容易了，不论是 PC 和移动设备，浏览器内核都是具备调试协议和 SDK 的，可以让开发人员按照你提供的维度在代码中进行提取并上报。

在我的测试团队里面，是要求功能测试人员去参与开发的技术评审，了解开发的设计方案，了解数据结构的。

从数据结构的设计以及数据与数据之间的关联关系反推业务逻辑设计是否合理，是否和 PRD 的功能设计匹配，并寻找业务逻辑的边界场景。

这样下来，测试人员便可以做到熟悉功能的同时对背后的数据结构也非常熟悉。在测试过程中对测试场景的构建才会更加的准确与高效。

真丶实践

在时间过程中，其实发现很多前端页面组件加载时序问题. 按照各指标的要求，调整后用户视角的体验提升很多 。

已经 ok 了，谢谢~~

想换几张图片，现在的图片太不清晰了

@chenhengjie123 为啥这边帖子的编辑提交，一直没审核啊

可以参考 https://testerhome.com/topics/35529

@chenhengjie123 求加精~

明天更新后回复你

现在大多都是前后端分离的，虽然接口的返回时间会影响功能的展示。

但是如果仅仅是从纯前端的性能角度看，需要清除前端渲染的流程，才能测准前端加载的性能好坏，以及哪一个加载渲染环节耗时。

建议看一下 google 前端性能指标和对应的提取方法

https://web.dev/metrics/

光看接口返回时间是不够的，前端页面渲染性能和不同组件层级的渲染方式都会影响用户对于页面加载快慢的感知

准确的说是：

开发数据工厂并不需要对测试目标的业务数据结构非常了解，而是需要对测试流程中测试数据的构造方法和造数流程非常熟悉。毕竟数据工厂是一种抽象的数据制造方式，所以数据工厂重点是如何抽象通用的写入业务数据。

使用数据工厂时，才需要对测试目标的业务数据结构非常了解。
例如：
如果测试用例对应的数据场景使用 “接口进行造数”，那么就需要了解此场景下数据对应的接口都有哪些
如果测试用例对应的数据场景使用 “直接向数据库写入数据”，那么就需要非常数据业务数据在数据库中的结构，包括 “表，表与表直接的关联性”
如果测试用例对应的数据场景使用 “消费消息”，那么久需要对消息的消息体内容和上下文非常了解

1、数据项分别有哪些？
2、这些数据项的计算口径是什么？
3、计算口径对应的底层数据来源于哪里，存放于哪里，数据结构是怎样的？
4、底层原子数据到页面展示的口径加工数据之间有几层中间数据？中间数据加工逻辑是什么？底层和中间层的数据是实时加工还是延迟计算。

根据以上内容确认测试范围：
1、页面数据展示质量控制维度是哪些？计算准确就行，还是说又要计算准确，又要计算全面，又要计算快速？数据计算的快、准、全
2、根据不同的计算质量控制维度进行质量控制设计。

针对底层原子数据，需要保障数据的及时性
例如，如果底层原子数据是有业务系统上报而来，那就需要确认上报方法，例如如果是通过消费消息的方式，那消息是否会在流量高峰期存在积压，系统是否具备高效的削峰能力，一旦积压，前端业务系统计算出的展示数据就会有波动。

无论是中间数据的加工计算还是上层展示数据的加工计算：在测试中可以采用以下方法：

1、你在清楚数据项计算口径的情况下，你可以将各数据项的数据根据计算口径转换成 SQL（可以使用 python+sqlachemy+pandas）来做，自己计算出一份数据。
2、自己计算出的数据与页面展示时调用的后端服务接口吐出来的数据做对比。

这样就可以进行全口径的自动对比.

可以看参考 https://testerhome.com/topics/35061

使用接口造数也可以，但有几个问题：

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 代码中因为一些特殊原因又对数据做了精度处理。最终导致界面展现数据和加工出的数据存在偏差。