1. 用 env 命令,看 Jenkins shell 和你 ssh 的 shell 环境是否一致
    2. 跑命令前,先用 source 命令加载环境变量配置。命令用法自行百度

    这个区别是 shell 的交互式/非交互式区别引起的,你要了解下相关知识

  • 阅读者已经懵了,完全不知道你业务情况、实现逻辑,想猜信息量也不够呀。建议直接找你们的开发同学询问这几个问题的答案。

  • 很高兴能帮到你,我离大牛还远着呢,共同学习交流哈。

    如果有时间,建议多走一步,看下堆栈里 self._find_robot_installation() 方法的源码。会出现这个错误说明这个地方还有可优化的地方,解决后还可以给官方提个 PR ,贡献下自己的开源力量。

  • 看起来有点像找到不止一个 robot framework 。堆栈最后的输出意思是 split 后元素不止 2 个,所以赋值失败。

  • 谢谢指正,deploy 拼写已更正。

    这三者的区别确实如你所说,总结得很清晰。distributionManagement 这个遗漏了说明,我这两天补充一下。

  • 这个 bug 报得不专业呀,没有环境,也没有步骤,请求方式也没提供。

  • 平台本身并没有开放过,不过可以看到文档里面的图来了解这个平台。

  • 接口测试的一些感悟 at 2018年06月08日

    不好意思,之前没看到消息。

    1. 不大了解 soapUI 从 swagger 导入 URI 可以做到什么程度,如果可以做到自动生成部分用例内容,那么选这个可能更能提高工作效率。
    2. 实现 excel 设计了数据组合后自动跑,如果是 java 可以用到 testng 的 dataprovider ,jmeter 的话可以直接用它读取 csv 的功能。其它工具就不大了解了。
    3. 校验点的设计是个学问,可以先从 response 中是否包含指定内容开始,然后后期成熟后扩展到数据库的校验。
    4. 开发提交后自动跑起来,可以用 jenkins 建一个 job 来跑自动化,job 的触发条件是开发代码仓库有 push 操作或者代码有改动。
  • 没尝试过,不大确定。理论上只要打包前有做好插桩,还是可以收集到覆盖率的。

  • 不错,嵌入容易,而且还带有用户操作记录,挺实用的。

  • 这类参数应该是类似于用户账户之类的参数,调用一次后状态就会改变?

    那可以把这类参数改成用 beanshell 随机生成,或者执行完毕后把通过操作数据库恢复数据。

  • 但是参数使用执行脚本后,这个参数就不可用了

    这个具体说下是什么情况?

  • 可以理解为一个基于 mock 技术和接口定义做的测试。mock 是一个技术,契约测试是一种测试类型。当然也有概念的成分啦,否则怎么和其它已有测试区分开 😄

    平时 mock 都是放在程序以外,单独维护,很容易出现代码更新后 mock 还没更新的情况。微服务下,这个问题会更加严重,因为十几个服务的 Mock 维护工作量可是不少的。并且调用链复杂的话,很容易上游改一个接口内容,下游就全都出问题。

    契约测试则把 mock 放到应用中,更新代码同时更新这个 mock 。并且有用到这个服务的应用,都可以在单元测试中就直接启动这个基于最新接口内容的 mock 服务,不需要额外的服务器。自然也就起到了接口更新后如果不兼容,可以尽早发现的作用(前提是你要写针对服务调用的测试代码,哈哈)。这方面的详细内容,可以看看 spring cloud contract 的解决方案。

    我们之前有尝试过,但因为项目中契约变动量不是特别大,而且说实话维护契约本身也是个不少的体力活,投入产出比并不高,所以后面放弃了。

  • 闪退相关的 logcat 日志是什么?

    截图里的是 warning ,不会引起闪退。

  • 都重要。一般来说流程比较规范的公司,技术也不会太弱。

  • 这个选择不错,第一家先熟悉规范的测试流程是挺重要的。

  • 为什么想从测试转开发 at 2018年05月30日

    方向和目标可以自己去找呀。比如定个小目标,走读下所测服务的代码,整理记录里面的模块结构?

    如果你能做到开发改了代码,你通过看 diff 就可以准确推导出影响范围和最低限度的测试用例,那你的效率就提高了,信心也增加了。从公司角度,原来要测半天的东西你能很有依据地说测 1 个小时就足够了,肯定是很欢迎的。

  • 为什么想从测试转开发 at 2018年05月30日

    额,其实我没有想从测试转开发,我是想从单纯的功能测试转为关注效率和质量的测试开发。

    另外,感觉是楼主自己把自己限制住了,负能量有点多。如果你确实只是开发或者产品告诉你什么你就测什么,那转了开发很可能你也是产品告诉你开发什么就开发什么,并不会有很大差异。限制你的不是功能测试,是你自己的心态。

    既然你讨厌的是开发告诉你把 xx 再测一下,而且也有一定的技术能力,为何不考虑下直接去看开发的改动,并且自己分析出是不是真的有必要再测一下,如果是要测只需要测哪些功能?

  • 一家外企的研发中心,加起来 300 人内,做外包业务的。严格意义上不算小公司。

  • 我不是大神,不是批评,只是建议。

    另外,建议用 markdown 排下版,现在的排版代码缩进都没了,看起来体验并不太好。

  • appium 服务器日志也发下吧?