过去10个月，我一直在使用Windows窗体应用程序和ASP.Net应用程序。我一直想知道如何以一种强大的方式对整个应用程序进行适当的单元测试，涵盖所有场景。我有以下关于他们的问题 -
答案 0 :(得分：3)
我推荐一本关于这个主题的好书：Michael Feathers的Working Effectively with Legacy Code。我发现它对类似的遗留项目非常有用。
遗留代码的主要问题是没有“标准”方式对其进行单元测试:-(“标准”测试驱动开发是为新项目发明的，您可以从头开始编写代码和单元测试，因此您可以从第1天开始将您的单元测试套件与代码一起扩展，并始终保留所有（或大部分）代码。
然而，实际情况是，大多数现实生活项目都涉及遗留代码，没有单一的单元测试（实际上，Feathers对遗留代码的定义是“没有单元测试的代码”）。这本书充满了有用的建议，当你需要触摸你几乎不了解的代码时，该怎么做，或修改1000行的怪物方法，并确保至少你的修改得到正确的单元测试。在这种情况下，通常很难编写单元测试，因为代码的设计并不可测试。所以你经常需要对它进行重构以使其可测试，但当然没有单元测试，这是有风险的......但是，这些陷阱还有很多方法，本书就是这样的。
一般而言，您不应该以覆盖整个代码库为目的（除非您有一个项目经理愿意接受您在接下来的几个月或几年内不会产生任何新功能; - ）。您有足够的时间从单元测试中获得最大的收益。因此，您必须首先关注代码中最关键的部分。这些通常是最常修改的和/或发现最多错误的那些（当然存在相关性）。您可能还事先知道即将推出的功能需要扩展代码的特定部分，因此您可以通过为其创建单元测试来做好准备。这样，随着时间的推移，您开始在代码中增加一些“安全岛”，这些单元测试将更好地覆盖。在这些地方维护和重构更容易，随着您添加更多单元测试，岛屿会慢慢增长......
请注意，这些“安全岛屿”一开始并不倾向于表现出非常“系统”的发生模式。代码中最关键，最常修改的部分通常是相当随机分布的。只有在更晚的阶段，当单元测试的岛屿开始增长和合并时，是否值得更系统地覆盖特定模块。例如。如果您在此特定模块中看到单元测试的代码覆盖率增长超过60％，您可以决定通过它并为剩余的代码部分添加测试。
答案 1 :(得分：2)
如果你想知道如何测试整个应用程序，它不是一个单元测试，因为谈论.Net应用程序时的单元是一个类或方法。我猜测您的困惑是因为您创建的自动事物是一个测试单元（您使用测试单元进行单元测试，但您也可以使用测试进行集成测试单位...）。您可能正在讨论自动集成测试或验收测试（绝不应该是自动的）。
V-Model等测试模型至少定义了三个测试阶段：
单元测试
测试单个功能或 系统的功能。它基于 技术规范 你是单位（阶级或方法） 建造。它可以通过自动化 使用测试单位。另外，我认为应该 使用CI Server（持续集成） 在这里，因为如果你的单位没有正确整合， 这个问题最有可能出现在这个阶段。
集成测试
一旦你认证了你的每一个 “单位”（类或方法）有效 个别地，你现在尝试检查是否 整个系统是一体的。所以 你做了一个集成测试 检查这些单位是否有效 正确地在一起才能实现 系统的目的。你应该 尝试将集成测试自动化为 好。你可以使用像这样的工具 StoryTeller为此。
用户验收测试
用户验收测试必须 由用户进行，所以没有 这里自动化。当然可以 创建并加载用户的数据 将验证，所以部分 测试是自动化的，但不是 结果。没有机器人应该给你系统的最后一句话 工作，只有用户。
现在，回答你的问题：
执行单元测试和编写测试用例的标准机制是什么？
您应该为此目的使用.Net测试单元。为了测试用户交互（您可以测试用户与屏幕的交互），您可以使用外部应用程序（请查看下面的链接）。有些机器人可能会自动为您进行此类测试。
方法是否会根据应用程序性质而变化，例如Windows窗体，Web应用程序等？
事实上。例如，批量应用程序可以通过单独使用测试单元进行单元测试。批处理系统的测试用例也可能更加宽松，但需要更多数据输入来检查所有约束。
确保涵盖所有方案的最佳方法是什么？有关这方面的热门书籍吗？
我不确定是否有一种真正的方法可以让确定覆盖每个场景，但你应该做的是定义你正在测试的内容。就像我之前说的那样，你应该对技术规范进行单元测试，所以如果你的规范编写得很好，你应该能够清楚地识别测试用例。如果您觉得需要针对未指定的内容进行测试，那么您应该改进您的设计技巧。
执行单元测试的常用工具？
List of unit testing frameworks
希望这有帮助。
答案 2 :(得分：1)
您需要编写测试程序中对象和功能的单元测试。 这意味着测试测试类中的每个函数，然后测试类的功能，然后测试库中的功能。从本质上讲，您正在为应用程序中的每个级别编写测试，从顶级库到函数。这可以确保如果您更改任何代码，它仍将按预期工作。
NUnit是一个流行的单元测试框架，但VS为您提供标准的内置单元测试（可能只是VS2008，但非常确定VS2005也是如此）
涵盖所有场景只是编写测试以涵盖所有已知可能性的情况，您无法涵盖每个场景，但您可以覆盖主要场景，这通常很好，因为您知道预期的输出并且可以对此进行测试。 / p>
答案 3 :(得分：1)
执行单元测试和编写测试用例的标准机制是什么？ 有许多.NET测试框架。我建议你给NUnit或MbUnit。
MbUnit将附带一个测试运行器，这样可以使事情变得更容易。我更喜欢一种集成的方法，我可以直接从visual studio运行我的所有测试，但这需要一些重要的设置。当使用测试运行器（例如MbUnit附带的Gallio）时，您将在visual studio项目外部运行单元测试。单元测试本身应该位于他们自己的项目中，通常是Fixture形式。其中的测试可以用不同的样式命名，但关键是尽可能具有描述性。 例如：
void when_my_class_is_sent_a_user_it_should_save_it()
也很受欢迎
[MethodName_StateUnderTest_ExpectedBehavior]
方法是否会根据应用程序性质而变化，例如Windows窗体，Web应用程序等？ 该方法确实根据应用性质而变化。幸运的是，Web表单和win表单非常相似。不幸的是，它们都是在没有测试的情况下设计的，并且倾向于难以正确测试的代码。
确保涵盖所有方案的最佳方法是什么？ 测试驱动设计（您编写测试，然后编写代码以使它们通过）。代码覆盖率也是一个有用的指标。
有关这方面的热门书籍吗？ 单元测试的艺术：以.Net中的例子来自Roy Osherove 使用NUnit在C＃中进行语用单元测试
执行单元测试的常用工具？ 如上所述，NUnit＆amp; MbUnit的。还有MSTest（与VS2008捆绑在一起），xUnit和其他一些。强烈建议你选择NUnit或MbUnit。
答案 4 :(得分：0)
如果您已经开发了10个月的应用程序，那么您根本不可能对其进行单元测试，因为每个定义的单元测试只涉及一次只测试一个单元（类或甚至方法）。
此时，您最好使用FitNesse或StoryTeller等工具编写自动验收测试。