如何维护测试数据？

Question

我在安全管理部门，而不是QA。我们的测试人员已经请求了一个可以完全访问QA数据库的userID，该数据库将在必要时运行脚本来清理/删除(DB2 SQL)数据--这几乎每天都是如此。我不太喜欢这个想法，因为它是另一个没有责任的userID，因为许多不同的工作人员每天都在使用它。他们希望它能简化他们的程序。

其他人如何管理他们的QA环境中的数据清理。

谢谢你的帮助，安·M。

Answer 1

它各不相同。我一直处于QA数据库完全由QA团队拥有和维护的情况。该数据库通常作为网络共享中的备份保存，并恢复到需要的测试环境中。

在我目前的情况下，数据清理是以不同的方式处理的。数据库太大，无法在可行的时间框架内恢复，并且包含太多敏感数据。相反，还有其他我无法访问的重置机制。我在这里的方法是尽可能保持我所创建的数据的干净，清理我遇到的任何坏的、畸形的或丑陋的数据，并尽可能地使我所做的工作可逆。

如果QA数据库足够小，而且QA团队运行自己的服务器是可行的(它可以在隔离子网上使用自己的内部防火墙)，让他们来运行。他们想要访问的原因是确保他们正在处理的数据保持在他们可以使用的状态--我认为每个长时间的测试人员都熟悉这个测试，这个测试需要2小时的配置时间和5分钟的测试时间(并且已经设置了一个专用的数据集，这样他们就不必做不止一次了)。

另一种可能是提高您的数据库日志记录，并给予qa团队成员他们想在他们的帐户上访问。如果您主要关心的是知道谁在什么时候运行哪个脚本，这将给您提供该信息。

测试人员确实经常会与安全进程发生冲突--我们对数据的主要关注是将其保持在满足我们需求的状态，这包括在进行测试之前进行大量备份，从而有可能损坏数据，然后在必要时恢复。(更不用说根据基线检查数据库表的自动化，并且需要能够使用未过期的密码夜间运行)。

如果你和他们一起工作，你很可能会找到一种适合你们两人使用的方法。如果初始尝试有问题，那么一旦开始，就可以随时进行调整。

Answer 2

我知道一些类似的问题，但从QA的角度来看。不幸的是，我们的管理员甚至没有要求可能的解决方案，我们听到了直接的“不”，所以我只能告诉你，我们如何尝试解决这个问题。

到目前为止，我们得到的最好的方法是采取所有必要的清理脚本，并限制对它们的访问仅限于执行(使用已编译的可执行文件，只在远程计算机上执行文件等)。然后，一个勇敢的人获得了对数据库的完全访问权，并提到了脚本，负责维护它们。其他船员在需要的时候很高兴地执行脚本，使用他存储的凭据，如果出了问题，则责怪可怜的人。

Answer 3

我们在目前的项目中解决这个问题的方法，是非常有效的，所以我们想要分享它。

在QA环境中，我们使用CSV/excel文件中的静态测试数据，这是清理、恢复和维护QA数据库的痛苦。

现在，我们完全采用了完全不同的方法，在这种方法中，我们会自动刷新数据库，从生产到每月开发，从开发到每周质量保证，这样一切都会定期保持同步。现在，每个测试都通过SQL查询动态地从QA DB获取数据，并在其上工作，因此，无论我们处理的是哪个DB实例，每个测试本身都动态地处理其数据需求。因此，在某种程度上，我们将数据依赖与测试本身分离开来。

如果测试没有在DB中找到必备的数据，那么它只是在第一步就失败了，因为“数据没有找到”，所以基本上所有的测试数据管理过程都是自动化的&与实际的测试分离，这对自动化团队和DBA来说是一个很大的解脱。