gpt 回答：

1. 技术学习曲线和培训成本

• 需要学习新技术：如果软件测试团队本身并未接触过 AI 技术，引入 AI 相关的工作将要求团队成员花费大量时间学习 AI 的基础知识、工具和模型。这可能会占用大量时间和精力，尤其是在没有相关背景的情况下，学习过程的效率较低。
• 培训和知识积累的成本：为了有效实施 AI 测试，可能需要组织外部培训、购买相关书籍或课程，甚至聘请专门的 AI 专家协助团队。这些都将增加额外的时间和成本，且如果团队没有深入的技术理解，培训效果可能有限。

2. 工作负担加重

• 多重任务负担：在软件测试团队已经有很多其他业务测试任务的情况下，引入 AI 技术意味着需要在现有工作负担基础上分配更多时间和精力。由于测试工作的复杂性和多样性，测试团队很可能会感到压力增大，导致效率下降，甚至影响现有的业务测试质量。
• AI 任务和其他测试任务的冲突：AI 技术的探索和实现本身是一项持续性工作，需要进行持续的调研、实验和反馈优化，这可能与正常的项目进度冲突。团队成员可能被迫在正常的测试任务和 AI 任务之间进行取舍，从而影响两者的工作进度。

3. 难以衡量和定位 AI 的实际价值

• 无法立即看到成果：AI 驱动的测试工具和流程通常需要经过一段时间的训练和优化才能见效，而且可能需要大量的实验和反馈，才能找到有效的测试策略。这使得团队很难在短期内看到 AI 带来的显著回报，可能会觉得投入的时间和精力并没有得到及时的回报。
• 初期效果可能有限：AI 在初期阶段可能无法发挥预期的效果，尤其是缺乏足够的数据、模型调优和团队技术熟练度的情况下。因此，测试人员可能会感到 AI 项目并没有显著改善工作负担，反而增加了不必要的工作量。

4. AI 与业务测试之间的矛盾

• 缺乏足够的 AI 专业知识：软件测试团队本身如果缺乏 AI 相关的专业知识，可能会陷入 “用 AI 解决问题” 的盲目状态，而忽视了 AI 实际应用中可能出现的困难和局限。这可能导致团队过早地投入时间和资源，而没有合理评估其可行性和实际价值。
• AI 工作与现有业务测试冲突：AI 在测试中的应用通常要求团队进行较多的试验、模型训练、调整等工作，这些都需要时间，而现有的业务测试工作（如功能测试、回归测试等）也不能停顿。两者的时间需求和优先级可能产生冲突，导致团队无法兼顾，工作压力增大。

5. 缺乏清晰的目标和规划

• 没有明确的目标和需求：如果没有清晰的目标和规划，AI 相关的工作可能会变得 “无目的地探索”。很多测试人员可能会投入到 AI 学习和探索中，但没有明确知道最终目标是什么，或者 AI 能为测试流程带来哪些实际好处。这可能导致工作没有效果，甚至浪费大量的时间和精力。
• 短期与长期目标的冲突：AI 技术的引入是一个长期投入的过程，而软件测试团队可能更关注短期内的任务完成。如果 AI 项目的时间投入过长，团队可能会感到不平衡，影响正常的测试任务进度。

6. AI 项目的技术复杂性

• 工具和框架的选择困难：AI 在软件测试中的应用依赖于多种工具和框架，而这些工具和框架的选择需要技术背景和经验。如果没有 AI 专业背景，测试团队可能很难选择合适的工具，导致技术堆栈的混乱和效率低下。
• 模型和数据的需求：AI 测试模型的准确性依赖于高质量的数据，并且需要持续优化。团队可能会面临数据收集、标注、清洗和处理的难题，尤其是在缺乏数据科学背景的情况下，数据问题可能成为阻碍 AI 项目成功的瓶颈。

总结：

从实际角度来看，引入 AI 进行软件测试的确可能导致工作量的增加，尤其是当团队本身没有 AI 技术背景，且需要同时承担其他业务测试时，工作负担可能变得更重。AI 项目的学习曲线和技术门槛、培训成本、与现有测试任务的冲突，都会使得团队的压力增大。此外，缺乏明确的目标、数据支持和技术经验，也可能导致 AI 项目的效果不如预期，甚至浪费时间。

然而，AI 在软件测试中的潜力仍然巨大，但要避免变成 “无用功”，最好的方法是：

• 逐步引入：在团队中逐步引入 AI 测试工具，而不是一次性大规模投入，可以先从小规模、低复杂度的试点项目开始。
• 明确目标：设定清晰的目标，明确 AI 在测试中应解决的问题，而不是盲目追求技术。
• 跨部门协作：如果团队内部缺乏 AI 技术，可以考虑与数据科学团队或外部专家合作，弥补技术上的不足。
• 合理分配资源：避免让 AI 探索占用过多的测试资源，确保在没有 AI 技术背景的情况下，不会影响现有的业务测试任务。

