[摘 要]隨著上海地鐵線網(wǎng)規(guī)模的擴(kuò)大，上海測試中心需要承接的測試任務(wù)越來越重，使用原來的人工測試和測試管理模式，導(dǎo)致測試中心的人力成本和運(yùn)營成本不斷加大。文章以測試中心平臺(tái)管理軟件的設(shè)計(jì)方案為例，通過管理軟件對(duì)測試工作進(jìn)行全生命周期管理，增加自動(dòng)測試腳本和自動(dòng)測試報(bào)告生成，減輕測試人員的工作壓力，提高測試工作的效率，以供參考和借鑒。

[關(guān)鍵詞]人工測試；全生命周期管理；自動(dòng)測試

中圖分類號(hào)：TP3；U28 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：1674-1722（2024）11-0010-03

截至2023年底，上海市已開通地鐵線路18條，自動(dòng)售檢票系統(tǒng)已開通終端設(shè)備共計(jì)15163臺(tái)，其中包括自動(dòng)售票機(jī)3464臺(tái)、自動(dòng)檢票機(jī)10236臺(tái)、半自動(dòng)售票機(jī)1463臺(tái)，另有車站計(jì)算機(jī)461臺(tái)，線網(wǎng)規(guī)模巨大。在新線入網(wǎng)時(shí)，需要對(duì)新制造的系統(tǒng)和設(shè)備以及將接入網(wǎng)絡(luò)化運(yùn)營的系統(tǒng)和設(shè)備進(jìn)行功能測試和性能測試，對(duì)待接入系統(tǒng)進(jìn)行兼容性測試。測試中心的功能、性能測試以及兼容性測試內(nèi)容包括設(shè)備硬件技術(shù)規(guī)格，設(shè)備功能、設(shè)備性能指標(biāo)是否滿足用戶需求。同時(shí)，測試中心需要測試設(shè)備和系統(tǒng)的軟件接口，檢驗(yàn)設(shè)備和系統(tǒng)軟件是否依據(jù)《上海城市軌道交通自動(dòng)售檢票系統(tǒng)專用技術(shù)說明》的要求，確保設(shè)備和系統(tǒng)能夠正確地接入原有的自動(dòng)售檢票系統(tǒng)。在傳統(tǒng)的測試模式下，相關(guān)的測試工作由測試中心派遣專業(yè)測試人員編制測試案例，按照測試案例逐項(xiàng)測試，手工記錄測試結(jié)果。對(duì)于接口測試，測試人員需要借助多種專用的測試工具，如門機(jī)構(gòu)測試工具、車票發(fā)售回收機(jī)構(gòu)測試工具和讀寫器測試工具等。測試人員操作測試工具，向上下級(jí)節(jié)點(diǎn)發(fā)送通信報(bào)文，人工檢查設(shè)備或系統(tǒng)的響應(yīng)報(bào)文是否正確。往往完整地測試一個(gè)終端設(shè)備就需要2周或者更長的時(shí)間。測試完成后還需花費(fèi)大約一周時(shí)間整理、統(tǒng)計(jì)和分析測試數(shù)據(jù)，編制測試報(bào)告。因此，一套設(shè)備功能性能測試及接口測試需要花費(fèi)的時(shí)間基本上為1個(gè)月左右。新線上線時(shí)，一般會(huì)有5—7套新設(shè)備外加車站計(jì)算機(jī)需要測試。在傳統(tǒng)模式下，測試一套設(shè)備一般需要兩位測試人員。因此，新線上線之前的測試工作壓力極大。同時(shí)，測試工具一般為部件廠商提供，測試工具的輸入輸出都不是按照測試的要求設(shè)計(jì)和開發(fā)的，給操作帶來諸多不便。

為了解決上述問題，文章提出了測試中心管理軟件的設(shè)計(jì)方案，該軟件集成了從終端設(shè)備到SC的各類模擬器，支持自定義測試方案，系統(tǒng)根據(jù)測試方案內(nèi)的各個(gè)測試案例按順序執(zhí)行，支持導(dǎo)入測試報(bào)告模板，在測試結(jié)束后自動(dòng)生成測試報(bào)告，形成測試方案庫。

一、軟件架構(gòu)設(shè)計(jì)

文章研究的測試中心平臺(tái)軟件采用B/S架構(gòu)，在邏輯上軟件采用分層結(jié)構(gòu)設(shè)計(jì)，軟件分為數(shù)據(jù)層、基礎(chǔ)應(yīng)用層和應(yīng)用層。軟件的邏輯架構(gòu)圖如圖1所示。

（一）數(shù)據(jù)層

