JR∕T 0101-2013 银行业软件测试文档规范(金融).pdf

《JR∕T 0101-2013 银行业软件测试文档规范(金融).pdf》由会员分享，可在线阅读，更多相关《JR∕T 0101-2013 银行业软件测试文档规范(金融).pdf（117页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、 ICS 35.240.40 A11 JR 中 华 人 民 共 和 国 金 融 行 业 标 准 JR/T 01012013 银行业软件测试文档规范 Specification of banks software test documentation 2013-03-14 发布 2013-03-14 实施 中国人民银行 发 布 JR/T 01012013 I 目 次 前言.VIII 引言.IX 1 范围.1 2 规范性引用文件.1 3 术语与定义.1 3.1 基础概念.1 3.2 被测对象.3 3.3 测试种类.4 3.4 测试相关文档.6 3.5 测试结果与质量.7 4 测试文档规范度.9 4

2、.1 单项测试和联动测试.9 4.2 基本策略.9 4.3 软件完整性级别与软件测试文档规范度的关系.9 4.4 测试文档规范度分级.10 4.4.1 1 级规范.10 4.4.2 2 级规范.10 4.4.3 3 级规范.10 4.4.4 4 级规范.11 5 测试计划.12 5.1 目的.12 5.2 提纲.12 5.3 详细说明.13 5.3.1 测试计划标识符.13 5.3.2 测试计划名称.13 5.3.3 引言.13 5.3.4 测试项.14 5.3.5 测试跟踪矩阵.14 5.3.6 被测试特征.14 5.3.7 不被测试特征.14 5.3.8 方法.14 5.3.9 测试项通过

3、准则.15 5.3.10 暂停准则和恢复要求.15 5.3.11 测试交付项.15 5.3.12 测试活动与任务.15 JR/T 01012013 II 5.3.13 环境要求.15 5.3.14 职责和权限.16 5.3.15 人员配备和培训要求.16 5.3.16 各部门间的工作衔接.16 5.3.17 进度.16 5.3.18 风险和应急.16 5.3.19 通则.17 6 测试设计说明.17 6.1 目的.18 6.2 提纲.18 6.3 详细说明.18 6.3.1 测试设计说明文档标识符.18 6.3.2 测试设计说明名称.18 6.3.3 引言.18 6.3.4 被测试特征.19

4、6.3.5 方法细化.19 6.3.6 测试用例标识.19 6.3.7 特征通过准则.19 6.3.8 通则.20 7 测试用例说明.20 7.1 目的.20 7.2 提纲.20 7.3 详细说明.21 7.3.1 测试用例说明文档标识符.21 7.3.2 测试用例说明名称.21 7.3.3 引言.21 7.3.4 测试用例描述.22 7.3.5 测试环境要求.23 7.3.6 通则.24 8 测试规程说明.24 8.1 目的.25 8.2 提纲.25 8.3 详细说明.25 8.3.1 测试规程说明文档标识符.25 8.3.2 测试规程说明文档名称.25 8.3.3 引言.25 8.3.4

5、环境和特殊需求.26 8.3.5 执行步骤描述.27 8.3.6 通则.27 9 测试规格说明.28 9.1 目的.28 JR/T 01012013 III 9.2 提纲.28 9.3 详细说明.29 9.3.1 测试规格说明文档标识符.29 9.3.2 测试规格说明名称.29 9.3.3 引言.29 9.3.4 被测试特征、测试方法与通过准则.30 9.3.5 测试用例.30 9.3.6 测试环境要求.31 9.3.7 执行步骤描述.32 9.3.8 通则.33 10 测试预案.33 10.1 目的.33 10.2 提纲.34 10.3 详细说明.35 10.3.1 测试预案文档标识符.35

6、 10.3.2 测试预案名称.35 10.3.3 引言.35 10.3.4 测试项.36 10.3.5 被测试特征与方法.36 10.3.6 不被测试特征.36 10.3.7 测试项通过准则.36 10.3.8 测试交付项.36 10.3.9 测试活动与进度.36 10.3.10 暂停准则和恢复要求.37 10.3.11 人员配备和培训要求.37 10.3.12 职责和权限.37 10.3.13 各部门间的工作衔接.37 10.3.14 风险和应急.37 10.3.15 测试用例.37 10.3.16 测试环境要求.38 10.3.17 执行步骤描述.39 10.3.18 通则.40 11 测

