为另一个操作系统重新编译软件时需要测试哪些内容？
我们的软件供应商目前正在开展一个项目，将我们的企业级实验室系统从 Tru64 unix 迁移到 Red Hat。 这显然意味着使用新的编译器重新编译并执行大量测试。
虽然供应商会自己进行测试，但我们也需要进行验收测试。 我们并不完全相信供应商的测试会像我们希望的那样彻底。 因此，我的任务是考虑需要测试的事情。 这是一个实验室系统，因此需要测试计算和舍入（以及一般数学）等内容。
但我想我应该向 SO 社区寻求关于测试什么的建议，或者也许是过去此类事情的经验？
Our software vendor is currently working on a project to migrate our enterprise scale laboratory system from Tru64 unix to Red Hat.
This obviously means recompiling with a new compiler and perform lots of testing.
While the vendor will do their own testing, we also need to do acceptance testing.
We don't exactly trust the vendor will be as thorough with their testing as we hope.
So I have been tasked to think of things that will need to be tested.
This is a laboratory system, so things such as calculations and rounding (and general maths) need to be tested.
But I thought I would ask the SO community for advice on what to test or perhaps past experiences with this sort of thing?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
你需要测试一切。无论您在原始环境中测试什么，都需要在新环境中进行测试。
最终，您将确信大多数测试在新环境中永远不会失败。只要新旧环境都是基于Unix的系统，肯定会有一组测试永远成功。没关系 - 这是一组您不需要不断运行的测试。不过，为了安全起见，我仍然会保留这些测试，以便在每个新操作系统版本或每个产品版本中运行一次。
You will need to test everything. Whatever you tested in your original environment, you will need to test in your new environment.
Eventually, you'll gain confidence that most of your tests will simply never fail in the new environment. There will surely be a set of tests that will always succeed, as long as the old and new environments are Unix-based systems. That's fine - that's a set of tests you won't need to run constantly. I'd still keep those tests around to run once per release of the new OS or per release of your product, however, just to be safe.
检查它是否适用于 32 位和 64 位 CPU、文件名中的空格、用户不需要管理员权限来运行它或更改配置
一个 Unix 到另一个 Unix 并不是一个巨大的飞跃。
Check it works on 32 and 64 bit CPUs, spaces in filenames, users don't need admin rights to run it or change configs
One unix to another isn't a huge leap.
如果您可以提出一套回归测试，您可以通过自动化工具针对原始系统和移植系统使用这些场景，以确保它们匹配。您当前针对系统运行的 QA 和 UAT 测试可能是一个很好的起点，然后您可以根据需要添加任何关键的边缘情况（例如详细测试数学的情况）。 Paul 上面关于编译器问题的建议也将允许推导一些好的边缘情况；我建议从 Tru64 和 RHEL 编译器的角度来查看该范围。
我最近的大部分经验都是使用 JMeter，它有许多断言、先决条件，以及可以评估以确保合规性的后置条件。如果合适的话，这个领域的许多工具还允许您进行负载测试。
如果您的系统没有远程访问接口（例如基于 Web 或基于套接字的接口），您可以使用脚本工具执行相同的操作。
If you can come up with a suite of regression tests, you can use those scenarios via an automated tool against the original and ported systems to make sure they match. The QA and UAT tests that you currently run against the system would probably be a good starting point, and then you could add any critical edge cases (such as those that test the math in detail) as needed. Paul's suggestion above about compiler issues would also allow derivation of some good edge cases; I'd recommend looking at that scope from the perspective of both the Tru64 and RHEL compilers.
A fair amount of my recent experience is with JMeter, which has a number of assertions, pre-conditions, and post-conditions that can be evaluated to ensure compliance. A number of the tools in this space would also allow you to do load testing, if appropriate.
If your system doesn't have a remotely accessible interface (like a web-based or socket-based interface), you could potentially do the same thing with scripted tools.
十三、十四年前，我无法将 Informix 数据库从 SCO OpenServer 迁移到 Linux，因为 SCO 使用 16 位 inode 号，Linux 使用 32 位 inode 号，而且 Linux 的“个性”远没有今天那么先进。我很欣赏你的怀疑。
如果您可以使用保存的数据和保存的结果重新运行旧的实验，那将是我首选的起点。给定简单的数据类型，不同编译器/平台上的精度或操作范围可能会有很大不同，因此如果输出中存在微小差异，我不会感到惊讶，因此精确匹配可能不现实，但当然结果应该足够接近，不会影响测试运行的更大“结果”。
与其搜索测试用例，不如将其用于您已经完成的工作。 （顺便说一句，这也是构建软件开发测试用例的好方法。）
Thirteen or fourteen years ago, I couldn't move an Informix database from SCO OpenServer to Linux because SCO used 16-bit inode numbers, Linux used 32-bit inode numbers, and Linux's 'personalities' was nowhere near as advanced as it is today. I can appreciate your skepticism.
If you can re-run old experiments with saved data and saved outcomes, that would be my preferred place to start. Given simple datatypes, the precision or range of operations may be vastly different on different compilers/platforms, so I wouldn't be surprised if small differences in output are common, so exact matches may not be realistic, but certainly results should be close enough to not influence the larger 'outcomes' of your testing runs.
Rather than searching for test cases, use it for what you've already done with it. (As an aside, that's also a good way to build test cases for software development.)
标准数学库函数之间的精度差异。它们在不同的系统上是不一样的。如果您需要一致的计算，则需要替换它们。查看 crlibm 和/或 fdlibm。
Differences in precision between the standard math library functions. They are not the same on different systems. If you need consistent calculations, you will need to replace them. Look into crlibm and/or fdlibm.