我们正在尝试找出在我们的测试计划中编写测试的最佳方式。具体来说，当编写一个供任何人（包括 QA 人员）使用的测试时，测试中的步骤应该非常具体还是更广泛，让测试人员在如何完成任务上有更多的余地。作为一个非常简单的示例，如果您正在测试在文字处理文档中打开文档，那么测试应该是：
或者
现在我意识到一个答案可能是“这取决于您要测试的内容”，但我试图在这里回答一个更广泛的问题：如果测试步骤过于具体，我们是否会冒险 a) 进行测试过程费力和乏味，更重要的是 b) 我们是否有错过某些东西的风险，因为我们写下了实现目标的过于具体的路径。或者，如果我们扩大范围，我们是否过于依赖测试人员当时的突发奇想而失去了对客户/客户更常见的路径的关键测试？
我的第一个问题是 - 为什么您的 QA 部门不编写测试计划？通常，软件开发人员向 QA 提供软件应该如何工作的功能规范，然后 QA 基于此创建测试计划。
话虽如此，我建议您对这些步骤非常具体，因为您正在详细说明事情应该如何工作。然后，测试人员的工作是确保您的具体步骤获得预期的结果，偏离计划并尝试破坏事情也是他们的工作。
如果有多种方法可以实现目标，则需要描述实现目标的每条路径。
我不是测试人员，但我认为记录测试必须采用的“UI 路线”以避免任何混淆至关重要。
我已经解决了无数无法重现的缺陷，因为我没有从与测试人员相同的 UI 路径访问该函数。例如右键菜单与工具栏或可以从各种对话框等执行的功能等。
如果他们不负责编写测试，听起来你的 QA 人员真的是 QC（质量控制）。如果他们确实负责编写测试，那么您的测试会有所帮助，但明确的规范将是他们自己编写测试的更好来源。更好的做法是将它们作为规范审查过程的一部分，以便他们可以询问允许他们编写测试的详细信息。
如果您确实处于为其他人编写测试的位置，则有一些注意事项。如果出现以下情况，您将需要痛苦的细节：
如果这些不是真的，你可以避免一些细节。但是，它仍然取决于:)
话虽如此，您所写的并不是通常认为的“测试计划”。测试计划描述了将执行哪些类型的测试（功能性、回归、安全性等）、要测试的特性，甚至可能要编写哪些测试、谁将进行测试、何时进行测试组计划和其他计划类型的活动。
您上面描述的只是一组测试。
让我们区分测试计划和测试套件:)
测试套件本身就是一组测试
测试计划是 [一部分] 测试套件 + 可用资源（人员、硬件、时间……）。
在您的测试文档中描述两种变体（详细和“粗略”）是可以的，只需将详细和“粗略”测试放在不同的文档中并优先考虑这些文档。
然后，当您有足够的时间对产品进行全面测试时，您将获取所有文件，例如 A 类文件，并根据这些文件测试产品。如果您没有时间，但需要快速得出关于质量的结论，您可以获取 B 类文件并通过那里描述的检查。
好的一面：您可以选择如何测试产品
坏的一面：你需要“重复”的文件
首先是功能测试。使用包含 UI 路线的详细步骤进行测试，因为到目的地的路线可能不止一条。测试所有路线。后者听起来更像是可用性测试。它也应该由您的测试人员完成，但也应该由外部人员完成。
对待你的测试员就像他们不了解系统或计算机一般有优点和缺点。
如果您详细说明事情（例如“从文件菜单中，选择'打开'...”），那么好处是您可以使用不熟悉您的系统的承包商。但是这样写需要更长的时间
如果您跳过很多细节（例如“打开文档文件...”），那么使用您的测试计划的人更有可能陷入困境，而不是打断您进行澄清。但是写起来要快得多
如果您使用轻快的版本，如果您最终只是花费额外的时间向质量保证人员解释系统，那么认为它更快可能是一种错误的经济
我有一篇文章更深入地探讨了这个主题：编写系统测试计划
在本文中，我赞成更详细的方法。但我最近一直在这两种方法之间开发一个“中间点”（称为FEATURE 测试计划），但我还没有成熟到可以分享的地步
-- LM
当有人发现问题时，想要精确、详细、重复的步骤是完全可以的。但是，如果您以这种方式编写测试计划，您将面临以下问题的风险：
1)不注意的失明——我看到人们执行详细的程序测试脚本，尽职尽责地走过并一丝不苟地记录每一步，完全错过了他们面前的明显错误。因为它“不在剧本中”。他们的注意力如此集中在所有那些挑剔的测试步骤上，以至于他们根本看不到他们面前的问题。
2) 你会错过所有那些离你非常详细、非常具体的路径仅一步之遥的错误。当客户拿到你的产品时，他们不会遵循详细的测试计划。他们将以各种方式浏览您的应用程序。他们会改变主意。它们的名称将比您认为的可能或可能的更长或更短。他们将完成交易并放弃它。他们会流浪。他们不会坚持一条路。而且每次有人重复测试时，他们都会再次错过那些错误。
3）您将花费非常长的时间来编写“任何人都可以遵循”的测试脚本。相信我，我花了数年时间试图完善这一点，而这在人类看来是不可能的。更糟糕的是，你浪费在做这件事上的时间可能会以其他方式花在更有利可图的地方，所以你的产品会变得更糟。
4) 你最终会得到大量的重复，如果不阅读整个内容，你将很难说出你的测试的重点。快速浏览测试以查看您可能错过的用例并不容易。
保持您的测试计划广泛，并让进行测试的人行使他们的判断力。如果您有关于必须测试的特定使用场景的信息，或者关于目标用户组希望如何操作的信息，那么将这些信息连同测试计划一起提供给测试人员 - 也许以用户角色的形式，也许只是在用例的形式。如果您需要勾选特定事项，请考虑使用清单。（有关更多信息，请参阅 Cem Kaner 的精彩演示 www.kaner.com/pdfs/ValueOfChecklists.pdf）。
Alternatively, write your test plans as short exploratory charters. You could, for example, give guidance such as: "Callcentre users will be using workstations with no mouse attached. Explore the process of raising a ticket on behalf of a customer, ensuring that it's possible to complete all activities using keyboard shortcuts only." This is far more likely to result in your testers finding defects than saying "Tab into field 1. Enter "Complaint about line quality". Tab into field 2. Select "Phone call" from the dropdown menu. Tab into .... field 68."