您在编写集成测试时遇到了哪些挑战？

Question

您在编写集成测试时遇到了哪些挑战？编写单元测试是否有助于编写集成测试？

Answer 1

我处理分布式软件系统，其中不同类型的基于服务器的应用程序进行通信（通常通过消息传递）。因此，长期存在的问题是保持在各自服务器上运行的所有这些复杂应用程序的配置和正确配置部署。准备集成测试具有显着的QA开销。虚拟机可以提供帮助。但是，使用UDP通信的集群软件（如JGroups）在虚拟机上与在物理服务器上运行时无法正常工作。

此类测试的另一个缺点是要进行测试的适当且一致的数据库上下文。通常情况下，创建可在数据库中建立数据上下文的测试设置脚本与设计本身的软件一样复杂（并且容易出错）。

单元测试的测试方法，内置回归测试等的持续集成测试方法都没有做任何事情来使这些测试问题更容易解决。它们是有用的和有价值的，但绝不存在任何银弹。

Answer 2

与单元测试一样，集成测试也需要对它有共同的理解和认识。

要求的每次变更都可能改变被测对象的行为。因此，您的集成测试可能会中断。

每次更改代码都可能会改变被测对象的行为。因此，您的集成测试可能会中断。

我认为编写集成测试就像坐在系统的利益相关者（编写需求的人）和开发人员之间。如果任何一方不了解集成测试的范围，那么您将需要解决问题。当出现问题时，您必须弄清楚的典型问题是：

• 有些要求改变了吗？ （当然， 你不检查你的电子邮件吗？协议 已更新至Spec 1.2。）
• 代码改变了吗？ （当然，我 优化了数据库访问 引入缓存的算法， 但我不知道会这样 打破你的集成测试。）

然后你将不得不面对许多范围爬行者。集成测试可能会成为开发人员的质量测试（是的，我知道我的单元测试不包括该类的很多行为，但集成测试将完成剩下的工作。）或利益相关者的验收测试（< em>请添加测试系统如果我们抛出无效命令将如何表现。）或管理员的压力测试（嘿，你的集成测试提供了一个很好的方法来轰炸服务器，每个请求数百个秒！）。

虽然这只是一个挑战，但您将面临，这是最重要的挑战之一：创建对集成测试范围的理解和认识。

Answer 3

UnitTesting在比集成测试更加孤立的空间中工作。因此，虽然工具大致相同，但存在一些不同的挑战：

随着时间的推移，后端系统中的数据会发生变化。有时您对这些更改没有任何影响，并且它们可以使详细的集成测试无用。通常，这会导致进行“冒烟测试”，就像集成测试一样，实际上并没有过多地断言后端系统的内容。另一种方法是使用其他服务来动态查找具有与您的测试需求相匹配的特定“形状”的数据。这些技术都没有真正与单元测试相同;所以这真的是一个相当不同的学科。

我觉得（在大型项目中）总是有一部分人专门从事集成测试，而每个人都在编写单元测试。可以说每个人都会编写集成测试，但通常还需要注意一点，这意味着随着时间的推移维护通常会变得更加专业化。每个人都不需要100％详细了解你的后端的特性。

Answer 4

我遇到了最困难的测试：

1. 单身人士（通常不是我创造的）
2. 创建许多依赖项的对象，导致难以提供“测试”版本 - 这就是IOC如此美好的一个原因
3. 重度消息驱动的异步对象

我有一个同事创造了作为单身人士的一切。因此，需要一起工作的对象只会说XXX x = XXX.INSTANCE;得到一个单身人士。一切都是单身人士，几乎不可能将任何一个放入测试框架中。