看这截图,里面这个像是 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
可以看下这篇:
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 报告的一部分吧?如果不属于,说明你配置有问题,把一些无关的文件也纳入了。
找到 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 的网盘,搜索 全球化 这类关键词