PDF下载
非安全级DCS平台软件测试需求分析

曲萃萃1 刘汪平2 夏丹阳1

1.中核控制系统工程有限公司,北京市,100176;2.中国核电工程有限公司,北京市,100013

摘要: 核电DCS系统设计过程中其可靠性、安全性、功能正确性是需要关注的。测试是验证DCS(Distributed Control System)平台质量的重要方式之一,测试需求分析可以保证测试的充分性。本文考虑目前核电DCS系统需求的内容,浅析需求分析的流程、方法,同时结合GB/T 16260.1-2006确定软件产品的质量需求。
关键词: DCS(分布式控制系统);SRS(软件需求规格书);测试需求分析
DOI:10.12721/ccn.2025.157027
基金资助:
文章地址:

1引言

核电非安全级DCS平台软件测试的正确性、一致性、完整性、准确性是测试用例的重要特性直接反映了测试用例的质量[1],也是确保平台质量的重要因素之一。测试需求是分析核电非安全级DCS平台软件需求后的产物,可以充分的识别测试对象,与测试阶段可追踪性分析任务共同确保测试的正确性、一致性、完整性、准确性,同时测试需求分析还能充分的发现需求的不完善、不足、不严密之处。

2核电非安全级DCS平台软件软件测试需求分析的流程

测试需求分析的基线文件是SRS,软件测试需求分析首先要从SRS中识别出测试的对象,即测试项。核电DCS系统软件测试需求分析步骤如下:

1.了解和学习核电DCS平台的软件需求,明确其范围,包括一层、二层所采用的软件。一般核电DCS平台包括组态软件(一层控制器、二层组态画面、控制域等)、二层HMI软件、数据库软件等。

2.了解核电DCS系统中涉及的名词、实际应用中的特殊名词定义、对应的业务,业务包括实际电厂运行时的相关操作,如挂牌、设备操作等;

3.按核电DCS系统包括的模块去确定软件的功能,形成测试需求。DCS系统包括的模块很多,可划分为步骤1中所列的部分,同时各部分依据其实现的功能不同又可以细化,如HMI软件又可分为报警、趋势、流程图、当前值、日志、挂牌、性能计算、打印、数据存档和查询、表格、报表、故障诊断、规程、安全参数显示、权限管理等功能模块。测试需求分析的原则是划分到最小的功能模块;

4.根据步骤3中确定的模块,将一个模块中的功能点形成对应的测试项。以报警模块为例,报警信息的确认可以作为一个测试项;

5.分析每一测试项所对应的参与项,包括其对应的输入、约束、处理和输出。以报警信息的确认为例,输入包括报警信息、确认指令、约束为报警信息的状态、处理为报警状态的修改、输出为报警列表中最终显示的状态;

6.明确各参与项之间的关系;

7.明确该功能所对应的流程,即该功能的执行路径;

8.明确需求分析中不同功能的流程所组成的业务,形成业务场景活动图;

9.分析不同功能所隐藏的隐性需求;

10.对部分需求进行删除、细化、合并,并形成记录。 

3软件测试需求分析的方法

3.1软件测试需求分析规程

DCS平台软件测试需求分析按如下几步实现:

1.列出DCS平台软件开发需求中可测试性的需求;

2.对步骤1)的每一条开发需求,形成分层描述的测试需求,对部分需求进行删除、细化、合并;

3.对步骤2)形成的每一条测试需求,从GB/T 16260.1-2006《软件工程 产品质量 第1部分:质量模型》中定义的软件内部/外部质量模型来确定软件产品的质量需求;

4. 结合测试需求和步骤3)中确定的质量子特性来确定测试类型。

5.建立测试需求跟踪矩阵,建立开发需求与测试需求的追踪关系,便于对测试需求进行管理。

3.2 需求的采集

需求采集的过程是将软件开发需求中的那些具有可测试性的需求或特性提取出来,形成原始测试需求。测试需求主要通过以下途径来进行收集:

1.与待测软件相关的各种文档资料。如技术规格说明书、SRS、任务书、合同、Use case、界面设计、项目会议或与客户沟通时有关于需求信息的会议记录、其他技术文档等;

2.与业主或开发/设计人员的沟通;

3.业务背景资料。DCS平台软件业务领域的知识等;

4.公司内部或外部的各类培训;

5.其他。如果以已有的DCS平台为原型,以全新的架构方式来设计或完善软件,那么已有的DCS平台原有功能跟特性就成为了最有效的测试需求收集途径。

采集的原始测试需求存在重复和冗余、内容颗粒度大,需经提取,可以通过以下方法提取原始测试需求:

删除:删除原始测试需求中重复的、冗余的含有包含关系的原始测试需求描述;

细化:对太简略的原始测试需求描述进行细化。

合并:如果有类似的原测试始需求,在提取时需要对其进行合并。

对每一条提取后的测试需求,应从GB /T16260.1定义的软件质量子特性角度出发,确定所对应的质量子特性并确定测试类型。

3.3测试需求分析表  

软件测试需求分析表如下所示:

3.png

1.测试项

测试项的名称应概括测试项描述中的全部测试需求,并具有一致性、无二义性。

2.测试项标识

测试项的标识在整个项目的全生命周期中应是唯一可识别的。

3.追踪关系

追踪关系是测试需求跟踪矩阵中建立的开发需求与测试需求的追踪关系。

4.测试项描述

测试项描述的内容是SRS的完全复现,对测试项的具体描述,详细的列出本测试项所对应的软件需求。在测试项描述中对采集到的需求应按照功能分类,如同一测试对象的不同功能需求、不同测试对象的相同功能可总结到一起,并以一个小标题进行说明。

例:【信息排序方式】

SRS-02-44-1报警行信息可以按照时间排序,不管前一次的操作状态,只要切入报警监视画面,就隐含选择了按时间排序显示的方式。

SRS-02-44-2报警行信息可以按照ID-Code字母排序方式显示,点击“字母”按钮可以切换到按ID-Code字母排序方式显示。

5.测试设计约束

测试设计的约束是在进行测试设计过程中,因某种外因而导致设计好的测试不具备可测的条件。这些外因包括硬件环境、软件环境及网络环境、人力资源等。

6.测试类型

测试类型是结合需求质量子特性而确定的。对每一条测试需求,从GB/T16260.1定义的软件质量子特性角度出发,确定所对应的质量子特性进而确定测试类型,测试类型包括功能测试、功能多余物测试、边界测试、性能测试、接口测试、安全性测试、强度测试、可靠性测试、恢复性测试、人机交互界面测试、余量测试、配置测试、安装性测试、兼容性测试。

7.测试内容及方法

测试需求分析的大致内容包括测试目的、测试类型、测试相关的风险点、测试相关各模块的优先级、测试环境(操作系统、浏览器版本等)、测试前置条件(有效条件、无效条件)、测试数据(有效数据、无效数据)、预期结果、测试执行方法(手工方法、自动化方法)、测试结果的验证过程及方法、测试执行后数据恢复方法。

4 总结

本文在总结了核电DCS系统软件测试需求分析必要性的基础上,深入剖析一下我们进行测试需求分析的成因,研究测试需求的方式方法,并以此做好测试需求的收集与整理工作[2]。为执行其他行业的软件测试需求分析提供了参考。

[1] 软件测试用例的设计方法[J]. 张倩倩,赵星汉,高湘飞.  电子技术与软件工程. 2018(11)

[2] 浅谈项目测试需求分析[J]. 曾丽兰.  计算机产品与流通. 2019(07) 

作者简介:曲萃萃(1985— ),通信作者,女,天津市人,工程师,硕士,从事核电厂仪控系统的验证和确认。