标准规范下载简介

DL／T 1729-2017 电力信息系统......

7.5.1测试目的和对象

DL/T 1729 2017

信息系统进行版本升级时，应对信息系统受影响部分在实际生产部署环境中开展运行测试。运行 测试的对象是完整的信息系统。

运行测试的内容是测试信息系统受影响部分的兼容性、响应能力等。

运行测试一般应符合以下测试要求： a）信息系统进行版本升级时DB37／T 3364-2018 装配式钢结构住宅-钢支撑通用技术要求，应对信息系统受影响部分在实际生产部署环境中开展运行测试； b）信息系统受影响部分应通过兼容性测试； C）信息系统的响应能力达到开发技术合同规定的要求

7.5.4测试环境和方法

测试环境应包括测试的运行环境和测试工具环境。 测试的运行环境一般应符合软件测试合同（或项目计划）的要求，通常是软件及其所属信息系统 的正式工作环境。 运行测试一般应采用黑盒测试方法，具体方法的说明参见附录A。

运行测试完成后形成的文档一般应有： a）运行测试计划； b）运行测试说明； c）运行测试报告； d）运行测试记录和测试日志； e）运行测试问题报告。 可根据需要对上述文档及文档的内容进行裁剪

回归测试的测试目的是： a）测试信息系统变更之后，变更部分的正确性和对变更需求的符合性； b）测试信息系统变更之后，信息系统原有的、正确的功能、性能和其他规定的要求的不损害性。 回归测试的对象包括： a）未通过内部测试的模块，在变更之后，应以其进行内部测试： b）未通过第三方确认测试的信息系统，在变更之后，首先应对变更的单元进行测试，然后再进行 相关的集成测试和第三方确认测试： c）因其他原因进行变更之后的单元，也首先应对变更的单元进行测试，然后再进行相关的测试。 信息系统各阶段测试未通过后均应再次申请回归测试，本标准中只列内部测试和第三方确认测试

DL/T17292017 的回归测试，上线测试、验收测试和运行测试可参照第三方确认回归测试内容开展测试工作，具体内 容可依据实际情况进行裁剪。

一般应根据变更情况确定内部回归测试的测试内容。可能存在以下三种情况： a）仅重复测试原内部测试做过的测试内容； b）修改原内部测试做的测试内容； c）在前两者的基础上增加新的测试内容

一般应根据变更情况确定内部回归测试的测 a）仅重复测试原内部测试做过的测试内容 b）修改原内部测试做的测试内容； c）在前两者的基础上增加新的测试内容。

一般应符合原内部测试的技术要求，可根据变更情况酌情裁剪。当回归测试结果和原内部测试的 正确结果不一致时，应重新进行回归测试，

8.2.3测试环境和方法

内部回归测试的测试环境要求应与原内部测试的测试环境要求一致。 当未增加新的测试内容时，内部回归测试应采用原内部测试的测试方法，否则应根据情况选择适 当的测试方法。

部回归测试完成后形成的文档一般应有： a）内部回归测试计划； b）内部回归测试说明； c）内部回归测试报告； d）内部回归测试记录； e）内部回归测试问题报告。 可根据要求对上述文档及文档的内容进行裁剪。 上述文档也可分别作为内部测试产生的文档的补充件。

8.3第三方确认回归测试

对于变更的信息系统的测试，测试人员应分析信息系统受变更影响的范围，并据此确定回归测试 内容。可能存在以下三种情况：一是仅重复测试与变更相关的，并在原信息系统测试中的做过的测试 内容；二是修改与变更相关的，并在原信息系统测试中做的测试内容；三是在前两者的基础上增加新 的测试内容。

第三方确认回归测试的测试要求一般应符合以下原则： a）对变更的信息系统的测试，应符合原第三方确认测试的技术要求，可根据受影响情况进行 裁剪； b）当回归测试结果和原第三方确认测试的正确结果不一致时，应对出现问题的单元重新进行回归

DL/T17292017

测试； c）信息系统主版本升级，应完成第三方确认测试，子版本升级时，应完成第三方确认测试的安全 测试。

8.3.3测试环境和方法

对于变更的信息系统的测试，其测试环境要求应与原第三方确认测试的测试环境要求一到 对于变更的信息系统的测试，当未增加新的测试内容时，信息系统测试采用原信息系 法：否则，根据情况选择适当的测试方法

