现在我计划在 32 位、64 位、Windows XP Home、Windows XP Pro、Windows Vista Home Basic、Windows Vista Ultimate、Windows 7 Home Basic 和 Windows 7 Ultimate 上进行测试……所有这些都使用最新的服务包.
但是,现在我想知道对于上面列出的所有场景是否值得同时在 AMD 和 Intel 上进行测试,还是会浪费时间?
注意:这是一款适用于日常普通用户的安全应用程序。
现在我计划在 32 位、64 位、Windows XP Home、Windows XP Pro、Windows Vista Home Basic、Windows Vista Ultimate、Windows 7 Home Basic 和 Windows 7 Ultimate 上进行测试……所有这些都使用最新的服务包.
但是,现在我想知道对于上面列出的所有场景是否值得同时在 AMD 和 Intel 上进行测试,还是会浪费时间?
注意:这是一款适用于日常普通用户的安全应用程序。
我的感觉是,只有在您拥有大量先进的手工编码汇编语言或某种令人难以置信的紧迫时间(无论如何您都不会遇到那种选择的操作系统)时,这才是值得的。
如果您使用的是现成的商业编译器,那么您可以合理地确定它们将生成在所有普通处理器上运行的代码。
当然,没有人能证明他们不需要在特定平台上进行测试,但我认为平台差异的原因比 CPU 品牌更令人担忧(例如,所有各种多核/超线程排列,这可能会以不同的方式暴露你所有的多线程代码错误)
仅当您使用汇编语言进行编程并使用扩展的、供应商特定的指令集时。但由于 AMD 和英特尔签订了交叉许可协议,这与其说是当前的问题,不如说是一个历史问题。
在所有其他情况下(例如使用高级语言),编译器编写者的工作是确保代码符合 x86 并在每个 CPU 上运行。
哦,除了FDIV 错误处理器供应商通常不会犯错误。
我认为您正在寻找测试场景的错误方向。
是的,您的代码可能在 Intel 上运行但在 AMD 上运行不正常,或者在 Windows Vista Home 中运行但在 Windows Vista Professional 中运行不正常。但是,除非您在第一种情况下所做的事情与低级编程密切相关,或者在第二种情况下与操作系统实现的细节密切相关,否则可能性很小。你可以说测试每一个可以想象的场景永远不会有坏处。但在现实生活中,您可用于测试的资源必须有一些限制。在大多数情况下,在不同的处理器或不同的操作系统上进行测试并不是在测试您的程序,而是在测试编译器、操作系统或处理器。你有多少时间来测试别人的工作?我认为您最好花时间在自己的代码中测试更多场景。您没有详细说明您的应用程序的功能,
在实践中,我什至很少测试在 Windows 上部署与在 Linux 上部署,更不用说不同版本的 Windows,而且我很少对此感到厌烦。
如果我正在编写低级设备驱动程序或类似的东西,那将是另一回事。但是普通的应用程序?不要浪费你的时间。
我永远不会在 AMD 和 Intel 上运行我的所有回归测试,除非我专门解决了其中任何一个独有的问题。这就是回归测试。
另一方面,单元测试......我预计不会有任何区别。再说一次,在我真正看到 AMD 或 Intel 的特定问题之前,我不会费心在两者上运行单元测试。
当然,这听起来对我来说是浪费时间——你的程序是用哪种语言编写的?
我会说不。除非您使用汇编程序编写应用程序,否则您应该远离处理器,不必担心差异。处理器将支持您正在与之交互的 API 的 Windows 操作系统(取决于语言)。如果您使用的是 .NET,那么您将遇到的唯一可预见的问题是您使用的是那些平台不支持的框架版本。鉴于它们都是 XP 或更高版本,你应该没问题。如果您想担心某些事情,请确保您的应用程序可以很好地与 Vista 和更高版本的安全模型配合使用。
问题可能是“你在测试什么”。任何测试都不太可能测试 AMD 和 Intel 硬件平台之间可能存在差异的东西。在驱动程序级别可能会出现差异,但您似乎并未针对周围可用的每一个现有 PC 硬件位来平面测试您的软件。最有可能的是,不同级别的 Windows Service Pack 之间的差异要比 AMD 和 Intel 处理器之间的差异大得多。
我想您的代码中可能有一些功能(无论您是否知道)利用其中一个或另一个可能对结果产生严重影响的某些处理/优化。关键字可能。
我会说一般来说你不太可能担心它。如果您无论如何要在多台机器上进行操作,请在它们上混合使用。但我不会为此感到压力。
如果您依赖准确/一致的浮点结果,那么肯定是的。