CICD 自动构建不就好了吗？为什么还要手动部署？

同意啊， 已经很明显出现了奔溃的现象， 还在想着没必要加入回归测试，我没办法理解。
所谓回归测试，就是即使没有任何改动，也要去回归一遍， 保证功能正常。 因为就算没有代码的改动，也不能保证所有的依赖（服务器，操作系统，浏览器等等）可能的变化对功能的影响。

这其实是你们的策略制定的出发点是什么， 如果说纯粹从技术角度来看， 没问题；
但是从质量管理的角度来看， 已经有客户会在实际使用的时候遇到这种奔溃的问题，而且从你的描述来看，不是随机的小概率事件，而是某些功能你们选择性地不去回归，没有发现问题。

如果是新功能影响到的老功能，说明你们的回归测试策略不完整。
有没有必要都放到回归测试里面，是基于风险去评估的， 很明显你们现在的情况就是需要加上。

1. 如果奔溃是功能性产生的，可以考虑跑个 monkey 测试之类的， 多覆盖一些随机的操作
2. 如果奔溃是跟设备兼容性相关的， 检查一下兼容性的测试策略， 还有找云测平台跑一下不同的设备。
3. 做好奔溃日志收集，定期检查分析，找出可能存在的问题。

每个行业都有历史发展的过程啊， IBM 小型机在某个时间就是处理这种业务的最好选择，很多银行系统都是沿用到现在。

你把读出来的每个 row 打印出来就知道了 ， 自己调试一下吧。
先把这个 get data 的方法给调通。

你需要的是列表，但是直接从 CSV 文件里面读取出来的就是一行字符串啊， 所以你要通过逗号去 split 成列表。

你每一行数据读取出来好像还是作为一个字符串来处理的， 应该要按逗号做一下分割，匹配到三个字段里面？

你想想几个场景：

1. 你在玩对一款游戏，每个月会停服 8 小时更新一次。你希望是在白天停服， 让你玩不了，还是希望它在半夜停服，反正对你没影响？
2. 你是一家超市的老板，每个月要停电 8 小时做一次线路检查。 你希望是一个白天关门不做生意， 还是让一些员工在晚上加班去完成检查， 不影响白天营业？

所以发版这个事情从来都是以尽量不影响用户，或者对用户影响尽量小的原则去规划的啊， 员工要定期晚上加班去支持发版， 只是这份工作的其中一个特殊性。 人家医院的医生护士还得三班倒值夜班呢。

PS 白天发版还是晚上发版，跟是不是自研没关系， 只是看你的用户量和访问量。 除非你们老板够牛，我就不喜欢加班，用户用不了就用不了咯。

我觉得这里的 7 个人并发不等于 7 个用户同时在线， 实际上每个用户不会每秒都在发请求。 最好是看下具体的 TPS 相关的数据来参考。
另外，不是很理解为什么有个更快的 UAT 环境会被废弃呢？ 我会倾向于开发环境是给开发自测的， 测试就得在 UAT（ 我们的测试也更靠近 UAT 这个阶段）

都怪明明

搞一个 mock server， 直接从接口上面 mock 吧
方法一： 让 app 开发把真正的接口改成 mock server 的接口
方法二： 让 API 开发做个开关，不 call 上游， 改为 call mock server

高中的时候校门口有家小吃店，发现老板很酷，每晚都带着一个耳机，以为他在听电台还是听音乐。
后来才知道，那是助听器。

docker 和 selenium 的结合就是可以快速拉取不同的 browser image，来作为测试执行的载体。
API 测试其实大部分只是执行代码而已，不需要浏览器这种依赖，所以也就没必要用到 docker 了

感觉某些智能助手应该可以帮忙？ 让奶奶语音控制？

TestFlight 支持运行 iOS 14 或更高版本的 iPhone、iPad 或 iPod touch 设备来测试 iOS 或 iPadOS 应用。如果是测试 App Clips（轻应用），同样需要 iOS 14 或 iPadOS 14 或更高版本。

此外，若要测试 iMessage 信息 App 和贴纸包，则需要安装 iOS 10 或更高版本。

如果是在较老版本的 iOS 设备上，可能无法安装最新版的 TestFlight，即便安装了旧版 TestFlight，也可能无法与最新的测试应用或开发者的设置兼容。

从官方文档上来看，iOS 14 还是最低的 support 版本，所以不应该 crash 的。 感觉是 app 已经升级了，不再支持 14， 但是 官方文档还没更新。
但是呢，我理解你用 test flight 是在上线前测试你们的应用，应该用用户数量最大的 iOS 系统才最保险（比如现在最大用户数是 iOS18）。 不然要是 iOS18 上面其实跑不了，你拿一个几乎没有用户在用的 iOS14 去测试，意义真的不大了。

试一下 selenium grid 吧

怎么定义完美呢？ 一个完美 design、没有任何（能被人找到）缺陷的软件（但是没人用得起）的软件？

一套代码，然后用不同的标签标记适配哪个 app

根据需求，设计整理测试用例， 只要三方评审觉得完整就是全的。
PS 没有绝对意义上的百分百覆盖，只有基于需求和修改范围和风险评估来整理合理的覆盖范围。

基于现有工具做的就是太 low？ 自动化又不是多么高深的东西，就是一个用来替代部分手工测试（不是替代所有），提升效率的工具而已，能快速用起来就是好的选择。
如果楼主单纯是想多写代码，要么在当前团队把手上的活干好之余，多挖掘一些潜在的需求，写些小工具什么的给团队提效； 要么换个能满足你手撸自动化代码的团队； 再不是就直接转开发吧。
其实现在的代码助手的智能程度，已经能替代很多了： 快速帮你生成测试代码，快速帮你实现某些需求。

20 年看到，然后你用了八年…

算平均意义不大啊，除非你们的流量是一群定时发送的机器。
可以评估一下峰值流量

5K 和 1K 之间也是差 3/4 K