中国龙,中国风,中国会变得更加强大! 力量越大,责任越大! 人的一生,会面临很多选择,但决定一个人一生的,往往就是最关键那么的一两步

测试用例管理工具的需求整理 『转载』

上一篇 / 下一篇  2008-12-15 11:18:12 / 个人分类:转载

测试用例管理工具的需求整理  『转载

首先分析了一下一般测试用例管理工具的流程:
Test case management procedure:

Requirement->Test plan->Define test->Design test step->Test library->Execute test->Analyze test Result->Add defects

系统工作流程

1.       系统登录:用户输入用户名、密码登录系统

2.       指定项目:选择项目,进入该项目的管理界面

3.       需求管理:打开需求模块,添加需求

4.       用例管理:打开用例模块,添加测试用例并注意与需求进行关联

5.       用例库管理:打开用例库,从已有用例中挑选用例组建用例集合

6.       用例执行:执行用例,并标识用例执行情况

7.       记录缺陷:提交缺陷后,需要关联发现该缺陷的测试用例

8.       数据分析:用例覆盖率,用例执行情况

 

然后简单列出了一些功能需求:

功能要求

1.       管理员数据维护

TestLink可以对多个产品进行管理,Admin进行产品设置后,测试人员就可以进行测试需求、测试用例、测试计划等相关管理工作了。TestLink支持对每个产品设置不同的背景颜色,方便管理。

管理员在初始阶段应该设置好项目(项目管理),项目成员(用户管理),为成员分配权限(权限管理)。

2.       需求管理

测试需求是我们开展测试的依据。首先,我们对产品的测试需求进行分解和整理。一个产品可以包含多个测试需求规格,一个测试需求规格可以包含多个测试需求;

l          创建测试需求规格
对测试需求规格的描述比较简单,内容包含名称、范围。

l          创建测试需求
测试需求内容包含:需求ID、名称、范围、需求的状态,以及覆盖需求的案例。 TestLink提供了两种状态来管理需求:正确的(Valid)、不可测试的(not testable)。

搭建需求管理结构

新建 修改 复制 删除 导入

需求变更管理,变更后可以列出对应的测试用例以及其执行情况。方便用例的维护。

需求和用例之间建立关联

通过需求建立测试用例

需求测试log,确认需求是正确的需求。

3.       用例管理

搭建用例管理结构

TestLink支持的测试用例的管理包含三层:分别为Component、Category、Test case。我们把Component对应到项目的功能模块,而把Category跟每个模块的function对应,Test case就是写在这些Category里的。我们可以使用测试用例搜索功能从不同的项目、成百上千的测试用例中查到我们需要的测试用例,甚至于可以直接将别的项目里写的测试用例复制过来,这样就解决了测试用例的管理和复用问题。

但是,还有一个问题没有解决,那就是与测试需求的对应问题。在测试管理中,测试用例对测试需求的覆盖率是我们非常关心的,从需求规格说明书中提取出测试需求之后, Testlink提供管理测试需求与测试用例的对应关系的功能。

l          创建Component
Component的内容包括:名称、介绍、范围、相关的内容、约束。

l          创建Category
Category的内容包括:名称、测试范围和目标、配置信息、测试数据、测试工具

l          创建 Test case
测试用例的要素包括:测试用例名称、简要说明、步骤、期望结果、关键字。

新建

Test case detailed 测试用例详细信息

(1)Test case information测试用例基本信息:

Test case ID 用例ID 唯一标识 Test case name 用例名称 Test type 用例类型:手工,自动化 Tester 提交员名称 Create date 提交日期 Version 项目版本号 Test objective 测试目的 Precondition 前提条件

(2)Test procedure 测试步骤:

Step 步骤编号 Step name 步骤名称 Action 执行动作 Expected result 预期结果

(3)Test result 测试结果:

Tester 测试员名称 Date of test 测试日期 Test version 测试版本号 Test result 测试结果

修改

Test case ID 用例ID 唯一标识 不允许修改    Tester 提交员名称 不允许修改

Create date 提交日期 不允许修改   Modify date 修改日期

复制

(1)复制测试用例

(2)复制用例中的步骤

删除

可以删除未经过执行的用例。

显示

(1)测试用例列表

(2)从列表中打开用例显示详细信息

建立用例和需求的关联

建立用例库(测试计划)

从已有的用例中挑选入库

在TestLink系统中,一个完整的测试计划包括:

l          测试阶段的名称(如集成测试阶段、系统测试阶段)

l          里程碑(明确每个测试阶段的开始和截止时间,以及完成A、B、C三种优先级的比例)

l          Build版本(定义本测试计划中需要测试的build版本,一般以产品名+时间来命名。)

l          安排测试人员(从用户列表中选择本测试计划的参与人员。)

测试用例集

l          制定优先级规则。优先级分为A、B、C三级,系统会根据用户定义的重要级别和风险级别的组合来确定优先级的归属。重要级别分为三级:Low、Medium、High。风险级别包括三级:1、2、3。

l          从测试用例中选择本测试计划的测试用例集

l          设置每个测试用例Category的重要级别和风险级别

l          设置每个测试用例Category的责任归属。从本测试计划的测试人员列表中选择每个Category的Owner,由他来负责和完成测试用例的执行。

