一般卡顿可以看下：

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

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

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

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

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

工具不错，点赞~

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

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

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

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

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

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

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

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

remotePath 写 4723 不大对吧？

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

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

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

如果是为了发现更多 bug ，推荐用探索性测试。

自动化的用处主要是提高回归测试的效率，适用于需要频繁回归的项目。更新非常慢的项目，我觉得其实引入的必要性不大。

stf 前后端也是通过路由方式通信的。你说的整合我理解是 iframe 这种，应该是可以整合的，但你会获取不到上下文，例如这个内嵌的页面不知道当前连的是哪台设备。

PS：stf 本身就支持一键上传 + 安装 apk ，你这个功能是不是和它自带的功能重合了？

这个是平台，不是框架了吧？

requests.post(url,data=para,headers= header1)

这里的 headers 对应的是 http 请求头部（header），即 http 协议中的一个特殊部分。和你在 http body 里面的 json 的 header 字段值不是同一个概念。而你的 http body 一直都是缺少了 header 这个 json 字段的。

遇到这类问题，推荐你用一个通用的解决方法：抓包。先抓到 Postman 发出的正确包，然后再抓 requests 发出的包，比对这两个包的差异，改你的脚本直至两者抓包结果一致。

PS：从 postman 截图来看，有 3 个 http header 字段，但你 python 脚本里没配，可以从这个方面尝试去看看？

目前还在筹备中，后续会有的

好持久，佩服。已经跟不上了。

加油！

换个角度来说，秒拒节省双方的时间，也不见得是坏事。

招聘目标明确的公司，最低要求不匹配就会秒拒。

你说的是服务器中的配置文件？ router 一般和具体功能绑定，不随便改，所以应该不会配置到配置文件。

你提到的这部分功能，其实都是由框架负责实现，应用只负责对应配置 router 规则。我理解这部分的测试应该通过检查 router 规则效率更高？

看源码。

内容不错，写得挺详细的。如果能用 markdown 排下版就更好了。

另外，我目前配置的时候新增 provider 节点不需要改 nginx 的，provider 不直接对外暴露。想问下你这里需要配置 nginx 的原因是？

从实际服务端开发的角度，一般会有一个 router 负责管理所有的 path + http method 组合的响应，如果这个组合服务端没有，那么就会返回 4xx 系列错误码（如 path 没有注册到 router 返回 404）。

看了下这个 options 的说明，感觉它只是一个特殊的 http method ，按照协议会告诉你这个 path 可以访问的 http method 有哪些，但实际实现是框架默认实现好的。从你描述上看应该是服务端关闭了 options 的自动响应吧。

想了解这个和安全有什么关系？依我愚见，即使关了 options ，也只是提高扫描成本，但照样可以通过每个 path 各种 http method 都试验一次找出所有允许的请求方法。