• 看这截图,里面这个像是 h5 或者自定义 view,所以采集不到内部控件树。

    你问下开发,这个是 webview 还是什么?

    实在不行就只能用图像识别找控件了。

  • 标题没看懂,内容勉强看懂了。我理解这里没有任何的异步,都是同步,接口实际还是要等待 mqtt 返回报文后才会返回。建议楼主先了解下异步和同步的概念?

    回到问题,你先明确你要测的是提供 mqtt 消息处理的那个服务的逻辑,还是接口自身的逻辑(比如先查缓存后发 mqtt,等到 mqtt 收到返回,接口才返回 response)?如果是前者,不管接口直接测就好。如果是后者,可以想办法监控 mqtt 的消息收发情况,然后确认这个收发情况是否符合逻辑。

    之前我们测试 mq ,要验证某个接口请求背后是否真实发出了 mq 消息,mq 消息内容是否正确,用的就是类似的手段。大概思路是给 mq 打开一些 debug 类开关,让它日志记录所有消息的收和发。然后再通过过滤日志,找到指定 topic 的消息,进行断言。

    写成伪代码,类似于

    # 调用接口
    resp = request.post(xxx)
    # 检查 topic 为 abc 的队列,在最近5秒内是否有一条包含 "userId: xxx" 内容的消息
    mqAssert.topic("abc").timeout(5).contains("userId: xxx")
    
  • 额,怎么隐藏的知道不?得先知道隐藏原理,才好推敲怎么识别吧。现在信息太少,没法给具体建议,硬要说就是先了解下这个是什么元素,怎么隐藏掉的。

    PS:你这个截图也看不出来这个控件树是怎么 dump 出来的,dump 的具体方法也同步下?除了这个控件树,是否也可以提供下 app 的截图?要不光看这棵树啥都看不出来。

  • 可以看看最近几届 MTSC 大会的议题,包括最新这届的:
    http://testerhome.com/topics/31136

  • 测试覆盖率的六大门派 at 2021年09月18日

    可以看下这篇:
    jacoco 的 merge 源码分析

    顺便给下搜索姿势:https://cn.bing.com/search?q=jacoco+merge&form=QBLH&sp=-1&pq=jacoco+merge&sc=0-12&qs=n&sk=&cvid=BF1058EE68D344DDA786303CAA5145A9 ,下次建议可以自行搜索下

    你这个场景,jacoco 的解决方案是多个覆盖率数据的 merge 。比如指令 a 在第一个数据里是未覆盖,第二个里是已覆盖,第三个是未覆盖,那 merge 后 a 就是已覆盖。整个 merge 是基于一个基础数据基础上,合并后面的其他数据,所以对于你说的 “修复 bug 后想要补上之前的覆盖率”,那你 merge 里基础覆盖率数据必须是修复 bug 后的最新数据。
    至于报告,都是基于覆盖率数据生成的,只要预先 merge 好数据,报告内容也会是 merge 后的数据。分母就是你 merge 里基础覆盖率数据里的总数,即修复 bug 后的最新代码产生的数据。

    但有一个点,如果要 merge 的覆盖率数据中,第一次的数据和第二次数据对应的代码是不一样的,那 jacoco 会以类为单位,哪个类不一样,那这个类就不会 merge ,只有一样的会 merge 。我发你的文章里对源码的分析也把这部分说得很清晰了。所以会出现,开发有改了代码的类,以前你可能已经覆盖过其中一些方法,但合并后这些方法还是会显示为未覆盖(因为类改了,merge 时这部分数据对不上,所以被丢弃)。

  • 加油!

  • 不适应是好事呀,说明是个可以得到学习提升的地方。

    之前也有遇到过,接口测试刚接触,产出慢,自己天天加班都达不到要求,心态会有点崩。当时是找了一些身边的同学多交流沟通尽快提高自己的技能,也找一些好朋友偶然吐吐槽,周末多做点自己喜欢的事情转换下心情。这样持续一段时间后,这道坎就过去了,而且自己也掌握了新技能,反过来看其实会很感激这段经历。

  • 一般代理有设定好规则自动 rewrite 的手段的,可以试试,这样不用担心 timeout 。

  • 你是不是手动改的抓包数据,改太慢所以客户端等不及 timeout 了?

  • 帮你加了下代码块排版,终于看到缩进了。。。

    你用 pycharm 具体是怎么执行的,也发一下具体步骤?如楼上所说,你这个文件里没有可直接执行的方法,都包在 class 里面。如果直接用 python xxx.py 这样的方式调用,实际里面没有任何一行是可以直接运行的,所以也是直接 Process finished with exit code 0

  • 要具体看你的上报事件是客户端上报还是服务端上报的,什么逻辑下才会产生。

    如果是客户端根据服务端返回值进行上报,抓包修改服务端返回值就好了。

    如果是服务端上报,那得再分服务端这个 fail reason 是根据什么得到的,如果是基于数据可以改数据库,基于下游接口可以 mock 下游接口。

    现在描述的信息不够具体,所以也没法给准确的建议。

  • 有自己内部平台,基于 agiletc 做的,也是 xmind 形式写用例。

  • xmind 优点是编写简单,缺点是别人相对没那么容易看懂(也有办法优化,写细一些,有问题能问人就行),适合经常有新功能要写用例,且大部分用例其实不会换着人重复执行的场景。互联网大多是这种,就算是发版固定要跑的场景,xmind 写细点其实也够用。

    excel 优点是很规范容易统一,缺点是写起来的成本比 excel 高,适合写完基本就不怎么会改,且会需要换着人执行的情况。只是互联网现在这种情况太少了,所以用得很少。

    至于你提到的 excel 听说很多大厂都用这种 ,建议细问下是大厂的啥业务,啥场景(比如给流动性很高的外包纯执行用)?不能听到大厂就直接追随,大厂通常有很多不同类型的业务,不同业务差异还是很大的。

  • 想问下,这个是稳定重现么?好慢具体是多慢(多少秒,浏览器开发者工具里,network 部分截个图看看就最好了)?完整的操作步骤发一下?

    我这试了几次,都挺快的,基本 1 秒不到就加载完了,没法重现,所以也没法了解到你具体的情况。需要你多提供点信息。

  • 3 年还年轻,多看看外面的世界吧。

    另外,提了离职就不要考虑回头路了,你的上级都知道你的心不在这,就算你留下了也不一定会主力培养你。何况你也说了,已经没太多成长,为了这 1K 放弃后面更大的成长(前提是你确认新岗位真的能成长更多,这点你可以找你未来 leader 多聊聊),不大值得。

  • 可以具体说下什么项目,安装不了是报什么错?

    个人经验,开源项目的作者对项目太熟悉,有些细节可能会遗漏写到文档里。而且也不一定有条件在各种环境下安装,所以大家实际在其他环境下安装,可能会出现一些作者不会遇到的问题。需要自行踩坑填坑一下。

    有问题安装不了,更建议大家社区发帖咨询沟通哈,安装文档都是需要大家持续反馈,持续迭代更新,才会越来越好的。说不定作者也在社区,这样交流起来也更便捷。

  • 哈哈,感谢支持。当时其实也是刚入门接口测试,会有挺多困惑的,所以写下来也是为了帮助自己更好总结理解。

    后面你对这个自动化意义有新的感悟,也欢迎来社区分享哈。学习了很多东西后,个人感觉,对术(怎么做、遇到的典型问题可以怎么解决)了解多了后,总结成道(能做什么不能做什么,什么时候适合什么时候不适合),会更容易记忆和应用,也避免跑偏用错,产生负效果。

  • 那么基于场景得接口自动化意义在哪里?

    个人理解主要有几个意义:
    1、能高频跑,更早发现问题。我们之前最高频率是每 30 分钟跑一次,失败立马预警,开发立马修复。这个换成人力跑成本太高了,而且有些核心问题如果到末尾回归再发现和修复,时间会很紧,改过的代码多,找问题原因也会更加费时费力。
    2、减少人工测试要跑的场景数量。主流程人工过一遍这个省不了,但工作量比全部过一遍要少不少了。
    3、如果自动化校验点足够齐全(包括数据库校验等所有人工测试会验证的都有验证到),且修改点确认只有服务端,不涉及其他端,那我觉得跑完直接上线是没问题的。

    例如一个支付接口他需要先添加购物车 =》下单 =》支付,那么在测试下单接口得时候,是把前两个接口都调用一遍获取订单信息再作为参数给到支付这里,还是直接在数据库里构造这部分信息测试支付呢?

    建议是都调用一遍,主要是从可维护性角度考虑。一般服务提供的接口,会保障向下兼容,且保障按顺序调接口没问题的。至于插库,这个特别姿势一般不会保障,意味着需要测试自己保障;而且这部分也是很可能会改动的,依赖的数据不一定都来自数据库,也可能是第三方服务什么的,那这个方式就行不通了。

  • 利用随机生成(0,1)方法随机生成 0~1000 的数

    我看到第一反应也是 random.random()*1000 ,日常写代码要取某个范围内的随机正整数就是这么写的,random.random() 生成的是大于 0,小于 1 的随机数。但这里有两个不确定的点:

    1、随机生成 (0, 1),不知道是指只会随机生成 0 或者 1,还是生成 0-1 这个范围内的数字。
    2、生成 0~1000 的数,不知道 0-1000 是范围还是啥。

  • 客气啦,最终还是你自己找到原因和解决的。我平时用 allure 也不多,也只是临时现找一些,给点思路。

  • 你把你的 jenkins 打包 html 报告那部分配置截图发下?

    我记得 html publisher 这个插件是把配置了的目录内所有内容都拷贝一份进行存档的,具体配置不大记得了。报错的那个 C:\DumpStack.log.tmp 应该不属于你 html 报告的一部分吧?如果不属于,说明你配置有问题,把一些无关的文件也纳入了。

  • 必应搜索了一下:https://cn.bing.com/search?q=allure+Behaviors+404&FORM=BESBTB&sp=-1&pq=allure+behaviors+404&sc=0-20&qs=n&sk=&cvid=191BE4F77E1D4B82A52481F85FA23E98&ensearch=1

    找到 1 个看起来有关的官方 issue ,大概指引是有垃圾数据导致:
    https://github.com/allure-framework/allure2/issues/1174

    另外,看官网,配合 pytest 生成报告的命令好像不是你发的那个,而是 allure serve /tmp/my_allure_results 。你可以换这个命令试试?
    https://docs.qameta.io/allure/#_pytest

    然后 allure 提供的 BDD 相关注解,官网没提到 @allure.epic ,你截图里有写。不知道有没有关系?
    https://docs.qameta.io/allure/#_bdd_markers

  • 个人观点:
    1、既然有这想法了,可以考虑出去面试一下,了解下行情,也是对自己能力水平的一种校验。担心直接投简历会被 hr 发现的话,可以找朋友内推试试。
    2、即使继续留这家公司,也可以争取向上走,比如带带团队、做些公司核心项目什么的,让自己变得更核心,能力更强。

    有时候,焦虑源于你对现有工作太过游刃有余,所以有太多时间去思考。当你在持续上升,保持着优势时,你就不会那么焦虑了。

  • 从截图上看,你 Archiving 的第二个是把整个 C:/ 都打包记录到指定目录,这范围太大了吧?

    C 盘会有 windows 操作系统的很多相关文件,其中不少文件都是有进程长期占用的,所以遇到这个报错不奇怪。根本原因是你范围有问题,不应该打包整个 C 盘的内容到报告目录里。

  • 人工查看是否有重叠等现象,场景比较多的时候,这块的工作任务会比较重

    之前 mtsc 大会有见到过这方面的议题,通过把值设定为所有语言下翻译的最大长度 + 页面自动遍历 + 图像重叠检测来处理。具体的你可以到公众号发送 ppt ,找到存历年 ppt 的网盘,搜索 全球化 这类关键词