我们正在尝试找出在测试计划中编写测试的最佳方法。具体而言，在编写供质量检查人员(包括QA人员)使用的测试时，测试步骤应非常具体还是应更广泛，以使测试人员在完成任务方面有更多的余地。作为一个非常简单的示例，如果要测试在文字处理文档中打开文档，则测试应读取：

• 使用鼠标打开文件菜单
• 在文件菜单中选择"打开文件..."
• 在出现的打开文件对话框中，导航到x并双击名为y的文档。

或者

• 弹出文件打开对话框
• 打开文件y

现在我意识到一个答案可能是"这取决于我们要测试的内容"，但是我想在这里回答一个更广泛的问题：如果测试步骤过于具体，我们会冒着以下风险：a)进行测试过程b)我们是否冒着遗漏某些东西的风险，因为我们写下了实现目标的过于具体的路径？或者，如果我们将其广泛推广，那么我们当时是否过于依赖测试人员的异想天开，而失去了对客户/客户更普遍的路径的关键测试？

解决方案

回答

我不是测试人员，但我认为至关重要的是，记录测试必须采取的" UI路线"，以免造成任何混乱。

我已经处理了无数缺陷，这些缺陷之所以无法重现，仅仅是因为我没有从与测试人员相同的UI路径访问函数。例如右键菜单与工具栏或者可以从各种对话框等执行的功能等。

回答

我的第一个问题是质量检查部门为什么不编写测试计划？通常，软件开发人员会向质量检查人员提供有关软件应如何工作的功能说明，然后质量检查人员将根据此功能创建测试计划。

话虽如此，我建议我们对步骤非常具体，因为我们正在详细说明事情的工作方式。然后，测试人员的工作就是确保特定步骤能够获得理想的结果，而偏离计划并试图打破常规也是他们的工作。

如果有多种方法可以实现目标，则需要描述实现目标的每条路径。

回答

听起来，如果QA员工不负责编写测试，则他们实际上就是QC(质量控制)。如果他们实际上负责编写测试，则测试会有所帮助，但明确的规范将是他们自己编写测试的更好来源。更好的办法是将它们作为规格审查过程的一部分，以便他们可以要求提供允许他们编写测试的详细信息。

如果我们确实处于为其他人编写测试的位置，则需要考虑一些因素。如果出现以下情况，我们将需要痛苦的细节程度：

• 进行测试的人无法来问你问题
• 测试人员对产品不熟悉

如果这些细节不正确，我们可以避免一些细节。但是，它仍然取决于:)

综上所述，我们所写的不是通常被认为是"测试计划"的内容。测试计划描述了将执行哪些类型的测试(功能，回归，安全性等)，要测试的功能，甚至要编写的测试，将由谁进行测试，何时进行测试的组。预定的和其他计划类型的活动。

我们上面所描述的只是一组测试。

回答

让我们区分测试计划和测试套件:)

测试套件本身就是一组测试

测试计划是[测试套件]的一部分+可用资源(人员，硬件，时间等)。

可以在测试文档中同时描述两种变体(详细和"粗糙")，只需将详细和"粗糙"的测试放在不同的文档中，并优先考虑这些文档。

然后，当我们有足够的时间完全测试产品时，可以获取A类的所有文档，并根据这些文档测试产品。如果我们没有时间，但需要快速得出质量结论，则可以获取B类文件并通过那里描述的检查。

好的一面：我们可以选择如何测试产品

不利的一面：我们需要"重复"的文档

回答

首先是功能测试。使用包含UI路由的详细步骤进行测试，因为到目的地的路由可能多于一条。测试所有路线。后者听起来更像是可用性测试。也应该这样做，但不仅要由测试人员来完成，而且还应由外部人员来完成。

回答

就像对待测试人员一样，通常对系统或者计算机一无所知，这是有利有弊。

如果我们将细节详细说明(例如，"从文件菜单中选择'打开'...")，则好处是我们可以使用熟悉系统的承包商。但是这样写要花更长的时间

如果我们跳过了很多细节(例如"打开文档文件...")，那么使用测试计划的人就很可能陷入困境，而打扰我们进行澄清。但是写起来要快得多

如果我们进行的是轻快的版本，则想想它的速度更快可能是一种错误的经济，如果最终我们只是花费额外的时间向质量检查人员说明该系统

我有一篇文章，我将对该主题进行更深入的研究：编写系统测试计划

在本文中，我赞成使用更详细的方法。但是最近我一直在这两种方法之间开发一个"中间点"(称为功能测试计划)，但是我还没有达到足够成熟的程度来共享

-LM

回答

当有人发现问题时，需要精确，详细，再现的步骤是完全可以的。但是，如果以这种方式编写测试计划，则会冒以下问题的风险：

1)疏忽大意我已经看到人们执行详细的程序测试脚本，认真地完成并仔细记录每个步骤，并完全消除了眼前的明显错误。因为它"不在脚本中"。他们的注意力集中在所有那些挑剔的测试步骤上，以至于他们根本看不到面前的问题。

2)我们将错过所有那些仅需高度详细，非常具体的路径的错误。当客户获得产品时，他们将不会遵循详细的测试计划。他们将以多种方式浏览应用程序。他们会改变主意。它们的名称可能比我们认为可能或者可能的名称长或者短。他们将在交易中途放弃。他们会流浪。他们不会走一条路。而且每次有人重复测试时，他们都会再次错过这些错误。

3)我们将花费非常长的时间来尝试编写"任何人都可以遵循"的测试脚本。相信我，我花了很多年的时间来完善这一点，但这在人类中是不可能的。更糟糕的是，我们浪费在尝试执行此操作上的时间可能会以其他方式浪费更多的利润，因此产品情况会更糟。

4)我们将要经过大量重复，如果不阅读全部内容，很难说出测试的重点。快速浏览测试以了解我们可能错过了哪些用例并不容易。

保持测试计划宽泛，并允许进行测试的人员做出判断。如果我们有关于必须测试的特定使用场景的信息，或者关于目标用户组将如何操作的信息，那么也可以将其连同测试计划一起以用户角色的形式提供给测试人员，也许只是以用例的形式。如果我们需要勾选特定的选项，请考虑使用清单。 (有关更多信息，请参见Cem Kaner的精彩演讲
www.kaner.com/pdfs/ValueOfChecklists.pdf)。

或者，将测试计划写成简短的探索性章程。例如，我们可以提供指导，例如：" Callcentre用户将使用未连接鼠标的工作站。探讨代表客户举票的过程，确保仅使用键盘快捷键即可完成所有活动。"这比测试人员说"在字段1中键入标签。输入"关于线路质量的投诉"。在字段2中选择"电话"。在下拉菜单中选择"电话"。 68. "