RSSP-II安全通信协议软件自动测试研究
2021-07-20刘国靖王静杨晓峰
刘国靖 王静 杨晓峰
【摘要】 本文首先针对RSSP-II安全通信协议与软件自动测试的相关理论进行阐述,并在此基础上,分析了RSSP-II安全通信协议软件自动测试过程中对于结构、脚本的设计方式以及测试执行和回归测试的具体方法,希望能够给从事相关领域研究的人员,提供可靠的参考。
【关键词】 RSSP-II安全通信协议 软件自动测试 脚本设计 结构设计
RSSP-II安全通信协议属于铁路工程通讯领域的一种重要安全产品,针对该软件的功能测试一般使用SDP专业测试工具进行自动化测试,表现出了良好的测试效果和测试规范性。因此,针对RSSP-II安全通信协议提出科学的自动化测试框架,依托测试引擎与脚本的综合设计来完成实际测试环节中的错误注入,将会对该软件今后的正常使用产生深刻的影响。
一、RSSP-II安全通信协议与软件自动测试的理论概述
1.1 RSSP-II安全通信协议
RSSP-II安全通信协议,是一种依托以太网通讯的,适合在封闭传输系统与开放传输系统中使用的安全通讯传输协议,能够大范围使用在我国的城际铁路、高速铁路、城市轨道等交通信号控制系统当中。从级别上来看,RSSP-II安全通信协议属于SIL4级的安全软件产品,针对其开展功能测试时判定软件是否符合功能要求,具有足够安全性的一种必要措施。
1.2软件自动测试
当前我国的软件自动测试具有工作效率高、可信度良好等优势,特别是依托于脚本的软件自动测试更加高效灵活,为了增强测试效率、提升测试工作的规范化程度,RSSP-II安全通信协议的测试需要使用信号系统设计研发平台—SDP的专业测试工具。
二、结构设计方法
按照RSSP-II安全通信协议软件功能测试要求,参考SDP测试系统结构,设计RSSP-II安全通信协议软件自动化测试结构。在开展测试的过程中,被测安全通信协议软件依靠适配层对分引擎1与分引擎2进行外接,原语接口分引擎用于对被测安全通信协议软件用户应用层进行模拟。对等协议引擎用于进行被测安全通信协议软件的实体模拟。是实际应用过程中,计划在主引擎对脚本指令进行解析以后,将命令分别传送到分引擎1与分引擎2当中,另外,两个分引擎把被测安全通信协议软件所给出的实际执行结果进行汇总,并上报到主引擎。脚本基于测试案例开展设计,使用依托于TCL的Expect脚本语言。对等协议栈分引擎和主引擎之间采用protobuf模式的信息开展通讯,待测安全通讯协议栈则使用TCP与UDP格式的网络数据开展通讯。
如图1所示,分引擎2能够接收到待测安全通讯协议软件依靠互联网所传递的各类信息,依靠对这些加密信息的逐步解包以及一些正常逻辑判断后,将这些数据传输至主引擎当中,主引擎依靠与脚本的评估结果进行对比,由此来进行判定。
分引擎2还能够在主引擎当中进行正常逻辑指令的接收,同时和待测安全通讯协议软件进行通讯交互。更为关键的是,主引擎能够依靠分引擎2对真实协议栈开展测试,并将错误进行注入,安全通信协议栈针对其中的错误信息会进行反馈,并依靠分引擎1与分引擎2传送到主引擎当中。
综上,针对对等协议栈分引擎的设计,是对该软件进行自动化测试的重点,只需要构建对等协议栈分引擎的基本框架与通讯流程,便能够依靠脚本控制传送不同类型命令或信息来完成各类错误注入。
三、脚本设计方法
结合上文所论述的测试结构,RSSP-II安全通信协议的自动测试前期准备工作整合在测试分引擎1、分引擎2的设计完成和脚本测试制作。在此当中,针对分引擎1的设计应当遵照RSSP-II的应用原语接口要求,为了达到各类型的错误注入的效果测量,针对分引擎2的设计和测试脚本制作需要保持更加密切的联系。
RSSP-II安全通信协议基于功能由上到下可以划分为安全应用中部子层(SAI)、信息安全鉴定层(MASL)、冗余與适配管理层(ALE)。针对对等协议栈中所获得的信息必须要经过多次解包,同时开展相关的逻辑判定(如CRC核验、MAC核验等),之后将每层的内容基于数据字段格式送往主引擎用于与脚本的预期结果进行对比分析。因为在ALE层要完成CLASS D冗余通讯,对等协议栈分引擎于双通道进行数据收取时,应当在ALE层入口位置对两通道所发出数据包内容是否相同进行核对。组包与解包是两个相互对应的流程,因此在对等协议栈分引擎的每一层都必须要添加对应的包头或包尾,才能符合协议数据格式要求,由此实现安全通讯协议栈的通讯活动。
所谓错误注入,则是指依靠添加不同错误内容来测量安全协议栈对于不同错误所呈现的反应,这同样是对等协议栈分引擎设计达标的重要要求之一,对等协议栈分引擎的任意一层在接收到信息后直接汇总呈报到主引擎同时继续向上层进行传送,最终到达应用层。在对等协议栈分引擎没有收到主引擎所发出的动作指令时,会始终处于等待状态,通常情况下,所有对等分引擎传送点都能够且应当成为错误的注入点,从而能够推断出关联的测试功能点以及与之相对应的错误注入点。之后总结SAI层、MASL层以及ALE层的功能点,由此获取不同错误注入点的测试内容和测试引擎和脚本设计的相关重点,由此让测试案例的系统归纳与测试引擎的脚本结合设计得到有效完成,在对错误进行成功注入以后,被测协议栈的反应将会依靠引擎1与引擎2传送至主引擎当中,之后依靠对脚本预先设计的逻辑对软件的运行情况进行判定。
四、测试执行与回归测试
依靠软件自动测试过程中工作人员对RSSP-II安全通信协议的不断优化完善,RSSP-II安全通信协议的功能测试一共包含有超过300个不同的测试案例;功能测试共涉及有248个测试脚本(超300个案例中有12个案例是非脚本执行案例同时有两个案例重复使用了之前的测试脚本)。各案例之间不存在有前后关联性,针对可用脚本执行的测试案例,每一次测试执行一个案例的对应脚本,依次执行完全部脚本,针对每一个测试案例所设计的脚本,会把主引擎从分引擎出获取的第一手测试结果和真实结果进行横向对比比较,由此对其进行逻辑判定,同时主引擎依靠记载各类脚本是否有效通过检测的统计测试案例的真实执行状况。
针对RSSP-II安全通信协议在前7轮的功能检测,整体结果表现如表1所示
在进行回归测试的过程中,案例的个数与脚本数量呈现出逐次递增的趋势,但是除去案例个数相对比较稳定的第2轮-第5轮以及第6轮-第7轮的回归测试以前,引擎与脚本的设计工作所占用的工作时间相对更多意外,其他测试工作都能够异同软件自动化测试技术来高效率的完成,同时因为软件自动化测试技术在使用过程中具有比较好的一致性,以上两个阶段当中针对所设计脚本的整体重复使用率也相对较高,综上,针对涵盖多轮次的回归测试,使用SDP专项测试工具能够显著提升测试工作整体效率,强化测试结果的准确性和一致性。
使用SDP专业测试工具进行软件自动化测试工作,所要求使用的额外的知识储备主要涉及有分引擎与脚本的设计、开发等。RSSP-II安全通信协议软件的功能检测,在初期就使用的自动化脚本测试这一方式,所以在多轮数的回归测试当中,得到了极佳的时间、人力使用效率以及良好的测试覆盖情况。在对其进行回归测试的过程中,必须要引起高度关注的是,因为分引擎和主引擎网络UDP在通讯过程中存在有不稳定性,通讯延迟和Expect脚本延迟控制精度尚无法得到有效控制,一些脚本需要通过手动二次回归测才可以有效通过,而部分必须要进行精准测量的定时器超时功能案例,需要将待测协议栈超时量数据的颗粒度设置为较粗大。另外,虽然自动测试案例的覆盖率已经相对较好,但是针对一些测试案例,因为现有技术在灵活性方面的局限,仍然不建议使用脚本编写的方式开展自动化测试。
针对区域控制器(ZC)的子系统独立测试,分引擎于脚本的设计可以对比应用接口协议来进行研发,但是RSSP-II安全通信协议,是一种和实際应用之间没有关联的通信协议软件,它的测试案例更多关注的是使用软件进行通讯过程中所出现的重复、插入、损坏、延迟、伪装等错误以及相应的安全防护,所以在进行分引擎开发的过程中,工作人员需要全面衡量后期脚本开发过程中所涉及的一致性和可行性问题,在测试案例持续增多的过程中,依托对protobuf消息种类的方法达到使用脚本来控制对等协议栈分引擎向RSSP-II安全通信协议软件开展错误注入的新接口。上述引擎脚本结合设计研发的模式,针对SDP专项测试工具在通讯协议类型软件模块测试领域中的使用具有十分重要的参考价值。
五、结束语
整体来讲,本文所介绍的依托SDP测试工具的RSSP-II安全通信协议软件自动化测试设计与实现方式并使其使用在软件测试当中,通过实践证实,使用这一工具确实可以显著提升测试工作效率,尤其是在进行回归测试中,可以发挥出显著效果,提升测试工作的一致性和有效性。
参 考 文 献
[1]袁天弋.RSSP-I铁路信号安全通信协议的测试研究[J].铁路通信信号工程技术,2020,17(10):14-18.
[2]左林,刘贞,王一民.SM4分组密码算法在RSSP-Ⅱ铁路信号安全通信协议中的应用[J].铁路通信信号工程技术,2020,17(08):24-27.
[3]张凯. RSSP-Ⅱ中消息认证码算法的安全性研究[D].兰州交通大学,2020.
[4]吴迪,颜如月.信号系统中安全通信协议自动测试软件的设计与实现[J].数码设计,2017,6(07):37-39.
[5]刘振玉,任军.RSSP-II安全通信协议软件的自动测试设计及实现[J].铁路通信信号工程技术,2017,12(06):44-47.