[摘 要]随着上海地铁线网规模的扩大,上海测试中心需要承接的测试任务越来越重,使用原来的人工测试和测试管理模式,导致测试中心的人力成本和运营成本不断加大。文章以测试中心平台管理软件的设计方案为例,通过管理软件对测试工作进行全生命周期管理,增加自动测试脚本和自动测试报告生成,减轻测试人员的工作压力,提高测试工作的效率,以供参考和借鉴。
[关键词]人工测试;全生命周期管理;自动测试
中图分类号:TP3;U28 文献标识码:A 文章编号:1674-1722(2024)11-0010-03
截至2023年底,上海市已开通地铁线路18条,自动售检票系统已开通终端设备共计15163台,其中包括自动售票机3464台、自动检票机10236台、半自动售票机1463台,另有车站计算机461台,线网规模巨大。在新线入网时,需要对新制造的系统和设备以及将接入网络化运营的系统和设备进行功能测试和性能测试,对待接入系统进行兼容性测试。测试中心的功能、性能测试以及兼容性测试内容包括设备硬件技术规格,设备功能、设备性能指标是否满足用户需求。同时,测试中心需要测试设备和系统的软件接口,检验设备和系统软件是否依据《上海城市轨道交通自动售检票系统专用技术说明》的要求,确保设备和系统能够正确地接入原有的自动售检票系统。在传统的测试模式下,相关的测试工作由测试中心派遣专业测试人员编制测试案例,按照测试案例逐项测试,手工记录测试结果。对于接口测试,测试人员需要借助多种专用的测试工具,如门机构测试工具、车票发售回收机构测试工具和读写器测试工具等。测试人员操作测试工具,向上下级节点发送通信报文,人工检查设备或系统的响应报文是否正确。往往完整地测试一个终端设备就需要2周或者更长的时间。测试完成后还需花费大约一周时间整理、统计和分析测试数据,编制测试报告。因此,一套设备功能性能测试及接口测试需要花费的时间基本上为1个月左右。新线上线时,一般会有5—7套新设备外加车站计算机需要测试。在传统模式下,测试一套设备一般需要两位测试人员。因此,新线上线之前的测试工作压力极大。同时,测试工具一般为部件厂商提供,测试工具的输入输出都不是按照测试的要求设计和开发的,给操作带来诸多不便。
为了解决上述问题,文章提出了测试中心管理软件的设计方案,该软件集成了从终端设备到SC的各类模拟器,支持自定义测试方案,系统根据测试方案内的各个测试案例按顺序执行,支持导入测试报告模板,在测试结束后自动生成测试报告,形成测试方案库。
文章研究的测试中心平台软件采用B/S架构,在逻辑上软件采用分层结构设计,软件分为数据层、基础应用层和应用层。软件的逻辑架构图如图1所示。
(一)数据层
数据层部署SQLite数据库管理软件,管理测试中心平台软件的各类数据。数据可分为测试用例库、测试案例库、测试执行日志、通信报文、测试报告模板和测试报告等。其中,测试用例库保存系统内使用的所有测试用例。测试用例是系统中测试案例的最小可执行单位。测试用例数据包括了测试用例的名称、测试用例的描述、测试用例的类型、所属的设备类型、测试用例的输入和输出信息[ 1 ]。测试用例的输入和输出信息是该测试用例需要发送和接收的通信报文。该项数据包括通信报文的传输节点、通信报文的格式、通信报文应答判定条件等。测试案例由一个或者多个测试用例组成。测试案例数据包括测试案例的名称、测试案例所属的设备类型、测试案例的功能描述和测试案例的执行序列(队列,保存测试案例中的各个测试用例)。同时,测试案例保存了待测试的系统的配置信息,包括系统内有哪些模拟器、模拟器的配置信息、模拟器和待测试部件/系统的通信配置等。测试案例、测试用例及测试方案的关系如图2所示。
同时,测试中心平台管理软件在执行测试案例的过程中,系统会保存执行过程中的通信报文和执行日志,方便用户在测试案例执行失败时追溯问题。测试中心平台软件还支持用户定制测试报告模板,系统按模板自动生成测试报告。系统在数据库中保存测试报告模板数据和生成过的测试报告。
(二)基础应用层
基础应用层为测试中心平台软件提供基础服务,包括各类模拟器、系统权限管理、系统配置、测试系统图形化管理界面、测试报告模板和测试数据统计等。为方便用户测试各类接口,测试中心平台管理软件包含了一系列的模拟器。模拟器的种类包括自动检票机模拟器、自动售票机模拟器、半自动售票机模拟器、读写器、车站计算机模拟器和多线路中心模拟器等[ 2 ]。
当用户需要测试自动售检票系统中的任意设备或者任意模块时,可以在图形界面对模拟器进行配置,完成测试环境的配置。测试中心平台软件使用RBAC模型管理系统用户的权限,对于不同的用户角色配置不同的系统使用权限,然后给用户分配一个或多个角色,完成权限配置。系统提供了图形化管理界面,使用组态软件的模式使得用户方便地在图形界面上通过拖拉就能构建起一个测试系统,通过对各个组件属性的编辑,设定测试环境的一系列参数。
为了方便用户,系统还提供了测试报告的定制功能,由用户导入测试报告的模板,系统在测试完成后,依据测试报告模板生成相应的测试报告。
(三)应用层
应用层为测试中心平台软件的顶层管理应用,为用户提供各类测试功能,包括测试系统构建、测试案例管理、测试用例管理、测试报告管理和测试数据分析等。
以下以用户执行一个完整的测试案例的场景,描述测试平台软件的功能设计。
(一)建立测试系统模型
当用户需要对某个部件、设备或者系统进行测试时,需对本次测试进行系统建模,构建要测试的系统。设定要测试的部件、设备或者系统的设备类型及其上下级节点的设备类型,设定要测试的部件、设备或者系统和上下级节点的配置参数[ 3 ]。为了方便用户操作,测试中心平台软件以组态软件的方式,给用户提供了图形界面操作方式,用户通过拖拉系统预定义的模拟器图标到界面上,将虚拟设备添加到测试系统中。由于需要测试待测试的部件、设备和系统与上下级节点的通信,因此,用户需要在测试系统模型中定义待测试的部件、设备和系统与上下级节点的通信配置参数。用户选择连接线图表将要测试的模块和新建的模拟设备相连,定义被测试的系统和模拟设备之间的通信连接方式和通信参数。通信连接方式包括网络通信、USB、串口通信连接等。由于目前上海市地铁已经对门机构、车票发售/回收机构等设备的通信协议进行了标准化,因此,系统判断被测试的系统的类型和与之连接的虚拟设备的类型后,自动匹配通信参数。对于还未标准化的部件、设备或者系统,用户需自定义被测试系统和模拟设备之间的通信参数。如果使用串行通信,那么用户需定义通信的波特率、起始字节、结束字节、转义符、各个数据段的名称和长度以及数据格式。以进行读写器测试为例,测试系统的模型如图3所示。
(二)测试案例管理
在完成对测试系统的建模以后,用户可以新建或者选择已有的测试案例,将测试模型与测试案例绑定。测试中心平台软件根据《上海城市轨道交通自动售检票系统专用技术说明》的规定预置了接口测试案例等多个案例。当用户需要新增测试案例时,可以修改已有的测试案例,生成新的测试案例,或者从测试用例库中选取系统预设的测试用例,重新建立新的测试案例。例如,当对自动检票机进行测试时,用户可以通过组合系统预置的自动检票机接口测试案例和自动检票机功能测试案例,组成一个新的测试案例。测试平台软件将自动检票机接口测试案例和自动检票机功能测试案例,按顺序添加到新的测试案例中。同时,测试平台软件可以通过查询条件,方便查找已有的或者预设的测试案例,用户可对测试案例进行基本数据操作,包括新增、删除、编辑和查找。
(三)测试用例管理
为了方便用户操作和管理,测试平台管理软件将测试用例作为测试案例的最小组成单位,即一个测试案例由一个或者多个测试用例组成。系统最小的测试执行单元为测试用例。测试用例使用与测试案例相同的管理机制,用户可对测试用例进行增删改查等操作。为了减少用户的操作不便,新建测试用例时,可以基于系统现有的预设测试用例或者从头新建一个测试用例。一个测试用例包括以下的基本信息:测试用例的名称、选择测试用例所属的设备/系统的类型、测试用例的描述信息、测试用例的输入和输出、测试用例通过的条件等。测试用例的输入和输出,指的是测试用例执行过程中需要进行的通信交互。其中,输入为模拟设备发送给被测试设备的报文,输出则为被测试的设备发送给与被测试设备相连接的模拟设备的报文。
在定义输入和输出的同时,还需定义输入和输出的节点信息,即为虚拟设备的IP地址。测试用例通过的条件是指,判定该测试用例执行成功的条件。以测试读写器初始化命令的测试用例为例,在这个测试用例中,要测试的设备是读写器,虚拟设备为上位机(可以是自动检票机、自动售票机或者半自动售票机中的一种)。测试用例的输入是由上位机发送给读写器的初始化命令,输出则为读写器返回给上位机的响应数据。所有的设置设定完成后,系统执行该测试用例。在执行中,模拟上位机(终端设备的一种)给被测试的读写器发送初始化命令,收到数据后检查相关的字段判断读写器是否正确地执行了初始化命令。
(四)测试报告管理
作为一套全自动的测试管理软件,测试中心平台管理软件应尽量减少用户的操作和表单录入工作。测试报告是测试案例执行中的最后一个步骤,作为测试数据展示和测试结果的证明文件,测试报告可能因为测试的项目的不同,或者委托客户的需求而需要有不同的格式。因此,测试中心平台管理软件需提供测试报告模板功能,使用户能够自定义测试报告的格式和内容。同时,应提供测试报告模板工具,提供图形化界面,使用户通过拖拉等简单的操作,就可以将要显示的内容添加到测试报告中。在添加完内容后,用户可以点击要显示的内容,在详细信息中设定要显示的数据的格式。在设置完以后,用户可以点击预览按钮,预览要生成的测试报告,查看测试报告的格式是否满足需求。
(五)测试数据分析
测试中心平台管理软件根据管理的需要,将需要统计测试案例的通过率和测试工作量等数据。在执行测试案例时,系统保存所有测试数据,以便统计测试数据,生成统计报表。可出具的报表包括测试通过率和按测试人员统计其进行的测试工作量等。其中,系统从测试人员登录系统后,监测和统计测试人员的各类行为。当测试人员进入测试案例编辑功能或测试用例编辑功能后,开始统计该测试人员的工时。因此,统计得出测试人员的总工时,即:总工时=新建/编辑测试案例的时间+新建/编辑测试用例的时间(属于前述测试案例的测试用例)+新建编辑测试报告模板的时间(属于前述测试案例的测试报告)。
文章通过对现有的测试中心设备和系统功能测试、性能测试和系统兼容性测试的需求的详细分析,设计了一套全新的测试中心平台管理软件。将原有的需要大量人力的可重复性测试工作升级为由系统自动执行的测试案例,减少了测试人员进行测试和记录的时间,加快了测试进度。同时,这一研究对促进系统标准化有着积极意义,对测试工作的减员增效有很好的效果,能够产生一定的社会效益。
[1]刘加森.软件测试方法研究[J].中国科技投资,2016(32):279.
[2]袁海根,李红丽.云计算下的软件测试系统探讨[J].佳木斯职业学院学报,2018(04):439.
[3]赵晓岚.规范化软件测试过程浅析[J].航天控制,2010(01):96-98.