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

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

4

5 回答 5

2

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

一个是为您的更多“标准网站”（例如商业网络存在）：

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

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

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

希望有帮助。

于 2009-05-17T05:07:08.483 回答
1

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

对于这些步骤，不要忘记包含一个评估步骤，您、测试人员、开发人员等在其中评估测试结果并更新下一轮的需求/测试文档（您经常会遇到无法解决的问题）已经考虑并应该从需求角度和测试角度添加到规范中）。

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

于 2009-05-08T02:33:44.350 回答
1

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

您可能还想查看 Dan North关于行为驱动开发 (BDD)的经典博客文章。很有帮助！

于 2009-05-11T00:01:04.440 回答
0

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

上面的米德建议将规范与测试结合起来。这被称为测试驱动开发，是一个非常好的主意。它以一种自然语言通常不会的方式将事情固定下来，并减少了工作量。

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

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

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

于 2009-05-08T17:25:43.713 回答
0

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

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

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

于 2009-05-17T05:23:26.090 回答