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

你需要测试一切。无论您在原始环境中测试了什么,都需要在新环境中测试。

最终,您将获得信心,相信您的大多数测试在新环境中永远不会失败。只要新旧环境都是基于Unix的系统,肯定会有一组测试总是成功的。没关系-这是一组你不需要经常运行的测试。不过,为了安全起见,我还是会让这些测试在新操作系统或产品的每个版本中运行一次。

检查它在32位和64位CPU上是否工作,文件名中是否有空格,用户不需要管理权限即可运行它或更改配置

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

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

我最近的一些经验是 JMeter ,它有许多断言、前置条件和后置条件,可以对这些条件进行评估以确保遵从性。如果合适的话,这个空间中的许多工具也允许您进行负载测试。

如果您的系统没有可远程访问的接口(如基于web或基于socket的接口),则可以使用脚本工具执行相同的操作。

13或14年前,我无法将Informix数据库从SCO OpenServer移动到Linux,因为SCO使用16位inode编号,Linux使用32位inode编号,而Linux的“个性”远不及今天。我很欣赏你的怀疑态度。

如果你能用保存的数据和保存的结果重新运行旧的实验,那将是我首选的开始。给定简单的数据类型,在不同的编译器/平台上,操作的精度或范围可能大不相同,所以如果 小的 输出上的差异是常见的,因此精确匹配可能不现实,但肯定的是,结果应该足够接近,不会影响测试运行的更大“结果”。

与其搜索测试用例,不如将其用于已经使用过的测试用例。(顺便提一下,这也是为软件开发构建测试用例的好方法。)

标准数学库函数之间精度的差异。它们在不同的系统上是不一样的。如果需要一致的计算,则需要替换它们。调查crlibm和/或fdlibm。