用例执行

允许在各个步骤后面添加执行状态 Pass,Failed,Block并且添加注释

添加测试用例执行状态 Not run,Pass,Failed,Block

Not run:没有执行

Pass:每个步骤都pass的用例

Failed:有莫个或多个步骤执行失败的用例

Block:因莫种外界原因导致用例中的操作步骤不能继续执行的用例

测试结果分析

TestLink根据测试过程中记录的数据,提供了较为丰富的度量统计功能,可以直观的得到测试管理过程中需要进行分析和总结的数据:

测试用例对测试需求的覆盖情况:哪些需求已经通过测试,哪些需求未通过测试,哪些需求处于阻塞状态,哪些需求还未开始测试。

针对每个版本的测试用例执行情况:
1)各种优先级的测试用例执行的比率
2)各个模块的测试用例执行的比率
3)各个测试人员测试用例的执行比率

每个版本的执行情况

所有测试用例在不同build版本的执行情况,显示?的地方表示还未执行。

阻塞的测试用例列表

失败的测试用例列表

每个测试用例的bug数
测试结果分析,统计

测试执行情况统计:统计测试用例集合中已执行的以及未执行的情况并导出图表

测试执行状态统计:统计Pass,Failed,Block的情况并导出图表

导出

导出summary列表信息

导出详细的用例信息

测试用例调用

同种类型的测试用例编写特定模版。

不同的操作可以调用这些特定的模版,减少测试用例的复制粘贴。

比如说:对于数据输入项的验证,采用等价类划分,边界值,数据类型验证等这些方法的话,可以统一编写一个模版。以后每次的数据输入项的验证都可以直接调用这些模版,而只需要作些测试数据的更改。

自动化测试用例脚本维护

自动化测试采用其他的测试用例模版,可以记载自动化测试工具,方法,目的,结果,执行情况即可。

用例更新日志

必须清楚的记载用例更新log,以便以后可以追溯到用例的所有变更情况。

测试用例评审、互查记录

做好测试用例的互查,

一种是请开发leader或者开发人员同测试人员一起检查用例覆盖情况。

另一种是测试人员进行互查。

做好评审互查记录可以保证用例的准确度,提高用例质量。

4.       缺陷管理

5.       权限管理

用户设置

在TestLink系统中,每个用户都可以维护自己的私有信息。admin可以创建用户,但不能看到其它用户的密码。在用户信息中,需要设置Email地址,如果用户忘记了密码,系统可以通过mail获得。

TestLink系统提供了六种角色,分别是admin、leader、senior tester 、tester、guest、testdesigner。相对应的功能权限如下:(详见图)

l          Guest:只有读的权限,适合于查看测试用例和测试需求,以及项目分析的用户。

l          Test designer:可以开展测试用例和测试需求的所有工作。

l          Tester:只能执行测试用例。

l          Senior tester:可以查看和维护测试用例,并且可以执行测试用例,但是不能管理测试计划、分配测试任务。Leader:可以开展测试规格和测试需求的所有工作,还可以管理测试计划、分配测试任务。

l          Admin:维护产品,用户。

同时,支持不同地域用户对不同语言的需求,可以根据用户的喜好对用户提供不同的语言支持。

User authority用户权限设置

用户信息维护

新建用户

修改用户信息

删除用户

密码管理

权限分配

6.       系统登录

7.       其他功能

多语言

Email通知


昨天下午讨论后,增加了:


1.       MS Project和用例管理工具的关联:

(1)         当用户登录用例管理工具的时候,能够根据MS Project的schedule来限制登录系统后的权限:

例如:

根据project的schedule:

……

3月8日-3月10日建立需求测试;

3月11日-3月18日创建测试用例;

3月19日创建Test Suite

3月20日-3月23日执行测试;

3月24日提交测试报告;

……

那么,

在 3月11日-3月18日登录该系统的用户,不允许对3月11日之前编辑的测试需求进行维护。

而 3月19日登录该系统的用户,不允许对3月19日之前编辑的测试用例进行维护。

……

(2)         里程碑等schedule的变更应及时发送email通知相关人员,并将(1)中相关的日期自动更新。

2.       VSS和用例管理工具的关联

(1)         测试需求主要是根据VSS上的产品需求文档及产品规格说明书来确定,对于测试需求可以分为三部分:原测试需求,新增测试需求,原测试需求变更后的测试需求。所以当产品需求,规格说明书有更新时,可以发送email给测试相关人员,并在界面标识需要更新的需求。

(2)         VSS中新版本发布以及daily build的更新后应发送email通知测试相关人员。

(3)         VSS中数据库的更新应及时发送email通知测试人员。

3.       Mantis和用例管理工具的关联

(1)         测试用例执行完毕后,测试结果中记录缺陷ID,并能通过ID查看缺陷状态及其他详细信息。

(2)         通过缺陷和测试用例的关联,建立缺陷和测试需求的关联。已知需求,可以查看关联的用例以及用例执行情况,可以查看关联的缺陷以及缺陷的状态;已知用例,可以查看关联的需求,可以查看关联的缺陷以及缺陷的状态;已知缺陷,可以查看关联的需求,可以查看关联的用例。


TAG: 测试用例 测试工具 转载

 

评分:0

我来说两句

Open Toolbar