以前好像有一些众测平台，可以接任务。不过不知道现在还有没有还活着的。

最简单直接的，比不会 go 的多一门语言技能，哈哈。

按照我个人理解，go 语言本身的优势是语法相对简单，而且性能比较高（比 python 之类的解释型语言高），打包产物为一个独立文件，部署也简单。目前用 go 比较多的应该是 运维开发、服务端开发。

对测试来说，如果你这个脚本想让别人更快速地部署起来（直接下载编译后的可执行文件->运行，不用装环境），go 是个不错的选择。我看到的其中一个例子就是 sonic 平台，改为用 go 写的 sib 取代 tidevice ，这样就不用让用户特意装 python 环境来运行 tidevice 了。

不过，貌似 go 领域的测试工具框架相比 java、python ，相对比较少，所以可能有很多轮子不一定有现成的用，得自己造。

2 个建议：

1、尝试下通过人脉找内推，至少他能帮你找到简历直接不通过的原因，方便你针对性优化。如果不介意的话，也可以考虑把简历隐去敏感信息后发出来，大家给些意见建议。

2、既然已经裸辞了，那就多点耐心吧，也降低一下预期。广州机会不多的话，也可以考虑找下广东其他地方的，比如深圳。

这个编写时间，一般你的评估是多久？一般是怎么估法？

可以以社区帖子的回贴功能作为被测对象来估一下。

@TH_tester 看看？

比如一个商城的迭代，有商品管理页面，里面有搜索框、高级搜索、商品状态、商品的操作之类的，应该首先从哪开始写起呢，怎么搭建一个系统的有结构的用例呢

可以自己找个顺序，比如先按页面分大类，然后里面再按页面从上到下或者从左到右控件的顺序，去细化测试点。只要顺序得当，至少从界面功能角度，都可以过一遍。

还有那种 b 端和 c 端有场景交互的功能，这种又什么时候写出来呢 ？

不知道你的 b 端和 c 端具体是怎么交互的。个人习惯，一般这种复杂场景交互的，先看是哪些功能涉及，然后往功能里面加这方面的测试点。

如何合理评估一个功能迭代的测试用例时间呢？

不知道你说的是用例编写时间，还是用例执行时间。一般评估时间最常用的方式就是拆解，把整体需要测试的内容拆到一个每个部分你都可以快速评估出需要测多久的程度后，把这些时间加起来，再乘以 1.2（留 20% 风险时间），会是一个相对靠谱的排期。

google 了一下关键字 api test platform ，找到了这篇：10 Best API Testing Tools In 2022 (SOAP And REST API Testing Tools) 。里面也有挺多的呀。

只是，国内的平台大部分情况下，会更符合国人的习惯（光是有中文这个，就比国外很多纯英文的受众面广了），加上宣传比较多，自然你会接触到的，大部分都是国内的。

你的信息还是不够全面。命令的正常输出是啥，程序返回内容里缺了啥呢？

另外，channel.recv(-1) ，这里参数传入 -1 确认是没问题的吗？我看其他文档都是传具体最大长度值的。

你三楼找到的这篇，是完全脱离 docker 的，这么装没问题，因为 linux 主机本身是有状态的（所有改动不会消失），不会像容器那样设计时就是很低的销毁成本。

然后我意思是，进入 docker 容器一般只建议做调试查错类工作（比如测试下某条命令是否可以正常执行之类的），不要做环境配置类工作（如装新软件）。
环境配置类的东西，尽量在镜像里就配置好，这样才更接近 docker 的理念：拿着镜像直接部署使用。

另外，随手查了下这个库的用法，好像不能 send 完立马 receive 的，需要稍等一下？

我看的这个：https://pyneng.readthedocs.io/en/latest/book/18_ssh_telnet/paramiko.html

稍微吐槽下，官方文档好像没有 quickstart 这类快速上手文档，只有怎么装，以及很详细的每个函数的说明。对于想要快速知道典型用法的人来说，看得有点蒙

没看懂这个问题。

代码里的关键命令内容 cmd 内容是啥？
完整的返回值是啥，和截图里有啥不同，缺了啥？

可能原因：

1、重连的容器不是原来的容器。比如你通过类似 docker run -it jenkins:latest /bin/bash 命令启动容器并自动进入命令行，然后退出命令行，这时候容器会一并被关闭。重新 run 就会从镜像新建容器，而非启动原有容器。

2、你虽然装了，但相关路径没有加到 PATH 环境变量，所以还是找不到

建议排查一下。

PS：不是很建议在容器里面手动装软件或环境。容器最好应该是无状态的（可以理解为啥都不存，只是单纯一个有处理逻辑的程序），随时可以重建。需要有状态的部分（比如数据），可以通过路径映射之类的方式存到容器外，或者直接自定义一个镜像构建脚本，把要装的东西加到镜像里，让每次启动就自动带上。

嗯嗯，这个确实是需要修复的。

