在编写手动测试用例和脚本时，在记录步骤时有多少细节？

#1 楼

好问题。正如其他人回答的那样，细节的数量将取决于您的特定上下文。当客户问我这个问题时，我开始绘制一个简单的2 X 2矩阵，如下所示：

#2 楼

这是个好问题。我希望有一个快速而准确的答案，但是您需要使用测试仪的功能来校准详细程度。我认为您应该始终描述测试用例的意图，即要测试的需求。对于有更多经验的人，您可以将其余的精力留给测试人员。对于经验较少的人，您可能需要说明清楚，并伴有维护费用。比测试用例的意图更快。例如，一个人的名字最长不能超过20个字符，这很重要，但是导航到相关对话框的方式会随着时间而改变。

好坏出于监管原因，组织可能被迫使用详细的测试说明。

#3 楼

除了给出的答案外，还取决于团队的当前成员以及您将来打算雇用的成员类型。当前的测试人员将非常了解与系统的基本交互，因此应为新员工提供适当的系统培训，因此，每个步骤都无需在TC中记录。

它记录如此详细的声音听起来像是一个好主意，以使系统未知的人可以来进行测试。但是您的应用程序真的会受到未知者的测试吗？测试人员花太多时间在文档上的时间也浪费了。

对于TC的功能和要求（无论是否有文档记录），我更喜欢TC说“ 1.验证在给定条件下，应用程序将以某种方式运行”，假设测试人员知道如何创建场景。不是规则，而是强烈的偏好。根据经验和判断，如果需要，可以添加其他步骤。
底线：文档不应比您的应用程序复杂，也不应比规范冗长。

#4 楼

不管是好是坏，几年前我被教写一个测试用例，就像一个测试员正走在街上执行它一样。因此，我的测试用例往往有很多细节。但是，我已经执行了其他人的测试用例，因此这些细节非常根深蒂固，以至于我不得不花一些时间来整理出有意义的部分并坚持下去。这非常令人沮丧，尤其是在到期日期的压力下。

（我将只讲一个测试用例的步骤，要理解的是，一个测试用例和脚本不仅仅是这些步骤。）

要回答您的问题，有效的测试用例步骤应具有以下信息，但应尽可能简洁：
-动作/说明需要具有要导航到的URL，功能路径和所需的动作。
-输入数据需要具有用于输入的示例（或真实）数据
-预期结果需要具有输出结果以及屏幕布局中的任何变化
-实际结果-与实际相比达到预期结果
-通过/未通过日期
-评论或注释-很少用于我；这是我输入已知错误信息的地方，或者为什么要使用x而不是y的逻辑（换句话说，该程序在这一步上的设计不是很直观，应予以澄清）。在另一篇文章中，由于我个人倾向于对步骤（或输入或预期结果）背后的逻辑发表简短评论，我损失了几分。也许我使用的程序不是很直观，需要在这里和那里进行解释。不能确定，但​​是测试案例的“目标受众”是我正在写的对象，我不希望“目标受众”掌握的信息很小，这将在执行特定步骤时产生很大的影响。您可以说是我的个人喜好。

#5 楼

这些年来，我尝试了两种方式，但每次都仍然有疑问。系统和良好的测试技能，您可以轻松地仅提供新闻标题。

#6 楼

如果您需要确定每个选项/路径都经过测试（单击按钮，使用热键，选择并输入），然后您想详细说明每个步骤。不幸的是，有时候有时候这是乏味的细节。是键盘手，因此错过了鼠标单击错误。如果我在测试计划中写了“ tab to this button＆”（我在测试计划中写了“ tab”），我将其范围缩小了很多，那么下一个要执行该计划的人也会错过鼠标单击错误。有时，鼓励其他测试人员在计划中不太相关的步骤中导航时“做自己的事”会更好。

#7 楼

您需要足够的详细信息，以确保可以实际测试您测试的所有要求。这就是应该停止的地方。用爱因斯坦的话来说，“尽可能简单，但不要简单”。您越具体，就越有可能过于专注于您错过了另一部分的需求的一部分。如果最近修复了一个错误，即使要求没有更改，您仍将需要对此进行一些其他测试，根据第一条规则，您将不需要再施加任何限制。我将采取步骤重现该错误，并确保不会重现该错误。将错误发布给公众可能会令人尴尬，但不如您说已修复错误且实际上还存在的错误要糟糕得多。理想主义者的观点。它不考虑常识和直觉之类的东西。

