2

我正在开发一个在并行开发环境中不断增强的 Web 应用程序（在两个不同的环境中开发两个需求，并在第一个需求发布到生产环境时将第一个代码库合并到第二个代码库）。

我的问题是关于应用程序及其维护的集成测试和单元测试。

带有模拟的单元测试使得难以在并行开发中维护测试，并行开发中的集成测试（使用 selenium）使得难以在数据库中维护所需的数据（这可能比修复失败的单元测试容易）

我倾向于集成测试，因为合并代码不会破坏用例，但单元测试用例可能会因预期而因合并代码而失败。该应用程序有点旧并且设计不正确对于单元测试和重构代码以及维护单元测试用例变得越来越困难。请提出更好的测试方法。

4

3 回答 3

1

单元测试和集成测试都有自己的位置。顾名思义，单元测试验证单元的行为是否符合预期。确实，集成测试涵盖了单元测试涵盖的相同代码。但是单元测试可以帮助您更轻松地查明问题。而不是调查失败以了解系统的哪个部分对问题负责 - 您有一个失败的单元测试可以帮助您找出问题。进行单元测试的另一个原因是速度。单元测试应该很快。它们不应依赖于各种系统依赖项（您应该为此使用模拟和存根）。如果您的单元测试覆盖率很高，那么您会在开始漫长的测试周期之前快速获得有关系统质量的反馈。

实际上，您通常会使用各种级别的自动化测试：

  1. 烟雾测试。这是在最基本的场景中测试系统各个部分的单元测试。它们通常用作不签入错误代码的门控签入的一部分。你需要这个速度很快。
  2. 回归 - 单元测试。通常是持续集成的一部分。同样，您需要尽可能快，以便构建不会花费太长时间。
  3. 完整的回归 + 集成测试。这些是需要更长运行时间的更多系统测试。这些通常在夜间构建中每天运行一次，甚至更少（取决于长度）
于 2013-02-24T18:11:10.153 回答
0

W/关于单元测试问题：

我怀疑你经常需要重构的单元测试的水平有点太低了。通常，最好有一些更高级别的测试，通过改变输入来执行较低级别的代码。

假设没有不必要的代码，更高级别的测试仍然应该提供良好的代码覆盖率（如果他们无法访问代码，为什么代码在那里？）。

W /关于功能测试问题：

您可能需要考虑一个有代表性的数据样本（或几个）。这样你就可以有一个已知的输入，所以你应该得到可预测的输出。

于 2013-02-25T01:36:40.177 回答
0

如果您发现维护某些类型的测试的成本太高，考虑放弃它们是明智的。我认为集成测试对于 QA 来说更重要，如果我只能选择一种类型的测试（单元与集成），那就是我会选择的。

但是，首先您可能还想考虑是否有一种方法来考虑单元测试以避免这些维护问题。当我第一次开始使用模拟时，我花了一段时间才找到合适的平衡点。根据我的经验，我发现最好尽可能避免模拟（有期望）。不过，我确实使用了模拟库，主要是为了简单的存根而不是更复杂的模拟。如果您有兴趣，我不久前写了一篇关于此的博客文章。

于 2013-02-25T01:09:51.017 回答