c# - 我们已将 VB6 代码迁移到 .net 中的 C#

Question

代码是使用第三方工具迁移的。该工具不能做什么，都是由 .net 开发人员完成的，因此所有编译问题都得到了修复。我的问题是，对于此类迁移活动，我们是否不必为功能运行单元测试。

其次，任何人都可以建议我们是否应该使用 VSTS 10 中的某些工具来创建此代码的 UML 模型，以最大限度地减少客户可能发现的问题的风险。有多麻烦。

鉴于我们不知道原始 VB6 应用程序的功能这一事实，是否有任何其他关于如何交付高质量迁移代码的建议。

Answer 1

对于此类迁移活动，我们是否不必为功能运行单元测试。

我根本不相信新翻译的代码（机械或其他）。绝对需要测试。

我们不知道原始 VB6 应用程序的功能。

这将使回归测试相当……具有挑战性。如果你不知道它应该如何表现，你怎么知道你什么时候完成了它？

当然，您可以决定不对翻译后的代码进行单元测试，那么您也不会知道新代码是如何工作的——虽然不确定“未知 = 未知”是否算作“通过”。

Answer 2

根据我的经验，绝大多数应用程序都提供了大量“未知”功能。毕竟，我们编写软件的原因是为了帮助我们以远远超出我们道德能力的方式管理信息。随着时间的推移，我们软件的规模和复杂性不断增长，不断增长，直到它包含大量“未知”功能。未知功能可能曾一度被认为是“正确的”并被源代码详细捕获。然而，随着时间的流逝，没有人完全记得/知道所有功能是什么，甚至为什么它是“正确的”。完整的功能仅由源代码“记住/知道”，团队“测试他们更改的内容”，其余的假设是正确的，除非出现问题。对于多年来已被许多人扩展和更改的系统尤其如此。当然，这会带来风险，我们可以做得更好，像 TDD 这样的过程和自动化单元测试的工具会有所帮助，但是对于许多旧系统来说，缺乏系统理解和不完整的测试是生活中的事实。我的技术理想主义者不喜欢这样，但我的商业现实主义者接受它。

尽管如此，这对迁移团队来说是一个主要问题。从理论上讲，这些团队正在“改变一切”。在 VB6 到 .NET 的迁移中，“测试我们更改的内容”意味着测试所有内容。哎哟。此外，迁移的功能要求通常是“让它做现在做的事情，但在新平台上”。当人们不知道/不记得系统所做的一切，更不用说如何验证它是否正确执行时，它就不是很有用。我正在与几个客户合作，他们拥有庞大的 VB6 应用程序，其中包含成千上万个 LOC 组织成数百个或表单和类以及数千个方法、属性和事件处理程序。我确信这些应用程序包含成千上万的功能点。我想问迁移团队，如果我进入 VB6，他们需要多长时间才能找到错误并且“

这就是为什么我提倡使用工具辅助重写方法。这个过程最关键的输入之一是经过生产测试的源代码。我们假设此代码是“正确的”，因为您或您的客户正在其上开展业务。源代码是对以下问题的极其详细、正式和完整的回答：系统做什么？在我们的方法中，迁移团队迭代地定制、校准和验证将 VB6 源代码自动、系统地转换和重新设计为完整的 .NET 源代码。我们翻译、测试、调整和重复；每次都在功能正确性和符合 .NET 编码标准方面提高翻译质量。验证和完善该工具的功能是该方法的核心。

为了验证代码质量，我们使用代码审查和“并行”测试。代码审查是通过使用眼睛和其他工具（如 .NET 编译器、FXCop、NDepends 等）检查 .NET 代码来完成的。我们还使用 BeyondCompare 等产品对翻译后的代码进行了很多比较，以验证每个翻译调整更改都具有所需的效果，并且没有不良的副作用。并行测试就是它听起来的样子：总体思路是在并行测试环境中运行遗留应用程序和 .NET 应用程序，并确保它们的结果和行为匹配。这里至少有几个挑战：

1. 当你“运行应用程序”时你会做什么；和
2. 你如何确保结果和行为匹配？

第一个问题通常根据测试数据、用例和自动化单元测试来回答；第二个问题是通过查看应用程序 UI 以及来自两个系统的结果（数据、网页、报告）和比较（也称为基于批准的测试）来回答的。当然，测试工具可以大大提高效率。大规模迁移是讨论开始使用测试工具的好时机。

如果您计划迁移大型复杂代码库，则需要计划非常聪明地进行测试。如果做得好，工具辅助方法可以非常有效地交付生产就绪代码，这将释放资源来生成 QC 工件并改进在迁移后将持续很长时间的 QC 流程。

免责声明：我为大迁徙工作。

Answer 3

从你提问的语气看来你已经知道答案了！我想说，除了一套完整的回归测试之外，任何东西都将是灾难的根源！理想情况下，您可能希望针对旧版本和新版本运行相同的测试集，尽管听起来您可能无法做到这一点......

我诚实的回答 - 确保您有足够的支持/维护开发人员准备好全天候工作以解决支持问题！