测试用例内容规范

1. 字段（测试用例所有属性）

用例编号

模块分类

用例标题

目的

预置条件

环境号

功能号

素材路径

操作步骤

预期输出

测试结果

 

用例级别

通过要求

适用产品 （可以选择多个）

附件

作者

修改说明

版本号

最后修改人

用例更新日期

备注

 

测试结果

测试耗时

测试成功次数

测试失败次数

总测试次数

 

红色：必填

2. 规范

整体测试环境要求：写明需要哪些软、硬件、网络条件。

分类：需要按照软硬件分类。

用例编号：按特性编号，如STB.EPG_Get_01

模块分类：按模块区分即可。

用例标题：直观清晰的表单要测试的内容，不可再分解。

目的：为了达到什么目的。

预置条件：具有完整的状态和数据输入。比如：预热30分钟后。

环境号：实验室的环境编号。如果还没有建立该环境号，请在预制条件中填写；redmine上的环境号或testlink系统上的环境号。

功能号：在redmine系统中有相关的功能，只需要输入该号即可。如果没有，在操作步骤中说明白正在测试哪个功能。

素材路径：测试可能需要测试素材，如码流等。只填写服务器上的路径即可。可能环境一样，但是素材不一样。

操作步骤：具有完整的操作步骤和明确的输入。

预期输出：具有明确的输出。

用例级别：

l  Level0：基本功能用例

对应系统的基本功能。由产品经理和项目经理指定。

含义：该类用例涉及系统基本功能，用于版本提交时作为“版本通过准则”。如果存在不通过的项目时，需要重新提交版本，例如：无法看直播、无法升级、无法搜台、无法画中画等；

划分依据：该用例的执行失败会导致基本功能无法使用，严重影响企业形象和收益。该类用例是系统必须具有的功能，同类产品也一般具有这些功能。

数量：该类用例的数量应受到控制。数量不多。

执行策略：每轮测试都必须严格执行。

l  Level1：重要功能用例

对应系统的重要功能。由产品经理和项目经理指定。

含义：针对一些重要功能的测试用例，该类用例在非回归的系统测试版本中基本上都需要进行验证以保证系统的重要功能都能够顺利实现。

划分依据：该类用例主要包括一些和功能交互相关的用例，各种应用场景的测试用例、一些使用频率较高的基本功能。

数量：数量比0级用例多。

执行策略：在非回归的系统测试版本中基本上都需要进行验证以保证系统的重要功能都能够顺利实现。在实际测试过程中，也可以根据版本当前具体情况安排是否进行测试。

l  Level2：一般功能和非常用操作功能用例

对应系统的一般功能。由产品经理和项目经理指定。

含义：针对系统的一般功能。该功能的使用频率比“重要功能”低。

划分依据：使用频率较低的功能；逻辑简单，也不容易出错的功能用例。

数量：较多。

执行策略：在非回归的系统测试版本不一定都要进行验证，并且在集成测试的中后期并不一定需要每个版本都要进行测试。

l  Level3：约束校验、异常校验类用例

含义：对应系统的预置条件、数据设置、约束限制、异常等处理。该类用例容易导致较严重的错误。

划分依据：正常条件下不会触发的错误。比如：字符串超长。

数量：较多。

执行策略：在版本测试中有某些正常原因（包括：环境、人力、时间等）经过测试经理同意可以不进行测试。

l  Level4：非功能类用例，如性能、压力、安全、界面规范、提示信息、资料等；

含义：所有非功能测试用例。

执行策略：按照产品经理、项目经理要求测试时间进行测试。但是集成测试阶段必须要验证1轮。

适用产品：该用例可以在哪个上测试，比如：通用STB、灵智、灵锐、灵犀、App、7162等。

修改说明：逐次修改的说明。

作者：自动生成。

最后修改人：从Redmine用户中选择。

用例更新日期：自动生成为当前日期。

测试结果：1.Pass：测试通过；2.Fail：测试失败；3.NA：不支持或无此功能4.Block：由于环境因素或模块之间影响等导致测试阻塞

通过要求：二选一：必须通过或 选择通过。

测试耗时：本条耗时消耗多长时间。

测试成功次数：自动计算。根据测试结果为“Pass”的累加。

测试失败次数：自动计算。根据测试结果为“Fail”的累加。

总测试次数：根据所有测试结果，进行累加。