在哪里可以找到好的测试用例模板/示例？ [关闭]

Question

我正在尝试建立比现在更正式的要求和测试程序，但我找不到任何相关文档的良好参考示例。

目前，在功能冻结测试人员在部署前“点击应用程序”之后，还没有正式的规范需要测试什么。

首先，我正在考虑一个文档，该文档指定需要测试的每个功能，如下所示（编造这个）：

1. 用户登记表
   1. 国家/地区下拉菜单（从服务器获取的国家/地区是否正确？）
   2. 密码验证（是否遵守所有密码规则，如果密码太弱，是否通知用户？）
2. 感谢您的注册

...等等。这也可以作为客户在程序员开始编码之前作为需求的一部分签名的东西。功能列表完成后，我正在考虑将此列表作为电子表格中的第一列，其中还说明了该功能上次测试的时间，它是否有效，如果它不起作用，它是如何破坏的。这将给我一个文档测试人员可以在每个测试周期后填写，以便程序员有待办事项列表，其中包含哪些信息不起作用以及何时中断。

其次，我正在为测试人员考虑测试用例，详细步骤如下：

1. 加载用户注册表。
2. （功能 1.1）检查国家下拉菜单。
   1. 国家下拉菜单中是否包含国家/地区？
   2. 国家名称是否本地化？
   3. 每种语言的排序顺序是否正确？
3. （功能 1.2）输入以下密码：“a”、“bob”、“password”、“password123”、“password123#”。只应接受最后一个密码。
4. 按“确定”。
5. （功能 2）查看感谢信。
   1. 文本是否已本地化为每种支持的语言？

这将为测试人员提供具体的案例和检查清单，并指出第一个文档中的功能。这也可以让我开始自动化测试过程（目前我们除了单元测试之外没有太多的测试自动化）。

我正在寻找其他人如何做到这一点的一些示例，而无需太多文书工作。通常，测试人员应该能够在一两个小时内完成所有测试。我正在寻找一种简单的方法来让客户同意我们应该为下一个版本实现哪些功能，并让测试人员验证所有新功能都已实现并且所有现有功能都在工作，并将其报告给程序员。

这主要是内部测试材料，应该是几个 Word/Excel 文档。我试图将一个测试/错误修复周期保持在两天以内。我正在以其他方式（JIRA）跟踪编程时间、新功能的实现和客户票，这基本上是测试文档。这是我想到的生命周期：

1. PM 列出功能列表。客户签字。 （文档 1 已创建。）
2. 已创建测试用例。 （文件 2。）
3. 程序员实现功能。
4. 测试人员根据测试用例测试功能。 （并通过文档 1 报告错误。）
5. 程序员修复错误。
6. 转到 4 直到所有错误都得到修复。
7. 内部测试结束；产品展示给客户。

有没有人指出可以在哪里找到一些带有测试用例的示例文档？此外，欢迎有关我上面概述的过程的所有提示。 :)

Answer 1

我开发了两个我使用的文档。

一个用于您的更“标准网站”（例如商业网站）：

http://pm4web.blogspot.com/2008/07/quality-test-plan.html

我用于基于 Web 的应用程序的另一个：

http://pm4web.blogspot.com/2008/07/writing-system-test-plan.html

希望有帮助。

Answer 2

首先，我认为将需求文档与测试用例文档结合起来是最有意义的，因为两者的大部分信息都是相同的，并且将需求放在测试人员面前，将测试用例放在用户和开发人员面前强化了要求并提供了不同的观点。这是文档布局的一个很好的起点：http://www.volere.co.uk/template.htm#anchor326763 - 如果您添加：测试步骤、测试结果预期、边缘/边界案例 - 您应该有一个非常可靠的需求规范和测试规范。

对于这些步骤，不要忘记包含一个评估步骤，您、测试人员、开发人员等在其中评估测试结果并更新下一轮的需求/测试文档（您经常会遇到您无法想到并且应该将其添加到规范中...无论是从需求角度还是从测试角度来看）。

我还强烈建议您使用思维导图/工作分解结构来确保正确捕获所有需求。

Answer 3

David Peterson 的Concordion web-site 有一个非常好的页面，介绍了编写良好规范的技术（以及执行所述规范的框架）。他的建议简单明了。

您可能还想查看 Dan North 在行为驱动开发 (BDD) 上的 classic blog post。很有帮助！

Answer 4

在开始工作之前，您绝对需要一份详细的规范；否则您的开发人员不知道要写什么或何时完成。 Joel Spolsky 就这个主题写了a good essay，并附有示例。但不要指望规范在开发过程中保持不变：在计划中进行修订。

上面的 meade 建议将规范与测试结合起来。这被称为Test Driven Development，是一个非常好的主意。它以一种自然语言通常不会的方式确定事物，并减少了工作量。

您还需要考虑单元测试和自动化。这是一个很大的节省时间和质量助推器。 GUI 级别的测试可能难以自动化，但您应该使 GUI 层尽可能薄，并对下面的功能进行自动化测试。这可以在以后的开发中节省大量时间，因为您可以根据需要对整个应用程序进行彻底的测试。手动测试既昂贵又缓慢，因此有一种偷工减料的强烈诱惑：“我们只更改了 Foo 模块，因此我们只需要重复测试 7、8 和 9”。然后客户打电话抱怨 Bar 模块中的某些东西坏了，结果发现 Foo 对 Bar 有一个开发人员忽略的模糊的副作用。自动化测试会捕捉到这一点，因为自动化测试运行起来很便宜。有关此类错误的真实故事，请参阅 here。

如果您的应用程序大到需要它，则使用 TDD 指定模块，并将这些模块测试转换为自动化测试。

运行所有手动测试一个小时听起来有点乐观，除非它是一个非常简单的应用程序。不要忘记您必须测试所有错误案例以及主路径。

Answer 5

查看旧的错误报告并从中构建您的测试用例。您可以测试特定的旧错误并进行更多概括。由于相同类型的错误往往会一遍又一遍地出现，这将为您提供一个测试套件，它更多地是为了捕捉真正的错误，而不是关于不可能（或非常昂贵）的全面覆盖任务。

利用 GUI 和网络自动化。 Selenium，例如。很多东西可以自动化，比你想象的要多得多。例如，您的用户注册场景很容易实现自动化。即使它们必须由人工检查，例如跨浏览器测试以确保事情看起来正确，也可以在 QA 工程师观看时记录和回放测试。开发人员甚至可以记录重现难以自动化的错误并将其传递给 QA 的步骤，而不是花费时间且经常有缺陷的任务来写下指令。将它们保存为项目的一部分。给他们关于测试意图的良好描述。将它们链接到一张票。如果 GUI 发生更改，导致测试不再工作，并且会发生这种情况，您可以重写测试以涵盖其意图。

我将详细说明 Paul Johnson 关于使 GUI 层尽可能薄的说法。将表单（GUI 或 HTML 或格式）与功能（它的作用）分开并自动测试功能。具有生成国家列表的功能，彻底测试。然后是一个函数，它使用它来生成 HTML 或 AJAX 或其他什么，你只需要测试它看起来是否正确，因为执行实际工作的函数经过了很好的测试。用户登录。密码检查。电子邮件。这些都可以在没有 GUI 的情况下编写工作。这将大大减少必须完成的缓慢、昂贵、有缺陷的手动测试的数量。