我们的团队遇到了有关测试用例管理的问题。
有人建议在测试用例中构建测试用例，但问题是它不会深入1层，它可以深入了解层。
测试案例A. - 测试案例B. - 测试案例C
这个问题是，测试用例B和C必须是静态数据。我们无法使其成为动态数据。由于测试用例C不能拥有动态数据，我们需要构建测试用例D +以容纳其他测试用例的自定义数据。
例如：
测试案例C正在登录脸书。它有2个用户名和密码的自定义数据字段
但是，因为我们无法从原始测试用例（A）中定义这些自定义数据字段。我们必须使数据保持静态，因此您不是以谁登录，而是以特定的人身份登录。
让我们说测试案例D将进入Facebook并将您的性别档案从M更新为F.
好吧，因为我们以特定的人身份登录，所以我们必须以男性身份登录。
现在，我们假设这个人有0张照片。但User2有大量的照片供测试。
所以现在我们必须构建一个相同的测试用例来测试用例C，但是使用不同的登录凭据。
所以我们现在有2个测试用例完全相同，但数据不同。
我不同意这种方法，但是在线告诉我这是构建测试用例的最佳方法之一。
在我看来，我们应该将测试步骤限制在实际的测试用例，以及任何我们充满动态和通用信息的前提条件。
因此，而不是测试案例A是测试案例B的先决条件 我们说，测试案例B有一个先决条件或者＆＃34;以BLAH＆＃34;登录Facebook。
由于我们没有测试该功能＆＃34;登录＆＃34;我们不需要执行额外或不同寻常的测试步骤。
由于我们没有假设我们的测试是愚蠢的，并且不知道如何使用该应用程序，我们可以是通用的。
如果测试人员发现通用的先决条件，请继续详细说明。
其他人的想法是什么。测试用例中的测试用例是一个明智的想法吗？我们的问题是我们的应用程序是巨大的，超级动态。就像疯狂的动态，你在屏幕上看到的，可以更换或完全删除。
如果我们沿着这条路走下去，我认为我们的1000个测试用例很容易变成2000个测试用例。
思考？我在想这个吗？
答案 0 :(得分：4)
编写测试用例是一门艺术。当您编写测试用例时，它应该是重点，并且组织良好。
它应该包括必要的信息。如果开发人员无法理解如何解决错误，则测试用例不仅适用于测试人员。
我真的建议保持简洁，以使其他人也可以理解。
答案 1 :(得分：0)
与测试（手动或自动）相同，测试用例应尽可能隔离和独立。 原因很简单：链式测试不太稳定和透明。
可能可以使测试用例链接成为可能，因此你可以将链接test-case1作为test-case2的前提条件，使其不必在其他方面描述前置条件。 另一方面，它使测试用例结构不那么清晰且困难得多。 当您需要重构或重新组织它们时，这会产生问题，转移到其他自定义测试运行\项目或只是将它们拆分为几个独立的测试套件。
我认为，除了通过自定义结构等技术功能之外，通过样式指南和编写测试文档的原则更好地解决了这个问题。
我更喜欢编写清晰且最小化的测试用例，因此每个团队成员只能使用测试用例名称执行它们，而无需逐个打开它们。
IMHO。
答案 2 :(得分：-1)
测试案例的编写因人而异，测试案例不仅适用于正在测试的人，如果有新人加入公司，他/她应该能够理解测试案例.TC应该简单易懂每个人都应该涵盖所有基本场景和端到端场景。
根据我的担心，如果测试用例简单易懂，这将使每个人都能轻松完成并执行相同的测试，这将是容易和简单的。