7、试日志.41 11.1 目的.41 11.2 提纲.41 11.3 详细说明.41 11.3.1 测试日志文档标识符.41 11.3.2 测试日志名称.42 11.3.3 引言.42 11.3.4 日志描述.42 11.3.5 活动和事件条目.43 11.3.6 通则.43 JR/T 01012013 IV 12 测试事件报告（异常报告）.44 12.1 目的.44 12.2 提纲.44 12.3 详细说明.44 12.3.1 测试事件报告文档标识符.44 12.3.2 测试事件报告名称.44 12.3.3 引言.45 12.3.4 测试事件描述.45 12.3.5 通则.46 13 中期测试

8、状态报告.47 13.1 目的.47 13.2 提纲.47 13.3 详细说明.48 13.3.1 中期测试状态报告文档标识符.48 13.3.2 中期测试状态报告名称.48 13.3.3 引言.48 13.3.4 测试状态描述.49 13.3.5 通则.49 14 测试总结报告.49 14.1 目的.49 14.2 提纲.49 14.3 详细说明.50 14.3.1 测试总结报告文档标识符.50 14.3.2 测试总结报告名称.50 14.3.3 引言.50 14.3.4 摘要.51 14.3.5 差异.51 14.3.6 测试充分性评价.51 14.3.7 测试结果汇总.51 14.3.8

9、 决策根据.51 14.3.9 结论和建议.51 14.3.10 通则.52 15 测试综合报告.52 15.1 目的.52 15.2 提纲.52 15.3 详细说明.53 15.3.1 测试综合报告文档标识符.53 15.3.2 测试综合报告名称.53 15.3.3 引言.53 15.3.4 已测试项.54 15.3.5 已测试特征与方法.55 JR/T 01012013 V 15.3.6 未测试特征.55 15.3.7 测试交付项.55 15.3.8 差异.55 15.3.9 测试项通过准则及测试充分性评价.55 15.3.10 决策根据.55 15.3.11 结论和建议.55 15.3.

10、12 测试环境.55 15.3.13 测试过程概述.56 15.3.14 测试组织和人员.56 15.3.15 测试用例.56 15.3.16 通则.57 16 与其他软件测试要求规范文件的依从性.58 附录 A（规范性附录）测试文档联动度.59 A.1 概述.59 A.1.1 需要统筹考虑联动测试的情况.59 A.1.2 测试文档联动度分级.59 A.1.3 软件完整性级别与测试规范度的关系.59 A.1.4 联动测试文档剪裁指南.59 A.2 测试文档联动度.59 A.2.1 S 级规范.59 A.2.2 P 级规范.60 A.2.3 A 级规范.60 A.3 联动测试计划.60 A.3.

11、1 目的.60 A.3.2 提纲.61 A.3.3 详细说明.61 A.4 联动测试报告.66 A.4.1 目的.67 A.4.2 提纲.67 A.4.3 详细说明.67 A.5 联动测试中测试文档编制逻辑时序.69 附录 B（资料性附录）测试文档规范度和测试文档联动度确定指南.71 B.1 概述.71 B.2 确定测试文档规范度考虑的维度.71 B.2.1 项目管理团队对测试文档规范的熟悉程度.71 B.2.2 项目管理团队经验倾向.71 B.2.3 项目人力资源.71 B.2.4 项目需求成熟程度.72 B.2.5 项目需求描述方法.72 B.2.6 项目采用的开发过程模型.72 B.2.

12、7 项目进度.72 JR/T 01012013 VI B.2.8 项目的运行风险.72 B.3 确定测试文档联动度考虑的维度.73 B.3.1 项目间的业务关联程度.73 B.3.2 项目间的测试资源关联程度.73 B.3.3 项目间的测试数据关联程度.74 B.3.4 项目间的运行资源关联程度.74 B.3.5 项目间的测试人力资源关联程度.74 附录 C（资料性附录）不同测试文档规范度中单项测试文档编制逻辑时序.75 C.1 概述.75 C.1.1 测试文档规范度与描述全面性的关系.75 C.1.2 图例.75 C.2 1 级规范.75 C.3 2 级规范.76 C.4 3 级规范.77

