面向安全苛刻系统的自动化测试资源管理方法及其平台 技术领域 本发明属于计算机应用领域， 具体涉及一种面向安全苛刻系统的自动化测试资源 的管理方法及其平台。
背景技术 目前， 应用系统软件规模不断扩大， 复杂度不断增加， 应用系统的质量和可靠性受 到越来越多的重视， 尤其是针对一些安全苛刻系统， 对其进行测试管理自动化非常有必要。 所述的安全苛刻系统本身具有如下特点 ： 系统庞大， 安全可靠性要求高， 分布式， 多用户权 限操作， 具有复杂的地图图形操作和显示功能。系统的庞大和安全苛刻的高要求使得在功 能测试和接口测试要尽可能的自动化， 以提高效率和减少人为误操作。而该分布式系统各 个模块因为需要协同操作和系统本身复杂的地图图形操作使目前已有的功能测试自动化 工具无法满足要求， 因而目前已经开发完成了专用的功能和接口自动化测试工具， 用来实 现自动执行测试脚本和自动验证被测系统的通信消息字段， 这就需要在管理测试用例时需 要支持这些专用的功能和接口自动化测试工具。
当前通用的软件测试管理工具众多， 它们的一个普遍特点是以一个或多个软件测 试标准为基础， 涵盖软件测试的诸多方面， 主要涉及测试流程管理、 测试资源管理、 缺陷管 理、 用户权限管理、 报告管理、 与其他自动化测试工具的互操作性、 应用编程接口 (API) 支 持和部署方式。虽然这些通用测试管理工具的覆盖范围广， 但是对于某些特定系统的测试 管理的某些方面支持并非都是完美的， 以下将围绕这几方面介绍该安全苛刻系统在测试管 理方面的特点， 以及目前已有的开源和商用测试管理工具在这些特点上的优势与不足。
较为成熟的技术主要以实现测试资源和缺陷管理的自动化为核心关注点， 以数据 为核心的管理技术较为成熟， 而测试流程管理的自动化技术本身复杂度较高， 相关的主流 解决方法， 如工作流技术， 远不如数据管理的发展成熟， 还有很多要解决的关键问题。在测 试资源的管理方法方面， 主要是管理测试中使用的主要工件 (Artifacts)， 比如被测对象、 测试需求、 测试计划、 测试用例、 各种文档等， 并定义它们之间的关联以自动实现管理过程 各种资源的一致性。在像 HP Quality Center 和 IBM Rational Quality Manager 这类典 型的商用测试管理工具中， 初始输入一般为测试需求， 根据测试需求生成测试计划， 编写具 体的测试用例的原则与指导。而测试用例根据测试计划以向导的方式创建， 由于测试需求 与测试用例的关联， 使得自动分析当前测试用例的覆盖度成为可能。这些成熟的管理方式 能胜任大部分软件的测试管理工作， 但是在所述的安全苛刻性系统的测试管理中由于专用 自动化测试功能的引入， 管理粒度要比测试用例小得多， 在测试用例下还涉及多个脚本的 管理， 每个脚本有附带的数据分组， 包含多个附加文件。
目前缺陷管理工具较多， 采用的管理方法或模型通常是定义缺陷状态， 并对其进 行跟踪， 这种管理方法流程清晰， 而且较为容易地覆盖缺陷的生命周期。 但是这些工具大都 独立于测试管理工具单独存在， 也可以集成于测试管理工具中。而缺陷往往和测试执行的 用例紧密相关， 属于测试资源的范畴， 所以将缺陷管理工具集成化是当前的主流趋势。
用户权限设计是整个测试管理工具安全性的重要决定因素， 同时也是支持多种角 色的用户在测试管理工具上协同工作的要求。 目前成熟的大型商用测试管理工具都支持基 于角色的访问控制， 用户可以新建角色并定制角色的权限。但是负责所述的安全苛刻系统 的测试组没有覆盖所有角色， 而且测试组要求的一些粒度更细的权限往往在这些通用的测 试管理工具没有体现， 比如评审员只能允许评审测试用例和大纲是否通过。 同时， 放开让用 户可以定制每个角色的既有权限也降低了安全性， 因为除评审员以外的其他角色也可以被 赋予评审权限， 这将成为潜在的安全隐患。
报告管理是软件测试管理工具的必备功能， 在该安全苛刻系统测试过程中需要的 报告包括测试大纲， 测试用例设计说明， 测试结果报告等。 基本覆盖了测试管理工具所有工 件具体信息的导出。目前已有的测试管理工具都具有报告生成功能， 但是报告的定制性有 强有弱， 比如大型的商用工具 IBM Rational Quality Manager 的报告不能同时包含需求、 用例和执行结果， 定制性不强。关于报告管理的另一个重要方面是测度与度量的支持。测 度和度量是指对软件测试过程的量化方案， 以及量化数据的收集和统计等。比如测试用例 覆盖度、 Bug 密度， 测试用例时间进展等指标。对测试过程进行量化有利于对整个测试过程 进行更好的控制。目前的通用测试管理工具支持测度和度量， 但是可选择的指标对于大型 安全苛刻系统的测试来说并不充足。 针对所述的安全苛刻系统， 在测试管理工具中需要集成该安全苛刻系统专用的自 动化测试脚本和数据的编辑界面以及诸如启动录制命令和文件组织的支持。
测试管理工具提供应用编程接口是一个比较高级的应用要求。所提供的 API 的组 织方式有多种 ： 接口面板是一种简洁的方式， 它将接口封装在一个类中， 但是这种方式在接 口很多且具有一定层级关系时显得混乱 ； 另一种方式是带有控制器的接口面板， 可以根据 请求返回不同的面板操作数据， 避免了单一面板可能引起的接口爆炸 ； 一种类似文档对象 模型 (DOM) 的接口方式完全是一种层次型组织， 这种方式需要考虑实体间的关系， 且实现 难度大， 但是在业务实体间具有很明显的单棵树的树型组织时这种方法比较直接。在应用 编程接口的提供方面， 一般开源的管理工具甚至某些成熟的商用的测试管理工具对此的支 持都不够， 比如 IBMRational Quality Manager， 只有针对重置 (REST) 请求的 API， 但是没 有相关的文档支持。
在测试管理工具体系结构的选择上， 一般采用浏览器 / 服务器 (B/S) 较多， 这种方 式部署简单， 客户端占用资源少， 但是表现力和交互能力不如客户机 / 服务器 (C/S) 结构， 因此， 在具有控制功能特点的测试管理系统多见 C/S 结构， 需要与自动化的执行程序交互， 如果选择 B/S 结构就不能很好的完成任务。
发明内容
本发明的目的是为了解决所述的安全苛刻系统缺失一种集成的、 适用的自动化测 试资源管理方法， 提出一种面向安全苛刻系统的自动化测试资源管理方法及其平台。
本发明一种面向安全苛刻系统的自动化测试资源管理方法包括以下步骤 ：
步骤 1 ： 对用户输入的用户名和密码进行验证， 若用户名和密码验证未通过， 提示 用户重新输入用户名和密码， 直到用户名和密码验证通过， 在用户名和密码验证通过后， 如 果用户具有系统管理员角色， 则判断该用户是否要进行用户管理操作， 若是， 进行用户管理操作， 若否， 执行步骤 2。
步骤 2 ： 创建测试工程并填写其属性， 或者从数据库中读取已有的测试工程， 所述 的测试工程代表对某一版本的安全苛刻系统的测试。
步骤 3 ： 选择测试管理类型 ： 如果选择测试用例管理， 转至步骤 4 ； 如果选择测试过 程管理， 转至步骤 7 ； 如果选择文档管理， 转至步骤 10。
步骤 4 ： 在指定的测试工程下添加测试项， 测试项下能再继续添加测试项， 并填写 测试项的属性信息。
步骤 5 ： 在指定的测试项下创建测试用例并填写测试用例的属性信息， 测试用例 具有版本特征。
步骤 6 ： 编辑测试项和测试用例的详细信息， 为测试用例添加自动化测试所需的 脚本文件和相应的数据文件。在测试项和测试用例建立完毕后自动生成测试说明文档， 然 后返回步骤 3 ； 所述的测试项的详细信息包括测试项所涉及的测试类型， 以及每个测试类 型中包括的测试方法、 测试输入、 测试输出和判断准则 ； 所述的测试用例的详细信息包括各 个测试步骤的步骤描述和预期结果。每个测试用例的脚本文件可以包括多个数据文件， 每 个数据文件可以提供脚本完整执行一次所需的全部数据， 这体现了数据驱动测试的思想。 步骤 7 ： 在指定的测试工程下创建测试阶段， 所述的测试阶段可以包括自测试、 系 统测试、 验收测试和任意用户自定义的测试阶段 ； 所述的测试阶段下包括一个以上文档， 每 个文档包括一个以上文档版本。
步骤 8 ： 为已有的测试用例指定测试阶段， 若不存在所需要的测试用例， 则转步骤 5 创建所需要的测试用例。
步骤 9 ： 执行测试用例， 如果测试用例执行不成功， 则执行 Bug 管理活动， 并在测试 阶段的 Bug 管理活动结束之后生成阶段测试报告， 然后结束执行本次自动化测试资源管理 方法 ； 如果测试用例执行成功， 则将测试用例的存入数据库中， 然后结束执行本次自动化测 试资源管理方法 ； 所述的 Bug 管理活动结束的标志是该测试阶段下的所有 Bug 报告都已经 为关闭状态， 所述的 Bug 管理活动具体是 ： 定义 Bug 节点， 通过 Bug 状态监控组件对 Bug 状 态变化进行跟踪管理， 所述的 Bug 节点与具体的测试用例引用关联。
步骤 10 ： 在指定的测试阶段下创建文档， 或创建文档的新版本， 并对文档进行下 载、 上传或删除的操作， 然后转步骤 3 执行。
本发明一种面向安全苛刻系统的自动化测试资源管理平台， 包括包括客户端和服 务器端， 服务器端包括关系型数据库， 客户端包括核心模块、 测试用例管理模块、 测试过程 管理模块、 文档管理模块、 Bug 管理模块 ； 测试用例管理模块、 测试过程管理模块、 文档管理 模块与 Bug 管理模块都包括界面层子模块和业务层子模块， 核心模块包括核心界面层子模 块、 核心业务层子模块和核心数据层子模块。
核心界面层子模块定义了主界面以及各个布局， 并通过抽象接口 Context 定义了 对主界面的所需操作， 还提供了用于验证用户名和密码的界面以及对系统管理员提供了进 行用户管理操作的功能， 测试用例管理模块、 测试过程管理模块、 文档管理模块与 Bug 管理 模块的界面层子模块都通过抽象接口 Context 操作主界面 ； 核心业务层子模块定义了抽象 节点类 Node， 加载或者创建测试工程 ； 核心数据层子模块在核心业务层子模块加载或者创 建测试工程时从关系型数据库中读取相应树型组织和实体类节点的数据传送给测试用例
管理模块、 测试过程管理模块、 文档管理模块和 Bug 管理模块的业务层子模块， 并将测试用 例管理模块、 测试过程管理模块、 文档管理模块和 Bug 管理模块的业务层子模块更新的树 型组织和实体类节点的数据传送给关系型数据库进行保存。
测试用例管理模块的业务层子模块用于定义测试用例管理的树型组织和实体类 节点， 具体是 ： 在指定的测试工程下添加测试项， 在测试项下继续添加测试项或者创建测试 用例， 填写测试项和测试用例的属性信息以及详细信息， 为测试用例添加自动化测试所需 的脚本文件和相应的数据文件， 所述的测试用例具有版本特征 ； 测试过程管理模块的业务 层子模块用于定义测试过程管理的树型组织和实体类节点， 具体是 ： 在指定的测试工程下 创建测试阶段， 为已有的测试用例指定测试阶段， 若不存在所需要的测试用例， 通过测试用 例管理模块的业务层子模块中创建所需要的测试用例， 所述的测试阶段下包括一个以上文 档， 每个文档包括一个以上文档版本 ； 文档管理模块的业务层子模块用于定义文档的结构 组织和实体类节点， 具体是 ： 在测试阶段下添加文档， 在文档下增加文档版本， 文档管理模 块的业务层子模块还在测试项和测试用例建立完毕后自动生成测试说明文档， 以及在测试 用例执行完毕后自动生成测试报告 ； Bug 管理业务层子模块用于定义 Bug 节点， 通过 Bug 状 态监控组件对 Bug 状态变化进行跟踪管理， 所述的 Bug 节点与具体的测试用例引用关联， 并 在测试阶段的 Bug 管理活动结束之后生成阶段测试报告 ； 测试用例管理模块、 测试过程管 理模块和文档管理模块的业务层子模块中定义的实体类节点， 以及 Bug 管理模块中定义的 Bug 节点均继承自核心模块的业务层子模块定义的抽象节点类 Node。 本发明为具有分布式、 操作系统异构性的特点的安全苛刻系统的自动化测试资源 提供诸如用例管理、 文档管理以及 Bug 管理的统一服务， 同时资源管理从时间上覆盖测试 阶段， 有效支持对安全苛刻系统的黑盒测试。 与传统的软件测试管理方法和工具相比， 本发 明的优点与积极效果在于 ：
(1) 本发明统一管理了软件测试中通常被独立的资源， 比如文档管理和 Bug 管理， 集成的管理方法利于这些资源与测试管理中的核心部分的关联， 避免了将这些管理软件独 立出来后产生的管理混乱。同时针对被测系统较为复杂的特点， 将测试计划和测试需求整 合在一起形成一个称为测试项的节点， 各个测试用例是测试项的子节点， 这种树型结构和 每个节点形象地表达了测试需求、 测试计划和测试用例的各自信息和内在联系， 简化了用 户操作。
(2) 本发明支持不同视角的软件测试管理， 即静态纵向的测试用例组织， 以及动态 横向以时间为视角的测试阶段定义和管理， 多重视角的测试资源管理符合测试人员的实际 测试需求。
(3) 本发明可对测试对象各个分系统与配置的管理， 并符合安全苛刻系统的具体 组成， 能够使测试者明确测试用例与具体测试对象的对应关系。
(4) 本发明支持该安全苛刻系统专用自动化测试工具， 在测试用例编辑中可以上 传不同主机节点的脚本文件， 每个脚本文件可以创建不同数据分组， 每个分组有一个数据 文件和多个附加文件， 以支持基于数据驱动的软件自动化测试， 符合当今软件测试从手工 逐步转化为自动化测试的趋势。
(5) 本发明支持大部分实体的属性和详细信息以常见格式进行数据导出， 也具有 按照 GJB-438B 标准的要求自动生成测试说明文档和测试报告的功能， 提高了自动化测试
资源管理的互操作性和可用性。 附图说明
图 1 为本发明的自动化测试资源管理方法的步骤流程图 ； 图 2 为本发明自动化测试资源的管理平台的模块结构示意图 ； 图 3 为本发明多叉树形所表示的对测试资源组织的实施例示意图 ； 图 4 为本发明的自动化测试资源的管理方法与平台中的数据库存储的实体 - 关系表图。 具体实施方式
下面将结合附图和实施例对本发明作进一步的详细说明。
本发明针对一种大型分布式安全苛刻系统的测试， 采用基于 Qt 的 C/S 架构设计并 实现测试管理方法及相应平台， 重点关注测试工件之间的关联、 审计管理、 测度和度量， 以 及支持专用自动化测试工具这几方面， 而不对众多复杂的测试管理标准、 规范和其他管理 细节面面俱到。
如图 1 所示， 本发明提供的一种面向安全苛刻系统的自动化测试资源管理方法， 由如下步骤组成 ：
步骤 1 ： 用户验证。首先对用户输入的用户名和密码进行验证， 若验证错误， 即出 现用户名错误或者密码错误的情况， 提示用户重新输入用户名和密码， 直到用户名和密码 验证通过。 若验证通过， 判断是否要进行用户管理操作， 若是， 则进行用户管理操作， 如果用 户具有系统管理员的角色， 可以选择用户管理操作， 例如创建新的用户， 为已有用户添加和 删除角色， 以及删除用户等。若不再进行用户管理操作， 执行步骤 2。
步骤 2 ： 创建测试工程并填写其属性， 或者从数据库中读取已有的测试工程。所述 测试工程代表对某一版本的安全苛刻系统的测试， 是所有测试实体的顶层组织。所述的测 试工程的属性主要包括名称、 创建时间、 创建者以及相关备注信息等。
步骤 3 ： 进行测试管理类型选择 ： 如果选择测试用例管理， 则转至步骤 4 ； 如果选择 测试过程管理， 则转至步骤 7 ； 如果选择文档管理， 则转至步骤 10。 所述的测试用例管理、 测 试过程管理和文档管理均设计了人机交互界面， 使方便用户的查看和操作。
所述的测试用例管理是测试用例的静态组织， 是一种多叉树型的结构， 根节点是 某一测试工程， 测试工程下包括若干测试项， 测试项可以嵌套包括子测试项， 也可包括测试 用例， 同一测试用例包括若干版本， 测试用例版本是测试用例管理的树型结构组织的叶子 节点。
所述的测试过程管理是以时间为视角对测试用例等测试资源的组织， 也是一种多 叉树型结构， 根节点也是某一测试工程， 测试工程下包括若干测试阶段。 实际上在测试资源 管理中， 测试阶段是测试用例的一个属性。测试阶段下包括若干文档， 文档包括若干版本， 文档的版本定义和测试用例的版本定义相同， 文档版本是测试过程管理的树型结构组织的 叶子节点。
所述的文档管理是指对测试阶段下的文档的管理， 在测试阶段下添加文档， 在文 档下增加文档版本， 对文档进行新建、 删除、 上传、 下载等操作。步骤 4 ： 在指定测试工程下添加测试项并填写测试项的相关属性信息。所述的测 试项的相关属性信息主要包括名称、 唯一标识、 创建者和创建时间、 参考引用、 描述、 设计约 束、 测试约束、 内容与要求以及停止条件等。测试项是对测试用例的一种层次化组织， 可以 赋予测试项具体的意义， 比如代表一个分系统的测试或者一个模块的测试， 测试项可以嵌 套， 比如代表某个分系统的测试项可以包括若干代表模块的测试项。
步骤 5 ： 在指定测试项下创建测试用例并填写测试用例的相关属性信息。所述的 测试用例的相关属性信息包括名称、 唯一标识、 创建者、 创建时间、 版本、 测试用例状态、 测 试类型、 描述、 前置条件以及参考文件等， 测试用例具有版本特征， 即某个名称的测试用例 可以包含多个版本。
所述的测试用例支持多版本管理， 版本号采用三段式， 包括小版本号、 中版本号和 大版本号， 版本号起始是 1.0.0。小版本号是未评审的更新， 在未评审时， 每做一次改动， 用 户可以选择增加小版本号 ； 中版本号是评审号， 在同一个测试阶段内， 每经过一次评审， 中 版本号增加 ； 大版本号与测试阶段相关， 如果测试用例被复用到其他测试阶段作为测试用 例， 而且名称没有改变， 则增加大版本号。版本号也可以是用户自定义的任意字符串。
步骤 6 ： 编辑测试项和测试用例的详细信息， 为测试用例添加自动化测试所需的 脚本文件和相应的数据文件， 在测试项和测试用例建立完毕后自动生成测试说明文档， 然 后返回步骤 3。
所述的测试项的详细信息包括测试项所涉及的测试类型， 如接口测试、 功能测试 等， 以及每个测试类型中包括的测试方法、 测试输入、 测试输出和判断准则 ； 测试用例的详 细信息包括各个测试步骤的步骤描述和预期结果。
步骤 7 ： 在指定的测试工程下创建测试阶段， 测试阶段是从时间角度对测试资源 的划分， 测试阶段包括自测试、 系统测试、 验收测试等。 各测试阶段下包含一个或多个文档， 每个文档下又包含一个或多个文档版本。
步骤 8 ： 为已有的测试用例指定测试阶段。 测试用例的测试阶段也可以在步骤 5 新 建测试用例中完成。若当前没有所需要的测试用例， 则转步骤 5 执行， 创建所需要的测试用 例， 若存在， 为该测试用例指定测试阶段。由于对自动化软件测试的支持， 测试用例包含可 执行的测试脚本和数据文件， 这样测试用例便具有可执行特征， 同时测试用例是测试脚本 编辑器和测试任务执行器的输入。所述的测试脚本编辑器和测试任务执行器为外界组件， 测试脚本编辑器用于编辑测试用例下各个可以自动执行的脚本文件， 测试任务执行器用于 将已有的测试用例组织成测试任务， 并控制测试任务下测试用例的执行、 暂停、 停止， 以及 执行结果的收集。
步骤 9 ： 执行测试用例， 如果测试用例执行不成功， 则执行 Bug( 缺陷 ) 管理活动， 监控 Bug 的状态变化， 直至所有 Bug 处于关闭状态。所述的 Bug 管理活动具体是 ： 定义 Bug 节点， 通过 Bug 状态监控组件对 Bug 状态变化进行跟踪管理。所述的 Bug 管理中的 Bug 与 具体的测试用例引用关联， Bug 生命周期的状态包括初始态、 就位态、 反馈态、 解决态和关闭 态， Bug 管理将监督每个 Bug 在生命周期中的各个状态， 直至 Bug 被关闭为止。在测试阶 段的 Bug 管理活动结束之后生成阶段测试报告， 然后结束执行本次自动化测试资源管理方 法。所述的 Bug 管理活动结束的标志是该测试阶段下的所有 Bug 报告都已经为关闭状态。 如果测试用例执行成功， 则更改该测试用例的状态为 “成功执行” ， 同时由测试任务执行器将测试用例的执行结果存入数据库， 然后结束执行本次自动化测试资源管理方法。
步骤 10 ： 在指定的测试阶段下创建文档或已有文档的新版本， 并对文档进行下 载、 上传、 删除等操作， 然后转步骤 3 执行。
一种面向安全苛刻系统的自动化测试资源管理平台， 基于 Qt 类库构建， 为 C/S( 客 户端 / 服务器端 ) 结构， 客户端采用 C++ 语言以面向对象方法开发。 本发明自动化测试资源 管理平台的核心包括对各个管理实体比如测试工程、 测试项和测试用例等的定义和关联， 以及对整个测试资源的状态和行为定义。如图 2 所示， 所述的自动化测试资源管理平台的 客户端包括核心模块 1、 测试用例管理模块 2、 测试过程管理模块 3、 文档管理模块 4、 Bug 管 理模块 5， 其中， 测试用例管理模块 2、 测试过程管理模块 3、 文档管理模块 4 以及 Bug 管理 模块 5 都分别包括界面层子模块与业务层子模块， 具体是测试用例管理模块 2 包括测试用 例管理界面层子模块 21 和测试用例管理业务层子模块 22， 测试过程管理模块 3 包括测试 过程管理界面层子模块 31 和测试过程管理业务层子模块 32， 文档管理模块 4 包括文档管 理界面层子模块 41 和文档管理业务层子模块 42， Bug 管理模块 5 包括 Bug 管理界面层子模 块 51 和 Bug 管理业务层子模块 52。核心模块 1 包括核心界面层子模块 11、 核心业务层子 模块 12 和核心数据层子模块 13。所述的自动化测试资源管理平台的服务器端包括关系型 数据库 6。 所述的关系型数据库 6 用于持久化自动化测试资源管理平台中的需要保存的数 据， 例如如图 4 所示的测试工程信息、 测试阶段信息、 测试项信息、 测试用例信息等等， 还包 括测试用例执行结果。
核心界面层子模块 11 定义了界面布局， 为测试用例管理界面层子模块 21、 测试过 程管理界面层子模块 31、 文档管理界面层子模块 41 和 Bug 管理界面层子模块 51 提供基本 的界面容器和工具。 核心业务层子模块 12 为测试用例管理业务层子模块 22、 测试过程管理 业务层子模块 32、 文档管理业务层子模块 42 和 Bug 管理业务层子模块 52 提供了一些顶层 抽象。
核心界面层子模块 11 通过继承自 Qt 主界面模板 QMainWindow 定义了主界面， 以 及各个布局。布局主要包括六个部分， 分别是菜单栏、 工具栏、 Dock 列表区、 属性 Dock 区、 编辑区和状态栏。 Dock 是图形用户界面中能够悬浮或者加载到主界面之上的一种界面元素 控件。其中， Dock 列表区在主界面上共有四个部分， 均可以显示测试资源管理涉及的实体 组织结构及相关操作的视图。以上各个区域中的控件应继承自 Qt 的相关控件类。核心界 面层子模块 11 通过抽象接口 Context 定义了对主界面的所需操作， 如添加菜单， 添加 Dock 区控件等， 测试用例管理界面层子模块 21、 测试过程管理界面层子模块 31、 文档管理界面 层子模块 41 和 Bug 管理界面层子模块 51 通过抽象接口 Context 操作主界面。
核心业务层子模块 12 定义了抽象节点类 Node， 树型关系结构中的各个功能模块 的业务层子模块组成的树形结构的各个实体节点均继承自 Node， 如图 3 所示。
核心数据层子模块 13 用于为测试用例管理业务层子模块 22、 测试过程管理业务 层子模块 32、 文档管理业务层子模块 42 和 Bug 管理业务层子模块 52 提供数据库数据的增 加、 删除、 修改和获取操作， 并负责对数据库 6 的连接管理。核心数据层子模块 13 将更新的 数据传送给数据库 6 中保存， 或者从数据库 6 中读取数据传送给测试用例管理业务层子模 块 22、 测试过程管理业务层子模块 32、 文档管理业务层子模块 42 和 Bug 管理业务层子模块
52。 测试用例管理界面层子模块 21 包括测试项树型列表组件， 测试用例树型列表组 件， 测试工程、 测试项和测试用例的属性编辑组件， 以及测试项和测试用例的详细信息编辑 组件。测试用例管理界面层子模块 21 为用户操作提供可视化界面， 用于显示测试用例管理 的数据和数据组织， 并通过测试用例管理业务层子模块 22 对测试工程、 测试项和测试用例 的属性进行编辑， 对测试项和测试用例的详细信息进行编辑。所述的测试工程的属性主要 包括名称、 创建时间、 创建者以及相关备注信息等。所述的测试项的属性主要包括名称、 唯 一标识、 创建者和创建时间、 参考引用、 描述、 设计约束、 测试约束、 内容与要求以及停止条 件等。所述的测试用例的属性主要包括名称、 唯一标识、 创建者、 创建时间、 版本、 测试用例 状态、 测试类型、 描述、 前置条件以及参考文件等。所述的测试项的详细信息包括测试项所 涉及的测试类型， 以及每个测试类型中包括的测试方法、 测试输入、 测试输出和判断准则。 所述的测试用例的详细信息包括各个测试步骤的步骤描述和预期结果。
测试用例管理业务层子模块 22 中主要用于定义测试用例管理的树型组织和实 体类节点， 具体是 ： 在指定的测试工程下添加测试项， 在测试项下继续添加测试项或者创 建测试用例， 填写测试项和测试用例的属性信息以及详细信息， 为测试用例添加自动化测 试所需的脚本文件和相应的数据文件， 所述的测试用例具有版本特征。测试用例管理业 务层子模块 22 通过核心数据层子模块 13 对关系数据库 6 中存储的树型组织和实体类节 点的数据进行更新操作。测试用例管理业务层子模块 22 定义的测试用例管理的多叉树 组织， 按照树的层次关系， 其节点类型依次包括测试工程节点 ProjectNode、 静态组织节 点 StaticOrgNode， 测试项节点 TestItemNode、 测试用例节点 CaseNode、 测试用例版本节 点 CaseVersionNode， 其中， 测试项节点 TestItemNode 也可以嵌套包括本身类型的节点。
TestItemNode 节点上层是一种组织类型的节点 StaticOrgNode， 类似于节点集合。
测试过程管理界面层子模块 31 包括测试阶段树型列表组件。测试过程管理界面 层子模块 31 为用户操作提供可视化界面， 通过测试过程管理业务层子模块 32 对测试阶段 进行删除、 新建和重命名等操作， 以及对数据实体的编辑功能， 包括属性编辑和详细信息编 辑。
测试过程管理业务层子模块 32 主要用于定义测试过程管理的树型组织和实体类 节点， 具体是 ： 在指定的测试工程下创建测试阶段， 为已有的测试用例指定测试阶段， 若不 存在所需要的测试用例， 通过测试用例管理模块的业务层子模块中创建所需要的测试用 例， 所述的测试阶段下包括一个以上文档， 每个文档包括一个以上文档版本。 测试过程管理 业务层子模块 32 通过核心模块数据层对关系数据库 6 中存储的树型组织和实体类节点的 数据进行更新操作。测试过程管理业务层子模块 32 主要是测试过程管理的多叉树组织， 按照树的层次关系， 其节点类型依次包括测试过程组织节点 ProcOrgNode、 测试阶段节点 PhaseNode、 其中 ProcOrgNode 不属于实际的实体节点， 是对下级节点的一种组织。
文档管理模块 4 从业务逻辑角度属于测试过程中的资源组织。文档管理界面层子 模块 41 包括文档组织树型列表组件、 文档版本列表组件和文档属性编辑组件。文档管理界 面层子模块 41 的功能是对文档组织树型列表和文档版本列表组件进行显示和操作， 对文 档属性进行编辑。
文档管理业务层子模块 42 主要用于定义文档的结构组织和实体类节点， 具体是 ：在测试阶段下添加文档， 在文档下增加文档版本。文档管理业务层子模块 42 通过核心模 块的数据层对关系型数据库 6 中的文档结构组织和实体类节点数据进行更新操作， 同时文 档管理业务层子模块 42 还实现了测试说明和测试报告的自动生成， 测试说明是在测试项 和测试用例建立完毕后自动生成， 按照 GJB-438B 标准编写的模板， 将生成的测试工程、 测 试项和测试用例信息填入模板中生成的。测试报告在一个测试阶段的测试用例执行完成 之后生成， 测试阶段完成的标志是该测试阶段下的 Bug 报告都已经关闭， Bug 管理活动已 结束。文档管理业务层子模块 42 中定义的文档的结构组织， 节点类型包括文档组织节点 DocumentOrgNode、 文档节点 DocumentNode 和文档版本节点 DocumentVersionNode， 所有节 点隶属于某一测试阶段节点 PhaseNode。
Bug 管理界面层子模块 51 包括 Bug 管理树型列表组件和 Bug 属性组件， 为用户操 作提供可视化界面。Bug 管理界面层子模块 51 的功能为 ： Bug 管理树型列表的显示包括创 建 Bug 报告、 填写 Bug 报告单的 Bug 描述、 所属用例版本、 复现方法、 提交目标信息。
Bug 管理业务层子模块 52 用于定义 Bug 节点 BugNode， Bug 节点 BugNode 属于测 试阶段节点 PhaseNode， 并与具体的测试用例引用关联， Bug 状态监控组件负责实现 Bug 状 态变化的跟踪管理。在测试阶段的 Bug 管理活动结束之后 Bug 管理业务层子模块 52 生成 阶段测试报告。
图 2 中各个业务层子模块之间的双向箭头指的是依赖关系， 具体为测试用例管理 业务层子模块 22 的测试用例对象和文档管理业务层子模块 42 中的文档对象需要了解所属 的测试过程管理业务层子模块 32 中那个测试阶段对象， 而测试过程管理业务层子模块 32 中的测试阶段对象也需要了解本身包括哪些测试用例和文档对象。Bug 管理业务层子模块 52 中的 Bug 对象属于测试用例管理业务层子模块 22 中的某个测试用例对象， 而测试用例管 理业务层子模块 22 中的测试用例对象包括 Bug 管理业务层子模块 52 中的多个 Bug 对象。
本发明的自动化测试资源管理平台是人机交互驱动的， 平台的界面行为和状态反 映该平台当前运行情况。测试资源的管理以测试工程为基础， 再加上数据一致性而导致的 状态， 平台的状态可以分为初始态、 数据一致态、 数据正向非一致态、 数据反向非一致态和 数据混合非一致态。以下具体说明这些状态， 以及之间的转化。
初始态是指平台启动， 初始化各个功能模块界面层的组件， 并添加到统一的界面 平台的相应位置， 但是没有加载测试工程以及其他数据。
数据一致态是指已经加载测试工程， 而且平台数据与服务器端数据库 6 中的数据 一致。
数据正向非一致态是指已经加载测试工程， 但是用户在平台中修改了数据， 但是 没有写入数据库 6， 这时需要保存操作到达数据一致态。
数据反向非一致态是指已经加载测试工程， 但是数据库 6 中数据被其他用户修 改， 当前平台的数据已经过期， 这时平台需进行刷新操作到达数据一致态。
数据混合非一致态较为复杂， 是指平台已经加载了某测试工程， 但是数据库 6 中 的某些数据被其他用户修改造成平台的这些数据过期， 同时平台的另一些数据被用户修 改， 但是还没有写入到数据库 6 中， 这时既有数据正向非一致态， 也有数据反向非一致态。 这时如果用户保存的是过期后修改的脏数据， 平台应报错并提示用户先刷新， 用户如果保 存的数据不是过期后修改的数据， 则写入正常。以数据一致性和测试工程加载为中心划分状态很重要， 因为对这些状态的考虑能 够在退出平台运行或者关闭界面某些组件时提示用户保存数据， 避免用户丢失数据， 这对 于以数据管理为核心的资源管理平台意义重大。
下面以一个实例介绍本发明面向某安全苛刻系统的自动化测试资源管理平台的 操作流程。
首先平台进行初始化过程， 在核心界面层子模块 11 定义的主界面中激活测试用 例管理模块 2、 测试过程管理模块 3、 文档管理模块 4 以及 Bug 管理模块 5 的界面层子模块， 测试用例管理模块 2、 测试过程管理模块 3、 文档管理模块 4 以及 Bug 管理模块 5 的界面层 子模块创建空的树型列表视图组件， 并放在主界面的相应 Dock 列表区， 初始化各个模块的 菜单单例对象并放在主界面菜单栏上， 主界面为初始态。以上涉及的组件在平台的声明周 期内均为单例。
初始化结束后选择打开指定的测试工程， 测试用例管理模块 2、 测试过程管理模块 3、 文档管理模块 4 以及 Bug 管理模块 5 在平台中可见的树型列表视图控件根据测试工程加 载相应数据。
用户可以选择进行测试用例管理模块 2、 测试过程管理模块 3 或文档管理模块 4 的 操作， 以进行测试过程管理模块 2 操作为例， 可以在测试阶段列表视图中通过右键对测试 阶段进行删除、 添加、 显示属性等操作， 例如选择某个测试阶段的属性菜单项， 在界面的属 性编辑区将出现测试阶段属性编辑控件的实例， 可以在控件中重新编辑测试阶段的各个属 性并保存至数据库。
在对测试用例管理模块 2、 测试过程管理模块 3 进行操作中， 可以拖动测试用例到 测试任务执行器和测试脚本编辑器， 即向外界组件提供测试用例， 以支持测试的自动化要 求。
可以在测试资源管理平台处于数据一致的状态下以常见格式如 Html、 Word， 导出 大部分数据实体对象， 以及包含的子对象， 比如测试工程、 以及包含的测试项、 测试用例等。 导出的数据实体对象主要是对象的属性信息和详细信息， 同时根据这些信息提供测试说明 文档的自动生成功能。在测试阶段的 Bug 管理活动结束之后， 可以自动生成测试报告。
在任务执行完毕后， 根据任务执行情况启动 Bug 管理， 可以在 Bug 管理视图和 Bug 属性视图中跟踪 Bug 的状态。
在本实施例的实施中， 平台与数据库的通信遵循 “惰性加载” 原则， 用户只有需要 获取数据库的数据时才进行具体的通信操作， 而不是初始时便加载数据库中的所有测试用 例信息， 而是根据界面显示的需要按需获取， 不管用户是否用到。 “惰性求值” 策略有利于在 一定程度上平衡负载， 在一定程度上提高了平台的可用性和易用性。
如图 3 所示， 为一对测试资源的组织采用多叉树形结构表示的示意图， 代表本发 明所述的测试资源管理平台各个模块所有业务层子模块中所有对象的组织关系。 根节点是 测试工程对象 ProjectNode， 它包括两种组织节点， StaticOrgNode 和 ProcOrgNode 对象， 分 别代表静态测试资源的组织管理和动态测试资源的组织管理。 静态测试资源管理包括测试 项节点 TestItemNode 对象和测试用例节点 CaseNode 对象， 其中测试项节点可以包括下级 测试项节点， 也可以包括测试用例节点。动态测试资源管理节点缺陷管理节点 BugOrgNode 对象和文档组织节点 DocumentOrgNode 对象， 缺陷管理节点包括各个缺陷节点 BugNode 对象， 文档组织节点包括各个文档节点 DocumentNode 对象。
如图 4 所示， 为测试资源管理平台数据存储的实体 - 关系模型。平台的所有数据 通过八个表存储在关系型数据库 6 中 ： Project 表存储测试工程信息 ； Phase 表存储测试阶 段， 依赖 Project 表 ； TestItem 表存储测试项信息， 依赖于 Project 表和 TestItem 本身 ； Case 表存储测试用例信息， 依赖于 Project 表、 Phase 表和 TestItem 表 ； Func_Script_File 表存储自动化测试脚本信息， 依赖于 Case 表 ； Func_Data_File 表存储自动化测试脚本所需 的数据文件信息， 依赖于 Func_Script_File 表 ； Document 表存储文档信息， 依赖于 Project 表和 Phase 表 ； Bug 表存储 Bug 报告信息， 依赖于 Case 表。