在为另一个操作系统重新编译软件时要测试什么？

Question

我们的软件供应商目前正致力于将我们的企业级实验室系统从Tru64 unix迁移到Red Hat。 这显然意味着使用新的编译器重新编译并执行大量测试。

虽然供应商会进行自己的测试，但我们还需要进行验收测试。 我们并不完全相信供应商会像我们希望的那样彻底进行测试。 所以我的任务是考虑需要测试的事情。 这是一个实验室系统，因此需要测试计算和舍入（以及一般数学）等事项。

但是我想我会问SO社区有关测试什么或者过去经历这类事情的建议？

Answer 1

你需要测试一切。无论您在原始环境中测试过什么，都需要在新环境中进行测试。

最终，您将获得大多数测试在新环境中永远不会失败的信心。只要旧的和新的环境是基于Unix的系统，肯定会有一组测试永远成功。那很好 - 这是一组你不需要经常运行的测试。为了安全起见，每次发布新操作系统或每个版本的产品时，我仍会保留这些测试，但为了安全起见。

Answer 2

检查它是否适用于32位和64位CPU，文件名中的空格，用户不需要管理员权限来运行它或更改配置

一个unix到另一个并不是一个巨大的飞跃。

Answer 3

如果您可以提出一套回归测试，则可以通过自动化工具对原始系统和移植系统使用这些方案，以确保它们匹配。您当前针对系统运行的QA和UAT测试可能是一个很好的起点，然后您可以根据需要添加任何关键边缘情况（例如那些详细测试数学的情况）。 Paul上面关于编译器问题的建议也可以推导出一些优秀的边缘案例;我建议从Tru64和RHEL编译器的角度来看这个范围。

我最近的经验是JMeter，其中包含许多断言，前置条件和后置条件，可以对其进行评估以确保合规性。如果合适，此空间中的许多工具还允许您进行负载测试。

如果您的系统没有可远程访问的界面（如基于Web或基于套接字的界面），您可以使用脚本化工具执行相同的操作。

Answer 4

十三年或十四年前，我无法将Informix数据库从SCO OpenServer迁移到Linux，因为SCO使用了16位的inode编号，Linux使用了32位的inode编号，Linux的“个性”远没有像它是今天。我很感激你的怀疑。

如果您可以使用保存的数据重新运行旧实验并保存结果，那么这将是我首选的起点。给定简单的数据类型，在不同的编译器/平台上，操作的精度或范围可能会大不相同，因此如果输出中的小差异很常见，我不会感到惊讶，因此完全匹配可能不太现实，但肯定的结果应该足够接近，不会影响测试运行的较大“结果”。

不是搜索测试用例，而是将其用于已经完成的测试用例。 （顺便说一句，这也是构建软件开发测试用例的好方法。）

Answer 5

标准数学库函数之间的精度差异。它们在不同系统上并不相同。如果需要一致的计算，则需要更换它们。查看crlibm和/或fdlibm。