第三方确认回归测试完成后形成的文档一般应有： a）信息系统回归测试计划； b）信息系统回归测试说明； c）信息系统回归测试报告； d）信息系统回归测试记录和测试日志； e）信息系统回归测试问题报告。 可根据需要对上述文档及文档的内容进行裁剪。 上述文档可作为第三方确认测试产生的文档的补充件。

附录A （资料性附录） 软件测试方法

1）模块中是否使用语言完整定义的有限子集？ 2）未使用内存的内容是否影响信息系统安全？处理是否得当？ e）存储器使用：

DL/T1729 2017

1）每一个域在第一次便用前正确地初始化了吗？ 2）规定的域正确吗？ 3）每个域是否由正确的变量类型声明？ 4）存储器重复使用吗？可能产生冲突吗？ f) 测试和转移： 1）是否进行了浮点相等比较？ 2）测试条件正确吗？ 3）用于测试的变量正确吗？ 4）每个转换目标正确并至少执行一次？ 5）三种情况（大于0，小于0，等于0）是否已全部测试？ g）性能： 1）逻辑是否被最佳地编码？ 2）提供的是一般的出错处理还是异常的例程？ h）可维护性： 1）所提供的列表控制是否有利于提高可读性？ 2）标号和子程序名符合代码的意义吗？ i) 逻辑： 1）全部设计是否均已实现？ 2）编码是否做了设计所规定的内容？ 3）每个循环是否执行了正确的次数？ 4）是否已直接测试了输入参数的所有异常值？ j) 软件多余物： 1）是否有不可能执行到的代码？ 2）是否有即使不执行也不影响程序功能的指令？ 3）是否有未引用的变量、标号和常量？ 4）是否有多余的程序单元？ 代码审查问题表应写明所查出的差错类型、差错类别、差错严重程度、差错位置、差错原因， 型有文档差错、编程语言差错、逻辑差错、接口差错、数据使用差错、编程风格不当、软件多 差错类别有遗漏、错误、多余。 这种静态测试方法是一种多人一起进行的测试活动，要求每个人尽量多提出问题，同时讲述程 会突然发现的一些问题。这时要放慢进度，把问题分析出来。

d）形成报告：会后将发现的差错形成报告，并交给程序开发人员。对发现差错较多或发现重大差 错的，在改正差错之后再次进行会议走查。 这种静态测试方法是一种多人一起进行的测试活动，要求每个人尽量多提供测试实例，这些测试 实例是作为怀疑程序逻辑与计算差错的启发点，在随测试实例游历程序逻辑时，在怀疑程序的过程中 发现差错。这种方法不如代码审查检查的范围广，差错覆盖全。

静态分析一般包括控制流分析、数据流分析、接口分析、表达式分析。此外，静态分析还可以完 成下述工作： a）提供间接涉及程序缺陷的信息： 1）每一类型语句出现的次数； 2）所有变量和常量的交叉引用表； 3）标识符的使用方式； 4）过程的调用层次； 5）违背编码规则； 6）程序结构图和程序流程图； 7）子程序规模、调用/被调用关系、扇入/扇出数。 b）进行语法语义分析，提出语义或结构要点，供进一步分析； c）进行符号求值； d）为动态测试选择测试用例进行预处理。 静态分析常需要实用软件工具进行。静态分析是在程序编译通过之后，其他静态测试之前进行的

A.1.3.1控制流分析

控制流分析是使用控制流程图信息系统地检查被测程序的控制结构工作。控制流按照结构化 现则和程序结构的基本要求进行程序结构检查。这些要求被测程序不应包含： a）转向并不存在的语句标号； b）没有使用的语句标号； c）没有使用的子程序定义； d）调用并不存在的子程序； e）从程序入口进入后无法达到的语句； f）不能达到停止语句的语句。 控制流程图是一种简化的程序流程图，控制流程图由“节点”和“弧”两种图形符号构成。

A.13.2数据流分析

数据流分析是用控制流程图来分析数据发生的异常情况，这些异常包括被初始化、被赋值或被引 用过程中行为序列的异常。数据流分析也作为数据流测试的预处理过程。 数据流分析首先建立控制流程图，然后再控制流程图中标注某个数据对象的操作序列，遍历控制 流程图，形成这个数据对象的数据流模型，并给出这个数据对象的初始状态，利用数据流异常状态图 分析数据对象可能的异常。 数据流分析可以查出引用未定义变量、对以前未使用的变量再次赋值等程序差错或异常情况。