數(shù)據(jù)層部署SQLite數(shù)據(jù)庫管理軟件，管理測試中心平臺(tái)軟件的各類數(shù)據(jù)。數(shù)據(jù)可分為測試用例庫、測試案例庫、測試執(zhí)行日志、通信報(bào)文、測試報(bào)告模板和測試報(bào)告等。其中，測試用例庫保存系統(tǒng)內(nèi)使用的所有測試用例。測試用例是系統(tǒng)中測試案例的最小可執(zhí)行單位。測試用例數(shù)據(jù)包括了測試用例的名稱、測試用例的描述、測試用例的類型、所屬的設(shè)備類型、測試用例的輸入和輸出信息[ 1 ]。測試用例的輸入和輸出信息是該測試用例需要發(fā)送和接收的通信報(bào)文。該項(xiàng)數(shù)據(jù)包括通信報(bào)文的傳輸節(jié)點(diǎn)、通信報(bào)文的格式、通信報(bào)文應(yīng)答判定條件等。測試案例由一個(gè)或者多個(gè)測試用例組成。測試案例數(shù)據(jù)包括測試案例的名稱、測試案例所屬的設(shè)備類型、測試案例的功能描述和測試案例的執(zhí)行序列（隊(duì)列，保存測試案例中的各個(gè)測試用例）。同時(shí)，測試案例保存了待測試的系統(tǒng)的配置信息，包括系統(tǒng)內(nèi)有哪些模擬器、模擬器的配置信息、模擬器和待測試部件/系統(tǒng)的通信配置等。測試案例、測試用例及測試方案的關(guān)系如圖2所示。

同時(shí)，測試中心平臺(tái)管理軟件在執(zhí)行測試案例的過程中，系統(tǒng)會(huì)保存執(zhí)行過程中的通信報(bào)文和執(zhí)行日志，方便用戶在測試案例執(zhí)行失敗時(shí)追溯問題。測試中心平臺(tái)軟件還支持用戶定制測試報(bào)告模板，系統(tǒng)按模板自動(dòng)生成測試報(bào)告。系統(tǒng)在數(shù)據(jù)庫中保存測試報(bào)告模板數(shù)據(jù)和生成過的測試報(bào)告。

（二）基礎(chǔ)應(yīng)用層

基礎(chǔ)應(yīng)用層為測試中心平臺(tái)軟件提供基礎(chǔ)服務(wù)，包括各類模擬器、系統(tǒng)權(quán)限管理、系統(tǒng)配置、測試系統(tǒng)圖形化管理界面、測試報(bào)告模板和測試數(shù)據(jù)統(tǒng)計(jì)等。為方便用戶測試各類接口，測試中心平臺(tái)管理軟件包含了一系列的模擬器。模擬器的種類包括自動(dòng)檢票機(jī)模擬器、自動(dòng)售票機(jī)模擬器、半自動(dòng)售票機(jī)模擬器、讀寫器、車站計(jì)算機(jī)模擬器和多線路中心模擬器等[ 2 ]。

當(dāng)用戶需要測試自動(dòng)售檢票系統(tǒng)中的任意設(shè)備或者任意模塊時(shí)，可以在圖形界面對(duì)模擬器進(jìn)行配置，完成測試環(huán)境的配置。測試中心平臺(tái)軟件使用RBAC模型管理系統(tǒng)用戶的權(quán)限，對(duì)于不同的用戶角色配置不同的系統(tǒng)使用權(quán)限，然后給用戶分配一個(gè)或多個(gè)角色，完成權(quán)限配置。系統(tǒng)提供了圖形化管理界面，使用組態(tài)軟件的模式使得用戶方便地在圖形界面上通過拖拉就能構(gòu)建起一個(gè)測試系統(tǒng)，通過對(duì)各個(gè)組件屬性的編輯，設(shè)定測試環(huán)境的一系列參數(shù)。

為了方便用戶，系統(tǒng)還提供了測試報(bào)告的定制功能，由用戶導(dǎo)入測試報(bào)告的模板，系統(tǒng)在測試完成后，依據(jù)測試報(bào)告模板生成相應(yīng)的測試報(bào)告。

（三）應(yīng)用層

應(yīng)用層為測試中心平臺(tái)軟件的頂層管理應(yīng)用，為用戶提供各類測試功能，包括測試系統(tǒng)構(gòu)建、測試案例管理、測試用例管理、測試報(bào)告管理和測試數(shù)據(jù)分析等。

二、功能設(shè)計(jì)

以下以用戶執(zhí)行一個(gè)完整的測試案例的場景，描述測試平臺(tái)軟件的功能設(shè)計(jì)。

（一）建立測試系統(tǒng)模型