tl; dr每个测试用例都应具有足够的信息以显示是否满足要求（请参考文档中的要求）或存在错误已修复（请参考文档中的错误），但仅此而已。

#8 楼

正如大多数其他帖子所指出的那样，手动测试计划中包含的详细信息的数量取决于测试人员的测试经验和能力。在最近的组织变更之前，我部门内的QA编写的所有测试也都由同一部门内的其他QA执行。

这意味着我们可以假设测试人员不需要测试编写者来绘制每个导航步骤并像“用户指南”一样编写测试。但是，随着最近组织向SCRUM开发的转变，其目标是SCRUM团队可以承担组织内所有产品的缺陷，并且完成变更请求的每项任务都变成了“团队目标”，我们经常发现自己处于没有特定测试产品的QA正在进行测试。另外，我们经常让开发人员执行测试以帮助实现我们的“团队目标”，因为开发人员在我的团队中的质量保证人数比QA高3：1。如果某人不熟悉测试过程或要测试的产品而试图进行测试，则会发现自己参与其中，以至于最好自己进行测试。现在，我将在测试步骤以及任何先决条件（包括数据设置，用于数据验证的脚本等）中提供更多详细信息。在测试编写过程中进行的额外工作可以节省数小时的时间。

#9 楼

以我的经验，最好有详细的步骤。这使不了解产品的测试人员只需执行预先编写的测试用例并填写结果即可运行测试用例。如果您要外包执行测试用例，这也很有用。

#10 楼

当使用头文件+步骤约定编写方案时，我通常将前提条件，参与者，涉及的系统组件放在头文件+简短摘要中；对于更复杂的方案，则是在该特定方案中使用的实体的“字典”。 >
在编写常规步骤时，我尝试遵循每个步骤的简单模式：

动作：


一个句子<实现目标/做到某事物>通过（微观）步骤<列表>

结果：验证结果的结果>进入细节，从而直观地识别方案逻辑或测试范围中的差距。

#11 楼

TL; DR：我的小组在编写仅指定高级操作的测试方面取得了成功，同时维护了一个单独的文档，其中包含许多高级操作的更详细说明。


在我公司，我们最近有两个项目采用了不同的方法来进行详细的测试。像这样的事情：


单击“确定”按钮
选择小部件X。将其拖到窗格Y中。（在这种情况下，有多种方法可以将小部件添加到窗格中但海上测试人员几乎总是以相同的方式编写它。）
对话框关闭。 （通常，对话框关闭功能不是测试的实际主题，如果对话框没有关闭，以后的事情将会失败。）这种方法。我们不断收到关于“缺少单击OK的指令”的测试的空运行反馈，以及与测试内容无关的其他小问题，但由于它们与其余部分的详细程度不匹配，因此引起了混乱测试。由于有太多的细节，通常很难分辨出实际测试的内容。而且，即使设计的一点细节都改变了吗？很多返工。

项目2采取了更高层次的方法，但有所不同。测试本身是非常高的水平。


将小部件X添加到列表Y。
创建一个新小部件。
配置小部件X使其具有翅膀和呼吸。

不同之处在于，有一个单独的文档为许多这些高级操作提供了详细的说明。各个测试可以专注于要测试的特定功能，如果测试人员不知道如何执行操作，则可以参考其他文档。这样可以更轻松地阅读测试并了解要测试的内容，并且由于设计细节位于更少的位置而使更新变得更加容易。 ，说明将更加详细，并包括预期的结果。但是大多数时候，只有一些可用的小部件才被设置为在协议的后面测试其他内容，因此，每次创建一个测试所需要的测试每次创建一个小部件都无法正常工作，这并没有增加价值。

#12 楼

好问题。根据我以前的经验，我想说的是，每当指示您编写用于手动测试的测试用例时，如果要在项目规划和设计时编写测试用例，则首先需要准备一些文档。如果获得项目需求文档（PRD）和项目工作流程，我会感觉更好。如果我有这些文档，则可以继续编写测试用例。客户与质量检查分析师之间的交流也非常重要。 QA Analyst与客户之间的密切沟通对于了解客户需求会更有帮助。

#13 楼

我认为有经验的用户应该编写不太详细的测试脚本。这使他们可以更快地编写更多的测试，从而获得更高的测试覆盖率。我还认为，有经验的测试人员编写和执行自己的脚本是件好事。在此过程中，他们可以找出差距。将脚本传递给不同的测试人员会减慢该过程的速度，因为如果他们只是遵循预先编写的脚本而看不到大图，那么他们将花费大量时间询问有关脚本本身的问题。