A.1.3.3接口分析

接口分析主要用在程序静态分析和设计分析。接口一致性的设计分析涉及模块之间接口的一

DL/T17292017

以及模块与外部数据库之间的一致性。程序的接口分析涉及子程序以及函数之间的接口一致性，包括 检查形参与实参的类型、数量、维数、顺序以及使用的一致性。

A.1.3.4表达式分析

表达式错误主要有以下几种（但不限于）： 括号使用不正确，数组引用错误，作为除数的变量可能为零，作为开平方的变量可能未负，作为 正切值的变量可能为元/2，浮点数变量比较时产生的错误。

动态测试是建立在程序的执行过程中。根据对被测对象内部情况的了解与否，分为黑盒测试和白 盒测试。 黑盒测试又称功能测试、数据驱动测试或基于规格说明的测试，这种测试不必了解被测对象的内 部情况，而依靠需求规格说明中的功能来设计测试用例。 白盒测试又称结构测试、逻辑测试或基于程序的测试，这种测试应了解程序的内部构造，并且根 据内部构造设计测试用例。 在单元测试时一般采用白盒测试，在系统测试时一般采用黑盒测试，

A.2.2黑盒测试方法

A.2.2.1功能分解

功能分解是将需求规格说明中每一个功能加以分解，确保各个功能被全面地测试。功能分解是 种较常用的方法。 步骤如下： a）使用程序设计中的功能抽象方法把程序分解为功能单元； b）使用数据抽象方法产生测试每个功能单元的数据。 功能抽象中，数据结构可以由抽象数据类型的层次图来描述，每个抽象数据类型有其取值集合。 程序的每一个输入和输出量的取值集合用数据抽象来描述，

A.2.2.2等价类划分

等价类划分是在分析需求规格说明的基础上，把程序的输入域划分为若于部分，然后在每部分中 选取代表性数据形成测试用例。 步骤如下： a）划分有效等价类：对规格说明是有意义、合理的输入数据所构成的集合； b）划分无效等价类：对规格说明是无意义、不合理的输入数据所构成的集合； c）为每一个等价类定义一个唯一的编号； d）为每一个等价类设计一组测试用例，确保覆盖相应的等价类

A.2.2.3边界值分析

边界值分析是针对边界值进行测试的。使用等于、小于或大于边界值的数据对程序进行 法就是边界值分析方法。 步骤如下：

DL/T 17292017

DL/T 1729 2017

a）通过分析规格说明，找出所有可能的边界条件； b）对每一个边界条件，给出满足和不满足边界值的输入数据； c）设计相应的测试用例。 对满足边界值的输入可以发现计算差错，对不满足的输入可以发现域差错。该方法会为其他测试 方法补充一些测试用例，绝大多数测试都会用到本方法。

判定表由四部分组成：条件桩、条件条目、动作桩、动作条目。任何一个条件组合的取值及其相 应要执行的操作构成规则，条目中的每一列是一条规则。 条件引用输入的等价类，动作引用被测试软件的主要功能处理部分，规则就是测试用例。 建立并优化判定表，把判定表中每一列表示的情况写成测试用例。 该方法的使用有以下要求： a）规格说明以判定表的形式给出，或是很容易转换成判定表： b）条件的排列顺序不会影响执行哪些操作； c）规则的排列顺序不会影响执行哪些操作； d）每当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则； e）如果某一规则的条件得到满足，将执行多个操作，这些操作的执行与顺序无关。

因果图方法是通过画因果图，把用自然语言描述的功能说明转换为判定表，然后为判定表的每 列设计一个测试用例。 步骤如下： a）分析成规格说明，引出原因（输入条件）和结果（输出结果），并给每个原因和结果赋予一个 标识符； b）分析程序规格说明语义的内容，并将其表示成连接各个原因和各个结果的“因果图”； c）在因果图上标明约束条件； d）通过跟踪因果图中的状态条件，把因果图转换成有限项的判定表； e）把判定表中每一列表示的情况生成测试用例。 如果需求规格说明中含有输入条件的组合，宜采用本方法。有些软件的因果图可能非常庞大，以 至于根据因果图得到的测试用例数且非常大，此时不宜使用本方法

A.2.2.6随机测试

随机测试指测试输入数据是在所有可能输入值中随机选取的。测试人员只需规定输入变量的取值 区间，在需要时提供必要的变换机制，使产生的随机数服从预期的概率分布。该方法获得预期输出比 较困难，多用于可靠性测试和信息系统强度测试。

