能否先说下你第三方支付接的哪个？大概是怎么和你们自己系统交互的？

不同第三方支付这方面还是有差异的，有的是服务端纯 api 对接，有的是内嵌 h5 界面 + 服务端回调，有的是 app sdk 接入。不同接入方式，对应的自动化方案差异还是挺大的。

这块问下你们开发应该会知道，先把交互理出来，才好说怎么自动化。

哦哦，明白。如果是 web 前端 +vue，确实得用 xpath ，因为 template 里一个组件，实际对应 html 好几层结构了。

页面增加新功能，导致页面元素发生改变
解决方案：
尽量不要使用元素本身的 ID、name、class 定位，尽量使用 xpath 定位方式

这个和我的认知不大一样。可以分享下具体什么场景下， xpath 定位比 id、name 要好？

从现在提供的信息里，看不出和问题原因有比较大关联的内容呀。。。

建议：
1、把截图也发一下，确认下实际用的是哪个输入法
2、把完整的 desired_caps 参数发一下，有不少参数是要组合使用的。
3、也发下你找过哪些资料，尝试过哪些方法，这些过程也能提供更有用的参考信息。

补充一个，极客时间的测试 52 讲里，有几讲相对系统地介绍造数据的各种形式，如果想系统点了解的话，也可以看看。

也补充下对标题这句 社区里满大街的测试平台都是接口类型的，为啥没有数据工厂的平台？ 的理解

1、做数据工厂或者这方面持续投入的，我目前接触除了金融类业务，好像其他业务需求都不强（大部分业务流程都是短且简单，中间态不多），所以可能做得也不多？
2、造数据很多都涉及到领域业务知识，分享出来度不好把握，脱敏太厉害就虚，写得太具体有风险。所以分享的也不多。
3、这方面更多还是体力活（一个一个脚本写下来），能做创新的点不多，受众相比接口测试这些也不广，所以大家可能分享欲望也不是太强。

所以，如果是领域相关，通用性相对不那么长的，可能你直接找同业务领域的同行交流，会比在外面找分享文章效果好很多。

额，我已经好久没用了，官方貌似更新了挺多代码，这个是否还能触发回放我还真不大清楚。

standalone 只是一个方便快速演示用的 demo 而已，建议你直接用非 standalone 方式吧。

我们之前内部有做，思路和你的类似，但有些地方不大一样。

我们当时的背景：业务是借贷业务，流程比较长（注册 - 登录 - 授信 - 风控审核 - 放款 - 还款 - 催收），有些时候测后面环节的变更，需要刚好到这个环节的账号，所以造数据需求比较强，很早就开始做了。

第一阶段，用的最简单的办法，web 前端根据提供的账号名，直接去改数据库某些数据的状态类型字段，比如一键注册、一键风控审核通过等。好处是实现简单，一个熟悉业务的测试同学就基本能 hold 住。缺点是容易改漏产生脏数据，而且从零造还得一步一步来。

第二阶段，结合接口自动化，用流程自动化用例来造数据。有几个能到上面提到流程点的自动化用例，并且把账号一些基础信息（如手机号）抽离成了配置项。好处是已经基本满足测试需要了，随时从零生成到某个节点的数据。缺点是客户端、前端开发以及产品还是不大会用（他们技术栈不一定是 java，所以不熟悉甚至本地都没有 java 环境），而且不同组用的不同的仓库，跨组使用还得了解哪个用例对应哪个东西，使用成本略高。

第三阶段，基于流程自动化用例，增加一些 controller+dto，变成 http 服务，并加入 swagger 做到每个接口自描述。同时也用 antd 做了一个前端，可以配置接入不同组的 http 服务，并基于 swagger 提供的内容，生成对应的界面。这样左侧是业务描述，右侧是这个业务下的各个造数据功能（也可以分组，一个 controller 在前端会放到一个 tab ）。执行失败前端会展示完整日志，方便用户提供给测试同学去定位解决。

除了我们的实践外，19 年的 MTSC 大会，工程效率专场，陆金所有一个议题特别分享了他们的造数服务，你可以到社区公众号底部的 MTSC 找到当时的视频和 ppt。

针对你这 3 个困惑，也相应说下我们之前对应的情况和解决：

只有写这个造数脚本/代码的人才知道相关的造数逻辑，给其他人维护或者小伙伴离职了都比较难维护下来

我们在第一阶段的时候这个问题遇到得比较明显，因为维护的人太少了，知识掌握在少数人手上。第二阶段就好了很多，毕竟大家都在写，而且能清晰说明这个流程，被定为了试用期通过的必要条件，也能保障不至于大多数人不清楚。

因为是造数嘛，通过 post 开发的接口去实现造数，版本迭代接口变了，那造数相关的代码也得跟着变

