问题标签 [regression-testing]

Java 中的回归测试是如何进行的？是否有自动化的回归测试框架，或者你只是编写（JUnit）单元测试来帮助确保防止回归？

是否有一种方法或一组最佳实践来编码单元测试，以便它们也可以作为回归测试的双重目的，或者您是否需要将回归测试与单元测试分开？

我们正在考虑从 zimbra 6 升级到 zimbra 7，并且我们希望避免我们编写的与它集成的帐户生命周期软件中的回归。由于大多数内容都由 WSDL 文件记录，因此我们正在考虑仅使用它进行测试。

我想知道的是，有没有办法使用 API 定义和两个目标服务器来填充测试套件？

有没有人可以清楚地定义这些测试级别，因为我发现在进行 TDD 或单元测试时很难区分。请如果有人可以详细说明如何，何时实施这些？

我正在为一个 FPGA 项目设置自动回归测试，几乎完全按照这里的描述：

• 复杂可重构系统的持续集成

现在我想让测试结果（来自REPORTModelSim 仿真中的 VHDL 语句）出现在 Jenkins 测试报告中。我的理解是 Jenkins 仅原生支持 jUnit 格式，我寻找支持非 XML 格式的插件但没有看到。

从 VHDL REPORT 语句生成有效的 XML 将非常困难，因为模拟可能会根据严重程度立即终止。这意味着每个测试的每个可能的退出路径都必须复制结束标签——这不是最可维护的方法。

那么，您知道将纯文本转换为 jUnit（或其他格式，如果 Jenkins 支持）的任何直接方法吗？如果某些东西尚不存在，那么编写 Jenkins 插件与仅将 perl 脚本放在一起是否有优势？还有其他建议吗？

在过去的几周里，我一直在试图找出一种方法来为我们的构建过程实施（或找到已经实施的人）回归测试，但到目前为止我还没有找到任何可行的方法。我们使用 TFS2008 和 VS2010，升级到 TFS2010 不是我们的选择。我尝试使用 NDepend 为我们提供更改的方法和类型依赖项的列表，但是通过我们的构建脚本运行它已被证明是极其不可靠的（如果我在不更改任何内容的情况下运行相同的构建两次，我不会对拥有一个完美的感到惊讶NDepend 报告，以及一个异常说 NDepend 由于某种原因无法运行）。

不幸的是，我几乎被我拥有的工具（TFS2008、VS2010、MSBuild 和 MSTest）所困。我可能会得到另一个工具，但是改变我已经拥有的工具（例如从 MSTest 到 NUnit，或从 TFS2008 到 TFS2010）是不可能的。

有人已经这样做了吗？或者有人可以为我指出正确的方向，以编程方式在两个构建之间找到哪些方法和类型发生了变化？

用于测试排序以及防止测试被中断。

另外，有什么方法可以中途停止模块或测试并重置 QUnit（包括所有历史结果）？

QUnit.moduleDone 是我尝试测试模块完成的唯一方法。但它适用于模块内的每一个测试，而不仅仅是整个模块。

我正在寻找以自动方式检测代码运行时性能变化的方法。这将以与 JUnit 类似的方式运行，但不是测试代码的功能，而是测试速度的突然变化。据我所知，目前没有工具可以自动执行此操作。

所以第一个问题是：有没有可用的工具可以做到这一点？

那么第二个问题是：如果没有可用的工具并且我需要自己推出，那么需要解决哪些问题？

如果第二个问题是相关的，那么这是我看到的问题：

1. 可变性取决于它运行的环境。
2. 由于 Java 中的微基准测试有很大的差异，如何检测变化。
3. 如果 Caliper 收集结果，如何将结果从 caliper 中取出，以便以自定义格式保存。缺少 Calibre 的文档。

每次我做出一些我认为可能有效的更改时，我都会提交：在提交之前我不会进行广泛的测试。此外，我的提交很快就会自动推送到远程存储库。（我是唯一的开发人员，我必须每天多次添加功能或重写部分代码。）

我想设置一台远程计算机，以便在我提交任何内容时自动运行回归测试；然后通过电子邮件将差异报告发回给我。

设置它的最简单方法是什么？

我所有的代码都在 Python 3 中。我自己的系统是 Windows 7、ActiveState Python、TortoiseHG 和 Wing IDE。我可以将远程计算机设置为 Linux 或 Windows。该应用程序是所有命令行，具有文本输入和输出。

我有一个小型命令行应用程序（大约 6k 行）。它没有单元测试，因为我不知道如何编写它们；但我现在追溯添加一些。我阅读了本教程，但对如何使用此模块测试整个应用程序感到困惑；事实上，我什至不确定我想做的是否称为“单元测试”。

具体来说，如果我使用某些参数运行我的应用程序，它应该会生成某些输出文件。我想确保那些输出文件没有改变。

即，我的应用程序的以下命令行调用：

创建一些小的输出文本文件（每个小于 10 MB）并将它们放入单独的文件夹中（每个调用一个），命名如下：

每个文件夹包含几个小文本文件（每个<10MB）。在每次代码更改迭代之后，我想使用几十个命令行参数运行我的应用程序，并注意输出文件不同的任何情况。（理想情况下，我想做更多的事情；例如，对于某些输出文件，将它们作为具有特定主键的制表符分隔表进行比较，这样如果行顺序发生更改，它们仍然会评估为相等；但这不是批判的）。

设置这个的好方法是什么？

我维护了一个 Python 程序，它为某些主题提供建议。它通过对输入数据应用复杂的算法来做到这一点。

程序代码定期更改，以解决新发现的错误和修改底层算法。

我想使用回归测试。麻烦的是，除了运行程序（即使那样，只有在没有错误的情况下）之外，没有办法判断某个输入的“正确”输出是什么。

我在下面描述了我当前的测试过程。我的问题是是否有工具可以帮助自动化这个过程（当然，如果对我正在做的事情有任何其他反馈）。

当程序第一次似乎对我的所有输入案例都正确运行时，我将它们的输出保存在我为“已验证”输出指定的文件夹中。“已验证”意味着，据我所知，输出对于我的程序的给定版本是正确的。

如果我发现一个错误，我会做出任何我认为可以修复它的更改。然后我在所有输入集上重新运行程序，并手动比较输出。每当输出发生变化时，我都会尽我所能非正式地审查这些变化并确定是否：

1. 更改完全是由于错误修复，或者
2. 这些变化至少部分是由于我引入的一个新错误

在案例 1 中，我增加内部版本计数器。我用等于版本计数器的后缀标记输出文件并将其移动到“已验证”文件夹。然后我将更改提交到 Mercurial 存储库。

如果将来，当此版本不再是最新版本时，我决定将其分支出来，我将需要这些经过验证的输出作为此特定版本的“正确”输出。

在案例 2 中，我当然会尝试找到新引入的 bug，并修复它。这个过程一直持续到我相信与之前验证版本相比的唯一变化是由于预期的错误修复。

当我修改代码以更改算法时，我遵循类似的过程。