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

【问题标题】：We have migrated VB6 code to C# in .net我们已将 VB6 代码迁移到 .net 中的 C#
【发布时间】：2010-04-29 11:31:29
【问题描述】：

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

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

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

【问题讨论】：

如果功能未知，为什么要移植源？功能未知的代码有什么用？
@Konrad，这种情况在大公司中经常发生，其中一些有机筹集的源代码通过几代开发人员传下来 - 而大多数代码的含义对于现代后代来说是未知的.如果在没有任何文档的情况下将工作外包“请移植到 C#”，也会发生这种情况——一些咨询公司提供这种服务。
@Joel - 请参阅我的帖子下方的评论（来自 OP）给您。
有很多关于迁移的建议 - 查看标记为 vb6-migration 的其他问题。我要强调的是，如果您不了解原始 VB6 应用程序的功能，那么成功迁移是不可能。
@VB，对不起，我对你没有任何建议。如果不知道代码应该做什么，就不可能验证“正确性”，因为您没有可比较的基线。有些人可能会争辩说，您可以测试代码是否健全并可以编译，但这与功能正确性相去甚远。

标签： c# vb6 vb6-migration

【解决方案1】：

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

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

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

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

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

【讨论】：

乔尔，你是绝对正确的。我是测试人员，需要证明商店正在交付高质量的代码。我也不知道功能。我可以要求商店对新代码的每个功能运行单元测试吗？ 2. 从本店迁移后如何要求 80% 无 bug 的代码。
+1。工作编号 1 是为原始 VB6 应用程序创建回归测试。这将需要与用户进行一些交互。我敢打赌，您在执行此操作时会在原始 VB6 程序中发现一些错误。

【解决方案2】：

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

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

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

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

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

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

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

免责声明：我为 Great Migrations 工作。

【讨论】：

【解决方案3】：

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

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

【讨论】：