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

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

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

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

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

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

闪退相关的 logcat 日志是什么？

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

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

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

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

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

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

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

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

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

我不是大神，不是批评，只是建议。

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

appium 服务器日志也发下吧？

请用 markdown 排版，代码缩进都没了。。。

另外，“干货” 这个词慎用，社区里有不少对 stf 很熟悉的人，这篇文章讲的东西离这个词还有段距离。而且文章中的改造方向不大对，这个 chunk.js 是通过 webpack 生成的，直接改里面的内容这种做法并不推荐，重新 build 一遍就 gg 了。stf 已经把登陆鉴权单独抽离成一个服务了， @0x88 给出的才是正确遵循 stf 本身设计的改造方法。

提示找不到 com.sun.tools.javac.util ，这个应该是 jdk 自带的包。检查下 jdk 安装对不对，idea 里这个项目有没有配置用对应的 jdk ？

我们内部仿照 360 case+ 自研了一个基于 xmind 的平台，可以直接在线编辑、存储 xmind ，也支持登记用例执行状态、关联 bug 、生成执行率和通过率报表。

一般卡顿可以看下：

1. 开发者工具里的 过度绘制 ，会不会绘制层级太多
2. 某些渲染时需要调用的方法耗时太长，导致卡顿（结合工具看各个方法耗时）
3. 资源不足（cpu、内存等）

一般来说，界面的卡顿和服务端没啥直接关系。

麻烦排下版吧？现在的格式读起来不大舒服

看自己兴趣吧。不过做测试开发，前两个是基础。

能给 404 ，说明双方通讯正常，肯定都是能 ping 通的。。。

工具不错，点赞~

我在想，后面如果用例需要做调整，怎么办？用 testlink 做感觉效率比 xmind 低不少呀。

post 传的数据也是明文呀。除非自己自定义加密或者用 https 。

不建议这么做，一扎堆就很难处理。而且自动化分给单独团队做会导致独立团队对业务熟悉度有限，增加业务熟悉成本。也不便于测试团队技能提升。

通过日志分析效率很低，要用 jprofiler 之类的工具查看具体各个方法的耗时，效率才高。