4

背景：我们收到了一个非常大的代码库（140 万行），主要是 C#。该应用程序主要由 asp.net 2.0 样式的 asmx Web 服务组成，该服务访问 SQL Server 2008 数据库中的数据以及各种 XML 文件中的数据。没有现成的自动化测试。我们有一个自动化的夜间构建（CC.NET）。

我们想引入某种程度的自动化测试，但针对这么多代码在粒度级别的单元测试中重构似乎不太可能。我们的第一个想法是找到一种方法来构建自动化测试，只需使用给定的一组参数调用每个 Web 服务，从而为我们提供一定程度的代码覆盖率。似乎是通过一些自动化测试获得最高代码覆盖率的最快方法。这甚至被称为单元测试还是会被视为其他东西？

我将如何隔离数据存储以获得一致的测试结果？是否有任何测试工具比其他工具更适合这种方法？单位？质谱测试？单元？

任何让我们朝着正确方向开始的建议将不胜感激。谢谢

4

4 回答 4

11

我的公司一直在用我们的代码库（C 而不是 C#）做类似的事情，总共大约有一百万行。步骤是这样的：

1）编写一些像您描述的那样进行系统级测试的自动化测试。
2) 执行新代码必须有单元测试的规则。
3）当一个区域有一些错误时，修复这些错误的过程应该包括编写一个基本的单元测试。

关键是 3 不需要完整的单元测试（如果它更容易人们会这样做）。如果您将特定模块的测试覆盖率从 0% 提高到 40%，那么您已经取得了很大的进步。

虽然 6 个月可能只占总代码库的 5%，但 5% 是变化最大的代码，也是最有可能引入错误的地方。我现在处理的代码大约 60% 被集成测试覆盖，15%（按行）被单元测试覆盖。这看起来并不多，但它确实提供了重要的价值，我们的开发工作也从中受益。

编辑：作为对其他评论之一的回应，目前我们运行的一组集成测试大约需要 14 小时。我们现在正在考虑并行运行一些以加快它们的速度。

于 2010-07-27T22:41:45.370 回答
4

The tests that you describe sound like more of an end-to-end or integration test than a unit test, strictly speaking. But that's not necessarily a bad thing! In your situation, it may be productive to work down from the end-to-end tests towards the unit tests, rather than up as you would on a new codebase.

  1. Write at least one simple test for each web service API, to ensure that you have some coverage of everything
  2. Identify the APIs that have historically been prone to failure, based on past bug reports. Write more extensive tests for those APIs.
  3. Every time that you encounter a failing test, drop down a level and write tests for the methods called on that code path. Eventually you'll find that one of those tests is failing. If the bug isn't obvious at that level, drop down a level and repeat.
  4. Rinse, wash, repeat every time you get a new bug report.

The idea here is that you introduce unit-test coverage "as needed" along the code paths that are currently prone to failure. This will harden those code paths for the future, and will gradually expand your unit test coverage over the entire application.

于 2010-07-27T21:29:54.937 回答
0

您可以查看的一件事是使用诸如SpecFlow之类的用户故事。我发现这些故事更自然地映射到集成测试，这正是您想要的。使用这些的额外好处是它创建了一组几乎可以由非技术团队（即产品管理/业务分析师）使用的用例。

于 2010-07-27T22:53:00.033 回答
0

正如 JSBangs 指出的那样，这些称为集成测试。而且我同意集成测试比您的案例更好的单元测试。由于有 140 万行代码，我不确定您可以从该代码库中对什么进行单元测试。

为了隔离数据存储，我喜欢执行以下操作：

  1. 最初有一组硬编码数据

  2. 过了一会儿，你应该有一个实际创建一堆测试数据的测试。首先运行这些测试，您不再需要硬编码数据。

  3. 当由于一组“不良数据”而导致生产出现问题时，请将其添加到您的测试中。最终，您将拥有一组很好的测试数据来测试大多数情况。

另外，请记住，集成测试需要更长的时间才能运行。您可能希望在测试机器上运行它们，这样它就不会阻塞您的计算机。对于需要数小时运行的测试套件来说，这是很正常的。

于 2010-07-27T21:53:16.253 回答