测试 & 测试设计者/测试者的职责

测试&测试设计者/测试者的职责

测试设计者/测试者的职责主要是设计和书写测试用例、执行测试用例、记录测试结果、记录和跟踪缺陷、进行测试覆盖分析等等。设计者在接到测试组织的测试要求后，应该运用适当的测试分析、测试设计和尽可能有效的测试覆盖分析方法来履行测试设计者的职责。这个目标是运用尽可能少的测试用例获得尽可能多的测试覆盖。

职责和产出

测试用例设计

测试用例设计不同于测试用例。这个设计结果是测试设计者/测试者正试图利用一个或多个测试用例达到的。它可能是正规测试执行之前的一个包含简单的测试用例内容的非正规的文档或图释。

测试用例

测试用例是用来从一个或多个角度测试应用程序的一系列有序地执行步骤。每个测试用例至少应该包括：操作步骤、测试数据和预期结果。可以使用合适的“测试用例模板”或者一些商业的/免费的/共享的软件来记录测试用例。

测试用例的执行

测试用例执行是实际的运行一个测试用例。可以通过手工或利用自动化测试工具或者测试脚本执行测试用例。

捕获测试结果

捕获测试结果主要是简单的逐条记录一个测试用例的每一个步骤成功失败与否。失败的测试用例意味着一个缺陷可能已经被发现–它意味着这个应用程序可能没有达到测试用例设计的预期的结果。通常导致测试用例步骤执行失败的原因有：无效的测试设计/预期结果、无效的测试数据或者无效的应用程序状态。测试者在提交缺陷之前应该确保导致测试用例执行失败的原因是由应用程序引起的，而非规格说明书，并且能够使缺陷重现。

记录缺陷

测试者应该记录下在测试用例执行期间发现的所有缺陷。缺陷记录应该包括：测试者姓名、缺陷名称、缺陷描述、严重等级、出现缺陷的功能区域和其他任何可以帮助理解缺陷的信息。

测试覆盖分析

如果测试者对测试的要求和预定义的测试范围感到满意了，就可以记录下应用程序当前的状态。如何进行测试覆盖分析依赖于对测试者有用的信息。如果测试者能够绘制测试用例图去更好的阐明需求那么测试覆盖分析就是一件很简单的事情。否则测试人员必须将测试用例分布在应用程序的各个功能模块上,并且确认是否已经完全覆盖了功能---这显然更像是某种内部检查,而不是真正的分析。

测试要求和范围

   测试者设计者和测试者在执行测试任务之前应该清晰的明确测试的要求和范围。测试者们的梦想就是可以测试所有的东西:但问题是任何应用程序的测试,都不可能给出足够的时间让你完成这个梦想.所以测试员必须确认任何一个测试用例的设计和执行都要符合当前测试所想要达到的深度和广度.如果不能,那么要么重新定义测试的范围,要么放弃这些不符。

测试阶段和测试用例设计

不同的测试阶段对测试用例的形式、内容和目的都有影响。如果设计者能够考虑到测试不同阶段那么测试的类型需要在任何一个给定的测试阶段贯彻执行。如果设计者在设计的时候根据测试深度，测试范围等，制定了测试阶段。那么显然需要根据这些给定的阶段，进行不同种类的测试。

单元测试

测试设计者，主要是开发者，创建测试用例进行代码级测试。

功能测试

测试设计者设计测试用例进行业务或功能级的测试。

系统测试

测试设计者设计测试用例进行系统级的测试（压力测试、功能测试、安全测试、可恢复性测试等等）或者完成点对点的业务测试。

可接受的测试/验收测试

在这个阶段中测试设计者通常是一个系统问题专家或者最终用户，设计测试用例对业务流程或可操作性进行测试。

任何测试用例都不能复制前一阶段完成的测试。一个最常犯的错误是测试者和测试组织通常复制功能测试阶段完成的测试来设计系统测试阶段的测试用例。

缺陷内容

缺陷是测试设计者引起的最重要的产出物。测试的主要目的是在版本发布之前发现应用程序中的缺陷；此外缺陷是唯一能够被工程组看到的可用来度量测试团队工作的指标。测试者必须形成一种缺陷记录风格，这对于缺陷过程改进是非常有用的。一个空白缺陷至少应包括：缺陷发现者、缺陷名称、缺陷描述、缺陷等级、缺陷出现区域和状态。下面以一个在功能测试中被发现经典登录缺陷为例进行分析：

缺陷名称/标题

缺陷名称/标题应该是对缺陷的存在区域和缺陷内容的一个概括性的描述。若从登录界面上找到的缺陷，应该用登录界面加上概括性的缺陷描述来定义缺陷的名称/标题。

 例如：“登录-用户在尝试三次登录失败后没有被锁定”。

缺陷描述

缺陷描述应该清晰的阐释缺陷产生的具体情形，何时能够捕获到缺陷快照或者可打印的错误。

例如：试图利用一个无效的用户ID登录系统，在前两次尝试的时候会出现预期的提示信息“用户名或密码错误-请重试”。但是到了第三次尝试的时候却直接显示了错误。根据需求用户应该被提示“无效的用户名和密码-请联系管理员”，然后被系统锁定。

如何重现缺陷

缺陷描述应该能够为项目维护小组提供尽可能详细的细节，并且开发者在进行缺陷修复的时候能够重现。

缺陷等级

缺陷的严重等级依赖于：测试的阶段、缺陷与测试成果之间的冲突、如果缺陷没有被发现可能带来的风险。使用“登陆系统”为例，如果这个缺陷在功能测试阶段被发现那么可能被定义为“中等”严重程度，但是如果在系统测试阶段才被发现或者一直隐藏在系统测试阶段，可能严重等级就被定义为“高级”。

缺陷发生区域

缺陷发生区域可能是系统的某个功能组建或者某个功能区域-亦或两者都有。以“登陆系统”为例，功能单元应该是“登陆界面”，功能区域应该是“安全”

团队中其他成员的关系

测试leader/测试经理

测试设计者和测试leader之间建立良好的合作关系是非常重要的，测试设计者必须让测试leader意识到任何的挑战都可能让测试团队走向成功。通常测试设计者（或设计者）应该更清楚的理解当前应用程序的状态和潜在的挑战。

自动化测试工程师

如果测试用例应用于自动化测试，那么测试设计者应该确保自动化测试工程师能够准确地了解测试用例试图达到什么目标，并且如果在测试执行期间出现错误系统会有什么样的响应。为了使自动化测试工程师能够更好的完成自动化测试任务，测试设计者有时候可能需要进行必要的妥协，前提是这个妥协不会对应用程序造成任何大的风险。