首先，服务端接口大多都是向下兼容的，所以接口变了很少会造数脚本也必须马上改，不改用不了。大多数情况是新产品接口加了参数，需要写心得脚本才能造新产品的数据。

因为组内每个人的代码风格都不一样，较难统一下来，整体看起来参差不齐

这个就需要培训和规范了。我们其实也有遇到，一开始考虑到水平不一，没限定写法，所以百花齐放，甚至有的组的写法只有自己组才能看得懂（主要是整体设计比较特别 + 各种奇妙的命名），而且大家都处于 “知道自己写得不好，但不知道怎么才能写得好” 的状态。后面整体做了一次重构，重新统一了写法，并且初期所有改动强 review ，由熟悉规范的人 review 通过才合并，保障大家姿势正确。后面就会好很多。

你试过直接用 shell 脚本啥的拷贝过去不？或者用 curl 命令把你 maven 仓库的包下载到你说的位置？

首先，app 和电商是两个不同维度的东西吧，app 算技术领域，电商算业务，按这个来说年限有点怪怪的。

其次，业务延续性确实不同人有不同的选择。我之前在互联网金融公司，里面的小伙伴出来有有继续在金融领域的，也有换到其他互联网领域的，甚至转行做产品或者其他岗位的。

我自己每次跳，虽然一直都是测试领域，但从公司对应业务领域来说差别都挺大。个人感受上，其实不会有太大的 “业务没有延续性” 这方面的担忧，反而会觉得自己的业务观会越来越大，而这个业务观也会帮助自己每次熟悉新领域的时候，更快速能上手和找到关键点。

补充一个点，对某个领域是否深入，呆多长时间只是一个参考值，关键还是是否有持续提升和扩大自己的视野。我在上家公司 3 年多时间，从小组长做到质量团队负责人，视野从只是管小组，变成了整个公司业务的质量，个人感觉对业务的深入度，尤其是对抓关键点的能力（比如那些功能对业务而言更重要），其实会越来越强。而这个能力后面换了公司，还是可以延续的。

包含但不限于这个，DevOps 关注的还是研发流程内部。这些年的实践，我对于提效的理解也有些转变，有点朝着精益的方向。

除了重复事情自动化外，会更多考虑怎么 “简单做”（简单到别人也能做，就可以顺势赋能），甚至 “不用做”（比如基于投入产出比评估来砍/拆需求、降低技术方案复杂度，这样质量风险减少，测试工作量也能对应减少）。

以我这几年做测开的经验， 很多有价值的事情都是需要一定的研发和运维能力才能去做。

这句想特别点个赞！很多时候想要做更有价值的事情，得先自己突破测试的界限。

我们以前遇到过类似场景，自己封装了一个断言函数，大概逻辑是：
1、入参是超时时间、查询 sql 、预期值
2、在超时时间内，每隔 1s 去查数据库的值，并确认值是否符合。不符合就继续查询，符合就 return
3、达到超时时间后的下一次查询，还是不符合，就抛出断言异常

借鉴的是 selenium 的 WebDriverWait 的思路。如果想通用性更强（比如不只是查库，还可以是其它断言），推荐直接引入 awaitility ，这个库就是专门干这个活的。

这个实践挺不错的，把重复繁琐的工作用自动化来提效。

手动筛选映射关系模板，人工核对代码的输出结果跟筛选的结果是否一致

这个部分能否详细说下在这个场景下，人工是怎么测试的验证的？

感觉这个 “筛选”，就是从庞大的映射集关系里，找到 key 和sku_key_list一样的规则，并把sku_list里对应的值，和规则里对应的值做一次匹配，得出对应的人可以理解的含义？筛选出这些规则后，后续是怎么测试？

我 2 年多出来的时候，也是差不多这个水平。这个薪酬和年限要求，薪酬不算低了吧。

话说，你那个朋友 9 年经验，这个 1-3 年的岗位也不一定匹配他把，忽略就好。真正要过百万那种高薪，基本都在大厂核心部门 + 高级别岗位。

客气啦，这些我也是和其他人交流 + 自己实践学到的，后面可以来社区多分享交流。

客气了，后面可以在社区持续交流。不仅是技术，也可以是一些提效的小技巧。

很多时候，通用性强（外面各种分享常见的基本都是这类）的工具，成本也不低。针对特定业务特定场景做的一些小工具，小改进，反而效果会更明显。

个人觉得，对于能效领域，工具平台都是辅助工具，关键点还是思想思维。比通过工具来提高测试效率来得更有效的，是通过需求分析、技术设计直接降低工程的复杂度，进而减少测试、开发工作量。

补充一个在实际中用处特别大的平台：环境部署管理平台。
主要提供能力：
1、快速部署单个应用（在部署里面融合流水线做各种卡点）
2、根据当前客户端绑定的环境，自行切换路由能力（比如完整系统是 a+b+c，本次需求只改了 b，那这个需求专属环境只需要部署 b，a 和 c 自动用公共环境里已有的）