當(dāng)用戶需要對(duì)某個(gè)部件、設(shè)備或者系統(tǒng)進(jìn)行測試時(shí)，需對(duì)本次測試進(jìn)行系統(tǒng)建模，構(gòu)建要測試的系統(tǒng)。設(shè)定要測試的部件、設(shè)備或者系統(tǒng)的設(shè)備類型及其上下級(jí)節(jié)點(diǎn)的設(shè)備類型，設(shè)定要測試的部件、設(shè)備或者系統(tǒng)和上下級(jí)節(jié)點(diǎn)的配置參數(shù)[ 3 ]。為了方便用戶操作，測試中心平臺(tái)軟件以組態(tài)軟件的方式，給用戶提供了圖形界面操作方式，用戶通過拖拉系統(tǒng)預(yù)定義的模擬器圖標(biāo)到界面上，將虛擬設(shè)備添加到測試系統(tǒng)中。由于需要測試待測試的部件、設(shè)備和系統(tǒng)與上下級(jí)節(jié)點(diǎn)的通信，因此，用戶需要在測試系統(tǒng)模型中定義待測試的部件、設(shè)備和系統(tǒng)與上下級(jí)節(jié)點(diǎn)的通信配置參數(shù)。用戶選擇連接線圖表將要測試的模塊和新建的模擬設(shè)備相連，定義被測試的系統(tǒng)和模擬設(shè)備之間的通信連接方式和通信參數(shù)。通信連接方式包括網(wǎng)絡(luò)通信、USB、串口通信連接等。由于目前上海市地鐵已經(jīng)對(duì)門機(jī)構(gòu)、車票發(fā)售/回收機(jī)構(gòu)等設(shè)備的通信協(xié)議進(jìn)行了標(biāo)準(zhǔn)化，因此，系統(tǒng)判斷被測試的系統(tǒng)的類型和與之連接的虛擬設(shè)備的類型后，自動(dòng)匹配通信參數(shù)。對(duì)于還未標(biāo)準(zhǔn)化的部件、設(shè)備或者系統(tǒng)，用戶需自定義被測試系統(tǒng)和模擬設(shè)備之間的通信參數(shù)。如果使用串行通信，那么用戶需定義通信的波特率、起始字節(jié)、結(jié)束字節(jié)、轉(zhuǎn)義符、各個(gè)數(shù)據(jù)段的名稱和長度以及數(shù)據(jù)格式。以進(jìn)行讀寫器測試為例，測試系統(tǒng)的模型如圖3所示。

（二）測試案例管理

在完成對(duì)測試系統(tǒng)的建模以后，用戶可以新建或者選擇已有的測試案例，將測試模型與測試案例綁定。測試中心平臺(tái)軟件根據(jù)《上海城市軌道交通自動(dòng)售檢票系統(tǒng)專用技術(shù)說明》的規(guī)定預(yù)置了接口測試案例等多個(gè)案例。當(dāng)用戶需要新增測試案例時(shí)，可以修改已有的測試案例，生成新的測試案例，或者從測試用例庫中選取系統(tǒng)預(yù)設(shè)的測試用例，重新建立新的測試案例。例如，當(dāng)對(duì)自動(dòng)檢票機(jī)進(jìn)行測試時(shí)，用戶可以通過組合系統(tǒng)預(yù)置的自動(dòng)檢票機(jī)接口測試案例和自動(dòng)檢票機(jī)功能測試案例，組成一個(gè)新的測試案例。測試平臺(tái)軟件將自動(dòng)檢票機(jī)接口測試案例和自動(dòng)檢票機(jī)功能測試案例，按順序添加到新的測試案例中。同時(shí)，測試平臺(tái)軟件可以通過查詢條件，方便查找已有的或者預(yù)設(shè)的測試案例，用戶可對(duì)測試案例進(jìn)行基本數(shù)據(jù)操作，包括新增、刪除、編輯和查找。

（三）測試用例管理

為了方便用戶操作和管理，測試平臺(tái)管理軟件將測試用例作為測試案例的最小組成單位，即一個(gè)測試案例由一個(gè)或者多個(gè)測試用例組成。系統(tǒng)最小的測試執(zhí)行單元為測試用例。測試用例使用與測試案例相同的管理機(jī)制，用戶可對(duì)測試用例進(jìn)行增刪改查等操作。為了減少用戶的操作不便，新建測試用例時(shí)，可以基于系統(tǒng)現(xiàn)有的預(yù)設(shè)測試用例或者從頭新建一個(gè)測試用例。一個(gè)測試用例包括以下的基本信息：測試用例的名稱、選擇測試用例所屬的設(shè)備/系統(tǒng)的類型、測試用例的描述信息、測試用例的輸入和輸出、測試用例通過的條件等。測試用例的輸入和輸出，指的是測試用例執(zhí)行過程中需要進(jìn)行的通信交互。其中，輸入為模擬設(shè)備發(fā)送給被測試設(shè)備的報(bào)文，輸出則為被測試的設(shè)備發(fā)送給與被測試設(shè)備相連接的模擬設(shè)備的報(bào)文。