13、C.5 4 级规范.79 附录 D（资料性附录）可选测试文档.82 D.1 需求可测性评估报告.82 D.1.1 目的.82 D.1.2 提纲.82 D.1.3 详细说明.82 D.2 测试工作总结.85 D.2.1 目的.85 D.2.2 提纲.85 D.2.3 详细说明.85 D.3 测试项传递报告.86 D.3.1 目的.86 D.3.2 提纲.86 D.3.3 详细说明.86 D.4 测试环境需求规格说明.87 D.4.1 目的.87 D.4.2 提纲.88 D.4.3 详细说明.88 D.5 测试数据需求规格说明.90 D.5.1 目的.90 D.5.2 提纲.90 D.5.3 详细

14、说明.90 D.6 组织级测试方针.92 D.6.1 目的.92 D.6.2 提纲.92 D.6.3 详细说明.93 D.7 组织级测试策略.95 D.7.1 目的.95 JR/T 01012013 VII D.7.2 提纲.95 D.7.3 详细说明.95 附录 E（资料性附录）对相关国家标准和国外先进标准的依从性分析.99 E.1 依从策略.99 E.2 对商业银行信息科技风险管理指引的依从性.99 E.3 对 GB/T 9386-2008 的依从性.101 E.3.1 测试文档章节对应关系.101 E.4 有关测试术语对应关系.102 E.5 对 IEEE Std 829-2008 的依

15、从性.102 E.5.1 采用主要内容.102 E.5.2 采用方式与部分术语对应关系.103 E.6 对 GB/T 8567-2006 的依从性.103 E.6.1 采用主要内容.103 E.6.2 部分术语对应关系.104 参考文献.105 JR/T 01012013 VIII 前 言 本标准按照国家标准GB/T 1.1-2009给出的规则起草。请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。本标准由全国金融标准化技术委员会（SAC/TC180）提出。本标准由全国金融标准化技术委员会（SAC/TC180）归口。本标准负责起草单位：中国农业银行股份有限公司。本标

16、准参与起草单位：中国工商银行股份有限公司、中国金融电子化公司。本标准主要起草人：于进、叶又升、孟毅颍、涂晓军、张冀峰、李宽、吴俊峰、韩建国、张桂伟、苏畅、张旭春、张金山、齐向东、张泽、贾树辉、李强、杨杰荣、刘运、谢雅莉、李琳、张鸿、宣染春、刘玉玲、张贺、王慧、何雯、张艳艳、徐颖、张博、彭施政、李来新、施晋、王成志、付佳、滕竹、邵硕、赵俊杰、周超、王谦、黄杰、李靖尘、李鑫、王彦锟、董德才、林超峰、李辉、阮俊杰、刘丽 JR/T 01012013 IX 引 言 按照不同的软件开发组织方法，软件测试或是贯穿于软件开发生存周期的活动，或者是软件生存周期中若干独立的的阶段。不论采用哪种方法论，软件测试都是

17、检测以及保证软件质量的重要手段，并为软件和基于软件的系统调优与持续改进提供依据。按照不同的软件开发组织方法，软件测试可以分解为不同的过程、活动和任务，软件测试文档是这些过程、活动、任务的产品，并往往是另一些相关过程、活动、任务的指导性文件，软件测试文档的内容则描述了这些过程、活动和任务的实质性内容。标准化的软件测试文档建立了一种通用的参照体系，一方面对在软件测试过程中需要关注的实质性内容给出了一个普遍适用的集合，一方面易于在沟通和交流中快速定位同类事宜。本标准在符合国家标准要求的基础上，参考国外先进标准，考虑到中国银行业软件测试的实际情况，描述了一组与软件测试有关的基本测试文档，定义了每个基本

18、文档的实质性内容，以适应各种具体的测试情况，实现按照本标准编制文档，可快速清晰地判定，哪些软件测试需要考虑的内容得到了有效处理，哪些内容没有考虑或考虑不充分，可有效提高测试过程、活动、任务的可视性，提高测试工作的可管理性。尽管本标准所描述的文档侧重于动态测试活动，但有些文档仍适用于其他种类的测试活动（例如，测试计划可以用于代码评审）。本标准采用了分级的概念，故可适应于绝大部分情况下的软件测试情况。随着选择的文档规范度的不同，将体现为选择了不同的测试过程、活动、任务集，并确定了相应测试过程、活动、任务集的产品。JR/T 01012013 1 银行业软件测试文档规范 1 范围 本标准汇集描述了软件

