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

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

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

如果你能做到开发改了代码，你通过看 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 之类的工具查看具体各个方法的耗时，效率才高。

各业务之间的 API 变更频繁，无法及时通知其它被调用方，导致在各自的 Unit 测试环节没有问题，但是集成测试时，就会出现各种问题

把各业务间的 API 封装成一些契约包，api 变更后契约包也自动改变，避免用了已废弃的契约却不自知。当然，api 变更的通知也得做好。

这个问题通过测试把关不是不行（例如一直维护着一份针对当前 api 的全量接口测试脚本，api 变更后脚本率先发现），但个人觉得效率不高，从开发底层上做效率会更高。

至于每个组件只管自己，不从全局考虑，这个就要靠测试去推动了，例如开始进入测试阶段的标准是全流程冒烟通过，而不仅仅是其中各组件独立跑通。

remotePath 写 4723 不大对吧？

相比于如何对外，如何对内，是否能让你成长和提高，我觉得更应该关注。我觉得一个好的主管不应该什么都说得很具体，而是给出方向，由团队成员给出具体方案和执行，否则成员比较难成长。

另外，会主动跟你介绍情况的都是非常好的主管了，一般情况下也就入职头 1-2 天会介绍下情况，其它时间他都很忙，这个时候确实需要靠自己问了。

至于需要揣摩心思，我觉得是你还没找到合适的沟通方法。不清楚的地方不妨自己思考下，然后给他说明下你对他交给你的工作的理解，看是否和他想的一致，这样更高效。