DLT1142-2009 核电厂反应堆控制系统软件测试
- 文档部分内容预览：
5.2功率调节的功能测试
5.2.1输入/输出测试
通过加载信号发生器或利用I/O信号软接线等方法，测试所有功率量程范围内的输入/输 计要求。 输入主要有来自汽轮机控制系统的需求负荷信号、由棒组计数器实时给出的功率调节 等。输出主要有棒组逻辑升/降信号、频率与需求棒速成比例的脉冲信号等。
5.2.2 控制功能测试。
利用I/O软连接创建模拟测试环境，或通过动态调试（单步执行、断点操作等）的方法， 稳态运行和瞬态运行工况下的功率调节功能建筑常用表格，应能够实现使反应堆的功率迅速跟踪二回路的 站具有参与电网调峰、快速跟踪负荷变化的控制功能。 5.2.3根据设计说明书的具体要求进行功率调节功能的其他测试项。
5.3平均温度调节的功能测试
5.3.1输入/输出测试。
通过加载信号发生器或利用I/O信号软接线等方法，测试所有功率量程范围内的输入 要求。
DL/T11422009
输入主要有反应堆冷却剂平均温度测量值、反应堆功率的中子注量率测量值等。输出主要有反应堆 冷却剂平均温度设定值、控制棒的棒速设定值等。
5.3.2控制功能测试
利用I/软连接创建模拟测试环境，或通过动态调试（单步执行、断点操作等）的方法，分别测试 稳态运行和瞬态运行工况下的温度调节功能，应能够实现通过调节温度调节棒在堆芯的位置来保持一回 路的平均温度，尽可能接近由负荷决定的整定值，以满足二次侧负荷变化的控制功能。 5.3.3根据设计说明书的具体要求进行平均温度调节功能的其他测试项。
5.4稳压器压力控制的功能测试
5.4.1输入/输出测试
通过加载信号发生器或利用I/O信号软接线等方法，测试所有功率量程范围内的输入/输出 计要求。 输入主要有稳压器压力定值、稳压器压力测量值等。输出主要有压力调节器输出信号、喷 控制信号。
5.4.2控制功能测试。
利用I/O软连接创建模拟测试环境，或通过动态调试（单步执行、断点操作等）的方法， 稳态运行和瞬态运行工况下的稳压器压力调节功能，应能够实现使反应堆一回路系统保持正常 的控制功能。 5.4.3根据设计说明书的具体要求进行稳压器压力控制功能的其他测试项。
的控制功能。 5.4.3根据设计说明书的具 功能的其他测试项，
5.5稳压器水位控制的功能测试
5.5.1输入/输出测试。
通过加载信号发生器或利用I/O信号软接线等方法，测试所有功率量程范围内的输入/输出应达到设 计要求。 输入主要有稳压器水位测量值、反应堆冷却剂温度等。输出主要有流量设定值、稳压器水位设定值 等。 5.5.2控制功能测试。 利用I/O软连接创建模拟测试环境，或通过动态调试（单步执行、断点操作等）的方法，分别测试 稳态运行和瞬态运行工况下的稳压器水位调节功能，应能够实现使稳压器水位保持在预定的程序值上的
5.5.2控制功能测试。 利用I/O软连接创建模拟测试环境，或通过动态调试（单步执行、断点操作等）的方法，分别测试 稳态运行和瞬态运行工况下的稳压器水位调节功能，应能够实现使稳压器水位保持在预定的程序值上的 控制功能。
5.5.2控制功能测试。
5.6蒸汽排放控制的功能测试
5.6.1输入/输出测试
通过加载信号发生器或利用I/O信号软接线等方法，测试所有功率量程范围内的输入/输出应达到设 计要求。 输入主要有蒸汽母管压力、蒸汽发生器压力、汽轮机入口压力等。输出主要有蒸汽排放阀开启信号 排放阀工作模式（调节开启或快开）信号、二回路压力设定值等。
5.6.2控制功能测试。
利用I/O软连接创建模拟测试环境，或通过动态调试（单步执行、断点操作等）的方法，分别测试 稳态运行和瞬态运行工况下的蒸汽排放控制功能，应能够实现将主蒸汽直接排放到主凝汽器和除氧器或 者大气，降低由汽轮机负荷衰降引起的核蒸汽供应系统温度与压力变化的幅度的控制功能。 5.6.3根据设计说明书的具体要求进行蒸汽排放控制功能的其他测试项。
5.7蒸汽发生器水位控制的功能测试
DL/T1142—2009
输入主要有蒸汽发生器水位测量值、蒸汽流量、给水流量和温度、给水母管和蒸汽母管之 等。输出主要有蒸汽发生器调节阀的开启和开度信号、给水流量需求信号、主给水泵速度控
输入主要有蒸汽发生器水位测量值、蒸汽流量、给水流量和温度、给水母管和蒸汽母管之间的差 输出主要有蒸汽发生器调节阀的开启和开度信号、给水流量需求信号、主给水泵速度控制信号 2控制功能测试。 利用I/O软连接创建模拟测试环境，或通过动态调试（单步执行、断点操作等）的方法，分别测
5.7.2控制功能测试
利用I/O软连接创建模拟测试环境，或通过动态调试（单步执行、断点操作等）的方法，分别测试 稳态运行和瞬态运行工况下的蒸发器水位调节功能，应能够实现维持蒸发器相应水位的控制功能。 5.7.3根据设计说明书的具体要求进行蒸汽发生器水位控制功能的其他测试项。
负载性能是指各种工作负载下软件系统的性能，通常用来度量系统的可扩展性。可以通过测试当 渐增加时系统各组成部分的响应输出项，如通过率、响应时间、CPU负载、内存使用等情况，通 分析来决定系统的性能。
压力性能是指在软件系统稳定运行 作量强度或提供的最大服务 以通过测试临界负载、容量变化、资源占用等指标，综合分析功能执行情况和系统性能表现 个系统的瓶颈或者不能接受的性能点 量强度或最大服务性能。
6.3.1反应堆控制系统软件容错性能应至少满足
a）采用计算机的控制系统，应具有双机备份，人为退出工作主机，备用主机应能自动投入工作。 b） 在双机切换过程中，控制系统应保持正常工作，维持机组的正常运行。 C 重要参数的检测元件应为符合逻辑所需的余配置，采用去掉一个测量元件信号或在一个测量 元件输出端改变信号的方式，检查其穴余的可靠性。 6.3.2容错性能测试应包括： a） 键盘操作的容错测试。在操作员站的键盘上操作任何错误的键或未经定义的键时，系统不得出 错或出现死机情况，应视为不允许的输入，不加处理。 b） 控制单元切换时的容错测试。人为退出控制站中正在运行的控制单元，这时备用的控制单元应 自动投入工作，在控制单元的切换过程中，系统不得出错或出现死机情况。 c） 通信总线亢余切换能力的测试。在任意节点人为切断每条通信总线，系统不得出错或出现死机 情况。切、投通信总线上的任意节点，或模拟其故障，总线通信应正常。
3.2容错性能测试应包
重置性能是指在出现电源跳闸或者切换、硬件故障或者切换、网络故障等情况下，整个系统保持 行的能力，或是迅速恢复正常运行的能力。当切除并恢复系统的外围设备时，反应堆控制系统轮 出现任何异常情况，
6.5.1显示画面响应时间的测试
6.5.2系统响应时间的测试
将系统输出的开关量操作信号直接引到该操作对象反馈信号的输入端。测量通过操作台的键盘发 指令，直到屏幕上显示反馈信号之间的时间，操作信号响应时间应为2.0s～2.5s，或技术说明
6.5.3模拟量信号采集实时性的测试
6.5.4开关量信号采集实时性的测试
DL/TT142=2009
选择3个～5个开关量输入通道，接入测试用开关量信号，使之按设计的开关量采样周期改变状态。 通过画面状态显示或开关量状态记录，检查开关量信号采集的实时性。
事件顺序记录分辨力的测
利用一台开关量信号发生器进行测试，信号发生器应能送出间隔时间可在1ms～5ms之间调节的3 个～5个开关量信号。将信号发生器的信号接入事件顺序记录的输入端，改变信号发生器的间隔时间， 直至事件顺序记录无法分辨时为止，即为事件顺序记录的分辨力。分辨力应为1ms～2ms，或技术说明 书中规定的时间。
6.5.6控制器处理周期的测试
分别选择模拟量控制器和开关量控制器测试处理厂
6.6 抗干扰性能测试
抗干扰性能是指软件程序抵抗外部干扰的能力。反应堆控制系统软件应具有良好的抗干扶 抵抗干扰而增加的防卫措施应不仅能够抵抗干扰，并且对软件原有性能没有影响或者影响不大 响软件的正常运行
软件可用率是指在需要软件投入使用时，能实现其指定功能的能力。反应堆控制系统软件可用率 与整个控制系统可用率的测试一起进行。
软件的接口应符合数据传输机制和接口间协议的要求，接口通常包括： a）软件之间的接口，与用户其他系统或软件的接口。 b）人机接口，即人机界面 c）与外部设备的接口，包括与计算机硬件的接口
7.2软件之间的接口测试
软件之间的接口包括软件本身内部各个程序单元之间的接口，与其他软件（如操作系统、数据管理 专用计算包等）的接口，以及与用户其他系统的接口。 a 测试数据穿过接口时不应丢失或失真。 测试程序单元之间不应由于疏忽而造成有害影响。 测试子功能组合起来应产生预期的主功能。 d 测试全程数据库不应有错。 e） 测试接口信息的内容和格式。 竹 测试不同软件之间不应存在冲突
a）工程师站基本操作的测试。 b）操作员站基本操作的测试。 c）工程师站和操作员站之间的闭锁和保护的测试。
面包括流程图、参数图、实时趋势图、历史趋势
a）测试显示画面的种类及数量，应与原设计相符。 b）测试显示画面的更新频率和画面更新数据量。 c）测试显示分区的划分及其使用方法。
7.4与硬件的接口测试
软件产品与硬件设备是紧密联系的，尤其在反应堆控制系统中，只有软硬件协调工作才能实现对反 应堆的控制功能，满足安全的要求。 a）测试所有与软件接口的设备。 b）测试软件与硬件之间的配置特性，如端口的数目、指令装置等。 C）测试软件与硬件之间的通信方式和协议。
进行文档测试时，应主要考虑以下方面： a）明确文档验收的标准，软件开发人员和用户应对此达成一致。 b）确定文档的重要性和项目文档需求，在软件开发的不同阶段，各类文档的重要性有不同。 c）检验文档完整性，主要是文档的种类和内容的完整性。 d）检验文档的一致性和可追溯性，包括： 1）软件的设计描述应按照需求定义进行。 2） 应用程序应与设计文档的描述一致。 3） 用户文档应客观描述应用程序的实际操作。 4）关于同一问题的描述不应存在不同的说法。 检验文档的准确性，主要是文档描述应准确无歧义，文字表达不应存在错误。 f 检验文档的可理解性，主要审核文档应针对指定的用户，表达应易于理解并且详细。 名） 检验文档的易浏览性，主要审核文档应易于浏览，各类文档之间的相互关系应明确；每个文档 都应有目录表和/或索引表。
反应堆控制系统软件的文档应包括 软件程序，包含系统软件程序和应用软件程序，主要有可执行程序、源程序、配置脚本、测试 程序或脚本等。 b）天 开发类文档，主要有《技术规范书》、《需求说明书》、《概要设计说明书》、《详细设计说明书》、 《测试计划》、《程序维护手册》、《用户手册》、《联机帮助文件》、《数据库说明》等。 管理类文档，主要有《项目计划书》、《质量保证和控制计划》、《配置管理计划》、《用户培训计 划》、《质量总结报告》、《评审报告》、《开发进度报告》、《项目总结报告》等。
反应堆控制系统软件的测试活动和测试结果应汇总在测试报告 a）测试报告名称。 b）概述。 1）简述测试活动。 2） 被测试项及其版本/修订级别。 3） 测试环境（主要指测试用的计算机系统软硬件配置）。 4）所参照的技术规范书或设计说明书及其版本。 c）测试活动描述。
1）测试日期和时间。 2 测试数据（测试用例）。 3） 预期结果。 4） 实际结果。 5） 异常现象。 6） 测试参与人员。 d）评价。 1）测试评价：以测试结果和测试项的通过准则为依据，对每个测试项进行总的评价。 2）差异评价：报告测试项与技术规范书或设计说明书之间的差别，指出测试活动与测试计划 之间的差别，并说明原因。 e）总结。 1）测试活动的总结，指出测试活动的作用和意义。 2） 测试结果的总结，说明所有已解决的问题及其解决方法，指出尚未解决的问题。 3）意见和建议。
DL/T11422009
a）用户文档应包含产品使用所需信息。 b）如果安装能由用户来完成，则用户文档应包括安装手册，其中包含所有必要的信息。 c）如果维护能由用户来完成，则用户文档应包括程序维护手册，其中包含各种维护该软件所需要 的信息。
a）用户文档、程序和数据本身内容不能自相矛盾，相互之间也不应矛盾。 b）每个术语的含义宜处处保持一致。 c）由用户行使的软件操作和行为（如消息，屏幕输入格式和打印报表）宜有一致的结构
a）用户文档中的所有信息应是正确的，不能有歧义和错误的表达。 b）程序和数据应与用户文档中的全部说明相对应。 c）程序功能应以正确的方式执行。
a）软件应方便用户学习和操作。 b）软件应方便输入信息和输出结果。
a）软件的功能目标、程序结构和操作要求应是易理解的，如通过使用适当的术语、图形表示、 细的解释以及引用有用的信息源来表现。 b）出错消息应提供解释相应差错产生的原因和纠正的详细信息
a）用户文档应易于浏览，以便相互关系明确。 b）软件程序宜以易观察易读的形式向用户提供信息，并通过对信息的编码和分组对用户提供指导。 c）屏幕输入格式，报表和其他输入/输出宜设计清晰和易于浏览
a）软件应能在由外界要求所确定的时间内对数据进行处理。 b）可通过软件的时间特性来判断实时性，即在规定的边界条件下，执行某一任务的指定功能所需 要的时间，或因这些功能调用资源所需要的时间，例如响应时间和吞叶率等参数。
A.8开放性和可扩展性
欧件应能在不同规模、不同档次的运行环境平台
DL/T11422009
b）软件系统或程序在增加新项目的条件下，应能保持原系统基本结构不变并且保持正常运行。
a）软件应能按照预定的要求对某一功能组件进行修改或维护。修改包括为了适应环境的变化以及 功能规格说明的变化而对软件进行的修改、改进或更改。 b） 软件的可维护性确定了对软件进行维护的容易程度，包括对软件内模块、模块间接口、软件间 接口等的维护。
软件程序应能建立前后阶段的联系，具有为用户提供追踪查询的能力。追溯的内容包括： a）过程变量。 b）开关量变态，模拟量变化。 c）机组启、停参数。 d）参数越限。 e）事件、事故追忆。
DL/T11422009
B.1 设计的基本准则
附录B （资料性附录） 测试用例的设计
a）测试用例的代表性：应能代表各种合理和不合理的、合法和非法的、边界和越界的，以及极限 的输入数据、操作和环境设置等。 b）测试结果的可判定性：测试执行结果的正确性应是可判定的或可评估的。 c）测试结果的可再现性：对同样的测试用例，系统的执行结果应是相同的
编写测试用例文档。编写测试用例文档应有文档模板，须符合内部的规范要求。测试用例文档由简 介和测试用例两部分组成。简介部分应包括测试目的、测试范围、定义术语、参考文档、概述等。测试 用例部分则逐一列示各测试用例，每个具体测试用例都应包括下列详细信息：用例编号、用例名称、测 试等级、入口准则、验证步骤、期望结果（含判断标准）、出口准则、注释等。 设置测试用例。常见的设置有按功能设置和按路径设置。按功能测试是最简捷的，即按测试用例的 规约遍测每一功能。但对于复杂操作的程序模块，各功能的实施是相互影响、紧密相关的，没有严密的 逻辑分析，产生遗漏在所难免。因此，最好结合路径分析方法，以避免漏测试。 测试用例可以分为基本事件、备选事件和异常事件。设计基本事件的用例，应该参照用例规约（或 设计说明书），根据关联的功能、操作按路径分析法设计测试用例。而对孤立的功能则直接按功能设 计测试用例。基本事件的测试用例应包含所有需要实现的需求功能，覆盖率达100%。而设计备选事 件和异常事件的用例，则相对复杂和困难得多，可以采用软件测试常用的基本方法来设计完整的测试 用例。
B.3.1.1逻辑覆盖方法
逻辑覆盖方法是指程序内部的逻辑覆盖程度。当程序中有循环时，覆盖每条路径是不可能的，设计 测试用例要使覆盖的程度较高或是覆盖最有代表性的路径。 a）语句覆盖：为了提高发现错误的可能性，在测试时应该执行到程序中的每一条语句。语句覆盖 是指设计足够的测试用例，使被测试程序中每条语句至少执行1次。 b）美 判定覆盖：设计足够的测试用例，使得被测程序中每个判定表达式至少获得1次“真”值和“假” 值，从而使程序的每一个分支至少都通过1次，因此判定覆盖也称分支覆盖。 c）条件覆盖：设计足够的测试用例，使得判定表达式中每个条件的各种可能的值至少出现1次。 d） 判定/条件测试：设计足够的测试用例，使得判定表达式的每个条件的所有可能取值至少出现1 次，并使每个判定表达式所有可能的结果也至少出现1次。 e） 条件组合覆盖：比较强的覆盖标准，设计足够的测试用例，使得每个判定表达式中条件的各种 可能的值的组合都至少出现1次。 f 路径覆盖：设计足够的测试用例，覆盖被测程序中所有可能的路径。在实际的逻辑覆盖测试 中，一般以条件组合覆盖为主设计测试用例，然后再补充部分用例，以达到路径覆盖测试标 准。
B.3.1.2循环覆盖方法
B.3.1.3基本路径测试方法
B.3.2.1等价类划分方法
DW/T1422009
B.3.2.2边界值分析方法
边界值分析方法是对等价类划分方法的补充，通常与等价类划分结合起来设计测试用例。使用边界 值分析方法时，首先应确定边界情况，通常输入和输出等价类的边界，就是应着重测试的边界情况。应 当选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值 作为测试数据。 运用边界值分析方法设计测试用例应遵循以下原则： a）如果输入条件规定了值的范围，可以选择正好等于边界值的数据作为有效的测试用例，同时还
要选择刚好越过边界值的数据作为无效的测试用例。 b） 如果输入条件规定了值的个数，则按最大个数、最小个数、比最小个数少1、比最大个数多1 等情况分别设计测试用例。 c 对每个输出条件分别按照以上两个原则确定输出值的边界情况。 d）如果程序的规格说明给出的输入域或输出域是个有序集合，则应选取集合的第个元素和最后 一个元素作为测试用例。 e）分析规格说明，找出其他可能的边界条件。
B.3.2.3错误推测方法
在测试程序时，可以根据经验或直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测 试用例的方法。 错误推测方法的基本思想就是列举出程序中所有可能存在的错误和容易发生错误的特殊情况，根据 这些情况选择测试用例
B.3.2.4因果图方法
等价类划分和边界值分析的缺点是没有检查各种输入条件的组合，而因果图是一种适合于描述对于 多种输入条件的组合而相应产生多个动作的设计方法。借助因果图列出输入条件的各种组合与程序对应 力作结果之间的阶段联系，构造判定表，是生成测试用例的有效办法。 运用因果图方法生成测试用例的步骤如下： a）分析设计说明书（或技术规范书）中的原因（输入条件或者输入条件等价类）、结果（输出可 能性），对每个原因/结果进行编号。 b）找出原因/结果之间、原因/原因之间的对应关系，画出因果图。 c）在因果图上用一些记号表明约束或限制条件，将因果图转换为判定表。 d）对判定表中每一列生成测试用例
B.3.2.5综合策略方法
每种方法都能设计出一组有用的测试用例，用这组测试用例可能很容易发现某种类型的错误，但 现另一类型的错误。因此，在实际测试中，应该联合使用各种测试方法，形成综合策略。通常是 盒法设计基本的测试用例，再用自盒法补充一些必要的测试用例。
B.4.1指导软件测试的
测试用例主要适用于集成测试、系统测试。在实施测试时测试用例作为软件测试的标准，测试人员 一定要严格按照测试用例的测试项目和测试步骤逐一实施测试，并将测试情况记录在测试用例管理软件 中，以便自动生成测试结果文档
B.4.2规划测试数据的
按照测试用例配套准备一组或若干组测试原始数据，以及标准测试结果。除了正常数据之外，还 据测试用例设计大量边缘数据和错误数据。
B.4.3评估测试结果的度量基准
完成软件测试后需要对测试结果进行评估，并且编制测试报告。判断软件测试是否完成，衡量测 需要有量化的结果，如测试覆盖率是多少、测试合格率是多少、重要测试合格率是多少等。采用 例作度量基准将更加准确、有效。
B.4.4分析缺陷的标准
通过收集缺陷，对比测试用例和缺陷数据库，分析确证是漏测还是缺陷复现。漏测反映了测试用 完善，应立即补充相应测试用例，最终达到逐步完善软件质量的目的。如果已有相应的测试用例 映实施测试或变更处理存在问题。
B.5.1测试用例的评审
DL/T11422009
要组织同级互查。完成编制后应组织专家评审，需获得通过才可以使用。评审委员会可由项目负责人、 测试、编程、分析设计等有关人员组成混凝土标准规范范本，也可邀请用户代表参加。
B.5.2测试用例的修改
测试用例在形成文档后还需要不断完善，主要来自三方面的原因： a）在测试过程中发现设计测试用例时考虑不周，需要完善。 b）在软件交付使用后反馈的软件缺陷是由于测试用例存在漏洞而造成的。 c）软件自身的新增功能以及版本的更新，测试用例也必须配套修改更新。
海洋标准B.5.3测试用例的管理软件
运用测试用例还需配备测试用例管理软件，主要功能有： a）能将测试用例文档的关键内容，如编号、名称等自动导入管理数据库，形成与测试用例文档完 全对应的记录。 b）可供测试实施时及时输入测试情况。 c）最终实现自动生成测试结果文档，包含各测试度量值、测试覆盖表、测试通过或不通过的测试 用例清单列表，
运用测试用例还需配备测试用例管理软件，主要功能有： a） 能将测试用例文档的关键内容，如编号、名称等自动导入管理数据库，形成与测试用例文档完 全对应的记录。 b） 可供测试实施时及时输入测试情况。 c）最终实现自动生成测试结果文档，包含各测试度量值、测试覆盖表、测试通过或不通过的测试 用例清单列表。
....- 相关专题： 核电厂