19、测试所涉及的术语，提出了软件单项测试和联动测试的概念，描述了软件测试文档规范度和软件测试文档联动度的分级和不同级别下需要编制的文档，提出了软件测试文档规范度和软件测试文档联动度的选择指南，规定了各级别需要编制的软件测试文档的结构和主要内容，描述了不同测试文档规范度中单项测试文档的逻辑关系和编制逻辑时序，给出了可选测试文档内容的建议，并对相关国家标准和国外标准的依从性进行了分析。本标准适用于银行业各类软件产品以及基于软件的系统的测试。本标准不针对任何软件生存周期模型，但对于一些软件生存周期模型来说，应用本标准需要进行剪裁。2 规范性引用文件 下列文件对于本文件的应用是必不可少的。凡是注日期的引用

20、文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。GB/T 8566-2007 信息技术 软件生存周期过程 GB/T 9386-2008 计算机软件测试文件编制规范 GB/T 11457-2006 信息技术 软件工程术语 GB/T 15532-2008 计算机软件测试规范 GB/T 18492-2001 信息技术 系统及软件完整性级别 ISO/IEC/IEEE 24765:2010 系 统 和 软 件 工 程 词 汇(systems and software engineering-vocabulary)IEEE Std 829-2008

21、软件和系统测试文档标准(Standard for Software and System Test Documentation)3 术语与定义 下列术语和定义适用于本文件，为了便于查阅，按照术语和定义的相关性，分为基础概念、被测对象、测试种类、测试文档、测试结果与质量5类给出。3.1 基础概念 3.1.1 生存周期模型 life cycle model 一个包含过程、活动和任务的框架，这些过程、活动和任务涉及软件产品的开发、运行和维护，跨越从需求定义到终止使用的系统生存周期。GB/T 8566-2007，定义3.12 3.1.2 活动 activity JR/T 01012013 2 a)一个

22、过程的组成元素；注：对基线的变更要经有关机构的正式批准。b)为实现某个目的而采取的任一步骤或执行的任一职能，既可是脑力的，也可是体力的。活动包括经理和技术人员为完成项目和组织的任务而做的全部工作。GB/T 11457-2006，定义2.35 3.1.3 完整性级别 integrity level 项的某个特性的取值范围的一种表示，该特性取值范围对将系统风险保持在可容忍的限度内是必需的。对于执行减缓功能的项，此特性是指项必须执行减缓功能的可靠性。对于因其失效能导致一个威胁的项，此特性是指对该失效的频率或概率的限制。GB/T 18492-2001，定义 3.9 注：在IEEE Std 829-20

23、08中，定义3.1.15对软件完整性级别的定义是：衡量软件符合（或必须遵守）由利益相关者选定的一系列软件特征（或基于软件的系统特征）的程度（例如，软件的复杂性，风险评估，安全级别，安全保密级别，理想性能，可靠性或成本）；还用于向利益相关者定义反映软件重要性的程度。3.1.4 测试 testing a)在规定的条件下操作系统或部件、观察或记录结果并对系统或部件的某些方面作评价的过程。b)分析软件项以检测在存在的和要求的条件之间的区别（即，隐错）以评价软件项的特征。GB/T 11457-2006，定义2.1727 注：在ISO/IEC TR 19759:2005的第5章中，对测试给出了如下描述：“

24、测试是为评估产品质量并改进产品质量，所执行的识别缺陷和问题的活动。软件测试就是通过执行一组有限的测试用例，将程序的表现行为和预期行为相对照，动态地验证程序的表现行为，而这组有限的测试用例通常是从无限的执行情形中适当地选取出来的。”3.1.5 测试方法 test approach 为了挑选测试用例取值而应用的特定方法。注：测试方法在特征上可能会从非常概括（例如黑盒或白盒）到非常细节（例如，最小和最大边界值）而变化。ISO/IEC/IEEE 24765:2010，定义3.3062 3.1.6 测试准则 test criteria 系统或部件为通过给定的测试必须满足的准则。GB/T 11457-20