在定義輸入和輸出的同時(shí)，還需定義輸入和輸出的節(jié)點(diǎn)信息，即為虛擬設(shè)備的IP地址。測試用例通過的條件是指，判定該測試用例執(zhí)行成功的條件。以測試讀寫器初始化命令的測試用例為例，在這個(gè)測試用例中，要測試的設(shè)備是讀寫器，虛擬設(shè)備為上位機(jī)（可以是自動(dòng)檢票機(jī)、自動(dòng)售票機(jī)或者半自動(dòng)售票機(jī)中的一種）。測試用例的輸入是由上位機(jī)發(fā)送給讀寫器的初始化命令，輸出則為讀寫器返回給上位機(jī)的響應(yīng)數(shù)據(jù)。所有的設(shè)置設(shè)定完成后，系統(tǒng)執(zhí)行該測試用例。在執(zhí)行中，模擬上位機(jī)（終端設(shè)備的一種）給被測試的讀寫器發(fā)送初始化命令，收到數(shù)據(jù)后檢查相關(guān)的字段判斷讀寫器是否正確地執(zhí)行了初始化命令。

（四）測試報(bào)告管理

作為一套全自動(dòng)的測試管理軟件，測試中心平臺(tái)管理軟件應(yīng)盡量減少用戶的操作和表單錄入工作。測試報(bào)告是測試案例執(zhí)行中的最后一個(gè)步驟，作為測試數(shù)據(jù)展示和測試結(jié)果的證明文件，測試報(bào)告可能因?yàn)闇y試的項(xiàng)目的不同，或者委托客戶的需求而需要有不同的格式。因此，測試中心平臺(tái)管理軟件需提供測試報(bào)告模板功能，使用戶能夠自定義測試報(bào)告的格式和內(nèi)容。同時(shí)，應(yīng)提供測試報(bào)告模板工具，提供圖形化界面，使用戶通過拖拉等簡單的操作，就可以將要顯示的內(nèi)容添加到測試報(bào)告中。在添加完內(nèi)容后，用戶可以點(diǎn)擊要顯示的內(nèi)容，在詳細(xì)信息中設(shè)定要顯示的數(shù)據(jù)的格式。在設(shè)置完以后，用戶可以點(diǎn)擊預(yù)覽按鈕，預(yù)覽要生成的測試報(bào)告，查看測試報(bào)告的格式是否滿足需求。

（五）測試數(shù)據(jù)分析

測試中心平臺(tái)管理軟件根據(jù)管理的需要，將需要統(tǒng)計(jì)測試案例的通過率和測試工作量等數(shù)據(jù)。在執(zhí)行測試案例時(shí)，系統(tǒng)保存所有測試數(shù)據(jù)，以便統(tǒng)計(jì)測試數(shù)據(jù)，生成統(tǒng)計(jì)報(bào)表。可出具的報(bào)表包括測試通過率和按測試人員統(tǒng)計(jì)其進(jìn)行的測試工作量等。其中，系統(tǒng)從測試人員登錄系統(tǒng)后，監(jiān)測和統(tǒng)計(jì)測試人員的各類行為。當(dāng)測試人員進(jìn)入測試案例編輯功能或測試用例編輯功能后，開始統(tǒng)計(jì)該測試人員的工時(shí)。因此，統(tǒng)計(jì)得出測試人員的總工時(shí)，即：總工時(shí)=新建/編輯測試案例的時(shí)間+新建/編輯測試用例的時(shí)間（屬于前述測試案例的測試用例）+新建編輯測試報(bào)告模板的時(shí)間（屬于前述測試案例的測試報(bào)告）。

三、結(jié)語

文章通過對(duì)現(xiàn)有的測試中心設(shè)備和系統(tǒng)功能測試、性能測試和系統(tǒng)兼容性測試的需求的詳細(xì)分析，設(shè)計(jì)了一套全新的測試中心平臺(tái)管理軟件。將原有的需要大量人力的可重復(fù)性測試工作升級(jí)為由系統(tǒng)自動(dòng)執(zhí)行的測試案例，減少了測試人員進(jìn)行測試和記錄的時(shí)間，加快了測試進(jìn)度。同時(shí)，這一研究對(duì)促進(jìn)系統(tǒng)標(biāo)準(zhǔn)化有著積極意義，對(duì)測試工作的減員增效有很好的效果，能夠產(chǎn)生一定的社會(huì)效益。

參考文獻(xiàn)：

[1]劉加森.軟件測試方法研究[J].中國科技投資，2016（32）：279.

[2]袁海根，李紅麗.云計(jì)算下的軟件測試系統(tǒng)探討[J].佳木斯職業(yè)學(xué)院學(xué)報(bào)，2018（04）：439.

[3]趙曉嵐.規(guī)范化軟件測試過程淺析[J].航天控制，2010（01）：96-98.