SDET：关于自动化测试的数据管理的传说

你好，QA界的朋友。准备用于手动或自动化测试的数据有时可能比测试场景本身更具挑战性，这已不是什么秘密。此外，你总是会思考如何计划并创建及管理测试数据，对吧？在这篇文章里，我们将带你一起看看几种不同的测试数据管理方法。准备好你的饮料，咱们开始吧。

用于测试的数据文件

我曾经见过一个实现，其中准备了很多JSON文件用于API请求中的有效负载发送。这只是一个存放不同有效负载的文件夹。

一些字段已经不再适用，而且这些文件的更新则依据我们想要发送的测试值进行。弄清楚正在发生的事情非常困难。支持和调试简直让人头疼。

这个设计决定并不好。我认为，建议你不要使用这种数据存储方式。我会创建一个模型，然后将数据序列化为JSON字符串。

在这种情况下，你可以更轻松地构建测试场景。而且最重要的是，你拥有动态数据。

这个例子稍微偏离了今天的主题。让我们回到正轨。那么，我们什么时候可以使用静态数据文件呢？

在我看来，静态文件在这种情况下可能很有用。当测试数据输入不依赖于预期结果时，例如：

• 文件上传功能的测试。比如确保我们支持某些文件格式，而不支持特定不被支持的文件格式。
• 进行大文件的性能测试。我们不测试功能性，我们测试性能。
• 测试与文件相关的特定功能，例如文件预览、转换或导出（例如，图像调整大小、PDF生成）。
• 测试边界情况，例如上传异常大的文件或损坏的文件，或不支持的文件格式。
• 测试受法律或合规限制的功能，例如上传特定的文档格式（例如法律文件、政府表格）。
• 测试处理不同编码或特定语言内容的文件的应用程序。
• 测试处理文件并从中提取数据的系统，例如文档解析或元数据提取（例如，从图像中提取EXIF数据）。

如果你认为这种情况适用于你，那么你应该准备好这些文件。记得不要让项目变得过于复杂。你的某些文件可能会被不同测试重复使用。另外，改动这些文件可能会影响到已有的测试。接下来我们开始讨论测试数据生成。

测试数据生成

测试数据生成非常有用，当你需要为多个案例反复生成不同数据时。这里最重要的是你想要避免大量类似的手动硬编码的数据，比如固定的FirstName。是的，有时候想名字确实会很无聊 :)

我想把它分成几块。

类似于实际数据

如果你希望你的数据看起来很真实，有一个非常强大的库叫“Bogus”。无论你用哪种语言，它都能支持，所以都没关系。

这个库中可以生成各种不同的东西类型，种类繁多。

你可以创建特定的数据对象并以后再使用它

它能为各领域提供重要帮助。

像管理财务一样：

或者一些随机日期

每次它都会生成看起来像真实信息的随机数据。比如名字、地址、邮箱、工作信息等各类个人信息。如果你还不太熟悉这个库的话，建议你试试看。

这种方法在你不在乎数据长度时很好。但是，如果你需要限制长度的话，我建议你用另一种方法。

完全随机的

在我的几乎所有项目中，我会根据数据类型来生成数据。

最重要的就是我能控制这些限制，比如生成一个包含10个字符的字符串。

或者说我想得到1到7的整数

或者想要生成一些随机布尔值（比如 true 或 false）。是的，这听起来确实有点怪，但这些值对我们来说并不重要。

你可以根据需要创建更多方法并进行重定义。最重要的是，你的随机数生成器必须在你的掌控之下，你才是老大。

API接口

API端点是非常强大的工具，如果你需要成功地准备初始状态。对于这样的事情，我建议你准备一个动作层，其中包含预定义的正确调用。记住这里你不是在测试端点的逻辑（但它应该单独进行测试），而是在使用它们来实现目标。记住你可能希望同时运行这些测试，并且注意数据量和值可能会有所变化。

酷的一点是你可以用这些接口来运行API测试或端到端测试。

进行API测试

这听起来挺合理的，你只是做一些初步的准备工作，以将系统或数据调整到某个特定状态。比如在发起支付请求之前准备订单。

如我之前所说，我建议创建一个参数最少的动作方法或函数。只有那些你预期会改变最终结果并需要测试的参数。记住，你在这里不是为了测试这个调用。建议在这个方法中检查一些基本的响应，以确保我们的初始条件已经满足。

例如，我们想在发送删除请求之前创建一个新的类别（或类型genre）。

请参阅我之前的文章之一。

SDET：API测试设计中的控制器和动作层概念介绍QA Avengers，大家好！medium.com

让我们跳到端到端测试吧

端到端测试

当人们开始使用GUI界面进行初始状态准备时，犯下的最大错误之一是。你应该记住，端到端测试层是所有测试层中最不稳定的。你应该这样构建测试金字塔，使得顶层的UI测试最少。最重要的是，你应该尽可能避免通过点击进行测试数据的准备。你应该专注于真正需要测试的部分。其余部分则尽量不要通过点击来完成。