25、06，定义2.1699 3.1.7 测试覆盖 test coverage 给定的测试或测试集，对于给定的系统和部件实现所有规定的需求的程度。GB/T 11457-2006，定义2.1698 3.1.8 测试就绪评审 test readiness review a)对于一个或多个配置项评价初始测试结果的评审行为，以验证对于每个配置项的测试规程是完整的、遵循测试计划和描述且满足测试需求、并验证项目准备好进行配置项的正式测试。b)对于任何硬件或软部件像在 a)中那样评审。GB/T 11457-2006，定义2.1717 3.1.9 测试可重复性 test repeatability JR/T 010

26、12013 3 测试的一种属性。指明每次进行的测试时，产生相同的结果。GB/T 11457-2006，定义2.1718 3.1.10 测试实践活动 test effort 执行一个或多个测试任务的活动。ISO/IEC/IEEE 24765:2010，定义3.3074 3.1.11 测试件 testware 在测试实践活动中产生的所有产品。示例：文档和数据。ISO/IEC/IEEE 24765:2010，定义3.3097 3.1.12 计算机辅助软件测试工具 computer-aided software testing tool 在软件测试过程中，辅助完成测试的计算机软件工具。可包括功能测试工

27、具、性能测试工具、测试管理工具、测试的桩模块和驱动模块等。3.1.13 数字字母 digital&letter 包括数字09和字母AZ。3.2 被测对象 3.2.1 软件 software 与计算机系统的操作有关的计算机程序、规程和可能相关的文档。GB/T 11457-2006，定义2.1469 3.2.2 项 item 能够作为单独考虑的一个实体，如一个软件、部件、子系统、设备或系统。一个项可以包括硬件、软件或两者兼而有之。GB/T 18492-2001，定义3.10 3.2.3 软件项 software item 源代码、目标代码、作业控制代码、控制数据或这些项的集合。GB/T 11457

28、-2006，定义2.1503 3.2.4 软件产品 software product a)指定交付给用户的计算机程序、规程和可能相关的文档和数据的完整集。b)a)中的任一单独的项。GB/T 11457-2006，定义2.1520 3.2.5 基于软件的系统 software-based systems 由软件控制的计算机系统。ISO/IEC/IEEE 24765:2010，定义3.2811 注：对于金融行业来说，一般情况下的基于软件的系统，是包括有支持软件运行的硬件设备、基础软件和应用软件JR/T 01012013 4 构成的系统。其中硬件设备可是计算机设备、存储设备、网络设备等，基础软件可是

29、操作系统、数据库管理系统、中间件等，应用软件则是处理业务逻辑的行业专用软件。3.2.6 软件特征 software feature a)区分软件项的特征（例如，性能、可移植性或功能）。b)由需求文档规定或隐含的软件特征（例如，功能、性能、属性或设计约束）。GB/T 11457-2006，定义2.1501 3.2.7 软件特性 software characteristic 软件固有的可能是偶然的品质、质量或特性（例如功能、性能、属性、设计限制、状态数、行数或分支数）。GB/T 11457-2006，定义2.1475 3.2.8 软件配置项 software configuration item

30、 为独立的配置管理而设计的并且能满足最终用户功能的一组软件。注：本术语摘自GB/T 15532-2008之7.1.1。3.3 测试种类 3.3.1 单项测试 test level 一项拥有自身文档和资源的独立测试实践活动。示例：部件、部件集成、系统、验收测试。ISO/IEC/IEEE 24765:2010，定义3.3081 3.3.2 部件测试 component testing 对独立的硬件或软件部件或有关部件组的测试。GB/T 11457-2006，定义2.264 3.3.3 模块测试 module testing 见：部件测试(3.16)。GB/T 11457-2006，定义2.979

31、3.3.4 单元测试 unit testing 独立的硬件或软件单元或相关单元组的测试。GB/T 11457-2006，定义2.1792 3.3.5 集成测试 integration testing 把软件部件、硬件部件或两者组合起来进行的测试，并测试以评价它们之间的交互。GB/T 11457-2006，定义2.788 3.3.6 配置项测试 configuration item testing 检验软件配置项与软件需求规格说明的一致性的测试。注：本术语摘自GB/T 15532-2008之7.1.2。JR/T 01012013 5 3.3.7 系统测试 system testing 在完整的、

