代码之家 › 专栏 › 技术社区 › Domchi

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

requirements project-management testing

5

Domchi · 技术社区 · 16 年前

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

目前,在特性冻结测试人员在部署之前“点击应用程序”,但是没有正式的规范需要测试什么。

首先,我在考虑一个文档,它指定了需要测试的每个特性,类似于这样(组成这个文档):

用户登记表
1. 国家/地区下拉列表(是否正确从服务器提取国家/地区?)
2. 密码验证(是否遵守所有密码规则,如果密码太弱是否通知用户?)
谢谢你的注册

等等…这也可以作为客户机在程序员开始编码之前可以签署的需求的一部分。功能列表完成后,我正在考虑将此列表作为电子表格中的第一列,电子表格中还说明了功能上次测试的时间、是否工作,如果不工作,它是如何中断的。这会给我一个文档,测试人员可以在每个测试周期后填写这个文档,这样程序员就有了一个待办事项列表,其中包含了一些不起作用的信息,以及什么时候中断的信息。

其次,我在考虑测试人员的测试用例,具体步骤如下:

加载用户注册表。
(功能1.1)检查国家/地区下拉菜单。
1. 国家下拉列表中是否有国家?
2. 国家名称是否本地化?
3. 每种语言的排序顺序是否正确?
(功能1.2)输入以下密码:“A”、“BOB”、“密码”、“密码123”、“密码123”。只接受最后一个密码。
按“OK”。
(功能2)检查感谢信。
1. 文本是否本地化为所有支持的语言?

这将为测试人员提供具体的案例和检查清单,并提供指向第一个文档中特性的指针。这也会给我一些东西来开始自动化测试过程(目前除了单元测试之外,我们没有太多的测试自动化)。

我在找一些其他人在没有太多文件的情况下如何做到这一点的例子。通常,测试人员应该能够在一两个小时内完成所有测试。我正在寻找一种简单的方法,让客户同意我们应该为下一个版本实现哪些特性,让测试人员验证所有新特性都实现了,所有现有特性都工作了,并将其报告给程序员。

这主要是内部测试材料,应该是几个Word/Excel文档。我试图在两天内保持一个测试/错误修复周期。我在跟踪编程时间、新特性的实现以及以其他方式(JIRA)获得的客户通知单,这基本上就是测试文档。这就是我想到的生命周期:

PM列出功能。客户签字。(创建文档1。)
创建测试用例。(文件2)
程序员实现特性。
测试人员根据测试用例测试特性。(并通过文档1报告错误。)
程序员修复错误。
转到4,直到修复所有错误。
内部测试结束;向客户展示产品。

是否有人有指向哪里可以找到带有测试用例的示例文档的指针?此外,欢迎提供有关上述流程的所有提示。:)

5 回复 | 直到 8 年前

1

2

louism 16 年前

我开发了两个文件。

一个是针对您的“标准网站”(例如,商务网站的存在):

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

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

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

希望有帮助。

2

1

meade 16 年前

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

对于这些步骤,不要忘记包括一个评估步骤,在这个步骤中,您、测试人员、开发人员等将评估测试结果,并为下一轮更新需求/测试文档(您经常会遇到一些您不可能想到并且应该添加到规范中的事情……从需求的角度和测试的角度)。

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

3

1

Jeffrey Cameron 16 年前

大卫·彼得森的 Concordion web-site 有一个非常好的页面,介绍编写良好规范的技术(以及执行所述规范的框架)。他的建议简明扼要。

你也可以去丹诺斯的 classic blog post 行为驱动发展(BDD)。很有帮助!

4

0

Paul Johnson 16 年前

在开始工作之前,您绝对需要一个详细的规范;否则,您的开发人员不知道要写什么,也不知道什么时候完成。乔尔·斯波斯基写过 a good essay 关于这个话题,举个例子。但不要期望规范在开发期间保持不变:在计划中构建修订。

上述MEADE建议将规范与测试结合起来。这被称为 Test Driven Development 这是个很好的主意。它以自然语言通常不具备的方式将事物固定下来,并减少工作量。

您还需要考虑单元测试和自动化。这是一个大大节省时间和质量的助推器。GUI级别的测试可能很难自动化,但是您应该使GUI层尽可能薄,并对下面的功能进行自动化测试。这在以后的开发中节省了大量的时间,因为您可以尽可能频繁地彻底测试整个应用程序。手动测试既昂贵又缓慢,因此有一个很强的诱惑去偷工减料:“我们只改变了foo模块,所以我们只需要重复测试7、8和9”。然后,客户打电话抱怨酒吧模块中的某个东西坏了,结果发现foo对酒吧有一个模糊的副作用,开发人员忽略了。自动化测试会抓住这一点,因为自动化测试运行起来很便宜。参见 here 关于这样一个虫子的真实故事。

如果您的应用程序足够大,需要它,那么使用TDD指定模块,并将这些模块测试转换为自动化测试。

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

5

0

Schwern 16 年前

浏览旧的bug报告并从中构建测试用例。您可以测试特定的旧错误,也可以进行更多的概括。由于同类的错误往往会一次又一次地出现,这将为您提供一个测试套件,它更多地关注真正的错误,更少地关注完全覆盖的不可能(或非常昂贵)任务。

利用图形用户界面和网络自动化。 Selenium 例如。很多都可以自动化,比你想象的要多得多。例如,您的用户注册方案很容易实现自动化。即使他们必须由人来检查,例如跨浏览器测试,以确保事情看起来正确,测试可以被记录并在稍后的时候重放,而质量保证工程师会观察。开发人员甚至可以记录复制难以自动化的错误的步骤,并将其传递给QA,而不是花时间(通常是有缺陷的)写下指令。将它们保存为项目的一部分。对测试的目的给予他们很好的描述。把它们连到一张票上。如果图形用户界面发生变化,使测试不再工作,并且会发生这种情况,您可以重写测试来覆盖其意图。

我将详细说明PaulJohnson所说的关于使GUI层尽可能薄的内容。将表单(GUI、HTML或格式)与功能(它所做的)分开,并自动测试功能。具有生成国家列表的功能,彻底测试。然后是一个函数,它使用这个函数来生成HTML或Ajax等,并且您只需要测试它看起来是否正确,因为完成实际工作的函数经过了很好的测试。用户登录。密码检查。电子邮件。这些都可以在没有图形用户界面的情况下编写来工作。这将大大减少必须进行的缓慢、昂贵、有缺陷的手动测试的数量。