使用第三方工具迁移代码。该工具无法做什么，是由.net开发人员完成的，因此修复了所有编译问题。我的问题是，对于这样的迁移活动，我们不打扰运行单元测试功能。
其次，是否有人建议我们是否应该使用VSTS 10中的某个工具来创建此代码的UML模型，以最大限度地降低客户可能发现的问题的风险。这有多累赘。
鉴于我们未知原始VB6应用程序的功能，是否有任何其他建议可以提供高质量的迁移代码。
答案 0 :(得分：7)
对于此类迁移活动，我们是否不打算对函数运行单元测试。
我不相信新编译的代码（机械或其他） 。绝对需要测试。
我们不知道原始VB6应用程序的功能。
这将使回归测试非常具有挑战性。如果你不知道它的表现方式，你怎么知道你什么时候完成它？
当然，您可以决定不对已翻译的代码进行单元测试，然后您就不会知道 新的 代码如何 - 不确定“未知=未知”算作“通行证”。
答案 1 :(得分：5)
根据我的经验，绝大多数应用程序提供了大量“未知”功能。毕竟我们编写软件的原因是为了帮助我们以不可估量地超越我们仅仅是道德的能力来管理信息。随着时间的推移，我们的软件的大小和复杂性会增长，增长，并且会增长，直到它包含大量“未知”功能。未知的功能可能已知并且一次被验证为“正确”，并且源代码详细捕获了该功能。然而，随着时间的推移，没有人完全记住/知道所有功能是什么，甚至是“正确”的原因。完整的功能只有源代码“记住/知道”，团队“测试他们改变了什么”，其余的假设是正确的，除非出现问题。对于多年来已被许多人扩展和改变的系统尤其如此。当然这会带来风险，我们可以做得更好，像TDD这样的过程和自动化单元测试的工具都有帮助，但对于许多旧系统来说，缺乏系统理解和不完整测试是生活中的事实。我的技术理想主义者不喜欢这样，但我的商业现实主义者接受了它。
所有这一切，这都是迁移团队面临的一个主要问题。从理论上讲，这些团队正在“改变一切”。在VB6-to-.NET迁移中，“测试我们改变了什么”意味着测试它。哎哟。此外，迁移的功能要求通常是“只是让它做它现在做的事情，但是在新平台上”。当人们不知道/记住系统所做的一切时，这并不是很有用，更不用说如何验证它是否正确完成了。我正在与几个拥有巨大VB6应用程序的客户合作，这些应用程序包含数百个LOC，组织成数百个表单和类以及数千个方法，属性和事件处理程序。我相信这些应用程序包含数以万计的功能点。我想问一下迁移团队，如果我进入VB6并在某个地方“破坏”一个小东西，他们需要多长时间才能找到错误。我很少得到答案......
这就是我提倡使用tool-assisted rewrite方法的原因。此过程最关键的输入之一是经过生产测试的源代码。我们假设此代码“正确”，因为您或您的客户正在运行其业务。源代码是对问题的非常详细，正式和完整的答案：系统做什么？在我们的方法中，迁移团队迭代地定制，校准和验证VB6源的自动，系统转换和重新设计到完整的.NET源。我们翻译，测试，调整和重复;每次都在功能正确性和.NET编码标准的一致性方面提高翻译质量。验证和优化工具的功能是该方法的核心。
为了验证代码质量，我们使用代码审查和“并排”测试。代码审查是通过使用眼睛检查.NET代码以及其他工具（如.NET编译器，FXCop，NDepends等）来完成的。我们还使用BeyondCompare等产品对连续代的翻译代码进行了大量比较，以验证每个翻译调整改变具有期望的效果并且没有不期望的副作用。并排测试恰如其分：一般的想法是在并排测试环境中运行旧版和.NET应用程序，并确保其结果和行为匹配。这里至少有几个挑战：
第一个问题通常是根据测试数据，用例和自动化单元测试来回答的;在查看应用程序UI以及来自两个系统和比较（也称为基于批准的测试）的结果（数据，网页，报告）方面，回答了第二个问题。当然，测试工具可以大大提高效率。大规模迁移是讨论开始使用测试工具的最佳时机。
如果您计划迁移大型复杂代码库，则需要计划对测试非常聪明。如果操作得当，工具辅助方法可以非常有效地提供生产就绪代码，这将释放资源以生成QC工件并改进迁移后很长时间内可以忍受的QC流程。
免责声明：我为Great Migrations工作。
答案 2 :(得分：2)
从问题的语气来看，听起来你知道答案！我会说除了一套完整的回归测试之外的任何东西都会成为灾难的秘诀！理想情况下，您可能希望针对旧版本和新版本运行相同的测试集，尽管听起来您可能无法做到这一点......
我诚实的回答 - 确保您有足够的支持/维护开发人员准备好全天候解决支持问题！