32、集成的系统的测试行为，它用以评价系统与规定的需求的遵从性。GB/T 11457-2006，定义2.1669 注：在目前的银行业工程实践中，称作ST或SIT的测试目标、范畴与方法等同或接近系统测试。3.3.8 验收测试 acceptance testing a)确定以系统是否符合其验收准则，使客户能确定是否接收此系统的正式测试；b)使用户、客户或其他授权实体确定是否接受系统或部件的正式测试。GB/T 11457-2006，定义2.19 注：在目前的银行业工程实践中，称作UAT的测试目标、范畴与方法等同或接近验收测试。3.3.9 功能测试 functional testing a)忽略系统或部件的

33、内部机制只集中于响应所选择的输入和执行条件产生的输出的一种测试。b)有助于评价系统或部件与规定的功能需求遵循性的测试。GB/T 11457-2006，定义2.669 3.3.10 性能测试 performance testing 评价系统或部件与规定的性能需求的依从性的测试行为。GB/T 11457-2006，定义2.1135 3.3.11 结构测试 structural testing 侧重于系统或部件内部机制的测试。类型包括分支测试、路径测试、语句测试。GB/T 11457-2006，定义2.1604 3.3.12 接口测试 interface testing 引导以评价系统或部件能否相互

34、正确地传送数据与控制信息的测试。GB/T 11457-2006，定义2.800 3.3.13 正式测试 formal testing 按照已经由客户、用户或指定的管理级评审和批准的测试计划和过程进行测试活动并报告结果。GB/T 11457-2006，定义2.649 3.3.14 非正式测试 informal testing 按照尚未由客户、用户或指定的管理级评审和批准的测试计划和过程进行的测试行为。GB/T 11457-2006，定义2.749 3.3.15 开发测试 develop testing 在系统或部件的开发期间的正式的或非正式的测试活动，通常由开发者在开发环境中进行。GB/T 11

35、457-2006，定义2.468 3.3.16 合格性测试 qualification testing 确定系统或部件是否适合于操作使用的测试行为。JR/T 01012013 6 GB/T 11457-2006，定义2.1291 3.3.17 运行测试 operational testing 在它的目标环境中，评价系统或部件的测试行为。GB/T 11457-2006，定义2.1065 3.3.18 回归测试 regression testing 系统或部件选择的重新测试，用以验证修改未引起不希望的有害效果，或证明修改后的系统或系统部件仍满足规定的需求。GB/T 11457-2006，定义2.1

36、329 3.3.19 强度测试 stress testing 评价系统或部件在它规定的需求的限定或超出情况的测试。GB/T 11457-2006，定义2.1599 3.4 测试相关文档 3.4.1 规格说明 specification 规约 a)以一种完全的、精确的、可验证的方法规定系统或部件的需求、设计、行为或其他特性的文件。并经常指明一过程，以确定给定的这些规定是否满足。b)规范的明确的约定。GB/T 11457-2006，定义2.1548 3.4.2 联动测试计划 master test plan 为（一个项目内或多项目间的）多项测试提供的测试管理文件。主要包括挑选项目测试实践活动的组成

37、部分，制定每个测试实践活动的目标，确定人力资源的分配并考虑各个测试实践活动的相互影响，识别出风险、假设和各测试实践活动人员分析解决问题的工作能力准则，定义测试实践活动的控制，确认质量保证计划确定的可实施的目标，标识完整性模式、选定完整性级别，划分测试、将要执行的总体任务和文档需求，是总体测试的纲领性文件。注：参照IEEE Std 829-2008第8章整理。3.4.3 测试计划 test plan 规定测试项、被测试特性和不被测试特性、测试的总体方法、项通过准则、测试交付物、测试任务、测试环境要求、测试实践活动职责和权限、对人员的要求、测试进度、风险和应急等内容，是测试的纲领性文件。IEEE

38、Std 829-2008，定义3.1.49 3.4.4 测试设计说明 test design specification 用来指定一个软件特征或者软件特征组合的测试方法细节并标识相关测试的文档。GB/T 9386-2008，定义3.7 3.4.5 测试用例说明 test case specification JR/T 01012013 7 对于一个测试项，用来指定输入、预期结果和一组测试执行条件的文档。GB/T 9386-2008，定义3.6 3.4.6 测试规程说明 test procedure specification 用来规定执行一项测试的执行动作顺序的一种文档。GB/T 9386-2

