代码是使用第三方工具迁移的。无论这个工具做不了什么，都由 .net 开发人员来完成，以便修复所有编译问题。我的问题是，在这样的迁移活动中，我们是否不需要运行函数的单元测试。
其次，有人能建议我们是否应该在 VSTS 10 中使用一些工具来创建此代码的 UML 模型，以最小化客户可能发现的问题风险。这有多麻烦。
在我们不知道原始 VB6 应用程序的功能的情况下，还有哪些其他建议可以提供高质量的迁移代码。
3个回答
7
针对这样的迁移活动，我们不必为函数运行单元测试而烦恼。
我不会完全信任新翻译的代码（无论是机器翻译还是其他方式）。它绝对需要进行测试。
原始VB6应用程序的功能对我们来说是未知的。这将使回归测试非常具有挑战性。如果你不知道它应该如何运作，那么你怎么知道什么时候完成呢？
当然，你可以决定不对翻译后的代码进行单元测试，那么你也不知道新代码的工作方式。不确定“未知=未知”是否算作“通过”。
- Marc Gravell
2
Joel，你说得完全正确。
我是测试人员，需要确保商店提供的代码质量合格。我也不知道功能。我可以要求商店在新代码的每个函数上运行单元测试吗？
2. 在从这家商店迁移后，我如何要求80％无错误的代码。 - VB.
1+1. 任务一是为原始的VB6应用程序创建回归测试。这将需要与用户进行一些交互。我敢打赌，在执行此操作时，您会发现原始的VB6程序中存在一些错误。 - MarkJ
5
根据我的经验，绝大多数应用程序提供了大量的“未知”功能。毕竟，我们编写软件的原因是帮助我们以超越我们作为普通人的能力来管理信息。随着时间的推移，我们的软件大小和复杂性不断增长，直到包含大量的“未知”功能。未知的功能在某个时候可能被认为是“正确”的并得到验证，并且通过源代码详细记录。然而，随着时间的推移，没有人完全记得/知道所有功能，甚至不知道为什么它是“正确”的。全部功能只有源代码“记住/知道”，团队“测试更改”，其余部分假定是正确的，除非出现问题。这在许多人多年来扩展和更改的系统中尤其如此。当然，这会带来风险，我们可以做得更好，像TDD这样的流程和自动化单元测试工具正在帮助，但对于许多老系统而言，缺乏系统理解和不完整的测试是生活中的事实。技术理想主义者不喜欢这一点，但商业现实主义者接受它。
所有这些都意味着对于迁移团队来说存在一个重大问题。从理论上讲，这些团队正在“改变一切”。在VB6到.NET的迁移中，“测试我们所更改的内容”意味着测试全部内容。哎呀。此外，迁移的功能要求通常是“只需使其在新平台上像现在一样运行即可”。当人们不知道/记得系统执行的每件事情，更不用说如何验证它正确执行了，这并没有什么用。我正在与几个客户合作，他们拥有巨大的VB6应用程序，包含数十万行代码，分为数百个表单和类以及数千个方法、属性和事件处理程序。我喜欢问迁移团队如果我进入VB6并“破坏”某个小东西，他们需要多长时间才能找到错误。我很少得到答案...
我推崇使用辅助重写工具方法。这个过程中最关键的输入之一是经过生产测试的源代码。我们假设这个代码是“正确的”，因为您或者您的客户正在运行业务。源代码是对问题“系统做什么”的一个非常详细、正式和完整的回答。在我们的方法中，迁移团队通过迭代定制、校准和验证VB6源代码到完整的.NET源代码的自动化、系统化翻译和重构。我们翻译、测试、调整并重复；每次都会提高翻译的质量，包括功能正确性和符合.NET编码标准。验证和改进工具的功能对于这种方法至关重要。
为了验证代码质量，我们使用代码审查和“并排”测试。通过使用眼睛和其他工具（如.NET编译器、FXCop、NDepends等）检查.NET代码来进行代码审查。我们还使用类似BeyondCompare的产品比较翻译代码的连续几代，以验证每个翻译调整更改是否产生了预期效果并且没有不良副作用。 “并排”测试就像听起来的那样：总体思路是在并排测试环境中运行旧版和.NET应用程序，并确保它们的结果和行为匹配。这里至少有两个挑战：
1.当您“运行应用程序”时该怎么办；
2.如何确保结果和行为匹配？
第一个问题通常通过测试数据、用例和自动化单元测试来回答；第二个问题则通过查看应用程序UI以及两个系统的结果（数据、网页、报告）并进行比较（也称为批准测试）来回答。当然，测试工具可以大大提高效率。大规模迁移是讨论开始使用测试工具的好时机。
如果您计划迁移一个庞大的复杂代码库，您需要计划进行智能测试。如果操作得当，工具辅助方法可以高效地生成生产就绪代码，这将释放资源以生成QC文档并改进QC流程，这些将在迁移之后长期存在。
免责声明：我为Great Migrations工作。
所有这些都意味着对于迁移团队来说存在一个重大问题。从理论上讲，这些团队正在“改变一切”。在VB6到.NET的迁移中，“测试我们所更改的内容”意味着测试全部内容。哎呀。此外，迁移的功能要求通常是“只需使其在新平台上像现在一样运行即可”。当人们不知道/记得系统执行的每件事情，更不用说如何验证它正确执行了，这并没有什么用。我正在与几个客户合作，他们拥有巨大的VB6应用程序，包含数十万行代码，分为数百个表单和类以及数千个方法、属性和事件处理程序。我喜欢问迁移团队如果我进入VB6并“破坏”某个小东西，他们需要多长时间才能找到错误。我很少得到答案...
我推崇使用辅助重写工具方法。这个过程中最关键的输入之一是经过生产测试的源代码。我们假设这个代码是“正确的”，因为您或者您的客户正在运行业务。源代码是对问题“系统做什么”的一个非常详细、正式和完整的回答。在我们的方法中，迁移团队通过迭代定制、校准和验证VB6源代码到完整的.NET源代码的自动化、系统化翻译和重构。我们翻译、测试、调整并重复；每次都会提高翻译的质量，包括功能正确性和符合.NET编码标准。验证和改进工具的功能对于这种方法至关重要。
为了验证代码质量，我们使用代码审查和“并排”测试。通过使用眼睛和其他工具（如.NET编译器、FXCop、NDepends等）检查.NET代码来进行代码审查。我们还使用类似BeyondCompare的产品比较翻译代码的连续几代，以验证每个翻译调整更改是否产生了预期效果并且没有不良副作用。 “并排”测试就像听起来的那样：总体思路是在并排测试环境中运行旧版和.NET应用程序，并确保它们的结果和行为匹配。这里至少有两个挑战：
1.当您“运行应用程序”时该怎么办；
2.如何确保结果和行为匹配？
第一个问题通常通过测试数据、用例和自动化单元测试来回答；第二个问题则通过查看应用程序UI以及两个系统的结果（数据、网页、报告）并进行比较（也称为批准测试）来回答。当然，测试工具可以大大提高效率。大规模迁移是讨论开始使用测试工具的好时机。
如果您计划迁移一个庞大的复杂代码库，您需要计划进行智能测试。如果操作得当，工具辅助方法可以高效地生成生产就绪代码，这将释放资源以生成QC文档并改进QC流程，这些将在迁移之后长期存在。
免责声明：我为Great Migrations工作。
- mark
2
从你的问题的语气来看，好像你已经知道答案了！我会说除了完整的回归测试集之外，任何其他东西都可能导致灾难！理想情况下，你需要对旧版本和新版本运行相同的测试集，尽管听起来你可能无法这样做......
我的真实回答是 - 确保你有足够的支持/维护开发人员准备在全天候修复支持问题！
- DaveyDaveDave
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接
vb6-migration的问题。我要强调的是，如果您不了解原始VB6应用程序的功能，则成功迁移是不可能的。 - MarkJ