#1 楼
4500。这是我的估计。有些人说6750，另一些人说500，但每个案例不会超过一百万步。
开玩笑，没有固定数目，也没有人可以设置限制。无论如何，这都是一个非常模糊的例子。
例如，您可以通过以下方式编写测试用例：
登录到应用程序
将2个项目添加到购物车
确认购物车中有2个商品
，或这样，
打开计算机
打开浏览器
导航到应用程序网址
单击用户名字段
输入用户名
单击密码字段
输入密码
单击登录按钮
将2项添加到购物车
确认2项是在购物车中
它们是相同的，但是第一个更加清晰（并且具有BDD样式）。
另外，请注意，每个步骤都可以看作是一个测试（1 。测试是否可以打开计算机，2.测试是否可以打开浏览器，3.测试导航是否正常...）
评论
荒谬！显然正确的数字是6739！ +1
–迈克尔·杜兰特（Michael Durrant）
20年8月27日在10:46
#2 楼
使用允许的词表明存在或应该有一个固定的规则。我认为您正在寻找的可能是一个准则。准则将取决于诸如上下文，领域复杂性，风险，执行测试用例的人员的技能水平等因素。
我建议您以最多10个步骤开始。一旦掌握了它，您可能会挑战自己，也许是测试用例：
是详尽的还是冗长的
正在测试多个功能并且可以拆分
这么长，因为应用程序的可测试性很差
很长，以至于很难理解它真正在检查什么
......
现在根据情况决定是否包含很多步骤的情况。一段时间后，重新评估您的指南，并决定挑战自己的新门槛。
#3 楼
测试步骤的数量无关紧要，但是无关紧要的事情却可以使测试用例变得高效：单个测试目标：每个测试都应专注于测试单个需求，该需求可以
清晰度：测试用例中的每个步骤都应该足够清楚，以便团队中的任何人都可以遵循。
没有重复的步骤：在步骤或验证方面，测试用例之间不应有任何冗余。
子测试用例：如果有一些通用步骤/ navigation，然后应在单独的子测试用例中将其抽象出来，以便在主要测试用例中称为（超链接）。
单次通过/失败原因：每个测试都应该通过/甚至出于单一原因而失败，这是测试用例的主要目标。
假设，前提条件和后置条件：测试用例应包括适用于测试的所有假设，以及执行测试之前必须满足的所有先决条件。
提供测试数据：识别和准备测试数据有时会花费大部分时间进行测试。如果可能，请提供测试测试用例描述中或特定测试用例步骤中用于测试用例的数据。
可跟踪性：如果可能，通过唯一的方式将测试用例链接到适当的用户案例或需求ids。
标记功能区域：在与功能模块相关的测试用例上附加关键字，以便更轻松地搜索相关的测试用例。
自动化映射：如果有与手动测试用例相关的自动化，则将其与唯一的ID链接以实现将来的可追溯性。
我亲自遇到了许多由他人编写的冗长的测试用例，尝试涵盖太多内容，并且可能由于多种原因而失败，这很令人困惑。
简而言之，测试应该小而切入点，集中于测试单个需求。
评论
测试用例失败的“原因”可能被解释为代码中的错误，并且您无法编写测试以使每个可能的唯一错误都具有匹配的测试用例。因此，每个失败的测试在代码中都有许多原因。我怀疑您的意思是每个测试用例都应检查结果的一个属性。例如。输出大小小于4 kB。
– MSalters
20年8月28日在9:48
我认为，测试应高度集中于仅测试一件事。如果测试由于各种原因而失败，我会怀疑它的范围太广（测试设计问题），并且更有可能也会与其他测试“重叠”。
– Vishal Aggarwal
20-09-3在0:29
#4 楼
编写测试步骤来记录测试或重现该错误的路径。没有这样的建议，即测试步骤不能超过6。测试步骤的数量根据测试用例和测试方案的不同而不同。如果场景复杂且难以理解，则将需要许多测试步骤。测试步骤应该简单而具体，以便其他测试人员/开发人员可以测试该测试用例。它不应该局限于数字。为测试人员和开发人员都编写了步骤。它可以帮助开发人员重现问题，并帮助测试人员重新测试问题。
编写清晰而简单的测试步骤，可以减少以最快的方式查找，解决和重新测试问题的时间。 。
#5 楼
测试用例是一个文档-一种传达想法的方法。交流中的文本限制仅在特定情况下才会发生，例如报纸的物理限制或文章中的单词数量过多。在软件测试中没有这种限制。任何文档的重要方面是要很好地传达其信息。对于测试领域，尤其是建议我研究Cem Kaner在Bug Advocacy方面的工作。
#6 楼
没有为特定测试用例分配步骤的硬性规定。我相信这取决于产品功能以及工程师进行质量检查验证的方法。举一个例子：
我们要在网站上测试结帐功能
一种方法是：
Create a single test case for verifying 'Purchase of a product'from the website and,
that test case would end up resulting in around 10-15 steps
但是，另一种方法是通过将测试步骤分为多个测试用例（每个测试用例现在将包含更少的步骤）来分离整个购买流程：
Testcase1: Verify Login into application
Testcase2: Verify category selection and search for the product you want to buy
Testcase3: Verify product view and browse the details
Testcase4: Verify product quantity, color, or any other attributes that need to be selected
Testcase5: Verify 'Add to cart' operation
Testcase6: Verify 'User details' operation
Testcase7: Verify 'Checkout' operation
Testcase8: Verify Payment process
Testcase9: Verify the success page once the order placed successfully
Testcase10: Verify Email/Messages confirmation sent to the customer
有些人会喜欢第一种方法，因为可以在单个测试用例下测试整个流程，而有些人可能更喜欢后者，因为它可以更好地了解流程中的通过/失败区域。
进一步详细说明，可以说我们的验证在以下步骤中失败：用户无法仅对“ Z”类产品执行“添加到购物车”操作，而对其他类别也可以正常使用。
前一种方法：将单个测试用例标记为失败，并带有特定的类别注释，因此，假定整个C
，但是，使用后一种方法，只有Testcase5将被标记为失败，并且QA工程师可以轻松地识别和跟踪结帐流程中哪些子区域工作正常或不正常。 >
如今，大多数软件测试服务公司都采用后一种方法进行手动测试服务。
除了测试用例步骤外，质量测试用例还应定义一些其他参数，例如前提条件，优先级，预期结果，产品区域，类型：烟雾/环境卫生/法规变更等详细信息，以便更好地了解各种情况。
评论
测试用例是一个文档-一种传达想法的方法。交流中的文字限制仅在特定情况下才会发生，例如报纸的实际限制或文章中的单词数量。在软件测试中，没有这样的约束。任何文档的重要方面是要很好地传达其信息。对于测试领域，尤其是建议我研究Cem Kaner在Bug Advocacy方面的工作。+1 @JoãoFarias此外，步骤的数量确实很重要……但这是您组织案件的方式的副作用。专注于质量测试用例，这将使步骤数保持较低。例如，您将不断地重构代码，以避免因案例而需要过多步骤的情况下反模式的建立
测量效果，但改变源是我一直在玩的一种表情。