对于一个类型来说，情况也是一样的。我们想测试类型删除逻辑在UI上的表现。首先，我们需要创建一个类型。所以，不需要通过UI进行。只需使用你已有的API调用即可。

接下来，导航到你想删除的那一页。记住，这里测试的重点不是导航功能，而是删除功能。你可以直接打开相应页面，而不需要通过导航点击。

你需要在导航前进行登录吗？不需要。试着弄清楚登录是怎么回事，并且不用输入用户名和密码，也不用点击登录按钮就能登录。你还有单独的测试专门检查登录功能。

你现在可能已经准备好了，可以开始你的场景。

• 点击删除。
• 如有需要，请确认删除。

我们现在想确认它是否真的被删了

你可能想要确认它已经从UI列表中消失。这可以理解。你也可能想要确认它已经从数据库中移除。此外，创建一个API调用动作来从数据库获取数据。对于我们来说，确保它在数据库中没有结果也是必要的。

查询测试端点

好吧，你卡壳了。实现你的目标并不需要一个终点。

试着沟通一下创建这个端点的事情，它可能已经被安排好了，也可能从未被安排过创建。

此端点可能非常简单，仅用于测试。你没有计划公开它，也不应包含任何额外的验证逻辑。如果需要实现某些目标，这种做法可能非常有用。不幸的是，有时你需要说服业务和开发团队，这种端点的需求是必要的。在这里你应该记住一个重要的原则——“让自己的应用更易于测试”。有时这很难，但最终这是我们的工作的一部分。你必须相信自己并尝试。确保你已经尽自己所能来说服对方。

操作数据库

这种方法或许可行，如果你能直接接触到数据库的话。总之，我会先看看有没有其他方法，比如通过API接口。

你应该记住要小心，因为你可能会搞砸数据库。我曾经遇到过一个情况，我将一些“配送类型”注入了一个有趣的名字叫“AirDrop”，质量保证人员（QA）们在手动测试应用程序时发现这是一个 bug。我只是说，数据库可能不像 API 调用那样有那么多保护措施。

好的。假设你没有其他选择，只能使用数据库。也许你想要在创建数据前确保某些数据存在？有时候，先检查一下是否已经有可用的数据更合逻辑。在这种情况下你可能不需要创建一个新的实体，只需要确保所有需要的值都能在API/GUI中看到。

这时你可以使用数据库访问来确保你的接口返回了你想要的数据。

让我们假设你有一个 GET /User/{id} 端点，并且没有创建另一个。你如何确保这个端点返回所有属性？

好的。我们已经讨论了测试端点。也许它还没有准备好，或者你还没有机会说服对方。这样的话，我们有两个选择：选择忽略数据验证，这存在一定的风险；或者我们可以尝试通过数据库调用来解决。

我想再次强调，处理数据库测试数据时一定要非常小心，特别是在执行任何非读操作时。

把自己的东西收拾干净

你频繁地跑测试，并生成大量的数据。到最后，你可能会积攒一大堆没用的东西。

熟悉吗？如果不是你的情况，那就太好了。

我的意思是，你应该始终考虑每次测试结束后清理的可能。这也是你在设计测试时常做的一个步骤。

再次强调，最有效的方法之一就是使用API接口。无论是真实还是测试的API，你都应该去尝试。重要的是要记住，尽管你的测试可能会失败，但你可能已经准备好了测试数据。因此，你需要设计你的测试逻辑或测试框架的逻辑，即使失败了，也能确保清理工作顺利完成。其中一种方法是利用每个测试框架内置的测试钩子。

假设你的测试数据逻辑很繁重，没有清理端点（清理结束点）。在这种情况下，你可能需要考虑一种策略来清理整个环境一段时间后。如果是一段时间，比如一个月或半年，拥有预先定义了一些数据的数据库可能很有用，重新初始化这个数据库可能很有用。

只要保持好你的功能环境干净就行了。

最后的话

最后来总结一下我们今天讨论的所有内容。

• 在不需要测试文件中的输入时，优先使用静态测试数据文件
• 当输入很重要时，使用模型驱动的方式生成测试数据
• 当需要生成大量数据时，使用数据生成方法
• 在进行API和E2E测试时，优先使用API来生成测试数据，特别是在API和E2E测试中
• 确保创建特定于测试的API端点来覆盖特定情况
• 在直接通过数据库调用来准备测试数据时要小心
• 保持环境干净
• 要灵活。分析哪种方法在具体情况下更合适

感谢您阅读本文。希望它能帮助您更好地管理测试数据，并保持测试环境的一致性。如果有您自己的经验，也欢迎分享出来。

祝你今天开心，期待在其他文章中再见到你。