DL/T 1729-2017
标准分类号
关联标准
出版信息
相关单位信息
标准简介
DL/T 1729-2017.Functional and nonfunctional test specification for
power information system.
1范围
DL/T 1729规定了电力信息系统功能及非功能性的基本测试方法、过程和准则。
DL/T 1729适用于电力企业经营管理类信息系统的功能及非功能性测试。本标准适用于电力信息系统的开发机构、测试机构及相关人员。
本标准不涉及信息系统安全性测试要求，安全性测试要求见GB/T 18336信息技术 安全技术信息技术安全性评估准则。
2术语和定义
GB/T 11457中确立的术语和定义适用于本文件。
2.1功能性functionality
一种在指定条件下使用时表示信息系统提供满足用户明确和隐含要求功能的能力。
2.2非功能性non-functionality
根据一些条件判断信息系统运作情形或其特性，而不是针对信息系统特定行为的测试，也可以视作为了满足用户业务需求而需要符合，但又不在功能性测试以内的特性。
2.3单元测试unit testing
对信息系统中的最小可测试单元进行检查和验证。
2.4集成测试integration testing
在单元测试的基础上，将所有模块按照设计要求组装成为子系统或系统，测试单元间的接口以及集成后的功能，主要目标是发现与接口有关的问题。
2.5回归测试regression testing
修改了信息系统的旧代码后，重新开展测试以确认修改没有引入新的错误或导致其他代码产生错误。
power information system.
1范围
DL/T 1729规定了电力信息系统功能及非功能性的基本测试方法、过程和准则。
DL/T 1729适用于电力企业经营管理类信息系统的功能及非功能性测试。本标准适用于电力信息系统的开发机构、测试机构及相关人员。
本标准不涉及信息系统安全性测试要求，安全性测试要求见GB/T 18336信息技术 安全技术信息技术安全性评估准则。
2术语和定义
GB/T 11457中确立的术语和定义适用于本文件。
2.1功能性functionality
一种在指定条件下使用时表示信息系统提供满足用户明确和隐含要求功能的能力。
2.2非功能性non-functionality
根据一些条件判断信息系统运作情形或其特性，而不是针对信息系统特定行为的测试，也可以视作为了满足用户业务需求而需要符合，但又不在功能性测试以内的特性。
2.3单元测试unit testing
对信息系统中的最小可测试单元进行检查和验证。
2.4集成测试integration testing
在单元测试的基础上，将所有模块按照设计要求组装成为子系统或系统，测试单元间的接口以及集成后的功能，主要目标是发现与接口有关的问题。
2.5回归测试regression testing
修改了信息系统的旧代码后，重新开展测试以确认修改没有引入新的错误或导致其他代码产生错误。
标准图片预览
标准内容
ICS35.080
备案号：60088-2017
中华人民共和国电力行业标准
DL/T1729—2017
电力信息系统功能及非功能性
测试规范
Functional and nonfunctional test specification forpowerinformationsystem
2017-08-02发布
国家能源局
2017-12-01实施
规范性引用文件
术语和定义
测试目的
测试过程
测试方法…
测试用例·
测试管理
测试文档
测试工具
测试环境
测试评价标准
功能性
适合性
准确性
互操作性
5.4依从性
非功能性
可靠性
易用性
可维护性
可移植性
非功能性测试指标
测试阶段
内部测试
第三方确认测试
上线测试
验收测试·
运行测试·
8回归测试
测试目的和对象
8.2内部回归测试
8.3第三方确认回归测试
附录A（资料性附录）软件测试方法目
附录B（规范性附录）电力信息系统非功能性测试指标表DL/T1729—2017
DL/T1729—2017
为规范电力信息系统功能及非功能性的各阶段测试，实现电力信息系统测试全过程管控，确保电力信息系统功能完备、性能稳定和安全可靠，保证电力信息系统建设质量，制定本标准本标准按照GB/T1.12009《标准化导则第1部分：标准的结构和编写》给出的规则编制。本标准由中国电力企业联合会标准化中心提出并解释。本标准由电力行业信息标准化技术委员会（DL/TC27）归口。本标准起草单位：中国电力科学研究院、国网浙江省电力公司。本标准主要起草人：纪鑫、汪洋、汤国龙、张大华、丁慧霞、董慧博、高强、颜月平、谢迎军、方帅、王智慧、张庚、全杰、滕玲、李哲、陈相舟。本标准首次发布。Www.bzxZ.net
本标准在执行过程中的意见或建议反馈至中国电力企业联合会标准化管理中心（北京市白广路二条一号，100761)。
1范围
电力信息系统功能及非功能性测试规范本标准规定了电力信息系统功能及非功能性的基本测试方法、过程和准则。DL/T1729—2017
本标准适用于电力企业经营管理类信息系统的功能及非功能性测试。本标准适用于电力信息系统的开发机构、测试机构及相关人员。本标准不涉及信息系统安全性测试要求，安全性测试要求见GB/T18336信息技术安全技术信息技术安全性评估准则。
2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。GB/T8566信息技术软件生存周期过程（GB/T8566—2007，ISO/IEC12207：1995，MOD）GB/T9386计算机软件测试文档编制规范GB/T11457信息技术软件工程术语GB/T15532
计算机软件测试规范
信息技术安全技术信息技术安全性评估准则（ISO/IEC15408：2005，IDT）GB/T18336
GB/T20158
信息技术软件生存周期过程配置管理（GB/T201582006，ISO/IECCTR
15846:1998，IDT)
3术语和定义
GB/T11457中确立的术语和定义适用于本文件。3.1
功能性functionality
一种在指定条件下使用时表示信息系统提供满足用户明确和隐含要求功能的能力3.2
生non-functionality
非功能性
根据一些条件判断信息系统运作情形或其特性，而不是针对信息系统特定行为的测试，也可以视作为了满足用户业务需求而需要符合，但又不在功能性测试以内的特性。3.3
unittesting
单元测试
对信息系统中的最小可测试单元进行检查和验证。3.4
集成测试integrationtesting
在单元测试的基础上，将所有模块按照设计要求组装成为子系统或系统，测试单元间的接口以及集成后的功能，主要自标是发现与接口有关的问题。3.5
回归测试regressiontesting
修改了信息系统的旧代码后，重新开展测试以确认修改没有引入新的错误或导致其他代码产生错误。1
DL/T1729—2017
内部测试internaltesting
信息系统开发完成之前，项目开发单位在其内部开展的测试。3.7
tvalidationtesting
第三方确认测试
项目开发单位完成内部测试，在信息系统交付前，委托第三方测试机构依照需求规格说明书、概要设计说明、详细设计说明等文档及其批复等开展的测试。3.8
上线测试onlinetesting
信息系统上线试运行前在实际生产部署环境中开展的测试。3.9
验收测试
acceptancetesting
信息系统上线试运行转为正式运行前进行的测试。3.10
trunningtesting
运行测试
信息系统正式运行后，信息系统功能模块有一定变化时或安装补丁时进行的测试4总则
4.1测试自的
信息系统测试目的是：
验证电力信息系统是否满足开发合同或项目开发计划，并且验证测试信息系统是否与需求规格a)
说明书、概要设计、用户手册等文档保持一致：b）通过测试，暴露被测试信息系统的缺陷，减少隐形缺陷：c）为信息系统的质量测量和评价提供依据。4.2测试过程
4.2.1概述
信息系统测试过程一般包括五项活动，按顺序分别是：测试策划、测试设计、测试执行、测试总结、测试报告。
4.2.2测试策划
测试策划主要是进行测试需求分析。即确定需要测试的内容或质量特性，确定测试的充分性要求，提出测试的基本方法，确定测试的资源和技术需求，进行风险分析与评估，制定测试计划（含资源计划和进度计划）。有关测试策划的内容和要求见GBT93864.2.3测试设计
依据测试需求：
a）分析并选用已有的测试用例或设计新的测试用例，获取并验证测试数据：b）根据业务逻辑、测试资源、风险等约束条件，确定测试用例执行顺序：c）获取测试资源，开发测试软件：d）建立并校准测试环境；
DL/T17292017
e）进行测试就绪评审，主要评审测试计划的合理性和测试用例的正确性、有效性和覆盖充分性，评审测试组织、环境和设备工具是否齐备并符合要求。4.2.4测试执行
测试执行有以下内容：
a）执行测试用例，获取测试结果：b）分析并判定测试结果，记录测试缺陷，根据不同的判定结果采取相应的措施：c）对测试过程的正确或异常终止情况进行核对，并根据核对结果，对未达到测试终止条件的测试用例，决定停正测试，还是需要修改或补充测试用例集，并进一步测试，4.2.5测试总结
整理和分析测试数据，评价测试效果和被测试项：a）描述测试状态。如实际测试与测试计划和测试说明的差异、测试用例合理性、测试充分性分析、未能解决的测试事件等；
b）描述被测试项的状态，如被测信息系统与需求的差异，发现信息系统差错等。4.2.6测试报告
依据测试总结，出具相应的测试报告。测试报告应至少包括产品名称、版本号、委托单位、样品编号、测试资源（硬件测试环境、软件测试环境和测试工具）、测试项目（功能性测试和非功能性测试）和测试结论。
4.3测试方法
测试方法一般分为静态测试方法和动态测试方法，详细说明参见附录A。4.4测试用例
4.4.1测试用例设计原则
设计测试用例时，应遵循以下原则：a）基于测试需求的原则：应按照测试类别的不同要求，设计测试用例：b）基于测试方法的原则：应明确所采用的测试用例设计方法。为送到不同的测试充分性要求，应采用相应的测试方法，如等价类划分、边界值分析、猜错法、因果图等方法；c）兼顾测试充分性和效率原则：测试用例集应兼顾测试的充分性和测试的效率；每个测试用例的内容也应完整，具有可操作性；d)
测试执行的可再现性原则：应保证测试用例执行的可再现性：测试用例具有代表性原则：能够代表并覆盖各种合理和不合理、合法和非法、边界和越界以及e)
极限的输入数据、操作和环境设置等：f)
测试结果可判定原则：测试执行结果的正确性是可判断的，每一个测试用例都应有相应的期望结果；
g）测试结果可再现原则：对同样的测试用例，信息系统的执行结果应相同。2测试用例要素
每个测试用例应包括以下要素：a）名称和标识，每个测试用例应有唯一的名称和标识符：3
DL/T1729—2017
b）测试追踪，说明测试所依据的内容来源：c）用例说明，简要描述测试的对象、目的和所采的测试方法；d）测试的初始化要求，应考虑下述初始化要求：1）硬件配置：被测信息系统的硬件配置情况，包括硬件条件或电气状态；2）软件配置：被测信息系统的软件配置情况，包括测试的初始条件：3）测试配置：测试信息系统的配置情况，如用于测试的模拟信息系统和测试工具等的配置情况：4）参数设置：测试开始前的设置，如标志、第一断点、指针、控制参数和初始化数据等的设置：5）其他对于测试用例的特殊说明。e）测试的输入，在测试用例执行中发送给被测对象的所有测试命令、数据和信号等。对于每个测试用例应提供如下内容：
1）每个测试输入的具体内容（如确定的数值、状态或信号等）及其性质（如有效值、无效值、边界值等）；
2）测试输入的来源（例如测试程序产生、磁盘文件、通过网络接收、人工键盘输入等），以及选择输入所使用的方法（例如等价类划分、边界值分析、差错推测、因果图、功能图方法等）：3）测试输入是真实的还是模拟的：4）测试输入的时间顺序或事件顺序。f)期望的测试结果，说明测试用例执行中由被测信息系统所产生期望的测试结果，即经过验证，认为正确的结果。必要时，应提供中间的期望结果。期望测试结果应该有具体内容，如确定的数值、状态或信号等，不应是不确切的概念或笼统的描述；g）评价测试结果的准则，判断测试用例执行中产生的中间和最后结果是否正确的准则。对于每个测试结果，应根据不同情况提供如下信息：1）实际测试结果所需的精度：
2）实际测试结果与期望结果之间的差异允许的上限、下限；3）时间的最大和最小间隔，或事件数自的最大和最小值：4）实际测试结果不确定时，再测试的条件：5）与测试结果有关的出错处理；6）上面没有提及的其他准则。
h）操作过程，实施测试用例的执行步骤。把测试的操作过程定义为一系列按照执行顺序排列的相对独立的步骤，对于每个操作应提供：1）每一步所需的测试操作动作、测试程序的输入、设备操作等；2）每一步期望的测试结果；
3）每一步的评价准则：
4）程序终止伴随的动作或差错指示：5）获取和分析实际测试结果的过程。前提和约束，在测试用例说明中施加的所有前提条件和约束条件，如果有特别限制、参数偏差或异常处理，应标识出来，并要说明它们对测试用例的影响：j）测试终止条件，说明测试正常终止和异常终止的条件。4.5测试管理
4.5.1过程管理
信息系统测试应由相对独立的人员进行。根据项自的规模等级和完整性级别以及测试类别，信息系统测试可由不同机构组织实施。4
应对测试过程中的测试活动和测试资源进行管理。有关管理要求见GB/T8566。一般情况下，信息系统测试的人员配备见表1。表1信息系统测试人员配备情况
工作角色
测试项目负责人
测试项目监督人
测试分析员
测试设计员
测试程序员
测试执行员
测试系统管理员
配置管理员
具体职责
DL/T1729—2017
管理监督测试项目，提供技术指导，获取适当的资源，制定基线，技术协调，负责项目的安全保密和质量管理
监督测试项目的执行情况、项目进展的合理性确定测试计划、测试内容、测试方法、测试数据生成方法、测试（软、硬件）环境、测试工具，评价测试工作的有效性
设计测试用例，确定测试用例的优先级，建立测试环境编写测试辅助软件
执行测试、记录测试结果
对测试环境和资产进行管理和维护设置、管理和维护测试配置管理数据库，测试文档归档。注1：当信息系统的供方实施测试时，配置管理员由信息系统开发项目的配置管理员承担：当独立的测试组织实施测试时，应配备测试活动的配置管理员。注2：一个人可以承担多个角色的工作，一个角色可由多个人承担。测试的准入、准出条件如下：
a）准入条件，开始信息系统测试工作一般应具备下列条件：1）具有测试合同（或项目计划）；2）具有信息系统测试所需的各种文档（宜包括项目可研报告及可研批复、需求规格说明书及评审意见、概要设计及评审意见、内部测试报告、用户手册）：3）所提交的被测信息系统受控：4）信息系统源代码正确通过编译或汇编。准出条件，结束信息系统测试工作一般应达到下列要求：b
1）已按要求完成合同（或项自计划）所规定的信息系统测试任务：2）实际测试过程遵循了原定的信息系统测试和信息系统测试说明3）客观、详细地记录了信息系统测试过程和信息系统测试中发现的所有问题：4）信息系统测试文档齐全、符合规范：5）信息系统测试的全过程自始至终在控制下进行：6）信息系统测试中的问题或异常有合理解释或正确有效的处理：7）信息系统测试工作通过了测试评审：8）全部测试软件、被测信息系统、测试支持软件和评审结果已纳入配置管理。4.5.2配置管理
应按照信息系统配置管理的要求，将测试过程中产生的各种工作产品纳入配置管理。由开发组织实施的信息系统测试，应将测试工作产品纳入项目的配置管理；由独立测试组织实施的信息系统测试，应建立配置管理库，将被测对象和测试工作产品纳入配置管理。配置管理要求见GB/T20158。
DL/T1729—2017
4.5.3审查
4.5.3.1测试就绪审查
在测试执行前，对测试计划和测试说明等进行评审，评审测试计划的合理性、测试用例的正确性、完整性和覆盖充分性，以及测试组织、测试环境和设备工具是否齐全并符合技术要求等。审查的真体内容和要求应包：
a）审查测试文档内容的完整性、正确性和规范性；b）通过比较测试环境与信息系统真实运行的软件、硬件环境的差异，审香测试环境要求是否正确合理，满足测试要求；
c）审查测试活动的独立性；
d）审查测试项选择的完整性和合理性；e）审查测试用例的可行性、正确性和充分性。4.5.3.2测试审查
在测试完成后，评审测试过程和测试结果的有效性，确定是否达到测试目的，主要对测试记录、测试报告进行评审，其具体内容和要求应包括：a）评审文档和记录内容的完整性、正确性和规范性：b）评审测试活动的独立性和有效性：c）评审测试环境是否符合测试要求：d）评审测试记录、测试数据以及测试报告内容与实际测试过程和结果的一致性：e）评审实际测试过程与测试计划和测试说明的一致性：f)评审未测试项和新增测试项的合理性：g）评审测试结果的真实性和正确性；h）评审对测试过程中出现的异常进行处理的正确性4.6测试文档
信息系统测试文档一般包括测试计划、测试说明（需要时进一步细分为测试设计说明、测试用例说明和测试规程说明）、测试项传递报告、测试日志、测试记录、测试问题报告和测试报告，测试文档的基本内容和要求见GB/T9386，根据软件的完整性级别和软件规模等级可对信息系统测试文档进行合理的取舍与合并。
4.7测试工具
4.7.1测试工具分类
测试工具可分为静态测试工具、动态测试工具和其他支持测试活动的工具，每类测试工具在功能和其他特征方面都具有相似之处，支持一个或多个测试活动（见表2）。应根据测试需求选择合适的工具。表2测试工具分类表
工具类型
静态测试工具
功能和特征说明
对需求、结构设计、详细
复杂度分析、数据流分
设计和代码进行评审、走查析、控制流分析、接口分析、句法和语义分析等工具
和审查的工具
针对需求、结构设计、详
细设计的静态分析工具很少
工具类型
动态测试工具
支持测试过程
活动的其他工具
4.7.2测试工具选择
功能和特征说明
表2（续）
支持执行测试用例和评价
测试结果的工具，包括支持
选择测试用例、设置环境、
覆盖分析、捕获和回放、
存储器测试、变异测试、仿
DL/T1729—2017
测试捕获和回放及数据生
运行所选择测试、记录执行真器及性能分析、测试用例 成器可用于测试设计活动、故障分析和测试工作
管理等工具
有效性评价等
测试计划生成、测试进度
支持测试计划、测试设计
和整个测试过程的工具
和人员安排评估、基于需求
的测试设计、测试数据生
成、问题管理和测试配置管
理工具
复杂度分析可用于测试计
划的制定、捕获和回放、
覆盖分析可用于测试设计
和实现
信息系统测试应尽量采用测试工具，避免或减少人工工作。为让工具在测试工作中发挥应有的作用。应确定工具的详细需求，并制定统一的工具评价、采购（开发）、培训、实施和维护计划。选择测试工具应考虑如下因素：a）测试工具的需求及确认：
1）应明确对测试工具的功能、性能、安全性等需求，并由使用机构进行验证或确认：2）可通过在实际运行环境下的演示来确认工具是否满足需求，演示应依据工具的功能和技术特征、用户使用信息（安装和使用手册等）以及工具的操作环境描述等进行。b）成本和收益分析：
1）估计工具的总成本，除了最基本的产品价格，总成本还包括附加成本，如工具的挑选、安装、运行、培训、维护和支持等成本，以及为使用工具而改变测试过程或流程的成本等；2）分析工具的总体收益。如工具的首次使用范围和长期使用前景、工具应用效果、与其他工具协同工作所提高的生产力程度等。c）测试工具的整体质量因素：
1）易用性：
2）互操作性：
3）稳定性：
4）经济实用性；
5）可维护性。
4.8测试环境
测试环境应包括测试的运行环境和测试工具环境。测试的运行环境一般应符合信息系统测试合同（或项目计划）的要求，通常是开发环境、生产环境或模拟仿真环境。测试工具一般要求是经过认可的工具。测试环境的要求见GB/T15532。4.9测试评价标准
测试机构对测试结果进行综合考查，对“功能性、效率（性能）、易用性、可维护性、可移植性、可靠性、用户文档集要求”7大质量特性结果均为“通过”的信息系统，在测试报告中确定为“通过”：对任意一项单一质量特性不通过的信息系统，在测试报告中确定为“不通过”测试问题级别定义如下：
a）致命性问题是指信息系统崩溃、数据丢失、数据毁坏或停止提供服务等问题；7
DL/T1729—2017
b）严重性问题是指主要功能错误或遗漏，骨干流程不可用，核心功能违反软件规范、业务规范等问题：
c）一般性问题是指非主要功能错误，信息系统的UI布局不合理及罕见的不影响主要业务操作等问题；
d）建议性问题是软件实际操作与使用说明不符，软件功能易用性不高，但不影响软件功能使用等问题。
单一质量特性评价标准要求测试用例覆盖需求率和测试用例回归执行率达到100%，信息系统测试后无致命性、严重性问题：其他不影响信息系统正常使用的一般性问题、建议性问题数量少于3个。5功能性
5.1适合性
从适合性方面考虑，应测试需求规格说明、概要设计说明、详细设计说明等文档规定的信息系统的每一项功能，具体包括：
a）功能充分性：
1）检测信息系统是否具有需求规格说明等文档中所要求的所有功能；2）根据测试的范围，对信息系统功能与需求规格说明书等文档中描述的功能一一核对，检查信息系统是否完全实现了需求规格说明中要求的功能。b）功能实现的完整性：
1）依据需求规格说明等文档，检验信息系统功能实现的完整程度：2）采用黑盒测试的方法，逐一检验信息系统功能是否完整。e）功能实现的覆盖率：
1）检验信息系统功能实现的正确程度：2）采用黑盒测试的方法，逐一检验信息系统功能是否正确。d）功能运行的稳定性：
1）检验信息系统功能运行的稳定性：2）应对信息系统实现的功能进行计数，将其与需求规格说明书中描述的功能总数进行对比。5.2准确性
从准确性方面考虑，可对信息系统中具有准确性要求的功能和精度要求的项进行测试，具体包括：a）预期的准确性：
1测试信息系统的实际结果与预期结果间的差别2）依据信息系统的特点，设计相应的测试用例，依据等价类法和边界值法选定具有覆盖性的测试数据作为输入，并计算出这些输入的预期结果。将用例应用于实现的信息系统，记录信息系统的实际输入结果，比较实际结果写预期结果间的差异。b）计算的准确性：
1）测试最终用户得到不准确数据的频率：2）根据预期的稳定性测试结果，结合用户对功能使用的次数，计算不准确数据出现的频率。测试信息系统的运算精度，与需求规格说明书中要求的精度之间的差异5.3互操作性
从互操作性方面考虑，可测试需求规格说明和接口设计文档规定的信息系统配置项与外部设备的接口、与其他信息系统的接口。测试接口协调性的格式和内容，包括数据交换的数据格式和内容，具体包括：8
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。
备案号：60088-2017
中华人民共和国电力行业标准
DL/T1729—2017
电力信息系统功能及非功能性
测试规范
Functional and nonfunctional test specification forpowerinformationsystem
2017-08-02发布
国家能源局
2017-12-01实施
规范性引用文件
术语和定义
测试目的
测试过程
测试方法…
测试用例·
测试管理
测试文档
测试工具
测试环境
测试评价标准
功能性
适合性
准确性
互操作性
5.4依从性
非功能性
可靠性
易用性
可维护性
可移植性
非功能性测试指标
测试阶段
内部测试
第三方确认测试
上线测试
验收测试·
运行测试·
8回归测试
测试目的和对象
8.2内部回归测试
8.3第三方确认回归测试
附录A（资料性附录）软件测试方法目
附录B（规范性附录）电力信息系统非功能性测试指标表DL/T1729—2017
DL/T1729—2017
为规范电力信息系统功能及非功能性的各阶段测试，实现电力信息系统测试全过程管控，确保电力信息系统功能完备、性能稳定和安全可靠，保证电力信息系统建设质量，制定本标准本标准按照GB/T1.12009《标准化导则第1部分：标准的结构和编写》给出的规则编制。本标准由中国电力企业联合会标准化中心提出并解释。本标准由电力行业信息标准化技术委员会（DL/TC27）归口。本标准起草单位：中国电力科学研究院、国网浙江省电力公司。本标准主要起草人：纪鑫、汪洋、汤国龙、张大华、丁慧霞、董慧博、高强、颜月平、谢迎军、方帅、王智慧、张庚、全杰、滕玲、李哲、陈相舟。本标准首次发布。Www.bzxZ.net
本标准在执行过程中的意见或建议反馈至中国电力企业联合会标准化管理中心（北京市白广路二条一号，100761)。
1范围
电力信息系统功能及非功能性测试规范本标准规定了电力信息系统功能及非功能性的基本测试方法、过程和准则。DL/T1729—2017
本标准适用于电力企业经营管理类信息系统的功能及非功能性测试。本标准适用于电力信息系统的开发机构、测试机构及相关人员。本标准不涉及信息系统安全性测试要求，安全性测试要求见GB/T18336信息技术安全技术信息技术安全性评估准则。
2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。GB/T8566信息技术软件生存周期过程（GB/T8566—2007，ISO/IEC12207：1995，MOD）GB/T9386计算机软件测试文档编制规范GB/T11457信息技术软件工程术语GB/T15532
计算机软件测试规范
信息技术安全技术信息技术安全性评估准则（ISO/IEC15408：2005，IDT）GB/T18336
GB/T20158
信息技术软件生存周期过程配置管理（GB/T201582006，ISO/IECCTR
15846:1998，IDT)
3术语和定义
GB/T11457中确立的术语和定义适用于本文件。3.1
功能性functionality
一种在指定条件下使用时表示信息系统提供满足用户明确和隐含要求功能的能力3.2
生non-functionality
非功能性
根据一些条件判断信息系统运作情形或其特性，而不是针对信息系统特定行为的测试，也可以视作为了满足用户业务需求而需要符合，但又不在功能性测试以内的特性。3.3
unittesting
单元测试
对信息系统中的最小可测试单元进行检查和验证。3.4
集成测试integrationtesting
在单元测试的基础上，将所有模块按照设计要求组装成为子系统或系统，测试单元间的接口以及集成后的功能，主要自标是发现与接口有关的问题。3.5
回归测试regressiontesting
修改了信息系统的旧代码后，重新开展测试以确认修改没有引入新的错误或导致其他代码产生错误。1
DL/T1729—2017
内部测试internaltesting
信息系统开发完成之前，项目开发单位在其内部开展的测试。3.7
tvalidationtesting
第三方确认测试
项目开发单位完成内部测试，在信息系统交付前，委托第三方测试机构依照需求规格说明书、概要设计说明、详细设计说明等文档及其批复等开展的测试。3.8
上线测试onlinetesting
信息系统上线试运行前在实际生产部署环境中开展的测试。3.9
验收测试
acceptancetesting
信息系统上线试运行转为正式运行前进行的测试。3.10
trunningtesting
运行测试
信息系统正式运行后，信息系统功能模块有一定变化时或安装补丁时进行的测试4总则
4.1测试自的
信息系统测试目的是：
验证电力信息系统是否满足开发合同或项目开发计划，并且验证测试信息系统是否与需求规格a)
说明书、概要设计、用户手册等文档保持一致：b）通过测试，暴露被测试信息系统的缺陷，减少隐形缺陷：c）为信息系统的质量测量和评价提供依据。4.2测试过程
4.2.1概述
信息系统测试过程一般包括五项活动，按顺序分别是：测试策划、测试设计、测试执行、测试总结、测试报告。
4.2.2测试策划
测试策划主要是进行测试需求分析。即确定需要测试的内容或质量特性，确定测试的充分性要求，提出测试的基本方法，确定测试的资源和技术需求，进行风险分析与评估，制定测试计划（含资源计划和进度计划）。有关测试策划的内容和要求见GBT93864.2.3测试设计
依据测试需求：
a）分析并选用已有的测试用例或设计新的测试用例，获取并验证测试数据：b）根据业务逻辑、测试资源、风险等约束条件，确定测试用例执行顺序：c）获取测试资源，开发测试软件：d）建立并校准测试环境；
DL/T17292017
e）进行测试就绪评审，主要评审测试计划的合理性和测试用例的正确性、有效性和覆盖充分性，评审测试组织、环境和设备工具是否齐备并符合要求。4.2.4测试执行
测试执行有以下内容：
a）执行测试用例，获取测试结果：b）分析并判定测试结果，记录测试缺陷，根据不同的判定结果采取相应的措施：c）对测试过程的正确或异常终止情况进行核对，并根据核对结果，对未达到测试终止条件的测试用例，决定停正测试，还是需要修改或补充测试用例集，并进一步测试，4.2.5测试总结
整理和分析测试数据，评价测试效果和被测试项：a）描述测试状态。如实际测试与测试计划和测试说明的差异、测试用例合理性、测试充分性分析、未能解决的测试事件等；
b）描述被测试项的状态，如被测信息系统与需求的差异，发现信息系统差错等。4.2.6测试报告
依据测试总结，出具相应的测试报告。测试报告应至少包括产品名称、版本号、委托单位、样品编号、测试资源（硬件测试环境、软件测试环境和测试工具）、测试项目（功能性测试和非功能性测试）和测试结论。
4.3测试方法
测试方法一般分为静态测试方法和动态测试方法，详细说明参见附录A。4.4测试用例
4.4.1测试用例设计原则
设计测试用例时，应遵循以下原则：a）基于测试需求的原则：应按照测试类别的不同要求，设计测试用例：b）基于测试方法的原则：应明确所采用的测试用例设计方法。为送到不同的测试充分性要求，应采用相应的测试方法，如等价类划分、边界值分析、猜错法、因果图等方法；c）兼顾测试充分性和效率原则：测试用例集应兼顾测试的充分性和测试的效率；每个测试用例的内容也应完整，具有可操作性；d)
测试执行的可再现性原则：应保证测试用例执行的可再现性：测试用例具有代表性原则：能够代表并覆盖各种合理和不合理、合法和非法、边界和越界以及e)
极限的输入数据、操作和环境设置等：f)
测试结果可判定原则：测试执行结果的正确性是可判断的，每一个测试用例都应有相应的期望结果；
g）测试结果可再现原则：对同样的测试用例，信息系统的执行结果应相同。2测试用例要素
每个测试用例应包括以下要素：a）名称和标识，每个测试用例应有唯一的名称和标识符：3
DL/T1729—2017
b）测试追踪，说明测试所依据的内容来源：c）用例说明，简要描述测试的对象、目的和所采的测试方法；d）测试的初始化要求，应考虑下述初始化要求：1）硬件配置：被测信息系统的硬件配置情况，包括硬件条件或电气状态；2）软件配置：被测信息系统的软件配置情况，包括测试的初始条件：3）测试配置：测试信息系统的配置情况，如用于测试的模拟信息系统和测试工具等的配置情况：4）参数设置：测试开始前的设置，如标志、第一断点、指针、控制参数和初始化数据等的设置：5）其他对于测试用例的特殊说明。e）测试的输入，在测试用例执行中发送给被测对象的所有测试命令、数据和信号等。对于每个测试用例应提供如下内容：
1）每个测试输入的具体内容（如确定的数值、状态或信号等）及其性质（如有效值、无效值、边界值等）；
2）测试输入的来源（例如测试程序产生、磁盘文件、通过网络接收、人工键盘输入等），以及选择输入所使用的方法（例如等价类划分、边界值分析、差错推测、因果图、功能图方法等）：3）测试输入是真实的还是模拟的：4）测试输入的时间顺序或事件顺序。f)期望的测试结果，说明测试用例执行中由被测信息系统所产生期望的测试结果，即经过验证，认为正确的结果。必要时，应提供中间的期望结果。期望测试结果应该有具体内容，如确定的数值、状态或信号等，不应是不确切的概念或笼统的描述；g）评价测试结果的准则，判断测试用例执行中产生的中间和最后结果是否正确的准则。对于每个测试结果，应根据不同情况提供如下信息：1）实际测试结果所需的精度：
2）实际测试结果与期望结果之间的差异允许的上限、下限；3）时间的最大和最小间隔，或事件数自的最大和最小值：4）实际测试结果不确定时，再测试的条件：5）与测试结果有关的出错处理；6）上面没有提及的其他准则。
h）操作过程，实施测试用例的执行步骤。把测试的操作过程定义为一系列按照执行顺序排列的相对独立的步骤，对于每个操作应提供：1）每一步所需的测试操作动作、测试程序的输入、设备操作等；2）每一步期望的测试结果；
3）每一步的评价准则：
4）程序终止伴随的动作或差错指示：5）获取和分析实际测试结果的过程。前提和约束，在测试用例说明中施加的所有前提条件和约束条件，如果有特别限制、参数偏差或异常处理，应标识出来，并要说明它们对测试用例的影响：j）测试终止条件，说明测试正常终止和异常终止的条件。4.5测试管理
4.5.1过程管理
信息系统测试应由相对独立的人员进行。根据项自的规模等级和完整性级别以及测试类别，信息系统测试可由不同机构组织实施。4
应对测试过程中的测试活动和测试资源进行管理。有关管理要求见GB/T8566。一般情况下，信息系统测试的人员配备见表1。表1信息系统测试人员配备情况
工作角色
测试项目负责人
测试项目监督人
测试分析员
测试设计员
测试程序员
测试执行员
测试系统管理员
配置管理员
具体职责
DL/T1729—2017
管理监督测试项目，提供技术指导，获取适当的资源，制定基线，技术协调，负责项目的安全保密和质量管理
监督测试项目的执行情况、项目进展的合理性确定测试计划、测试内容、测试方法、测试数据生成方法、测试（软、硬件）环境、测试工具，评价测试工作的有效性
设计测试用例，确定测试用例的优先级，建立测试环境编写测试辅助软件
执行测试、记录测试结果
对测试环境和资产进行管理和维护设置、管理和维护测试配置管理数据库，测试文档归档。注1：当信息系统的供方实施测试时，配置管理员由信息系统开发项目的配置管理员承担：当独立的测试组织实施测试时，应配备测试活动的配置管理员。注2：一个人可以承担多个角色的工作，一个角色可由多个人承担。测试的准入、准出条件如下：
a）准入条件，开始信息系统测试工作一般应具备下列条件：1）具有测试合同（或项目计划）；2）具有信息系统测试所需的各种文档（宜包括项目可研报告及可研批复、需求规格说明书及评审意见、概要设计及评审意见、内部测试报告、用户手册）：3）所提交的被测信息系统受控：4）信息系统源代码正确通过编译或汇编。准出条件，结束信息系统测试工作一般应达到下列要求：b
1）已按要求完成合同（或项自计划）所规定的信息系统测试任务：2）实际测试过程遵循了原定的信息系统测试和信息系统测试说明3）客观、详细地记录了信息系统测试过程和信息系统测试中发现的所有问题：4）信息系统测试文档齐全、符合规范：5）信息系统测试的全过程自始至终在控制下进行：6）信息系统测试中的问题或异常有合理解释或正确有效的处理：7）信息系统测试工作通过了测试评审：8）全部测试软件、被测信息系统、测试支持软件和评审结果已纳入配置管理。4.5.2配置管理
应按照信息系统配置管理的要求，将测试过程中产生的各种工作产品纳入配置管理。由开发组织实施的信息系统测试，应将测试工作产品纳入项目的配置管理；由独立测试组织实施的信息系统测试，应建立配置管理库，将被测对象和测试工作产品纳入配置管理。配置管理要求见GB/T20158。
DL/T1729—2017
4.5.3审查
4.5.3.1测试就绪审查
在测试执行前，对测试计划和测试说明等进行评审，评审测试计划的合理性、测试用例的正确性、完整性和覆盖充分性，以及测试组织、测试环境和设备工具是否齐全并符合技术要求等。审查的真体内容和要求应包：
a）审查测试文档内容的完整性、正确性和规范性；b）通过比较测试环境与信息系统真实运行的软件、硬件环境的差异，审香测试环境要求是否正确合理，满足测试要求；
c）审查测试活动的独立性；
d）审查测试项选择的完整性和合理性；e）审查测试用例的可行性、正确性和充分性。4.5.3.2测试审查
在测试完成后，评审测试过程和测试结果的有效性，确定是否达到测试目的，主要对测试记录、测试报告进行评审，其具体内容和要求应包括：a）评审文档和记录内容的完整性、正确性和规范性：b）评审测试活动的独立性和有效性：c）评审测试环境是否符合测试要求：d）评审测试记录、测试数据以及测试报告内容与实际测试过程和结果的一致性：e）评审实际测试过程与测试计划和测试说明的一致性：f)评审未测试项和新增测试项的合理性：g）评审测试结果的真实性和正确性；h）评审对测试过程中出现的异常进行处理的正确性4.6测试文档
信息系统测试文档一般包括测试计划、测试说明（需要时进一步细分为测试设计说明、测试用例说明和测试规程说明）、测试项传递报告、测试日志、测试记录、测试问题报告和测试报告，测试文档的基本内容和要求见GB/T9386，根据软件的完整性级别和软件规模等级可对信息系统测试文档进行合理的取舍与合并。
4.7测试工具
4.7.1测试工具分类
测试工具可分为静态测试工具、动态测试工具和其他支持测试活动的工具，每类测试工具在功能和其他特征方面都具有相似之处，支持一个或多个测试活动（见表2）。应根据测试需求选择合适的工具。表2测试工具分类表
工具类型
静态测试工具
功能和特征说明
对需求、结构设计、详细
复杂度分析、数据流分
设计和代码进行评审、走查析、控制流分析、接口分析、句法和语义分析等工具
和审查的工具
针对需求、结构设计、详
细设计的静态分析工具很少
工具类型
动态测试工具
支持测试过程
活动的其他工具
4.7.2测试工具选择
功能和特征说明
表2（续）
支持执行测试用例和评价
测试结果的工具，包括支持
选择测试用例、设置环境、
覆盖分析、捕获和回放、
存储器测试、变异测试、仿
DL/T1729—2017
测试捕获和回放及数据生
运行所选择测试、记录执行真器及性能分析、测试用例 成器可用于测试设计活动、故障分析和测试工作
管理等工具
有效性评价等
测试计划生成、测试进度
支持测试计划、测试设计
和整个测试过程的工具
和人员安排评估、基于需求
的测试设计、测试数据生
成、问题管理和测试配置管
理工具
复杂度分析可用于测试计
划的制定、捕获和回放、
覆盖分析可用于测试设计
和实现
信息系统测试应尽量采用测试工具，避免或减少人工工作。为让工具在测试工作中发挥应有的作用。应确定工具的详细需求，并制定统一的工具评价、采购（开发）、培训、实施和维护计划。选择测试工具应考虑如下因素：a）测试工具的需求及确认：
1）应明确对测试工具的功能、性能、安全性等需求，并由使用机构进行验证或确认：2）可通过在实际运行环境下的演示来确认工具是否满足需求，演示应依据工具的功能和技术特征、用户使用信息（安装和使用手册等）以及工具的操作环境描述等进行。b）成本和收益分析：
1）估计工具的总成本，除了最基本的产品价格，总成本还包括附加成本，如工具的挑选、安装、运行、培训、维护和支持等成本，以及为使用工具而改变测试过程或流程的成本等；2）分析工具的总体收益。如工具的首次使用范围和长期使用前景、工具应用效果、与其他工具协同工作所提高的生产力程度等。c）测试工具的整体质量因素：
1）易用性：
2）互操作性：
3）稳定性：
4）经济实用性；
5）可维护性。
4.8测试环境
测试环境应包括测试的运行环境和测试工具环境。测试的运行环境一般应符合信息系统测试合同（或项目计划）的要求，通常是开发环境、生产环境或模拟仿真环境。测试工具一般要求是经过认可的工具。测试环境的要求见GB/T15532。4.9测试评价标准
测试机构对测试结果进行综合考查，对“功能性、效率（性能）、易用性、可维护性、可移植性、可靠性、用户文档集要求”7大质量特性结果均为“通过”的信息系统，在测试报告中确定为“通过”：对任意一项单一质量特性不通过的信息系统，在测试报告中确定为“不通过”测试问题级别定义如下：
a）致命性问题是指信息系统崩溃、数据丢失、数据毁坏或停止提供服务等问题；7
DL/T1729—2017
b）严重性问题是指主要功能错误或遗漏，骨干流程不可用，核心功能违反软件规范、业务规范等问题：
c）一般性问题是指非主要功能错误，信息系统的UI布局不合理及罕见的不影响主要业务操作等问题；
d）建议性问题是软件实际操作与使用说明不符，软件功能易用性不高，但不影响软件功能使用等问题。
单一质量特性评价标准要求测试用例覆盖需求率和测试用例回归执行率达到100%，信息系统测试后无致命性、严重性问题：其他不影响信息系统正常使用的一般性问题、建议性问题数量少于3个。5功能性
5.1适合性
从适合性方面考虑，应测试需求规格说明、概要设计说明、详细设计说明等文档规定的信息系统的每一项功能，具体包括：
a）功能充分性：
1）检测信息系统是否具有需求规格说明等文档中所要求的所有功能；2）根据测试的范围，对信息系统功能与需求规格说明书等文档中描述的功能一一核对，检查信息系统是否完全实现了需求规格说明中要求的功能。b）功能实现的完整性：
1）依据需求规格说明等文档，检验信息系统功能实现的完整程度：2）采用黑盒测试的方法，逐一检验信息系统功能是否完整。e）功能实现的覆盖率：
1）检验信息系统功能实现的正确程度：2）采用黑盒测试的方法，逐一检验信息系统功能是否正确。d）功能运行的稳定性：
1）检验信息系统功能运行的稳定性：2）应对信息系统实现的功能进行计数，将其与需求规格说明书中描述的功能总数进行对比。5.2准确性
从准确性方面考虑，可对信息系统中具有准确性要求的功能和精度要求的项进行测试，具体包括：a）预期的准确性：
1测试信息系统的实际结果与预期结果间的差别2）依据信息系统的特点，设计相应的测试用例，依据等价类法和边界值法选定具有覆盖性的测试数据作为输入，并计算出这些输入的预期结果。将用例应用于实现的信息系统，记录信息系统的实际输入结果，比较实际结果写预期结果间的差异。b）计算的准确性：
1）测试最终用户得到不准确数据的频率：2）根据预期的稳定性测试结果，结合用户对功能使用的次数，计算不准确数据出现的频率。测试信息系统的运算精度，与需求规格说明书中要求的精度之间的差异5.3互操作性
从互操作性方面考虑，可测试需求规格说明和接口设计文档规定的信息系统配置项与外部设备的接口、与其他信息系统的接口。测试接口协调性的格式和内容，包括数据交换的数据格式和内容，具体包括：8
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。