我们内部仿照 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 天会介绍下情况，其它时间他都很忙，这个时候确实需要靠自己问了。

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

如果是为了发现更多 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 的原因是？