猜错法是有经验的测试人员，通过列出可能有的差错和易错情况表，写出测试用例的方法。

A.2.2.8正交实验法

正交实验法是从大量的实验点中挑出适量的、有代表性的点，应用正交表，合理地安排实验 科学的实验设计方法。

DL/T17292017

利用正交实验法来设计测试用例时，首先要根据被测软件的规格说明书找出影响功能实现的操作 对象和外部因素，把他们当作因子，而把各个因子的取值当作状态，生成二元的因素分析表。然后， 利用正交表进行各因子的状态的组合，构造有效的测试输入数据集，并由此建立因果图。这样得出的 测试用例的数目将大大减少。

A.2.3自盒测试方法

A.2.3.1控制流测试

控制流测试依据控制流程图产生测试用例，通过对不同控制结构成分的测试验证程序的控制结 内。所谓验证某种控制结构即指使这种控制结构在程序运行中得到执行，也称这一过程为覆盖。以下 个绍几种覆盖。 a）语句覆盖：要求设计适当数量的测试用例，运行被测程序，使得程序中每一条语句至少被执行 一次，语句覆盖在测试中主要发现出错语句； b）分支覆盖：要求设计适当数量的测试用例，运行被测程序，使得程序中每个真值分支和假值分 支至少执行一次，分支覆盖也称判定覆盖； C） 条件覆盖：要求设计适当数量的测试用例，运行被测程序，使得每个判断中的每个条件可能取 值至少满足一次； d）条件组合覆盖：要求设计适当数量的测试用例，运行被测程序，使得每个判断中条件的各种组 合至少出现一次，这种方法包含了“分支覆盖”和“条件覆盖”的各种要求； e）路径覆盖：要求设计适当数量的测试用例，运行被测程序，使得程序沿所有可能的路径执行， 较大程序的路径可能很多，所以在设计测试用例时，要简化循环次数。 以上各种覆盖的控制流测试步骤如下： a）将程序流程图转换成控制流程图； b）经过语法分析求得路径表达式； c）生成路径树； d）进行路径编码； e） 经过译码得到执行的路径； f）通过路径枚举产生特定路径的测试用例

A.2.3.2数据流测试

数据流测试是用控制流程图对变量的定义和引用进行分析，查找未定义的变量或定义了而未使用 的变量，这些变量可能是拼错的变量、变量混淆或丢失了语句。数据流测试一般使用工具进行。 数据流测试通过一定的覆盖准则，检查程序中每个数据对象的每次定义、使用和消除情况。 数据流测试步骤： a）将程序流程图转换成控制流图； b）在每个链路上标注对有关变量的数据操作的操作符号或符号序列； c）选定数据流测试策略； d）根据测试策略得到测试路径； e）根据路径可以获得测试输入数据和测试用例。 动态数据流异常检查在程序运行时执行，获得的是对数据对象的真实操作序列，克服了静态分析 险查的局限，但动态方式检查是沿着与测试输入有关的一部分路径进行的，检查的全面性和程序结构 爱盖有关。

DL/T17292017

DL/T17292017

A.2.3.3程序变异

一种差错驱动测试，是为了查出被测软件在做过其他测试后还剩余一些的小差错。本方法一 则试工具进行。

A.2.3.4程序插装

程序描装是向被测程序中描入操作以实现测试目的方法，程序描装不应该影被测程序的运 和功能。 有很多的工具有程序插装功能，由于数据记录量大，手工进行较为繁。

域测试是要判别程序对输入空间的划分是否正确。该方法限制太多，使用不方便，供有特殊 测试使用。

A.2.3.6符号求值

符号求值是允许数值变量取“符号值”以及数值。符号求值可以检查公式的执行结果是否达到程 序预期的目的；也可以通过程序的符号执行，产生出程序的路径，用于产生测试数据。符号求值最好 使用工具，在公式分支较少时手工推导也是可行的。

DL/T17292017

SHT3408-2022石油化工钢制对焊管件技术规范.pdfDL/T17292017

DL/T17292017

DL/T17292017

DL/T1729—2017

DL/T 1729 2017

DL/T17292017

DL/T17292017

155198.712

北京市场地形成工程勘察设计技术规程(DB11／T 1625-2019) 宣贯培训材料（北京市规划和自然资源委员会）155198.712