测试资产配置管理指南TestlinkWord格式.doc

测试资产配置管理指南TestlinkWord格式.doc

《测试资产配置管理指南TestlinkWord格式.doc》由会员分享，可在线阅读，更多相关《测试资产配置管理指南TestlinkWord格式.doc（8页珍藏版）》请在冰豆网上搜索。

如果今后业务部门开始维护产品级别的系统需求说明书，则testlink应当转而以项目为基础进行管理，需求模块也相应只记录每个版本改变的需求，这也更符合testlink本身的架构设计。

在新建测试产品页面，需要填写的栏位包括：

·

名称：

测试产品名称。

如果某个产品较为复杂，也可以分解到模块级别，以该产品的每个模块作为一个测试产品

前缀：

该测试产品下的测试案例的通用前缀（在测试案例建立的时候自动插入到案例标志前），前缀的格式应当为：

“TC-”+测试产品简称

产品描述：

对于该产品的目的，功能等方面的一个简要描述。

增强功能：

一般需要勾选的是“启用需求功能”，“启用测试优先级”。

可用性：

一个产品在新建立的时候应当勾选“活动的”，当其不再被使用，则应取消勾选“活动的”。

一般不应勾选“公共”，则只有被加入到该产品的成员才可以在测试产品下拉菜单中看到该产品；

如果勾选“公共”，则所有testlink用户都可以看到。

第二步，项目经理或测试经理将初始的需求集和需求加入到需求模块中，或对现有的需求集和需求进行修改。

Testlink中的需求是按照模块（而非项目版本）安排的。

需求的树形结构应当为：

产品-》模块-》子模块-》系统需求。

需求的模块和子模块在testlink中都体现为需求集。

在新建需求集的页面，需要填写的栏位包括：

文档ID：

模块或子模块的编号，格式应当为：

TBD

标题：

模块或子模块的名称。

描述：

对于该模块或子模块的目的，功能等方面的一个简要描述。

类型：

一般来说，testlink中应该保存“系统需求集”。

在新建需求的页面，需要填写的栏位包括：

需求ID：

系统需求的唯一编号，格式应当为：

对于每条系统需求的简要描述。

对于每条系统需求的详细描述。

状态：

由于并不使用testlink管理需求的功能，所以在下拉列表中常用的状态只包括（括号内是testlink系统中存储的状态值）：

◦草案（D）：

初次加入（或修改）该需求项时需求尚未通过评审，该需求项未最终确定

◦定稿（F）：

测试完成之前，新加的（或修改的）需求已通过评审，该需求项已最终确定；

如果该需求项在加入testlink时已经确定，则应该直接设置为“定稿”状态

◦已实施（I）：

测试完成后，该需求项已通过全部相关测试，或已通过部分测试但其相关风险已得到决策层认可；

若该需求项未能通过测试，则应当停留在“定稿”状态

◦不可测试（N）：

不具备条件对该需求项进行测试，或该需求项无需测试；

此状态可以在测试分析过程中逐一设置，或在测试完成后统一设置

◦已废弃（O）：

该需求项不再有效，应当在测试全部完成后将其删除；

此状态应该在需求修改（可能是由于初始需求或在项目过程中的需求变更）过程中设置，并在测试完成后从系统中删除

由于并不使用testlink管理需求的功能，所以在下拉列表中常用的类型只包括与测试相关的以下几个（括号内是testlink系统中存储的状态值）：

◦功能/特性

（2）：

产品的功能描述或特性描述

◦用例（3）：

产品的使用或操作的典型场景

◦界面/接口（4）：

产品的UI界面或系统间接口定义

◦非功能性（5）：

非功能性需求，如操作性，性能等

需要的测试案例数：

第三步，测试人员在测试模块中创建初始的测试案例集和测试案例，或对现有的测试案例集和测试案例进行修改。

Testlink中的测试案例是按照模块（而非项目版本）安排的。

产品-》模块-》子模块-》测试案例。

这个树形结构与需求模块中的树形结构应当是一致的。

测试案例的模块和子模块在testlink中都体现为测试案例集。

在新建测试案例集的页面，需要填写的栏位包括：

案例集名称：

关键字：

可选。

在新建测试案例的页面，测试案例填写的栏位包括：

案例名称：

预置条件：

案例级别：

测试数据：

测试工具：

案例评审人/日期：

案例备注：

后置条件：

选填

重要性：

关键字：

第四步，测试经理或测试设计师为当前测试阶段/轮次创建测试计划，并将需要的测试案例加入到测试计划中。

第五步，测试经理或测试设计师创建新的构建，测试人员在执行模块中填写测试结果

第六步，测试结束，测试人员将需求，测试案例，测试计划以及构建归档