我们的团队遇到了一个关于测试用例管理的问题。
有人提议在测试用例中构建测试用例，但问题是它不会深入 1 层，它可以深入到无限层。
测试用例 A - 测试用例 B - 测试用例 C
问题在于，测试用例 B 和 C 必须是静态数据。我们不能使它成为动态数据。由于测试用例 C 不能有动态数据，我们需要构建测试用例 D+ 来容纳其他测试用例的自定义数据。
例如：
测试用例 C 正在登录 Facebook。它有 2 个用于用户名和密码的自定义数据字段
但是由于我们无法从原始测试用例 (A) 中定义那些自定义数据字段。我们必须使数据静态化，因此您不是以任何人的身份登录，而是以特定的人身份登录。
因此，假设测试用例 D 是进入 Facebook 并将您的性别资料从 M 更新为 F。
好吧，由于我们以特定人身份登录，因此我们必须以男性身份登录。
现在，让我们假设这个人有 0 张照片。但是 User2 有大量的照片用于测试。
所以现在我们必须构建一个与测试用例 C 相同的测试用例，但使用不同的登录凭据。
所以我们现在有 2 个测试用例在做完全相同的事情，但数据不同。
我不同意这种方法，但是网上告诉我这是构建测试用例的最佳方法之一。
在我看来，我们应该将测试步骤限制在实际的测试用例中，以及我们用动态和通用信息来满足的任何先决条件。
因此，我们不是说测试用例 A 是测试用例 B 的先决条件，而是说测试用例 B 有一个先决条件或“以 BLAH 身份登录 Facebook”。
由于我们没有测试“登录”功能，我们不需要执行额外的或超出普通测试步骤。
因为我们没有假设我们的测试是愚蠢的并且不知道如何使用应用程序，所以我们可以是通用的。
如果测试人员发现通用的前提条件，请继续详细说明。
别人的想法是什么。测试用例中的测试用例是一个聪明的主意吗？我们的问题是我们的应用程序是巨大的和超级动态的。就像疯狂的动态一样，您在屏幕上看到的任何内容都可以更改替换或完全删除。
如果我们沿着这条路走下去，我预计我们的 1000 个测试用例很容易变成 2000 个测试用例。
想法？我想太多了吗？