我们已将 .net 中的 VB6 代码迁移到 C#
该代码是使用第三方工具迁移的。该工具无法完成的事情都由 .net 开发人员完成，因此所有编译问题都得到了解决。我的问题是，对于这样的迁移活动，我们是否不费心为功能运行单元测试。
其次，有人可以建议我们是否应该使用 VSTS 10 中的某些工具来创建此代码的 UML 模型，以尽量减少客户可能发现的问题的风险。多么麻烦啊。
鉴于我们对原始 VB6 应用程序的功能一无所知，对于如何交付高质量的迁移代码，还有其他建议吗？
The code was migrated using a third party tool. what ever the tool couldnt do, was done by the .net developers, so that all compile issues were fixed. My question is, for such migration activities, do we not bother running unit tests for the functions.
Secondly, Could anyone suggest if we should use some tool in VSTS 10 to create a UML model of this code to minimize risks of issues that the client might find. How cumbersome is it.
Are there any other suggestions for how quality migrated code can be delivered, in light of the fact that the functionality of the original VB6 application is unknown to us.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我根本不相信新翻译的代码（机械或其他）。。绝对需要测试。
这将使回归测试变得相当......具有挑战性。如果您不知道它的行为方式，您如何知道它何时完成？
当然，您可以决定不对翻译后的代码进行单元测试，那么您将不知道新代码如何工作或者 - 不确定不过，“未知=未知”算作“通过”。
I wouldn't trust freshly translated code (mechanical or otherwise) at all. Absolutely it needs testing.
That will make regression testing quite... challenging. If you don't know how it is meant to behave, how do you know when you've finished it?
Of course, you could decide not to unit test the translated code, then you won't know how the new code works either - not sure that "unknown = unknown" counts as a "pass", though.
根据我的经验，绝大多数应用程序都提供了大量“未知”功能。毕竟，我们编写软件的原因是为了帮助我们以远远超出我们道德能力的方式管理信息。随着时间的推移，我们软件的规模和复杂性不断增长，直到它包含大量“未知”功能。未知的功能可能曾经被已知并被验证为“正确”，并且由源代码详细捕获。然而，随着时间的推移，没有人完全记住/知道所有功能是什么，甚至为什么它是“正确的”。完整的功能仅由源代码“记住/已知”，团队“测试他们更改的内容”，除非出现问题，否则其余部分被认为是正确的。对于多年来被许多人扩展和更改的系统尤其如此。当然，这会带来风险，我们可以做得更好，像 TDD 这样的流程和自动化单元测试的工具会有所帮助，但对于许多旧系统来说，缺乏系统理解和不完整的测试是生活的事实。我内心的技术理想主义者不喜欢这样，但我内心的商业现实主义者接受它。
话虽如此，这对迁移团队来说是一个主要问题。理论上，这些团队正在“改变一切”。在 VB6 到 .NET 的迁移中，“测试我们更改的内容”意味着测试所有内容。哎哟。此外，迁移的功能要求通常是“让它做现在所做的事情，但在新平台上”。当人们不知道/记住系统所做的一切时，这不是很有用，更不用说如何验证它是否正确执行了。我正在与几个客户合作，他们拥有庞大的 VB6 应用程序，其中包含数百个组织成数百个表单和类的 LOC，以及数千个方法、属性和事件处理程序。我确信这些应用程序包含数十万个功能点。我喜欢问迁移团队，如果我进入 VB6 并在某个地方“破坏”了一件小事情，他们需要多长时间才能找到错误。我很少得到答案...
这就是为什么我主张使用工具辅助重写方法。此过程最关键的输入之一是经过生产测试的源代码。我们假设此代码是“正确的”，因为您或您的客户正在其上开展业务。源代码是对以下问题的极其详细、正式和完整的回答：系统做什么？在我们的方法中，迁移团队迭代地定制、校准和验证 VB6 源代码到完整 .NET 源代码的自动、系统转换和重新设计。我们翻译、测试、调整、重复；每次都在功能正确性和符合 .NET 编码标准方面提高翻译质量。验证和完善该工具的功能是该方法的核心。
为了验证代码质量，我们使用代码审查和“并行”测试。代码审查是通过使用眼睛和其他工具（例如 .NET 编译器、FXCop、NDepends 等）检查 .NET 代码来完成的。我们还使用 BeyondCompare 等产品对连续几代的翻译代码进行大量比较，以验证每个翻译调整更改都具有所需的效果并且没有不希望的副作用。并行测试顾名思义：总体思路是在并行测试环境中运行旧版应用程序和 .NET 应用程序，并确保它们的结果和行为匹配。这里至少有几个挑战：
第一个问题通常通过测试数据、用例和自动化单元测试来回答；第二个问题通过查看应用程序 UI 以及两个系统的结果（数据、网页、报告）并进行比较（也称为基于批准的测试）来回答。当然，测试工具可以大大提高效率。大规模迁移是讨论开始使用测试工具的好时机。
如果您计划迁移大型复杂的代码库，则需要非常明智地进行测试。如果做得正确，工具辅助方法可以非常有效地交付生产就绪的代码，这将释放资源来生成 QC 工件并改进 QC 流程，这些流程将在迁移后持续很长时间。
免责声明：我为大迁徙工作。
In my experience, the vast majority of applications provide a great deal of "unknown" functionality. After all the reason we write software is to help us manage information in ways that immeasurably exceed our abilities as mere morals. Over time, the size and complexity of our software grows, and grows, and grows until it contains a vast amount of "unknown" functionality. The unknown functionality was probably known and verified as "correct" at one time and it was captured in detail by the source code. However, as time passes no one fully remembers/knows what all the functionality is or even why it is "correct". The full functionality is only "remembered/known" by the source code, teams "test what they change" and the rest is assumed correct unless a problem shows up. This is particularly true of systems that have been extended and changed by many people over many years. Of course this creates risk, and we can do better, process like TDD and tools to automate unit testing are helping, but for many older systems lack of system understanding and incomplete testing are facts of life. The technical idealist in me does not like this, but the business realist in me accepts it.
All that said, this presents a major problem for migration teams. In theory these teams are "changing everything". In a VB6-to-.NET migration, "Test what we changed" means test it all. Ouch. Also the functional requirements for a migration often are "just make it do what it does now, but on the new platform." Not very useful when people do not know/remember everything the system does let alone how to verify that it does it correctly. I am working with several customers that have huge VB6 apps containing 100s of thousands of LOC organized into hundreds or forms and classes and several thousand methods, properties, and event handlers. I am sure these apps contain 10s of thousands of function points. I like to ask migration teams how long it would take them to find the error if I went into the VB6 and "broke" one little thing somewhere. I rarely get an answer...
This is why I advocate using a tool-assisted rewrite methodology. One of the most critical inputs to this process is the production-tested source code. We assume this code is "correct" since you or your customers are running their business on it. The source code is an extremely detailed, formal, and complete answer to the question: what does the system do? In our approach, the migration team iteratively customizes, calibrates, and verifies the automatic, systematic translation and re-engineering of the VB6 source to a complete .NET source. We translate, test, tune, and repeat; each time improving the quality of the translation in terms of functional correctness and conformance to .NET coding standards. Verifying and refining what the tool does is central to the methodology.
In order to verify code quality, we use code reviews and "side-by-side" testing. Code reviews are done by inspecting the .NET code using eyes, and other tools such as the .NET compiler, FXCop, NDepends, etc. We also do a lot of comparing successive generations of the translated codes using a product like BeyondCompare to verify that each translation tuning change has the desired effect and no undesired side-effect. Side-by-side testing is just what it sounds like: the general idea is to run the legacy and .NET apps in side-by-side test environments and make sure their results and behaviors match. There are at least a couple challenges here:
The first question is typically answered in terms of test data, use cases and automated unit tests; the second question is answered in terms of looking at the application UI, and the results (data, web pages, reports) from both systems and comparing (aka approval-based testing). Of course testing tools can go a long way to increase the efficiency. A large-scale migration is a very good time to have a discussion about starting to use testing tools.
If you are planning to migrate a large complex codebase, you need to plan to be very smart about testing. If done properly, the tool-assisted approach delivers production ready code very efficiently, and this will free up resources to produce QC artifacts and improve QC processes that will endure long after the migration.
Disclaimer: I work for Great Migrations.
从你提问的语气看来你已经知道答案了！我想说，除了一套完整的回归测试之外的任何事情都将导致灾难！理想情况下，您希望对旧版本和新版本运行相同的测试集，尽管听起来您可能无法做到这一点......
我诚实的答案 - 确保您获得足够的支持/维护开发人员准备全天候工作解决支持问题！
From the tone of your question it sounds like you know the answer! I would say anything other than a complete set of regression tests would be a recipe for disaster! Ideally, you would want to run the same set of tests against both the old and new versions, although it sounds like you might not be able to do that...
My honest answer - make sure you've got plenty of support/maintenance developers ready to work round the clock fixing support issues!