@LinearUncle: 上周在与另一家公司沟通时,我给他们的测试团队提了一个小建议:测试必须包括…
摘要
作者建议缺陷测试应包括屏幕录制,使用AI通过ffmpeg提取片段并分析帧,显著提高缺陷修复成功率。
上周在与另一家公司沟通时,我给他们的测试团队提了一个小建议:测试必须包括屏幕录制。提交缺陷时,附加录制、问题发生的时间区间,以及传统的最小化文本和截图(实际上可以省略截图)。然后AI可以使用ffmpeg提取片段、从图像中分析帧,并显著提高缺陷修复成功率。
相似文章
@RayFernando1337: 导致用户流失的错误几乎从不出现在差异对比中,只有当你停止审查代码时才能真正捕捉到它们……
一位开发者分享了在Cursor中使用Opus 4.8 Max Thinking模型与子代理框架的工作流,并介绍了一个包含可安装技能文件的GitHub仓库,其中包含一个名为'running-bug-review-board'的技能,可进行实时QA测试。
@gabriel1: 每个 PR 显然都会附带 100% 覆盖率的 AI 应用测试,测试界面中的每个按钮以确保其正常工作……
一条推文认为,AI 应用测试应成为编码应用的一流功能,并指出如果让 AI 自行尝试应用,许多明显问题都可以被发现。
@svpino: 与其手动查看AI生成的代码,不如花时间制定一个计划来验证系统是否按预期运行…
这篇文章提倡使用Replay QA对Web应用程序进行自动化测试,特别是针对AI生成的代码,强调了其易用性以及持续质量保证和根本原因分析等特性。
@copyconstruct: 端到端测试 > 单元测试,在 vibecoding 时代。一个几乎完全由 AI 代理编写的大规模重构通过了所有单元…
一位开发者认为,在 AI 编码代理时代,端到端测试比单元测试更重要。一个由代理编写的重构通过了所有单元测试,但却破坏了一个关键功能,这个缺陷只在手动端到端检查中被发现。
我的AI应用中最糟糕的错误不是崩溃。而是那些已经构建、连接、测试、在CI中通过,但在生产环境中从未真正起作用的功能。我已经发现了20多个。你们是怎么抓到这些的?
作者描述了在AI应用中令人沮丧的错误,这些错误虽已构建和测试,但在生产环境中未能有效执行,例如功能针对错误用户或因环境条件未能触发,并询问捕捉这些问题的方法。