哪里可以找到好的测试用例模板/示例？

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. GOTO 4直到所有错误都得到修复。
7. 内部测试结束;产品展示给客户。

是否有人指出可以找到带有测试用例的示例文档的位置？此外，欢迎所有关于我上面概述的过程的提示。 ：）

Answer 1

我开发了两个我用过的文件。

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

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

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

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

希望有所帮助。

Answer 2

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

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

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

Answer 3

大卫彼得森的Concordion web-site有一个关于编写好规范的技术的非常好的页面（以及执行所述规范的框架）。他的建议简单明了。

您也可以查看Dan North的classic blog post行为驱动开发（BDD）。非常有帮助！

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和Web自动化。例如Selenium。很多都可以实现自动化，远远超出您的想象。例如，您的用户注册方案很容易实现自动化。即使必须由人进行检查，例如跨浏览器测试以确保事情看起来正确，也可以在QA工程师观看时记录并重放测试。开发人员甚至可以记录重现难以自动化错误的步骤，并将其传递给QA，而不是花费时间，而且往往是有缺陷的，写下指令的任务。将它们保存为项目的一部分。给他们关于测试意图的良好描述。将它们链接到票证。如果GUI发生变化，测试不再起作用，并且会发生，您可以重写测试以涵盖其意图。

我将放大保罗约翰逊关于使GUI层尽可能薄的说法。从功能（它做什么）中分离表单（GUI或HTML或格式）并自动测试功能。具有生成国家列表的功能，彻底测试。然后是一个使用它来生成HTML或AJAX或其他任何东西的函数，你只需要测试它看起来是否正确，因为执行实际工作的函数已经过充分测试。用户登录。密码检查。电子邮件。这些都可以在没有GUI的情况下编写。这将大大减少必须进行的缓慢，昂贵，有缺陷的手动测试的数量。