19

背景 我在一个由 7 名开发人员和 2 名测试人员组成的团队中工作，负责物流系统。我们使用 Delphi 2007 和模型驱动开发，使用Bold for Delphi作为框架。该系统已经投入生产大约 7 年，拥有大约 170 万行代码。我们在 4-5 周后发布到生产环境，几乎每次发布后，我们都必须为我们没有发现的错误做一些补丁。这对我们和客户来说当然是令人恼火的。

当前测试 解决方案当然是更自动化的测试。目前我们有手动测试。以空数据库开始并从建模方法添加数据的 Testdbgenerator。我们还有Testcomplete，它运行一些非常基本的脚本来测试 GUI。时间不足使我们无法添加更多测试，但脚本对应用程序的更改也很敏感。几年前，我真的尝试过使用 DUnit 进行单元测试，但几天后我放弃了。这些单元的连接太强了。

单元测试先决条件 我想我知道单元测试的一些先决条件：

  • 编写做一件事的小方法，但要把它做好。
  • 不要重复自己。
  • 首先编写失败的测试，然后编写代码使测试通过。
  • 单元之间的连接应该是松散的。他们应该不太了解对方。
  • 使用依赖注入。

使用框架 我们可能会升级到 Delphi XE2，主要是因为 64 位编译器。我对Spring进行了一些研究，但这需要从 D2007 进行更新，而且现在不会发生。或许明年。

问题 大多数代码仍未自动测试。那么提高旧代码的可测试性的最佳途径是什么？或者最好只为新方法编写测试？我不确定增加自动测试的最佳方法是什么，欢迎对此发表评论。我们可以时不时使用 D2007 + DUnit，然后稍后轻松更改为 Delphi XE2 + Spring 吗？

编辑：关于手动测试的当前测试方法，正如克里斯所说的那样，只是“重击并尝试打破它”。

4

3 回答 3

8

您想要 Michael Feathers 的书，有效地使用旧代码。它展示了如何将（单元）测试引入到没有考虑可测试性的代码中。

一些章节的命名是为了开发人员可能会给出为什么测试旧代码很难的借口，它们包含案例研究和解决每个问题的建议方法：

  • 我没有太多时间，我必须改变它
  • 我无法在测试工具中运行此方法
  • 这堂课太大了，我不希望它变得更大
  • 我需要改变一个怪物方法，我不能为它写测试。

It also covers many techniques for breaking dependencies; some might be new to you, and some you might already know but just haven't thought to use yet.

于 2011-10-13T18:08:57.290 回答
3

自动化单元测试的要求正是这样的：

  1. 使用单元测试框架（例如，DUnit）。
  2. 使用某种模拟框架。

第2项是艰难的。

DRY，小方法，先做个测试，DI都是糖。首先你需要开始单元测试。随手添加 DRY 等。减少耦合有助于使单元测试更容易，但如果没有大量的重构工作，您将永远不会减少现有代码库中的耦合。

考虑为新的东西和版本中更改的东西编写测试。随着时间的推移，您将获得合理的单元测试基础。新的和变化的东西也可以重构（或写得很好）。

此外，考虑一个自动构建过程，它运行单元测试并在构建中断时发送电子邮件。

这仅涵盖单元测试。对于 QA 测试人员，您将需要一个允许他们运行自动化测试（不是单元测试）的工具（它们存在，但我想不出任何工具）。

于 2011-10-12T21:31:35.847 回答
1

你的测试团队太小了，IMO。我曾在 QA 部门数量超过开发人员的团队中工作。考虑在适合较小周期的可管理块（功能、修复）的“冲刺”中工作。“敏捷”会鼓励 2 周的冲刺，但这可能太紧了。无论如何，它会让 QA 一直忙于工作，在发布窗口之前工作得更远。现在，我怀疑他们是空闲的，直到你给他们大量的代码，然后他们就被淹没了。通过更短的发布周期，您可以让更多的测试人员忙碌起来。

另外，您对他们的测试方法没有多说。他们是否有运行的标准脚本，并根据预期的外观和行为验证外观和行为？还是他们只是“敲打它并试图打破它”？

IMO，Dunit 测试很难处理大量依赖项，如数据库、通信等。但它是可行的。我创建了自动运行数据库设置脚本的 DUnit 类（查找与正在测试的类同名的 .sql 文件，运行 sql，然后测试继续进行），并且非常有效。对于 SOAP 通信，我运行了一个返回预设结果的 SoapUI 模拟服务，因此我可以测试我的通信。
这确实需要工作，但这是值得的。

于 2011-10-12T21:00:44.013 回答