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

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

还有那种 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 因为前面的回复内容比较抬杠，且字眼里有涉及机关单位，比较敏感，所以均审核不通过。

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

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

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

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

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

要用好代码覆盖率，前提是对代码的变更内容以及被测系统有比较高的熟悉度，最好是结合 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 版本有关？