另外，随手查了下这个库的用法，好像不能 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 因为前面的回复内容比较抬杠，且字眼里有涉及机关单位，比较敏感，所以均审核不通过。

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

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

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

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

核心目标我觉得楼上已经说得比较清晰了，补充一个个人观点：

要用好代码覆盖率，前提是对代码的变更内容以及被测系统有比较高的熟悉度，最好是结合 code review 进行，便于测试人员在熟悉代码的基础上，确认自己有哪些部分的代码还没有运行到，辅助补充用例场景。覆盖率本身最强大的不是这个，而是建立起用例和代码的有效关联关系，作为后面进一步的 基于变更内容推荐所需的回归用例集 的基石。

如果团队对代码熟悉度还不高，还没有深入到技术方案评审 + 开发变更代码 review 的程度，或者周期短时间紧对质量要求没那么高，那其实都不大适合引入覆盖率。容易只解读覆盖率指标，而不去实际看代码，而且还额外增加了熟悉代码的负担。

没太理解这个需求，为啥要作为 fixture 的入参呢？一般用法应该是 fixture 提供参数给用例用，用例提供参数给 fixture 有点反过来了。

如果实在需要这么做，我能想到的方式就是把返回值放到一个自定义的全局变量，fixture 从全局变量里读取。

从 docker 部署截图看，8899 端口原来是 authority-ui 服务监听的，然后 docker 通过端口映射，改为了由 nginx 来监听这个端口，authority-ui 则改为了 80 端口。

你在 nginx 内部有配置好转发规则，让收到的 8899 端口请求，转回给 authority-ui 服务么？

另外，这个部署方式很奇怪，你想让用户通过 8899 端口访问，还是通过 80 访问呢？一般部署应该是 80（http）、443（https）给 nginx ，nginx 再按内部规则把请求转给内部前端或后端服务的。你现在把 80 给了内部的前端服务，nginx 反而监听一个 8899 的自定义端口，有点奇怪。

里面好多问题都不完整，比如 35、请说出这些测试最好由那些人员完成，测试的是什么？ 。

建议发出来之前，多校对下？

不知道。瞎猜和 jmeter 版本有关？

不熟悉 python 的覆盖率方案，帮顶一下。

这种就有点涉及办公室政治了。
1、团队的 leader，日常需要和业务方打好关系，多吃吃饭啥的，普及一下这方面一些基本知识（至少测试环境和线上环境分开下）。至少有问题先反馈给技术去处理，小问题内部解决掉，别啥问题直接怼给最大的领导。
2、如果真闹大，闹到领导那，也叫上你自己的领导过去，和产品那边把问题怼到领导那边的至少同级的，杠到底。角色不对等的话，会天然弱势
3、看清下在这个公司的业务形态下，技术到底是辅助角色还是核心角色。如果技术本身就是辅助角色的话，要获得话语权非常难，而你又比较在意这个的话，建议考虑换个公司，避免老是气到自己。

可以考虑搞个类似 wda 的程序，通过 http 和程序通讯，让程序获取？

ios 不越狱是进入不了系统控制台的，所以能获得的东西也比较有限。你说的这些，通过系统提供给应用调用的 api 反而容易获取。

这个复盘总结很棒，32 个赞！稍微修正一个信息：恒温不是产品角色，他也是开发之一，他对网站代码熟悉度比我高。

其实这个问题，解决效率没那么高的核心点，还是关键细节没有提供齐全，导致无法复现。坦白说确实很难留意到，在 chrome 浏览器 www 是会自动隐藏的，不复制网址都不知道自己用了 www 域名，我自己都没留意到这个点。然后 www 域名是前几个月做域名备案时，监管要求必须有才加的，以前确实都没有提供，也没有人想到会引发问题，还好有同学提供了 url 这个关键信息，这才破了案。

也想借此也提醒一下各位测试同学：

提供足够细节让其他同学得以重现问题，是让问题得到解决非常非常非常（重要的事情重复 3 遍）重要的一环。不管是提缺陷，还是提技术问题，都是一样的。所以，请大家后续建提问帖，或者缺陷单的时候，尽可能把你所知道的能让问题重现的信息都提供一下，便于其他同学重现问题，进而了解到更多的问题细节，给出解决的建议。