对大型应用程序进行单元测试 - 经过验证的方法？
过去 10 个月我一直致力于 Windows 窗体应用程序和 ASP.Net 应用程序。我一直想知道如何以涵盖所有场景的稳健方式对整个应用程序执行正确的单元测试。我对它们有以下问题 -
- 的标准机制是什么 执行单元测试并编写测试用例？
- 方法论是否会根据以下情况发生变化： 关于应用程序的性质，例如 Windows 窗体、Web 应用程序等？
- 最好的方法是什么 确定我们涵盖了所有场景吗？任何 这方面的热门书籍？
- 表演单位流行的工具 测试？
I've been working in windows forms applications and ASP.Net applications for the past 10 months. I've always wondered how to perform proper unit testing on the complete application in a robust manner covering all the scenarios. I've the following questions regarding them -
- What are the standard mechanisms in
performing unit testing and writing test cases? - Does the methodologies change based
on the application nature such as
Windows Forms, Web applications etc? - What is the best approach to make
sure we cover all the scenarios? Any
popular books on this? - Popular tools for performing unit
testing?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我推荐一本关于这个主题的好书：有效地处理遗留代码迈克尔·费瑟斯.我发现它对于类似的遗留项目非常有用。
遗留代码的主要问题是没有“标准”方法来对其进行单元测试:-(“标准”测试驱动开发是为新项目发明的，您可以从头开始编写代码和单元测试，因此您可以从第一天开始就将单元测试套件与代码一起扩展，并始终覆盖所有（或大部分）代码。
但是，现实情况是，大多数现实项目都涉及遗留代码，而没有单个单元测试（。事实上，Feathers 对遗留代码的定义是“没有单元测试的代码”）。这本书充满了关于当您需要接触您几乎不理解的代码或修改怪物时该怎么做的有用建议。 1000 行的方法，并确保至少您的修改得到正确的单元测试。在这种情况下，通常很难编写单元测试，因为代码不是设计为可测试的，因此您经常必须重构它。它是可测试的，但当然，如果没有适当的单元测试，这是有风险的……尽管如此，还是有办法摆脱这种陷阱的，本书展示了它们。
一般来说，您不应该以覆盖整个代码库为目标（除非您有一个项目经理愿意接受您在接下来的几个月或几年内不会产生任何新功能；-）。您从单元测试中获得最大可能收益的时间有限。因此，您必须首先关注代码中最关键的部分。这些通常是最常修改的和/或发现最多错误的（当然存在相关性）。您可能还提前知道即将推出的功能需要扩展代码的特定部分，因此您可以通过为其创建单元测试来做好准备。这样，随着时间的推移，您开始在代码中形成小的“安全岛”，单元测试可以更好地覆盖这些“安全岛”。在这些地方，维护和重构更容易，并且当您添加更多单元测试时，孤岛会慢慢增长......
请注意，一开始这些“安全孤岛”往往不会表现出非常“系统”的发生模式。代码中最关键、最常修改的部分通常是相当随机分布的。只有在更晚的阶段，当单元测试的岛屿开始增长和合并时，才值得更系统地覆盖特定模块。例如，如果您发现在此特定模块中单元测试的代码覆盖率增长超过 60%，您可能会决定仔细检查它并为其余代码部分添加测试。
I recommend a very good book on this subject: Working Effectively with Legacy Code by Michael Feathers. I found it immensely useful for similar legacy projects.
The main problem with legacy code is that there is no "standard" way to unit test it :-( The "standard" Test Driven Development is invented for new projects, where you start writing code - and unit tests - from scratch, so you can grow your unit test suite together with your code from day 1, and keep all (or most) of your code covered all the time.
However, reality is that most of the real life projects involve legacy code, without a single unit test (in fact, Feathers' definition of legacy code is "code without unit tests"). This book is full of useful advice on what to do when you need to touch code you barely understand, or modify a monster method of 1000 lines and make sure that at least your modification gets unit tested properly. In such cases, typically it is very difficult to write unit tests, because the code was not designed to be testable. So often you have to refactor it to make it testable, but of course without unit tests in place, this is risky... still, there are ways out of such traps, and this book shows them.
In general, you shouldn't start with the aim of covering the whole codebase (unless you have a project manager willing to accept that you are not going to produce any new feature in the next couple of months - or years ;-). You have a limited amount of time to achieve the most possible benefit from your unit tests. Thus you have to focus on the most critical parts of the code first. These are typically the ones most often modified and/or the ones where the most bugs are found (there is a correlation of course). You may also know in advance that an upcoming feature requires extending a specific part of the code, so you may prepare the way by creating unit tests for it. This way, over time you start to grow little "islands of safety" within the code, which are ever better covered with unit tests. Maintenance and refactoring is easier in these spots, and as you add more unit tests, the islands slowly grow...
Note that in the beginning these "safe islands" don't tend to show a very "systematic" pattern of occurrence. The most critical, most often modified parts in the code usually are distributed fairly randomly. Only at a much later stage, when the unit tested islands start to grow and merge, is it worth covering a specific module more systematically. E.g. if you see that in this particular module the code coverage of unit tests grew over 60%, you may decide to go through it and add tests for the remaining code parts too.
如果您想知道如何测试整个应用程序，那么它不是单元测试，因为谈论 .Net 应用程序时的单元是类或方法。我猜你的困惑是由于你创建的自动化东西是一个测试单元（你使用测试单元进行单元测试，但你也可以使用测试进行集成测试）单位...）。您可能正在谈论自动化集成测试或验收测试（永远不应该是自动的）。
V-Model 等测试模型至少定义了三个测试阶段：
现在，回答您的问题：
为此，您应该使用 .Net 测试单元。为了测试用户交互（您可以测试用户与屏幕的交互），您可以使用外部应用程序（检查下面的链接）。某些机器人可能会自动为您进行此类测试。
的确。例如，可以通过单独使用测试单元来对批处理应用程序进行单元测试。批处理系统的测试用例也可以更加宽松，但需要更多的数据输入来检查所有约束。
我不确定是否有真正的方法来确保您涵盖了所有场景，但您应该做的是定义您要测试的内容。就像我之前说的，你应该根据技术规范进行单元测试，所以如果你的规范写得很好，你应该能够清楚地识别测试用例。如果您觉得需要针对未指定的内容进行测试，那么您应该改进您的设计技术。
GUI 测试工具列表
单元测试框架列表
希望这会有所帮助。
If you want to know how to test whole application, it's not a unit test, since the unit when talking about .Net applications is a class or method. I guess your confusion arouse from the fact that the automated thing you create is a test unit (you do unit tests with tests units, but you can also do integration tests with test units...). You are probably talking about automated integration tests or acceptance tests (which should never be automatic).
Testing models such as V-Model define at least three test phases:
Now, to answer your questions:
You should use .Net Test Units for that purpose. In order to test user interaction (you can test a user interaction with a screen), you can use a external application (check the links below). Some robot might automate such tests to you.
Indeed. For example, a batch application can be unit tested through the sole use of test units. Tests cases for batch systems can also be more lax, but will need more data input to check all the constraints.
I'm not sure that there's a real way to make sure that you covered every scenario, but what you should do is define what you are testing against. Like I said before, you should unit test against the technical specification, so if your spec is well written, you should be able to clearly identify the test cases. If you feel the need to test against something that wasn't specified, then you should be improving your design techniques.
List of GUI testing tools
List of unit testing frameworks
Hope this helps.
您需要编写单元测试来测试程序中的对象和功能。
这意味着测试要测试类中的每个函数，然后测试整个类的功能，然后测试库中的功能。本质上，您正在为应用程序中的每个级别编写测试，从顶级库到函数。这可以确保如果您更改任何代码，它仍然可以按预期工作。
NUnit 是一个流行的单元测试框架，但 VS 为您提供了内置单元测试作为标准（可能仅限 VS2008，但很确定 VS2005 也如此）
覆盖所有场景只是编写测试来覆盖所有已知的可能性，您无法覆盖所有情况但您可以涵盖主要的场景，这通常很好，因为您知道预期的输出并可以对其进行测试。
You need to write unit tests that test objects and functionality within your program.
This means tests to test each function within a class, then the class functionality as a whole, then functionality inside libraries. Essentially you are writing tests for each level in the application right from top level libraries to functions. This ensures that if you change ANY code it will still work as expected.
NUnit is a popular unit testing framework but VS provides you with built in unit tests as standard (might be VS2008 only but pretty sure VS2005 does too)
Covering all scenarios is simply a case of writing tests to cover all known eventualities, you cannot cover EVERY scenario but you can cover the main ones, which normally are fine as you know what output is expected and can test against that.
执行单元测试和编写测试用例的标准机制是什么？
有许多 .NET 测试框架。我建议您提供 NUnit 或 MbUnit。
http://www.nunit.org/
http://www.mbunit.com/
MbUnit 将附带一个测试运行程序，因此这可能会让事情变得更容易。我更喜欢一种集成方法，可以直接从 Visual Studio 运行所有测试，但这需要一些重要的设置。当使用测试运行程序（例如 MbUnit 附带的 Gallio）时，您将在 Visual Studio 项目外部运行单元测试。单元测试本身应该位于自己的项目中，通常采用 Fixture 的形式。其中的测试可以用不同的风格命名，但关键是尽可能具有描述性。
例如：
也很流行
方法是否会根据应用程序性质（例如 Windows 窗体、Web 应用程序等）而改变？
该方法确实会根据应用程序的性质而变化。幸运的是，Web 表单和 win 表单非常相似。不幸的是，它们在设计时都没有考虑到测试，并且倾向于编写难以正确测试的代码。
确保我们覆盖所有场景的最佳方法是什么？
测试驱动设计（您编写测试，然后编写代码以使它们通过）。代码覆盖率也是一个有用的指标。
有这方面的热门书籍吗？
单元测试的艺术：以 .Net 中的示例作者：Roy Osherove
使用 NUnit 在 C# 中进行实用单元测试
执行单元测试的流行工具？
如上所述，NUnit & Mb 单位。还有 MSTest（与 VS2008 捆绑在一起）、xUnit 等。不过，强烈建议您使用 NUnit 或 MbUnit。
What are the standard mechanisms in performing unit testing and writing test cases?
There are many .NET testing frameworks. I would recommend you give NUnit or MbUnit.
http://www.nunit.org/
http://www.mbunit.com/
MbUnit will come with a test runner, so that might make things easier. I prefer an integrated approach where I can run all my tests right from visual studio, but that requires some significant setup. When using a test runner (such as Gallio which comes with MbUnit) you will be running your unit tests external of your visual studio project. Unit Tests themselves should be located within their own project, generally of the form Fixture. The tests within can be named with differing styles, but the key is to be as descriptive as possible.
For example:
Also popular
Does the methodologies change based on the application nature such as Windows Forms, Web applications etc?
The methodology does change based on the applicaiton nature. Fortunately, web forms and win forms are very similar. Unfortunately, they both were designed without testing in mind and tend towards code that is difficult to test properly.
What is the best approach to make sure we cover all the scenarios?
Test Driven Design (You write the tests, then write the code to make them pass). Code coverage can also be a helpful metric.
Any popular books on this?
The Art of Unit Testing: With Examples in .Net By Roy Osherove
Pragmatic Unit Testing in C# with NUnit
Popular tools for performing unit testing?
As mentioned above, NUnit & MbUnit. There is also MSTest (comes bundled with VS2008), xUnit and some others. Stongly suggest you go with NUnit or MbUnit though.
如果您已经开发一个应用程序 10 个月，那么您根本不可能对其进行单元测试，因为每个定义的单元测试一次只涉及测试一个单元（类甚至方法）。
此时，您最好使用 FitNesse< 等工具编写自动化验收测试 /a> 或 故事讲述者。
If you have already been developing an application for 10 months it is highly unlikely that you will be able to unit test it at all, because unit testing per definition involves testing only one unit (class or even method) at a time.
At this point, you would be better off writing automated acceptance tests using such tools as FitNesse or StoryTeller.