在测试自动化拆卸过程中，是否应删除工具生成的测试数据？

#1 楼

我同意塔伦（Tarun），也正是出于您所说的原因。将所有测试数据保留在适当的位置可以使您有效地分析和调试测试结果。

如果您希望为每次测试执行提供一个干净的测试环境，最好在创建自己的测试之前立即执行“拆卸”任务当前运行的测试数据。

#2 楼

只要您100％确保在正确设置之前始终清理所有测试，并且始终可以进行清理（例如，它的设置不会过时），就可以不进行拆卸。如果您是唯一的测试人员和使用环境的唯一人员-或者，如果您拥有良好的“清理环境并还原为默认值”脚本/功能，所有测试人员都可以在测试前使用该脚本/功能，或者该线束自动运行，那么我认为可以正常工作。

但是，大多数软件在出现故障后仍无法保持原始故障状态，并且错误中的所有数据仍保持其原始形式时，不希望停下来停坐。大多数软件项目都需要有效地使用测试资源，这意味着需要清理并继续进行下一个测试。要发生可调试的故障，这意味着您需要继续保存状态。复制错误文件和配置文件，备份数据库，将CPU / RAM等上的计算机信息转储到日志文件中，依此类推，然后将它们全部放在一个位置，以便测试人员轻松地调查问题以查找所有内容她需要。由于大多数测试人员都想在测试结束前保存状态，因此避免在拆卸期间进行全面清理并没有很多优势。*

此外，如果您在拆卸期间未进行清理， ，当更多配置选项可用时，您将需要维护旧测试，以便它们正确设置这些新选项。通过使用总是在测试之前调用的单个功能在运行测试之前将机器设置为“默认状态”，可以避免这种情况，因此，您只需更新一个功能即可-但是如果您选择不在测试后进行清理，则可以维护测试设置是您可能要计划的事情。如果您没有确保测试设置保持可维护性的过程（并且这种计划的可行性因公司而异），那么清理是个好主意。

我知道在我的公司中，我不能依靠其他测试开发人员在开始测试之前清理所有内容-主要是因为我的公司计划在将来对质量检查进行重大更改，而且我不确定其他使用我的安全带的测试人员将很熟练，或者对系统有足够的了解，可以想到他们需要清理的所有东西。我没有制定政策，我只能尝试和影响它。我可以让其他测试开发人员因其不良习惯而受苦，但是我知道这可能会在政治上使我反弹。因此，我总是尽我最大的能力进行清理。

在某些情况下，故障会严重破坏事物，导致清理代码无法运行。在这种情况下，我个人希望能够报告导致问题的实际测试失败，而不是报告清除失败，而不是将其报告为下一个要运行的测试设置失败。如果没有其他要求，向开发人员和管理人员展示和解释为一个失败的测试而不是两个失败的测试会更容易。费用很高，并且在设置和拆卸期间都非常耗时-在设置期间进行清理绝对更为重要。也许您没有时间开发“保存一切”基础架构，所以您确实希望事情停下来休息，而不是继续运行。也许您认为在产品上的测试人员在测试前没有清理的情况如此罕见，以至于您宁愿节省清理工作所需的开发时间，并相信这种质量保证文化不会随着公司的发展而改变。

#3 楼

我不相信“清除”是指“删除”。这只是意味着您必须确保一次运行不会溢出到第二次运行中。您可能需要考虑在擦除数据库之前转储数据库，或者只是为每次运行创建一个新数据库。

，只要有清楚的隔离墙，并且两次在相同输入上运行可以产生相同的集合数据，应该没有问题。

#4 楼

如果您在自己的环境中运行自动化测试，则可以通过备份或快照来解决此问题，如果测试失败，则可以收集数据错误。当然，您还需要复制任何日志文件或任何其他集合，我注意到这始终被忽略，有时似乎是数据错误的东西完全是另外一回事，然后我必须仔细研究日志文件以查找我想要的一个-如果尚未被覆盖。

有时候我在测试环境中运行自动化测试，但是我们对测试进行了结构化，因此我们不需要清除数据-在某些情况下这比测试所需的难度更大。由于我们需要生产数据，并且在Test中安装非常耗时，并且我们不断运行测试，因此我们进行了解决。您的里程可能会有所不同。

对我来说，clear的概念可以追溯到我想在测试之前和之后进行数据库比较并且知道我希望事物处于什么状态时，这就是方法确保数据正确并且测试通过。因此，最好在可能的时候清除它并为您提供价值，但是您应该仔细定义清除的含义。

#5 楼

您希望测试是可重复的；如果发现错误，则其他人可能希望通过在相同条件下运行相同测试来重现该错误。

总是有很多情况下，tearDown方法会失败或无法运行，例如当有人手工杀死一个测试时，我不想依靠tearDown方法清理所有内容。相反，我仅使用tearDown方法释放后续测试可能需要的任何资源。

如果我的测试需要在一组特定条件下运行，我将编写设置方法来建立这些条件。如果确定条件太繁琐，那么我的设置方法可能只是检查条件是否正确，如果出现问题，则发出错误信号。

#6 楼

要回答您的问题：是，不是。

为了进行错误测试，我们使用2个不同的数据库。通常，我从一个“干净”的数据库（通常是“ demo”数据库）开始，但是有时我使用的开发数据库中充满了各种压力测试类型数据。对此没有一般性规则，开发人员在编码时始终使用压力测试数据库。

在安装测试期间，约有98％的测试是使用压力测试类型数据完成的。这是因为大多数客户将其数据库转换为新版本。

#7 楼

从已知数据状态开始，这是测试自动化中的一成不变的法则。永远不要依靠拆卸或其他测试的结果。在测试运行之前，请清除状态并建立基线数据。这是进行可靠测试的唯一方法，并且具有将复杂数据作为已知的第一响应者以已知状态进行调试的优点。