39、008，定义3.14 3.4.7 中期测试状态报告 interim test status report 用来汇总指定测试活动的结果、描述对测试计划的偏离和对测试状态的度量，并根据这些结果有选择地提供评价和建议的文档。注1：通常用具体测试的名称来冠于文档标题中的“中期”之前，例如：“系统中期测试状态报告”；如为多项目联合测试中期测试状态报告，则应称为“XX 联合测试中期测试状态报告”。由于为不同种类的测试或为测试全局所定义的中期测试状态报告的格式差异会很大，故可为标识的每一个测试与测试全局各定义一种“中期测试状态报告”的格式。注2：根据 IEEE Std 829-2008 第 15 章整理。3

40、.4.8 测试总结报告 level test summary report 简述测试过程，报告测试项与测试计划说明的差异，对测试充分性和测试结果进行评价的文档。3.4.9 联动测试报告（MTR）maser test report 用于总结各指定测试活动的结果并根据这些结果进行评价。注1：任何使用总体测试计划的组织均可使用总体测试报告。在生成和实施一个总体测试计划时，要求有一个相应的总体测试报告来描述总体测试计划实施的结果。注2：根据 IEEE Std 829-2008 第 17 章整理。3.4.10 测试规格说明 test specification 包括了测试设计说明、测试用例说明和测试规程

41、说明的核心内容的文档。3.4.11 测试预案 test scenario 包括了测试计划和测试规格说明的核心内容的文档。3.4.12 测试综合报告 level test comprehensive report 在仅有一个测试文档的情况下，描述了测试预案、测试过程和测试总结报告主要内容的文档。3.4.13 需求可测性分析报告 testability analyzing report of requirement 通过对业务需求或者需求规格说明进行分析，确定其提出的功能、性能、接口、约束指标是清晰和可量化的，可通过测试进行验证和确认的文档。3.4.14 测试依据规格说明 test basis s

42、pecification 描述测试有关被测试特征细节与被测试特征关联，以确定可作为测试结果判据的文档。3.5 测试结果与质量 3.5.1 JR/T 01012013 8 软件质量 software quality a)软件产品中能满足给定需要的性质和特性的总体。例如，符合规格说明。b)软件具有所期望的各种属性的组合程度。c)顾客和用户觉得软件满足其综合期望的程度。d)确定软件在使用中将满足顾客预期要求的程度。GB/T 11457-2006，定义2.1522 3.5.2 异常 anomaly 从文档或软件操作观察到偏离以前验证过的软件产品或引用的文档的任何事件。GB/T 11457-2006，定

43、义2.64 注：在IEEE Std 1044-2009中，对异常的描述为“术语异常可用于提及任何反常、不规则、不一致或与期望的差异。它可以用于指一个状况或事件、一个外形或行为、一个窗体或一个函数。”3.5.3 出错 error 误差 差错 a)计算的、观察的或测量的值或条件与实际的、规定的或理论上正确的值或条件的差别。例如，在计算的结果和正确的结果之间差30；b)不正确的步骤、过程或数据定义。例如，在计算机程序中的不正确的指定；c)不正确的结果。例如，当正确的结果是10，而计算的结果是12；d)产生不正确结果的人为动作。例如，在编程或操作的一部分上的不正确动作。注：当上述所有四种定义是公共使用

44、时，一种区分赋给定义a)为字差错(error)，定义b）为字过错(fault)，定义c)为字失效(failure)和定义d)为字错误(mistake)。GB/T 11457-2006，定义2.561 3.5.4 故障 fault 缺陷 a)硬件设备或部件中的缺陷。例如，短路或断线。b)在计算机程序中不正确的步骤、过程或数据定义。注：此定义最初由容错系统使用。在通常用法中，术语“差错(error)”和“隐错(bug)”表示同样含义。GB/T 11457-2006，定义2.609 3.5.5 失效 failure 系统或部件不能按规定的性能要求执行它所要求的功能。GB/T 11457-2006，定