这个平台在团队并行需求多的情况下，能非常有效提升效率，彻底解决测试环境少了不够用、多了部署和维护成本高的问题。

都是挺好想法。前 4 个点也很认同。现在为了 kpi 而做的平台已经越来越少了，也是一个好事。

个人觉得除了看到有这些业内有成功经验的能效平台外，还需要关注是否适合公司当前的业务，落地的 ROI（投入产出比）是否合适。上面提到的平台很多都是外部分享的常客，但有不少目前没有对应的可开箱即用的开源实现，所以对于不少公司来说，需要自行开发的部分不少，成本还是不低的。

比如流量回放平台
主要成本：找到运维 + 开发进行对应系统调整及接入，以及结果比对里如何有效降噪。由于业内目前没有什么开箱即用级别的开源工具，需要自行整合和适配自己公司的基础框架，开发成本会比较高
主要收益：对于已有流量的接口，可以快速构造对应的真实测试用例
ROI 最高的场景：接口不变情况下的系统重构/代码持续优化
总结：如果接下来有大型的系统重构，或代码持续优化是开发团队比较关注的点，且一直会占据一定的比例，带来一定测试工作量，适合使用。如果没这类场景，或者这类场景比重较低（基本都在做新功能，不怎么还技术债），投入产出比不高。

比如代码覆盖率平台
主要成本：测试环境的覆盖率数据接入、覆盖率统计平台开发、个别个性化能力的开发（比如增量覆盖率、多版本覆盖率合并等）、测试人员额外投入时间分析未覆盖点风险。
主要收益：覆盖率可以作为测试范围是否充分的参考指标；未覆盖行的分析可以辅助发现漏测点。
ROI 最高的场景：测试全面度的指标统计、测试末期的未测试点补充
总结：团队对质量要求较高，不仅要求需求点都有测试，且要求开发的一些功能点（比如异常处理流程）也需要覆盖时，收效会比较明显。如果还没到达这个阶段，或者相比精细化测试更关注快速交付，不一定适合。

有两种方式。

一种是你说的，去查询数据库。
另一种也是你目前在做的，使用查询接口。

两种都可以，相对来说查询数据库会更自由（因为系统可能没提供查询接口，或者部分内部字段客户端/前端用不到，查询接口不会暴露出来）。不过如果查询接口可以满足，用查询接口是最好的，后续有线上接口拨测需要的时候，可以直接复用（运维是不大可能为了这个，给你开线上数据库的权限的）

至于分页这个，抽验几个点就可以了：
1、总页数对不对
2、改变当前页数，数据是否有对应变化

实际开发写代码实现分页逻辑，这方面都有对应的库（可以百度下 mysql 分页查询），库的写法对了就很稳了，配置不对上面两个数据其中一个基本都会出问题，也很容易发现。

其实你说的东西是有一定道理的，比如从看技术书开始，学习要不断否定自己，这些我都认同。确实相比算法这类技术要求很高的岗位，自己还很菜。

只是这个表述方式有点太居高临下的感觉了，甚至略带点嘲讽（特别是 哎，挺难的，我这要求确实太高了 这一句，可能希望起到激将法，但可能听起来更像是打上了你们就是做不到的标签）。这语气更多会引起反抗，而非反思。

辩论不等于争论，更不等于要说服别人哈。个人理解，辩论的目标不是要辩赢谁，而是要看到事物的两面性，让大家对这个问题产生新的理解。

主要是看到大家戾气有点强，求学态度慢慢变弱了，所以才想搞下这样的活动。我比较喜欢 “三人行必由我师” 这种态度。

至于鄙视这个点，其他人怎么鄙视测试那是其他人的观点，也确实会天外有天人外有人。单纯语言上的反驳收效是很微小的，自己持续想办法变强，证明自己就好了。

看来涉及到了不少 pytest 特性，这块不大熟悉，先退下了。

看看其他同学有没有什么建议把。

额，从你的截图看，你这个代码里，self.staue 没可能是 False 。你这里逻辑是不是没贴全？

1、初始值是 True
2、后续改变值的语句 self.statue = outcome.success ，是放在了 if outcome.success 里面的，意味着这里面的 outcome.success 值如果是布尔值，那也必定是 True

所以，你在后面继承的 B 类里拿到 self.statue 是 True ，说明不了这个 True 就是第二个位置给的。

然后，也没太看懂你这里加个 self.statue 且想要被子类拿到的目的是什么，想实现什么功能？这块可以说下不？

PS：statue 是不是拼错了？状态的英文应该是 status

这个要看公司。没法一概而论。也有的直接按各个团队人员比例来裁。