问题标签 [regression-testing]

我正在寻找一种用于回归测试我们正在构建的设备套件的工具。

当前的概念是您为工具创建一个输入文件 (text/csv)，指定对被测系统的输入。然后，该工具从系统捕获输出并将输入和输出记录到输出文件中。

输出与原始输入文件的格式相同，可用作工具后续运行的输入，测量的输出与前一次运行的值匹配。

两次运行的结果不会完全匹配，存在一些时间差异，这取决于电池的状态，或者取决于设备的其他内部状态。

我们必须编写自己的接口来将命令从工具传递到设备并捕获设备的输出。

这是一项相对简单的任务，但我正在寻找现有的工具/包/库，以避免重新发明轮子/从中吸取教训。

我们正在使用 VMWare 和 NUnit 开发自动化回归测试。我们已将测试划分为多个步骤，现在我希望查看每个步骤的性能回归。像 NUnit 那样简单地为测试计时似乎并不可靠。我计算了大约 15% 的接受系数，但我们的步骤有时可能会超过 35%。在这种依赖资源的测试环境中，是否有任何一致的测试性能的方法？“智能”计时系统是我唯一的选择吗？

我们正在针对我们现有的代码库运行 Selenium 回归测试，并且我们的 Web 应用程序中的某些屏幕使用弹出窗口进行中间步骤。

目前我们在测试中使用的命令：

...大部分时间都有效。有时测试会waitForPopUp()失败

任何人都可以提出更好，更可靠的方法吗？

此外，我们主要在 IE6 和 7 上运行这些测试。

我被告知回归测试只是整体测试的一个小样本（仅足以证明您没有通过引入更改或新模块而破坏任何东西）样本。然而， Ron Morrison 和 Grady Booch 的这篇文章让我有不同的想法：

理想的策略是一次将每个单元纳入一个单元，执行广泛的回归测试，纠正任何缺陷，然后继续下一个单元。

同一份文件还说：

一旦添加了少量单元，就会生成测试版本并进行“冒烟测试”，其中运行少量测试以获得集成产品将按预期运行的信心。目的既不是彻底测试新单元，也不是完全回归测试整个系统。

在描述冒烟测试时，作者是这样说的：

同样重要的是，烟雾测试对整个系统进行快速检查，而不仅仅是新组件。

我从未见过一起使用“广泛”和“回归测试”，也从未见过被描述为“对整个系统进行完全回归测试”的回归测试。回归测试应该尽可能简单和快速。烟雾测试的定义是我学到的回归测试。

我误解了我所教的内容吗？是不是我教错了？还是对“回归测试”有多种解释？

我希望在一个相当大的 Excel 加载项上开始自动回归测试，该加载项围绕一个由几个带有标准控件的模态用户窗体组成的 GUI。

主要问题是我研究过的大多数自动化测试工具（Rational Robot、AutomatedQA TestComplete、Network Automation Automate等）并不完全支持 VBA 控件，因此他们的测试最终会重播鼠标点击和按键操作，所以不是t 真的可以维护。理想情况下，我需要一个能够识别 VBA 表单控件的测试工具，所以我可以说“按下此按钮并等待此列表框更改”而不是“单击 (237, 58) 并等待 500 毫秒”。

我还考虑将测试自动化作为 VBA 构建到加载项中，但用户的大部分时间都花在与模式对话框交互上，该对话框会阻止 VBA 在后台运行，所以这几乎是不可能的。

我的问题 - 这里有没有人有任何使用自动化测试工具的经验

a) 识别 VBA 用户表单控件并能可靠地与它们交互

b) 支持带有条件分支和成功/失败日志的测试脚本，而不仅仅是记录和回放？

或者，有谁知道我可以解决模式对话框暂停 VBA 执行的问题，以便我可以从 VBA 中驱动加载项？

我花了一段时间在 QA 论坛上四处寻找，但在那里没有找到任何东西，所以任何帮助或线索将不胜感激。

谢谢你的帮助，

-马丁

我希望在发布 Web 应用程序之前对其进行回归测试。

简而言之，我正在寻找可以执行以下操作的东西：

1. 使用 selenium 之类的东西通过网络浏览器记录测试
2. 将这些测试加载到应用程序中
3. 进行所需的逻辑/功能更改
4. 运行测试脚本
5. 查看测试状态（通过/失败）
6. 修复损坏的测试
7. 冲洗并重复

我想要一个具有最低编码技能的 QA 人员能够完成上述工作。这是对编码人员进行自己的较低级别回归和单元测试的补充。

有任何想法吗？

在嵌入式环境中或在自动化测试的可能性非常有限的其他情况下运行回归测试有哪些好的实践和策略。

根据我的经验，许多测试必须手动执行，即测试人员需要按下一系列按钮并验证机器是否正常运行。作为开发人员，很难保证您的更改不会破坏其他内容。

如果没有适当的回归测试，在大型重构等过程中情况会变得更糟。

有没有人认识到这个问题？您是否找到了处理此类问题的良好解决方案或流程？

我正在尝试写一篇关于软件测试自动化的论文。我计划比较两种测试脚本的记录和编程方法，并讨论几个自动化框架，例如 Abbot、Selenium、Yemmy、FEST 等……在我的论文中还将简要概述软件测试技术和也许是自动化测试与软件测试的比较。

编辑：我计划在其 GUI 上测试应用程序的各个方面。所以我的测试主要是在测试世界的黑盒方面。我还没有打算写单元测试。

目前，我阅读了很多关于不同自动化框架的信息，但我可能没有时间查看所有这些。所以我计划阅读它们并使论文更加基于文学。

• 你觉得这个话题能成功吗？
• 你对这个话题还有其他想法吗？
• 你能推荐文学吗？
• 你对这个话题有什么看法？

我目前正在做很多回归测试。就像我想看一些世界上最好的回归测试代码（即开源）。所以基本上列出你认为展示回归测试的好例子的开源项目。

PS 顺便说一句，真正的回归测试是黑盒。然而，到目前为止的例子是一个很好的测试读物

我不能对代码的某些部分使用单元测试，所以我回退到回归测试。我想检查一些修改后我的程序是否以相同的方式运行。我所说的行为主要是指数据结构的状态。到目前为止，我正在将它们序列化为人类可读的文本格式，并在第一次运行时转储到一些文件中。然后在接下来的转储中，我可以比较状态是否发生了变化。如果更改来自新功能而不是错误，则更新它。

我可以使用库 (C++) 来组织所有这些。你知道任何？与转储文件一起，它将提供廉价、大规模的单元测试。

最麻烦的是序列化程序。有时我只是转储内存状态，但是当它不同时，很难进行逆向工程。所以我转向了另一种方法。现在，在比较阶段，我将内存转储读入“幻像”对象并运行专门的 diff 方法（操作符 == 具有丰富的错误报告），这有时比序列化为人类可读的文本格式更容易编写。

基本上我想重新发明轮子，所以我的问题很笼统：
你如何进行回归测试（如果你这样做的话）？
您使用任何库/工具包吗？
您是否曾经根据自己的需要实施过一个？

只是出于好奇：
你有没有想过做回归测试，但有什么事情阻止了你？