45、义2.601 3.5.6 隐错 bug 见：出错error(3.5.3)和故障 fault(3.5.4)GB/T 11457-2006，定义2.163 3.5.7 软件测试待查事件 software test incident 在软件测试执行期间发生的要求调查的任一事件。GB/T 11457-2006，定义2.1536 JR/T 01012013 9 4 测试文档规范度 4.1 单项测试和联动测试 单项测试是指独立实施的单个特定阶段或特定类型的测试。示例1：单元测试、集成测试、系统测试、验收测试均属于特定阶段的单项测试。示例2：功能测试、性能测试、安全测试均属于特定类型的单项测试。联动测试是指

46、统筹管理的多个特定阶段和或特定类型的测试，包括但不限于：a)在一个项目中统筹管理不同单项测试的测试；b)在一个工程中统筹管理的多个项目的相同单项测试的测试；c)在一个工程中统筹管理的多个项目的不同单项测试的测试。示例1：统筹管理对核心银行的银行卡子系统的单元测试、集成测试和系统测试，是在一个项目中不同阶段联动测试的一个例子；示例2：统筹管理对核心银行的银行卡子系统和网上银行的压力测试，是在同一个工程中不同项目间同类单项测试进行联动测试的一个例子；示例3：统筹管理对核心银行的银行卡子系统的压力测试和网上银行的功能验收测试，是在同一个工程中不同项目间不同类别单项测试进行联动测试的一个例子。测试文档

47、规范程度分为适用于单项测试的测试文档规范度和适用于联动测试的测试文档联动度。测试文档规范度在本章描述；测试文档联动度见附录A。4.2 基本策略 测试文档规范度描述了在编制单项测试文档时，对测试相关实质性内容描述、记录的完整与详细程度。较高的测试文档规范度，要求在单项测试过程中，过程阶段划分相对清晰和明确，描述和记录内容相对完整，具备分阶段评审的可能性，需要编制的文档较多；随着测试文档规范度的降低，对测试过程阶段划分的要求也逐渐降低，更多的内容可以在一个测试文档中描述，相关的内容可以简化和合并描述，以适应过程阶段划分不很清晰、在某一阶段测试相关的内容难以描述准确和完整的情况，文档规范度越低，需要

48、编制的文档越少。在编制测试文档时，除应撰写文档标识符和文档名称外，可本着统筹考虑风险控制、工作效率和度量需求的原则，对本标准要求的每个文档的每一章的内容进行剪裁。某章若无可写的内容，则可不写，但应保留该章的编号和标题。剪裁时，可调整内容，亦可在基本文档集外增加另外的文档。本标准注重测试文档实质性内容的完整性，并鼓励采用软件工具对测试的实质性内容进行管理，同一个文档中的实质性内容，可描述和记录在不同的软件工具中，此时，应在适宜的文档中说明该实质性内容的描述方式和访问方法。注1：考虑到本标准应用者软件测试工作的差异和被测试软件的差异，可针对不同的被测软件类型、软件测试阶段、软件测试种类确定不同的剪

49、裁内容，这些剪裁内容可以看作对软件测试文档编制的最低要求。注2：是否允许在项目级和部门级进行剪裁，由本标准的应用者确定。4.3 软件完整性级别与软件测试文档规范度的关系 根据失效所造成后果的危害程度，计算机软件的完整性级别被分为A、B、C、D四个等级（其定义见GB/T 18492）。不同完整性级别软件的安全性要求不同，对软件的测试内容、测试要求和测试所采用方法也有所不同。对完整性级别较高的软件，宜采用较高的软件测试文档规范度。对没有规定被测软件完整性级别的情况，应考虑多个维度因素确定应采用的测试文档规范度，宜考虑的维度参见附录B。JR/T 01012013 10 4.4 测试文档规范度分级 4

50、.4.1 1 级规范 1级规范提供的文档包括：a)在需要时，第 11 章描述的测试日志；b)在需要时，第 12 章描述的测试事件报告；c)第 15 章描述的测试综合报告。三个测试文档的编制要求为：测试日志宜随着测试过程编制，真实记录测试的状况；测试事件报告宜随着测试过程编制，真实记录测试的状况；测试事件报告可针对每一个事件进行记录和提交；对于同一个事件反复发生的，宜在每次发生后编制或者编辑测试事件报告；测试综合报告应在测试执行完成后编制。在遵循1级规范时，单项测试文档编制逻辑时序参见本标准附录C.3。4.4.2 2 级规范 2级规范提供的文档包括：a)第 10 章描述的测试预案；b)第 11