好吧。。。
建议弄台 linux 虚拟机,或者给官方提个 issue 。这块比较深入 windows 和 linux 的差异了,我也不大知道怎么解决比较好。
刚找了台 windows 机器结合 git bash 试了下,貌似 ps 不会显示所有进程。可能是 windows 下不支持。
可以试试直接改为用控制台找到的 pid ,继续进行后续的 attach 步骤。
那就好。不好还是比较好奇,为啥一个 timeout 会导致 http method 都消失了。方便把你之前存在问题的代码附上来不?
另外,建议下次提问,可以把关键代码加上足够的注释,直接贴出来。这样沟通成本低很多。
你的异步请求代码是怎么写的?这个请求很奇怪,连 http method 都没看到用的是哪个。
这个太粗了吧。。。
会向后台提交这些步骤
,具体是怎么提交,同步还是异步,一次交互还是多次交互?
去调用我判断这些元素并执行相应的方法去找到对应的关键字驱动
,这个是纯服务端还是服务端 + 客户端的操作?
建议画个 uml 时序图(可以用 plantuml 或者找些支持时序图的 markdown 编辑器),说明下网页点击这个 测试 按钮后,浏览器端和服务端的交互。比你写文字清晰多了。或者直接把你这方面的代码贴出来,也便于了解具体实现细节。
另外,从你的说明上,大致猜到你是用了同步请求,但正常来说同步请求浏览器或者服务端会有个默认超时时间,达到时间只会返回 504 或者 timeout 错误,不应该页面卡住。这里面应该还有其他的问题。需要你提供上面提到的实现细节才好定位解决。
建议详细说下你这个 “点击测试” 按钮点击背后,到底平台做了啥事?
信息太少,只有个截图,也没有齐全的日志(浏览器的、平台服务端的)、大致功能实现逻辑,大伙也不好给你出主意,只能靠猜。实现逻辑猜错了,给的意见也很难有参考意义。
这个坑确实挺深的。想请教下,应该怎么做能避免踩中这个坑?
设置成不可见只是一个选项,便于作者做一些个人私藏的记录。专栏的核心点是提供更好的个人社区影响力。
至于发的帖子很少人回复,可以换个角度想下,会不会是帖子内容对大家吸引度有限,无法引起大家回帖的兴趣?一般大家回帖,要不是有同感,要不是发表自己不同观点,但这类帖子大多都是有作者的观点或者感想。一些不包含作者观点或感想的(如消息公告),容易无感导致没找到能回帖交流的点。
建立专栏本身,也期望大家更多去分享自己的独特经验或观点,便于社区的其它同学更好地认识你。
挺不错的,敢于突破。如文中领导所说,已经超越 95% 的人了。
功能做得挺全的,基本上大部分核心功能都有了。但个人比较好奇,这个平台的相比其它已有平台,独特的点是什么?或者说哪个点其它平台没满足,而这个平台可以满足?
后续周边功能方面的建议(仅供参考,具体还得看公司实际需要):
1、和持续集成的对接(如支持通过调用指定接口触发测试任务执行、支持自动发送测试结果到邮件/钉钉)
2、对流程类用例更友好的支持。从介绍上看,一次接口调用为一个用例,那对于流程类用例(调用多个接口的),是怎么处理?如果用用例集管理,那 3 个核心流程的用例要变成一个用例集一次性执行,是否可以配置?
3、对于多项目的支持(每个项目有自己的独立的环境配置、用例集、定时任务等)
4、数据报表(如趋势图、饼图)。这个领导会比较关注
另外,通过平台降低技术要求是一个挺好的切入点,但如果要把自动化坚持下来,逐步让测试关注技术、推动规范统一还是需要的,要不维护用例会累死,自动化发现不了什么问题也会导致大家不认可。
我指的不是线上回滚,是测试环境切换版本到可以验证的旧版本
1、先把问题归类。bugly 之类的平台已经会自动按出现次数排序了。
2、寻根问底是什么原因导致的问题。可以参考 5 why 原则,了解到根本原因,再从根本上解决。
假设占比最大的问题,从崩溃平台上看到原因是空指针,可以按照类似下面的套路询问:
那问题的原因就比较清晰了:接口文档的维护成本太高,导致客户端没考虑到这个场景,最终导致这个空指针。那解决的方法,可以考虑用 swagger 之类的自动生成接口文档工具生成接口文档,免除接口文档的额外维护成本。当然,也可以更进一步,了解为何接口总是要调整,是否团队人员经验太缺乏导致设计没做好,还是需求改动太频繁导致系统必须配合调整。
同时,也补充一个,使用前判空是一个很关键的编程习惯,可以团队内分享下各种遗漏判空导致的损失,以及形成什么样的习惯来避免空指针异常(调用这个对象的子方法/子属性前,都先判空)。
执行 cd complete mvn install && java -jar target/*.jar
之后,你是新开窗口执行 ps aux | grep target/gs-rest-service-0.1.0.jar
的吗?
从你的描述上看,这个 jar 包在 attach 的时候是没有在运行的。
个人理解,javaSubInvokeBehaviors 对应子调用,回放时会被 mock 掉(前提是回放时给到的入参和录制时一致),javaEntranceBehaviors 是入口调用,回放时会被作为输入。
举个例子,a 接口对应的 controller 方法是 A,而 A 的实现里面有调用另一个系统的接口,方法是 B 。录制回放主要测试的是 A 方法的逻辑,不想依赖另一个系统。
此时,应该配置 javaEntranceBehaviors 为 A ,javaSubInvokeBehaviors 为 B 。
这样回放时,A 这个入口调用会被原封不动地发给应用进行回放,而 B 这个调用会被 mock 掉,应用实际不会发请求给另一个系统。
深有同感,从用户角度思考很重要。
建议可以看看产品经理相关的文章,对如何培养用户嗅觉,有很多相关的资料
赞!期待后续解决阻碍后的更新。
这类问题去脉脉匿名区问比较好吧,也为陆金所的同学着想下?
PS:这类问题可以直接问 HR ,或者问你要入职部门的同学。陆金所还是挺大的,很有可能回答你的同学加班情况和你即将入职部门的不一样。
感觉楼主的解决方案,不好保障是否做到位?比如要求大家都检查配置文件的 ip 是否正确,如果刚好这次是一个新入职的同学,不知道或者不记得要这么做,问题是不是还会存在?有什么手段检查大家是否都有做到位,甚至达到做不到位就无法进行线上/预发布环境的接口测试的地步,杜绝问题的再次发生?
个人建议,可以从这几个方面做:
上述几个如果做到了的话,那么如果一个测试人员要让一个本不该在生产环境跑的用例,到生产环境跑,必须拿到 jenkins job 的配置权限并改为自己的用例集/绕过组长往线上用例集中加入不该加入的用例,除非故意做,否则不可能由于粗心达到这个目标。这样是否能更有效地避免同类问题发生?
文中提到一个点,做出来的工具没有落地使用,所以价值不大。但从后面的规划看,好像没提到与之合作的团队的声音?
有试过和其它团队一起沟通,以一种合作的方式来进行工程效率工具/平台的建设吗(比如前期需求目标确认,喊上合作团队的同学一起参与;每部分功能完成后,都邀请合作团队试用)?有轮岗到业务团队一起去完成一次业务项目,从中感受下业务团队的痛苦点吗?如果没有,那很多时候并不好抓住最痛的痛点,因为看问题的角度并不一样。
个人建议,可以尝试参考腾讯的《不测的秘密 精准测试之路》里面的模式,业务组一个同学 + 工程效率组一个同学 + 一个 leader 级人物一起合作,大家朝着一致的目标,完成一次效能提升。
嗯,那看来情况不同。
我们是用代码实现的话,多接口加密会导致代码重复比较多,不好维护。
用 JSR223,会不会调整参数不方便?
对于这类加解密,我们一般是通过增加 http 实现来做,便于继续复用 http 界面进行入参编辑。
没有尝试过。已经一段时间没有弄 app 相关的东西了。
这个问题有点伸手党呀,公众号、百度有尝试过不,如果有,也把相关记录贴下?
我们公司有在使用,公司的 java 规范就是基于阿里规范调整而来的。
只是这块更多是由独立的 代码评审委员会 做,测试同学参与不是太多。
额,你没有再确认下,mock 写入大致指的是什么?
“mock 的写入” 这个术语我也是第一次听,能猜想的可能有两个:
1、mock 逻辑的写入。类似于 mock 规则怎么写
2、把应用中写入相关的逻辑 mock 掉
但真的无法确认是哪个。