测试管理平台使用需求说明

测试管理平台使用需求说明

基本要求：同一时刻10个以上并发用户数，并可无限升级。管理平台界面友好、人性化，操作简单、维护方便、高效、稳定、可靠。

1.整体架构（树形文件架构）

具体规划如下图：

2.测试流程图

如下图所示，要求每一节点状态变化时有邮件通知下一流程负责人。

内容上：除了有流程记录LIST外，需提供实时更新状态的流程图。

3.BUG子流程

采用微软BUG管理流程，如下图所示：

样品（2

用户手册

测试需求

测试版本包

驱动

测试

负责人

4.流程节点具体描叙

4.1出厂测试管理

经过与研发、生产和质量的探讨，初步确定这块的具体流程如下：

质量发起出厂测试任务委托→测试组业务受理→起草测试项和测试用例→研发产品或项目负责人审批→执行出厂测试任务→输出测试报告→质量确认→发起入库

要求每一节点状态变化时有邮件通知下一流程负责人。

4.2测试任务流

统一由研发版本与产品管理（孙娴）创建测试任务并上传测试版本附件→任务缓冲池按优先级排队→测试负责人审批并分配任务→任务执行和状态更新→任务完成

要求每一节点状态变化时有邮件通知下一流程负责人。

4.3测试计划

4.3.1测试计划创建

由测试任务负责人编写测试计划，然后发起测试计划审批流程，并以附件形

式上传测试计划（草稿版）。

4.3.2测试计划审批

邮件通知指定人员参加测试计划评审会议。邮件内容：

1.标题：XXX测试计划评审会议

2.会议时间：可填

3.会议地点：可填

4.参会人员：研发项目组成员+测试人员

4.3.3测试用例管理

目前的测试用例是基于LabVIEW的小程序（功能单一的模块），在测试管理

平台上很难实现自动执行用例。因此，测试用例的管理是基于文件的测试用

例库管理（LIST形式），不同产品的测试可以重新组合测试用例集。

测试用例的命名规则如下：

用例名的组成：测试类别（UT/LT/PT/FT/ST）+功能类别（描叙缩写）+ID

（2012XXXXXX）+版本号（V100）。

其中，测试类别UT代表单元测试、LT代表指标测试、PT代表性能测试、FT

代表功能测试和ST代表安全等级测试。

功能测试用中文或英文简要描叙即可（尽量简短）。

ID由年份+6位数字组成（不允许重号）。

版本号初始为V1.0.0（文件名写成V100），后面的升级版本在最后一位上依

次加1。

以上各部分的中间连接符用下划线“_”。

实例如下：

FT_AI_2012000001_V100——描叙为模拟量输入功能测试，版本为V1.0.0，

4.3.4测试用例集执行

如果用例库中有现存的测试用例，则直接调入本测试用例集，作为测试计划

的部分测试用例。后期会考虑自动化测试，则以测试用例集为单位，自动按

顺序执行用例集中的所有测试用例。然后自动生成测试报告，如果测试项有

FAIL的则自动创建BUG，并统计测试用例执行情况和BUG统计情况。

4.3.5BUG流管理

按照上面提到的BUG子流程图来进行BUG管理，要求每一节点状态变化时

有邮件通知下一流程负责人。

内容上：除了有流程记录LIST外，需提供实时更新状态的流程图。

4.3.6测试报告

1.半自动方式：提供测试报告生成模板，按照提示添加测试项和数据（要

求具体项目支持可认为编辑或调整）。整个报告格式要求为HTML或PDF

格式。

2.全自动方式：自动执行测试用例集，并生成测试报告。

3.手动上传：可手动上传测试报告文档。

4.3.7报表与统计

1.测试用例执行报表

2.BUG统计报表（类型、严重程度、状态和与测试人员关联的BUG统计）

严重程度统计，如下图（参考）：

备注：“1”表示“严重”；“2”表示“高”；“3”表示“中”；“4”表示“低”。

统计数据（表和图形）可写入测试报告中。

4.4测试工具集成

4.4.1自动化测试工具

自动化测试方向，可编辑的自动化测试序列，序列中的每一模块作为一个独

立的、标准化的测试用例来执行，并向指定位置（多行文本框、测试报告或

指定格式的文件中）写入测试数据，最后自动生成测试报告。

4.4.2MSA数据分析工具

MSA(测试量系统分析)工具，提供常用的数据分析，方差、均方根值、平均

值、曲线拟合、数据与图标的转换、测试测量系统的可行性分析（数据或曲

线图）等。

4.4.3其他常用工具

参考同行。

4.5用户管理与系统维护

提供人性化的用户管理和系统维护界面，并有数据备份方案和系统应急预案等。5.培训文档

应提供如下文档：

1.用户手册。

2.操作指南（PPT和视频教程）。