问我应该在AMD和Intel芯片上运行我的回归测试程序吗？

EN

我的感觉是，只有当你有很多前沿的手工编写的汇编语言或某种令人难以置信的紧凑的时间安排时，这才是值得的(无论如何，你不会在选择的操作系统上遇到这些)。

如果您使用的是现成的商业编译器，那么您可以合理地确定它们将生成在所有普通处理器上运行的代码。

当然，没有人能证明他们不需要在特定的平台上测试，但我认为有比CPU品牌更大的平台差异原因需要担心(例如，所有各种多核/超线程排列，它们可能以不同的方式暴露所有多线程代码错误)。

只有当你用汇编语言编程并使用扩展的、供应商专用的指令集时。但由于AMD和英特尔已经达成了交叉许可协议，这更多的是一个历史性的问题，而不是一个当前的问题。

在其他情况下(例如，使用高级语言)，编译器编写者的工作是确保代码是x86兼容的，并在每个CPU上运行。

哦，除了FDIV Bug处理器供应商通常不会犯错误。

我认为你在测试场景中看错了方向。

是的，您的代码可能会在英特尔上运行，但不能在AMD上运行，或者在Windows Vista Home上运行，但在Windows Vista Professional上不能运行。但是，除非您在第一种情况下与低级编程紧密相关，或者在第二种情况下与操作系统实现的细节密切相关，否则这种可能性很小。你可以说，测试每一个可能的场景都不会有什么坏处。但在现实生活中，您可用于测试的资源肯定有一定的限制。在不同的处理器或不同的操作系统上测试，在大多数情况下，不是测试你的程序，而是测试编译器、操作系统或处理器。你有多少时间来测试别人的工作？我认为你的时间最好用在你自己的代码中测试更多的场景。你没有详细说明你的应用程序做了什么，但就拿我自己的一个例子来说，花一天的时间测试我们自己公司生产的产品与我们从其他制造商转售的产品，或者测试不同州的销售税规则，或者其他任何东西，会更有效率。

在实践中，我甚至很少在Windows上测试部署与在Linux上部署，更不用说不同版本的Windows了，我很少因为此而感到焦头烂额。

如果我写的是低级设备驱动程序或类似的东西，那就是另一回事了。但是普通的应用程序呢？不要浪费你的时间。