在没有足够的 AI 技术积累的情况下，完全依赖 AI 进行软件测试可能并不现实，因此将其作为一种长期、逐步引入的优化手段，配合现有的测试流程，可能是更为可行的方式。

其实我都觉得几奇怪，明明之前的 UI 自动化都几成熟，虽然麻烦且作用不大，但系 UI 自动化本来就没期待能发现多少 bug，现在想引入 AI 是想解决什么问题呢？

公司不是要玩 AI，是想玩你们

对，感觉互联网人都应该以他为戒。。。。。那时候说没就没了

及时做手术才没事，否则还是挺麻烦的。关键是切除了甲状腺后，得吃一辈子激素药，大半年不能出力，很多海鲜也要忌口，还是挺不好的

好吧 只能羡慕了，我也在找副业

结节有两方面的原因，
一方面是生活压力大、生活不规律、情绪不稳定
另一方面是医疗仪器精度提高，能查出以前扫描不出的结节
注意甲状腺结节是否良性

你该不会之前在飞书团队吧

人只有大病一次，才会懂得健康是首位，其他都是浮云

可以感觉得出，你是属于那种好相处的同事

看多了些悲观焦虑文，再来看我是不是就可以缓冲一下

社区有我这种乐子人是幸事

就像所有打篮球的少年，都会在某一天穿上背带裤

我吃拼好饭咋办

发现领导跟同事有一腿算不算刺激 bug

那估计会比较困难，我不是唱衰你，你年龄应该 32+ 了吧，你没有大厂背景，像游戏行业这种我个人感觉是挺难的，除非你能找人内推，否则面试官普遍比你小的情况下，还真挺难维持你原来的薪资

虽说测试现在内卷很严重，招聘的要求也挺高，
但神奇的就是依然存在 bug 单都不能写清楚的人

1. 问题表述不够清晰：

   • 描述不完整：只说 Postman 可以访问，JMeter 不可以，但没有提供具体的报错信息或失败现象（如 HTTP 状态码、超时、网络错误等）
   • 缺少上下文：例如请求类型（GET/POST）、请求参数、Header 配置、是否 HTTPS、是否需要 Cookie 等信息。

2. 缺乏基本排查步骤：

   • Header 对比：确认 JMeter 和 Postman 的请求头完全一致
   • 请求内容对比：如 Body 数据、Query 参数
   • 日志检查：查看 JMeter 的请求日志，确定具体失败原因
   • SSL/HTTPS 问题：确认 JMeter 是否正确处理证书

3. 忽略工具的差异性，Postman 和 JMeter 它们对请求的处理方式不同：

   • Postman：会自动管理 Cookies、Header、重定向等。
   • JMeter：需要手动配置这些内容，否则可能导致请求失败

4. 没有思考提问的受众和背景

   • 问题的表述太随意，难以引导别人提供有价值的回答。
   • 没有展示自己已经尝试过的排查过程或思路。

• 提问时遵循以下格式：

  • 问题背景：xxxxxxxxxxxx
  • 当前配置：请求方法、URL、Header、Body、Cookie 等。
  • 遇到的问题：如返回的 HTTP 状态码或错误日志。
  • 尝试的排查步骤：1234

当然你排查完后估计都不用写提问贴了，这种工具使用小问题其实应该不难。。。。。。
问问题一定要描述清楚，毕竟可能性很多，就比如可能是防火墙配置问题，导致一个软件的请求被拦截，你啥都没描述，谁能推断出来？？？

其实这两个做起来，就是往产品路线走的测试

言外之意： 我们其实不缺人，面试只是一个任务流程
你也没有那种让我们眼前一亮的特质（学历/经历/技术/性格/背景/颜值/年龄），你有的我们组内的人都有
后面还有几个人面试，我们继续看看

所以你不用纠结什么才算对业务思考深刻，这个没有确定定义，面试你的人只是找了一个你能接受的结果，毕竟你一面过了证明技术能力还行

知足吧你，出来后我估计你连 15K 都难

总结： 鸡肋

你先抓包看下请求发出去没，如果请求都没到服务器，你怎么定位都没用

所以我一直觉得以前的测试走技术路线是错误的进化路线，
测试面向的应该是业务质量和业务本身，
至于测试需要用的工具/平台/自动化/性能等应该引导和督促开发去完成，而不是去混淆自己的定位，
往产品的方向走，逐步替代产品的职能，让自己在业务上也能收获到更重要的地位，
只可惜以前的测试只想走技术流，搞得现在测试不伦不类，职能上太容易被开发取代了。

培训班死了很多了，现在都是部分互联网中年人自己搞的线上培训和知识星球，主要通过贩卖焦虑的模式运营