• 你这个是通过加 java agent 来弄的,属于 On the fly 。至于引入这个依赖,我理解是主要给单测覆盖率采集用的吧?没怎么玩过 java 服务的 offline 插桩(因为 On the fly 很香,没有什么改用 offline 的理由),不大清楚。

    也补充说明下,一切覆盖率工具,原理上都得给原版代码加额外代码。加的这个代码主要是一个标记,让给某个指令/某一行代码的运行前后,改变这个标记(比如默认标记是 0,有跑过就变成 1),标识这一个指令/代码行执行了。
    只是由于 java 这门语言支持运行时字节码增强技术,也提供了 java agent 这样的不用改源码就能改字节码的玩法,所以才出现了这种特别的看起来 “无侵入” 的加代码姿势。所以官方把这种方式比较形象地称为 on the fly(直译是飞行中,你可以理解为运行中插桩)。

    但要注意,因为 java agent 本质上还是在运行时改了字节码的,所以原理上是完全可以改变代码逻辑的(比如 jvm-sandbox 官方例子里的,不改源码直接改变某个函数的行为来修 bug ),接入多个 java agent 也有可能产生相互影响出 bug ,所以不要觉得这个方式真的 “不侵入、无风险” 哈。

  • @jiazurongyu 大猫知道么?

  • 小程序的菜单不一定属于 webview 的一部分吧,你先 dump 整体界面控件树看看?

  • 学习 Java 还是 Python? at November 04, 2021

    @Fhaohaizi 标题帮你改了,不要把正文直接作为标题。。。

  • 看出问题概率高不高,高的话就要在灵活和安全两个里面做取舍,牺牲灵活性。比如收回多部门的编辑权限变为某个部门集中设置,或者每个这种规则的变更都需要上级审核确认后才能生效(比如线上数据库变更的玩法)。

  • 个人理解,测试没办法对所有业务人员的配置正确性负责(权限上线上业务人员权限分分钟比测试还高,测试没法把控),但需要对系统的健壮性负责,即要能尽量确保系统配置不符合业务规则时,能明确提示;对应的降级容错措施能把业务问题降到最低。

    不过大部分内部配置系统规则都会比较复杂,全部做校验成本比较高,产品和开发是不愿意的。而且运营人员流动性很大,本身也不一定熟悉系统,配错漏配真的是常事,最终造成线上故障,测试肯定逃不掉要协助排查处理。所以我们内部实际落地还有一种方式,就是重要活动/配置在配置完未发布时,给测试在预发环境进行验证,确保配置正确无遗漏。既然配置容易出问题,出问题后测试都是要投入,事前投入保障没事故,比出故障后费劲排查要高效得多。

  • 行,讨论到此结束吧,我们继续保持双方的观点就好。也希望后续的文章,这些概念性的内容,请做好审核,最好是加上参考资料或者出处,经得起大家的推敲。

    关于言论自由这个,也特别说明下,社区一直保持言论自由,这个帖子一直没有被屏蔽就是一个证明。但也请注意,社区的初衷是为了帮助新人成长,提高测试地位,推进质量发展,因此会保持对内容进行审核。遇到内容不大正确,经不起推敲的,会有人站出来指出;太不靠谱的,我们也会直接屏蔽。

  • 每个人角度不一样这个没问题,只是你这个分类,特别是 RPC 和 gRPC 并列,这个分类方法会让新手很迷惑这两个 rpc 有啥差异,实在有点说不过去。

    既然要给新同学布道入门接口自动化,内容里给读者一个经得起推敲的指引,这个是基本要求吧。如果有些不确定的,建议特别说明 “个人观点,不一定正确,欢迎探讨”。

  • hmm,你想办法和领导沟通好吧。

    不是所有手工都适合自动化的,也要考虑投入产出比,不要为了自动化而自动化。

  • 现在这个还是不大对。。。我说下我的个人理解。

    首先,按网络接口角度,网络接口调用的核心目的,主要有 2 个:把约定好格式的信息发送给指定的目标

    传输协议的目的是为了解决发送给指定的目标这个目的的。有多种协议,比如 http、https、tcp 等。tcp 也是常说的长连接,http 是基于 tcp 的但无法支持任意一方随时发起通知,所以对于一些实时通信要求比较强的,会直接基于 tcp 来进行网络连接。tcp 典型的使用场景有微信的消息传输、直播应用的公屏消息等。至于怎么定义指定传输目标?http/https 用的是 url ,tcp 用的是 ip 。

    而序列化方式则是为了解决约定好格式的信息这个问题的,常见的有 proto buffer 、json、xml 等。序列化方式保障发送者和接收者用一致的格式解读数据,确保数据传输正确性的同时根据传输场景进行优化(比如一样的信息,用 json 占用的空间比 xml 小,proto buffer 又比 json 小)。当然,除了序列化方式,部分协议也有定义信息格式这类字段,比如 http header 。

    然后,在实际编码中,不管什么传输协议、序列化方式,都得自行基于网络库来建一大堆封装方法,接口多了这部分逻辑也有不少的工作量,所以就有了 RPC 调用,把网络库部分自动封装好,开发不用管底层网络库,直接引用 api 包,调用里面提供好的对象和函数即可,大幅度降低开发的调用成本。

    而 dubbo、grpc 属于实现了 RPC 理念的具体框架,由于它们封装了底层的传输协议、序列化方式,因此也具备切换多这个协议的能力,比如 dubbo 支持 http、dubbo、thrift 等多种协议。同样由于 RPC 本身就是一种调用方式,本质就是对传输细节的封装,所以一样会有 一个rpc框架封装另一个rpc框架 的情况。比如 dubbo 底层也支持通过 grpc 来进行调用。

    至于 RESTful(Representational State Transfer),不属于以上任何一类,它是一种针对 http 协议的接口风格。核心思想是把最常见的数据库的增删改查,和 http 协议的 post、delete、put、get 方法进行一一对应,便于简化服务端逻辑(这种直接增删改查数据的,可以直接基于数据库生成完整的调用逻辑,现在实际也有相关的工具)。当时时代背景是接口协议定义没有任何统一指导思想,大家随心所欲,经常会出现同样是删除资源,每个人创造一种风格的接口路径(有的叫 delete,有的叫 remove 等),复用度也不高,所以产生了这种定义清晰简单,扩展性复用性也强的接口风格,并受到很多开发的欢迎。只是传播过程中很多一知半解的,把它等同于 http 接口了,讲着讲着变了味。

    可能有的人会觉得,概念不重要,也确实很多人即使把概念搞混,也不影响工作。但基于这篇文章是想给新人们宣导用的,所以里面的概念还请理清,避免新人们不同地方看到不同的概念,陷入混乱,这就违背了初衷了。

  • 根据调用特性,接口大致可以分为以下几类:
    http
    https
    RPC
    webservice
    Restful api
    ...

    这个分类方法表示不认同。http、https 代表的是传输协议;RPC 代表的是调用方式;web service 代表是个 web 服务(有点废话);restful api 代表的是接口定义风格

    这几个东西不是同一个维度的,不能进行并列分类,比如这句话是没问题的 “某某 RPC 调用方法,背后采用了 http 传输协议和 web service 进行通讯” 。

    基础概念非常重要,请说明清楚,不要误导别人。

  • 没操作,因为没用到。好奇问下,你们那为啥要弄 frame ?移动端本身界面就不大,很少见到还会往这么小的 h5 弄 frame 的。现在就算桌面端 h5 用 iframe 也越来越少了。

  • 而且测试去修改 开发的代码也不太现实

    不知道你们公司是什么氛围,在我的经历里面,测试去修改开发代码,做一些自己需要的增强或者修改功能,让测试更便利,是非常正常的且被鼓励的(当然,改动后要开发 review 通过才能合并)。而且这样也更容易产生产出。不修改代码,你能做的和一个用户能做的差不多,实际会非常有限。

    比如我们做 UI 自动化,如果元素不加唯一标识,要定位会非常费劲,而开发只需要加一行和业务逻辑无关的代码,就可以加上这个唯一标识了。
    比如验证码,开发做个万能验证码支持,我们就不用费劲去搞各种验证码识别了。
    再比如一些 rpc 通讯协议,只要网络组件支持多通讯协议切换,并支持使用 http+json ,那测试就有一大堆现成的工具可用,而不需要再重新自研针对这个自家通讯协议的配套测试工具。

  • 你在跑哪个命令的时候报错?可以把完整的日志发一下不?

    项目本身没有依赖 python ,估计是项目某些依赖有需要用 python 安装。

  • 这个话题略庞大,很难回答,只能说从我自己经历角度,给个参考回答吧。

    要掌握哪些技能?

    测试的:接口自动化、UI 自动化、脚本造数据等
    开发的:web 前后端开发、app sdk 开发(视情况而定)

    从哪里学起?

    建议从自动化学起,先学会写脚本跑起自动化,然后把脚本重复部分抽离成框架让你的维护成本和编写成本降低。同时日常中多用自动化脚本解决批量问题,锻炼自己按需随时可以写脚本的经验

    测开的工作是怎样的?

    目前接触,测开一般有两大类,一类是业务测开,一类是平台测开。

    业务测开一般在业务团队里,属于业务测试团队里的技术担当,日常会承担一些迭代测试,但更关注自动化、专项测试(如性能测试)这些方面。同时也会肩负如何提高业务测试效率的责任,针对业务开发对应的提效工具(比如造数据脚本)

    平台测开一般在独立的效能团队,属于整个测试部门的技术担当,日常主要负责部门各个测试平台的建设、优化和推广落地。典型产出是类似接口测试平台、UI 自动化平台等。这类测开基本专注在平台开发了,对开发技能要求高于测试技能,偶尔也会支援业务完成一些业务需要的工具平台开发。这类测开一般是从业务测开做上来,又或者是直接从开发转过来。

  • 技术上可以考虑 adb 直接发键盘事件

    但建议涉及实际付款的,先别自动化了吧。一个是跑多了你的钱很快就不够了,另一个是支付页面各家都会做安全方面的防护确保是用户本人操作,自动化成本会比较高。

  • 1、为啥无法预先准备呢?你先跑一遍模拟登陆,把 token 拿到,然后再把这些 token 用到后面接口就可以?你原来用登录接口也是分 登录获取 token 和 其它接口使用 token 两步吧,现在只是把第一步拆出来而已。
    2、我只是举个例子。如果你已经确认了 TPS 要 300,那就按 300 就好。

  • 个人能想到的三个方案

    方案一:把你的真机也搬到机房,人工需要控制时,通过远程真机连接控制。
    方案二:找运维加白名单,打通链路。
    方案三:不要部署到机房服务器,自己申请个 mac mini 当服务器用,放在自己工位。

    我们目前用的是方案三,原因:
    1、方案一,idc 机房一般不愿意接受放手机进去的,手机电池长时间充电容易过充产生危险,不满足机房安全方面要求。
    2、方案二,运维加白了之后,如果没有专线网络(真正的专线,不是 vpn 这种走公网的虚拟专线),网络会不稳定,导致自动化执行不稳定。

  • 你是在行车记录仪的开发公司是么,那应该有行车记录仪的源码吧?

    有的话,直接改源码里面的视频信号入口,把原来从摄像头硬件来的流,改为从你指定的另一个地方(比如你要播放的视频)来,是否就可以?

  • 没有 MFI 认证,用破解 lighting 芯片的就会这样,系统升级之类的就会因为无法适配失效。
    预算可以的话,确保采购的都是有 MFI 认证的就可以了。

  • 从主贴描述,你应该还在自动化起步阶段,建议一步一步来

    1、先把主流程列出来(先不要管是否涉及端到端交互,列全了先),然后逐条评估自动化实现及维护成本。
    2、按自动化成本排序,进行分阶段。先做成本低的部分,快速出效果,让你的自动化得到认可进而获得长期投入的机会。剩下的成本高的,先继续人工覆盖。
    3、逐步补充剩下的成本高的自动化用例。
    4、偶尔出现的一些线上出过大事故且自动化成本不算特别高的,也可以加到自动化里面,避免再次遗漏。

    不知道你们团队对于自动化用例的编写维护经验如何,如果都是新手的话,最晚第二阶段产出一部分用例后,就要考虑维护成本,优化写法了。要不用例越来越多,维护成本会越来越高。

  • 精准测试中的一些疑问? at October 29, 2021

    从严格意义上说,这种不能反推调用链就覆盖到了,也可能实际这几个节点是在好几个调用链里分别覆盖到的,不是真的有走过一条直接就是这几个节点的调用链

    不过从工程角度,要真的那么细成本很高也很难,做到这个也足够了。

  • 也是,前面回答的时候没想太全面。

    你参照 6 楼的回复吧,写得比较全面了。

  • 人工哪个跑得最多,就写哪个。自动化首先是为了降低人工成本的,人工本身就不怎么跑,说明不重要,自动化也没必要跑。