我想强调文章的另一部分：> 一般来说，当我和软件人员谈论测试时，我所处的立场和他们完全不同，他们立刻觉得我像个外星人，所以让我们谈谈我们在这家硬件公司Centaur是如何进行测试的，这影响了我偏好的工作方式。我们所做的某些事情在软件界是或曾经是非传统的，包括：> 雇佣专门的QA/测试工程师，测试被作为与开发人员同等重要的职业路径 - 默认情况下没有代码审查 - 几乎没有手动编写的测试 - 通过程序员有时称为基于属性的测试、随机测试、模糊测试等进行持续测试，尽管我们只是称其为测试（手动编写的测试被称为“手动测试”）。 - 大型回归测试套件（在计算农场上需要3个月的时钟时间来执行） - 没有单元测试 有人尝试过这种（或类似）方法吗？尤其是全面投入基于属性的测试和模糊测试，而没有单元测试。…
源讨论加拉帕戈斯岛的代理编程笔记原帖 83 条评论 · 导入时统计把你的经验，加入这段讨论。
我一开始想知道的是“这是否是CPUID（EAX=0）中显示为‘CentaurHauls’的同一种Centaur？”
完整原文我真的很好奇“随机测试”在实践中是什么样子的。成功的衡量标准是什么？ 我明白对于模糊测试，你有一个非常基本的“不会崩溃”的指标。属性测试……你必须为属性测试编写属性。随机测试在测试什么？
完整原文我现在把MCP工具集成到所有东西中，包括截图。任何LLM都可以运行几乎所有功能，包括调整窗口大小。我刚刚看到Fabel 5对一个新项目进行了完整的可用性测试，复制了我代理终端的发布周期，当它进行测试时重新启动了应用程序大约20次，确保迁移到构建和签名的发布版本是有效的。它安装了程序大约5次（这是我每天多次做的事情）。 我注意到地图瓦片没有工作，开始告诉它，但突然之间它们又出现了，检查日志后发现它已经找到了问题并自动纠正了自己。 这里的关键是反馈循环和系统退火。 至于Dan，我的天，我真的很喜欢这个家伙。很高兴有人发布了！
完整原文默认情况下没有代码审查违背了实际已建立的证据（软件开发实践中很少有这方面的证据）表明代码审查是发现缺陷的最佳方式。 我从使用硬件和其他类似例子中总是觉得，硬件公司很少擅长软件开发，因为他们的核心竞争力是硬件。公平地说，软件公司也很少擅长软件开发。 每种形式的测试在做得好的时候都有其价值，他们使用了几种大多数软件开发人员不会使用的测试形式——这可能弥补了缺乏代码审查和单元测试的不足。但如果他们结合了代码审查和单元测试，他们的软件质量可能会更高。 属性测试非常棒，但它无法提供全面的覆盖。 回归测试套件非常棒，但通常最昂贵的…
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。