logo标签列表

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

testingproject-managementrequirements
6

我正在尝试建立更正式的要求和测试程序，但是我找不到任何好的相关文件的参考例子。

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

首先，我想要一个文档，该文档指定了需要测试的每个功能，类似于以下内容（这是虚构的）：

  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. 项目经理列出功能清单，客户签署（创建文档1）。
  2. 编写测试用例（文档2）。
  3. 程序员实现功能。
  4. 测试人员按照测试用例测试功能（并通过文档1报告错误）。
  5. 程序员修复错误。
  6. 返回步骤4，直到所有错误都被修复。
  7. 内部测试结束；向客户展示产品。

是否有任何指向一些包含测试用例的样本文档的提示？此外，欢迎提供有关上述过程的所有建议。:)

5个回答
2
1
首先，我认为将需求文档与测试用例文档结合起来是最有意义的，因为两者的许多信息都是相同的，并且在测试人员面前放置需求，在用户和开发人员面前放置测试用例可以加强需求并提供不同的视角。这是文档布局的良好起点：http://www.volere.co.uk/template.htm#anchor326763 - 如果您添加了：测试步骤、测试结果期望、边界/限制情况，那么您应该拥有一个相当完整的需求规格和测试规格。
对于测试步骤，请不要忘记包括评估步骤，其中您、测试人员、开发人员等评估测试结果并更新下一轮的需求/测试文档（您经常会遇到一些无法想到的事情，应该将其添加到规格中...从需求和测试的角度）。
我还强烈建议使用思维导图/工作分解结构来确保您已正确捕获所有需求。
1

David Peterson的Concordion网站有一篇非常好的关于编写良好规范的技术文章（以及执行这些规范的框架）。他的建议简单明了。

此外，您可能还想查看Dan North的经典博客文章，介绍行为驱动开发（BDD）的相关内容。非常有帮助！

0

在开始工作之前，您绝对需要详细的规范；否则，您的开发人员不知道该写什么或何时完成。 Joel Spolsky已经针对这个问题撰写了一篇好文章，其中包含了示例。不过，在开发过程中，不要指望规范保持不变：要在计划中考虑构建修订。

上面提到，meade推荐将规范与测试结合起来。这被称为测试驱动开发，这是一个非常好的想法。它以一种自然语言往往无法做到的方式固定事物，并减少了工作量。

你还需要考虑单元测试和自动化。这是一个大的时间节省和质量提升。GUI级别的测试可能很难自动化，但你应该尽可能地将GUI层变得薄，并为其下面的功能编写自动化测试。在开发后期，这可以节省大量时间，因为你可以随时彻底测试整个应用程序。手动测试费时费力，所以有强烈的诱惑去走捷径：“我们只更改了Foo模块，所以我们只需要重复测试7、8和9”。然后客户打电话抱怨Bar模块中的某些内容出现问题，结果发现Foo对Bar有一个隐晦的副作用，而开发人员却没有注意到。自动化测试会捕捉到这个问题，因为自动化测试运行起来很便宜。请参阅此处，了解有关此类错误的真实故事。
如果你的应用程序足够大，则需要使用TDD指定模块，并将这些模块测试转换为自动化测试。
要运行所有手动测试需要一个小时听起来有点乐观，除非它是一个非常简单的应用程序。不要忘记你必须测试所有的错误情况以及主路径。
我们正在使用单元测试，但有些事情无法自动化，确实需要人类的参与；我正在尝试规范该过程的这一部分。其他公司测试人员使用的任何文档都将非常有帮助。我知道理论，现在我正在寻找可以帮助我应用它的示例。意外的副作用正是我做整个事情的原因。 - Domchi
0

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

利用GUI和Web自动化。例如Selenium。许多东西都可以自动化，比您想象的要多得多。例如，您的用户注册场景很容易自动化。即使它们必须由人类检查，例如跨浏览器测试以确保事物看起来正确，测试也可以在QA工程师观察时记录并重放。开发人员甚至可以记录重现难以自动化的错误的步骤，并将其传递给QA，而不是花费时间繁琐且常常存在缺陷的编写说明任务。将它们保存为项目的一部分。为测试意图提供良好的描述。将它们链接到票证。如果GUI发生更改，以便测试不再起作用（这将发生），则可以重新编写测试以涵盖其意图。

我将强调一下Paul Johnson关于尽可能使GUI层变得轻薄的观点。将表单（GUI或HTML或格式）与功能（它所做的事情）分开，并自动化测试功能。编写生成国家列表的函数并进行彻底测试。然后编写一个使用该函数生成HTML或AJAX或其他内容的函数，您只需要测试其外观是否正确，因为执行实际工作的函数已经经过充分测试。用户登录、密码检查、电子邮件等都可以编写成无需GUI即可运行的形式。这将大大减少必须进行的缓慢、昂贵、有缺陷的手动测试量。
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接