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

    不同第三方支付这方面还是有差异的,有的是服务端纯 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 年多时间,从小组长做到质量团队负责人,视野从只是管小组,变成了整个公司业务的质量,个人感觉对业务的深入度,尤其是对抓关键点的能力(比如那些功能对业务而言更重要),其实会越来越强。而这个能力后面换了公司,还是可以延续的。

  • 大厂面试总结 at July 05, 2021

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

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

  • 大厂面试总结 at July 05, 2021

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

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

  • 我们以前遇到过类似场景,自己封装了一个断言函数,大概逻辑是:
    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 分页查询),库的写法对了就很稳了,配置不对上面两个数据其中一个基本都会出问题,也很容易发现。

  • 某篇匿名是我写的 at June 29, 2021

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

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

  • 某篇匿名是我写的 at June 29, 2021

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

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

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

  • 看来涉及到了不少 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

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