这个区别是 shell 的交互式/非交互式区别引起的,你要了解下相关知识
阅读者已经懵了,完全不知道你业务情况、实现逻辑,想猜信息量也不够呀。建议直接找你们的开发同学询问这几个问题的答案。
很高兴能帮到你,我离大牛还远着呢,共同学习交流哈。
如果有时间,建议多走一步,看下堆栈里 self._find_robot_installation()
方法的源码。会出现这个错误说明这个地方还有可优化的地方,解决后还可以给官方提个 PR ,贡献下自己的开源力量。
看起来有点像找到不止一个 robot framework 。堆栈最后的输出意思是 split 后元素不止 2 个,所以赋值失败。
谢谢指正,deploy 拼写已更正。
这三者的区别确实如你所说,总结得很清晰。distributionManagement 这个遗漏了说明,我这两天补充一下。
这个 bug 报得不专业呀,没有环境,也没有步骤,请求方式也没提供。
平台本身并没有开放过,不过可以看到文档里面的图来了解这个平台。
不好意思,之前没看到消息。
没尝试过,不大确定。理论上只要打包前有做好插桩,还是可以收集到覆盖率的。
不错,嵌入容易,而且还带有用户操作记录,挺实用的。
这类参数应该是类似于用户账户之类的参数,调用一次后状态就会改变?
那可以把这类参数改成用 beanshell 随机生成,或者执行完毕后把通过操作数据库恢复数据。
但是参数使用执行脚本后,这个参数就不可用了
这个具体说下是什么情况?
可以理解为一个基于 mock 技术和接口定义做的测试。mock 是一个技术,契约测试是一种测试类型。当然也有概念的成分啦,否则怎么和其它已有测试区分开
平时 mock 都是放在程序以外,单独维护,很容易出现代码更新后 mock 还没更新的情况。微服务下,这个问题会更加严重,因为十几个服务的 Mock 维护工作量可是不少的。并且调用链复杂的话,很容易上游改一个接口内容,下游就全都出问题。
契约测试则把 mock 放到应用中,更新代码同时更新这个 mock 。并且有用到这个服务的应用,都可以在单元测试中就直接启动这个基于最新接口内容的 mock 服务,不需要额外的服务器。自然也就起到了接口更新后如果不兼容,可以尽早发现的作用(前提是你要写针对服务调用的测试代码,哈哈)。这方面的详细内容,可以看看 spring cloud contract 的解决方案。
我们之前有尝试过,但因为项目中契约变动量不是特别大,而且说实话维护契约本身也是个不少的体力活,投入产出比并不高,所以后面放弃了。
闪退相关的 logcat 日志是什么?
截图里的是 warning ,不会引起闪退。
都重要。一般来说流程比较规范的公司,技术也不会太弱。
这个选择不错,第一家先熟悉规范的测试流程是挺重要的。
方向和目标可以自己去找呀。比如定个小目标,走读下所测服务的代码,整理记录里面的模块结构?
如果你能做到开发改了代码,你通过看 diff 就可以准确推导出影响范围和最低限度的测试用例,那你的效率就提高了,信心也增加了。从公司角度,原来要测半天的东西你能很有依据地说测 1 个小时就足够了,肯定是很欢迎的。
额,其实我没有想从测试转开发,我是想从单纯的功能测试转为关注效率和质量的测试开发。
另外,感觉是楼主自己把自己限制住了,负能量有点多。如果你确实只是开发或者产品告诉你什么你就测什么,那转了开发很可能你也是产品告诉你开发什么就开发什么,并不会有很大差异。限制你的不是功能测试,是你自己的心态。
既然你讨厌的是开发告诉你把 xx 再测一下,而且也有一定的技术能力,为何不考虑下直接去看开发的改动,并且自己分析出是不是真的有必要再测一下,如果是要测只需要测哪些功能?
一家外企的研发中心,加起来 300 人内,做外包业务的。严格意义上不算小公司。
我不是大神,不是批评,只是建议。
另外,建议用 markdown 排下版,现在的排版代码缩进都没了,看起来体验并不太好。
appium 服务器日志也发下吧?