不行，这样实际还是向大量人员公开的，起不到内容审核作用。而且如果被发现，可能会被认为故意蒙骗监管部门有做内容审核，风险更大。。。

你上面提的，我理解已经挺全了。大部分情况下，不同环境的核心差异是 url 不同、数据不同，以及少量的被测系统逻辑差异（一般是被测系统配置项差异带来的）。

url 这个，抽离到环境配置文件里就好。
数据不同这个，如果可以重复用，就也抽离到环境配置；如果不能重复用，那就补充每个环境从零进行数据构造的逻辑，到用例的 setUp 里面。
被测系统配置项不同引发的差异（比如某些逻辑开关可能会有差异），这块就不建议脚本去适配了，直接弄个单独的检查脚本，让测试执行前，检查确认这些被测系统配置项尽可能一致就好。

可以加点达梦数据库介绍？第一次听这个数据库，搜了下，是个国产数据库。

大概看了下，有几个点想交流下，谈不上建议哈：

1. 从实现逻辑看，没太理解为何必须拉代码后，还得编译成 jar 包再解析？我理解静态的调用链信息获取，应该用 java 文件结合抽象语法树解析，就足够了。
2. 拼接 class 和 method 的 Mapping 注解 url 时，条件是 classUrl!=null&&methodUrl!=null ，而 controller 并不一定有 class 级别的 mapping 声明，如果没有的话，不知道会不会引起遗漏？（从下面逻辑大致来看，好像如果 class 没有 mapping 声明，是不会产生对应的数据的，即 classUrl 可能为 null ？）因为没有本地跑，所以只是一个猜测哈，如果有说错请见谅。
3. 从实际使用角度，光拿到 url 其实还不大够，可能会存在单个 url 有多个 http method 的情况，加上 http method 会更佳。
4. 建议项目加个 readme ，否则大家都不知道怎么用。

补充下，如果你只是要手工拿数据，不需要自动化或者转换为数据记录到独立平台，那直接用 chrome 的 devTools 就好了，有图形化的展示，数据也齐全。

Performance insights 应该可以直接获取到你提的白屏时间等指标：

详细的，你看看 chrome devTools 自己的相关文档研究下吧。

我看你给的参考连接里，第一个社区 360 团队的文章，你上面提到的几个问题，都有很详细的说明了。

对于白屏时间、首屏加载时间这块，大致原理我的理解是：

1、在 webview 启动上加料，让它注入监控相关的 api 调用，获取数据。这个就是 https://github.com/jwcqc/WebViewMonitor 这个项目干的活。
2、解析数据获取到的数据，就可以得到你提到的几个指标了。

然后文章里还提到的 pacap、pacap2har、harviewer 之类的，主要是分析资源请求情况用的（类似浏览器里的 network 标签内容），用于辅助定位为何白屏时间长这类问题。和获取白屏时间本身是不同的东西。

然后你提到编程语言，建议你先不要受制于语言，现在哪个工具比较适合，就去快速上手这个工具，别纠结自己不懂这个语言，非得找自己懂的那个语言的。

基本两个大方向：
1、如果只是测试有些配置限制是否生效，那改下判断逻辑里获取的那个数据值就好。比如改点赞数这个字段的值为 9999。
2、如果是要测试大数据量下性能是否会下降之类的，可以用接口自动化之类的自动触发用户行为。

看完后有个疑惑，你这里分享的是怎么测试小程序，还是测试提供给小程序调用的一些 sdk 框架？

metersphere 的用例管理模块，印象中也支持脑图形式的？

不过我觉得你们这个推进，应该最主要的问题，还是角色和时机。开发不清楚测试的痛点，测试也不一定喜欢由开发来主推这个事情，然后就会导致没人能拍板推进落地，容易不了了之。

如果是测试觉得 metersphere 能解决自己痛点，进行主推，可能又是另一个故事了。

通过代理把手机里的 wda 端口转发到电脑后，就可以用 usb 连接手机的电脑的 ip+ 端口访问了 wda 了。

tidevice 的 relay ，或者 iproxy 都可以做这个端口转发。

@Thirty-Thirty 因为前面的回复内容比较抬杠，且字眼里有涉及机关单位，比较敏感，所以均审核不通过。

欢迎友好讨论问题，但请勿抬杠。

而本项目的数据底数是有政数局提供，由于数据比较多且比较杂，从而导致数据在融合的过程中，有一部分数据缺失了某些字段，

当实际使用时，会有外部引入数据的时候，就要特别关注下外部引入数据的数据质量，并对其进行适配/修复了。你应该是只关注了功能质量，遗漏了关注数据质量。

涉及老数据迁移、外部数据输入的，都需要关注好数据质量。哪些字段一定有，哪些字段可能缺失，哪些字段可能有多种数据结构，都必须很明确，并且确保程序有做对应的适配。这部分正常应该在技术方案评审的阶段，稍微以终为始一下，过一下预计上线流程，就可以发现。