姜 文，劉立康

(西安電子科技大學(xué) 通信工程學(xué)院，陜西 西安 710071)

0 引 言

隨著計(jì)算機(jī)技術(shù)的發(fā)展，云計(jì)算技術(shù)在各行各業(yè)的應(yīng)用普及，基于云計(jì)算的應(yīng)用軟件的種類也越來越多。軟件產(chǎn)品在使用過程中出現(xiàn)軟件失效，將導(dǎo)致一系列嚴(yán)重的事故與后果。軟件測試階段不僅需要進(jìn)行軟件的功能、性能測試，還需要對軟件進(jìn)行可靠性測試，以確保新開發(fā)的軟件上線后能夠正常運(yùn)行。

在可靠性測試技術(shù)中，故障注入技術(shù)應(yīng)用十分廣泛。與傳統(tǒng)可靠性評測技術(shù)相比，它具有無需建立和求解復(fù)雜的系統(tǒng)模型、實(shí)驗(yàn)時(shí)間短、結(jié)果精度高等優(yōu)點(diǎn)，已引起眾多學(xué)者和研究人員的重視。目前對故障注入技術(shù)應(yīng)用非常成功的領(lǐng)域之一是容錯系統(tǒng)的可靠性驗(yàn)證。

文中介紹了可靠性測試的基本概念；敘述了可靠性測試過程以及各個(gè)角色在測試過程中的職責(zé)和任務(wù)；結(jié)合工作實(shí)踐敘述了一個(gè)云化通訊軟件實(shí)例采用故障注入技術(shù)在云環(huán)境開展可靠性測試工作的全過程；最后給出了測試結(jié)果分析。

1 軟件可靠性基本概念

軟件可靠性是指軟件在所規(guī)定的環(huán)境條件下和規(guī)定的時(shí)間內(nèi)正確地完成任務(wù)的能力。

1.1 軟件可靠性的定義

1983年美國IEEE計(jì)算機(jī)學(xué)會對軟件可靠性[1]給出如下的定義：

(1)在規(guī)定的條件下，在規(guī)定的時(shí)間內(nèi)，軟件不引起系統(tǒng)失效的概率。該概率是系統(tǒng)輸入和系統(tǒng)使用的函數(shù)，也是軟件中存在的缺陷的函數(shù)。

(2)在規(guī)定的時(shí)間周期內(nèi)，在所述條件下程序執(zhí)行所要求的功能的能力。

經(jīng)美國標(biāo)準(zhǔn)化研究所批準(zhǔn)，該定義成為美國的國家標(biāo)準(zhǔn)。1989年中國國標(biāo)GB/T-11457 采用了這個(gè)定義。

1.2 軟件可靠性測試

軟件可靠性測試包括：測試數(shù)據(jù)、測試環(huán)境的準(zhǔn)備、測試運(yùn)行、可靠性數(shù)據(jù)收集、可靠性數(shù)據(jù)分析和失效糾正。目的是為了發(fā)現(xiàn)軟件運(yùn)行中出現(xiàn)的錯誤，實(shí)現(xiàn)軟件可靠性增長；驗(yàn)證軟件的可靠性要求，定量評估軟件的可靠度。

1.2.1 可靠性測試方法

可靠性測試方法主要有兩種類型：

(1)基于操作剖面開展測試。

按照軟件操作剖面[2]對軟件進(jìn)行隨機(jī)測試的測試方法。根據(jù)軟件在客戶實(shí)際使用過程的各種操作的使用概率選擇操作剖面，對軟件系統(tǒng)進(jìn)行可靠性測試。

(2)基于故障注入開展測試。

故障注入是按照選定的故障模型，采用人工的方法將故障注入到特定的目標(biāo)系統(tǒng)中，同時(shí)采集系統(tǒng)對所注入故障的反應(yīng)信息，通過這些信息對系統(tǒng)進(jìn)行可靠性分析。

1.2.2 軟件故障注入技術(shù)

與其他可靠性評價(jià)技術(shù)相比，故障注入方法能方便靈活、便捷有效地處理各種可靠性問題，得到了越來越多的關(guān)注。故障注入技術(shù)[3-6]有模擬實(shí)現(xiàn)的故障注入、硬件實(shí)現(xiàn)的故障注入和軟件實(shí)現(xiàn)的故障注入三種。

軟件故障注入是通過修改硬件或軟件的狀態(tài)變量或相關(guān)數(shù)據(jù)來模擬故障的產(chǎn)生，加速系統(tǒng)的失效，分為靜態(tài)注入和動態(tài)注入兩種類型[7-11]。

靜態(tài)故障注入主要通過程序變異的方法，通過改變原程序，使被測系統(tǒng)文件靜態(tài)的存在錯誤，從而使其運(yùn)行時(shí)出現(xiàn)故障。靜態(tài)注入占用很少的系統(tǒng)資源，能夠較好地保持系統(tǒng)原來的時(shí)序，這種注入法有很好的優(yōu)化性。

動態(tài)注入是在被測系統(tǒng)正常運(yùn)行過程中，實(shí)現(xiàn)故障注入。該種方式是根據(jù)被測系統(tǒng)的運(yùn)行狀態(tài)或條件注入故障的，具有靈活性。

2 可靠性測試

2.1 可靠性測試過程

軟件產(chǎn)品在需求分析階段時(shí)，就需要啟動針對軟件的可靠性分析?？煽啃詼y試過程[12]主要包括：仔細(xì)研讀軟件需求說明書、分析測試需求、提交測試策略、設(shè)計(jì)測試用例、搭建測試環(huán)境、執(zhí)行可靠性測試、分析測試結(jié)果，如圖1所示。

圖1 可靠性測試過程

(1)制定測試計(jì)劃：明確可靠性測試的對象、目的、內(nèi)容、方法、進(jìn)度要求。

(2)分析可靠性測試需求：根據(jù)需求說明書，確定可靠性測試方案，編寫測試策略。

(3)設(shè)計(jì)測試用例：設(shè)計(jì)測試用例設(shè)計(jì)，編寫自動化測試用例腳本。

(4)搭建測試環(huán)境：搭建測試所需的各種軟硬件環(huán)境，如數(shù)據(jù)、網(wǎng)絡(luò)、測試工具的安裝和設(shè)置等。

(5)執(zhí)行可靠性測試：采用手動或者自動化模式執(zhí)行可靠性測試，記錄測試數(shù)據(jù)。

(6)分析測試結(jié)果：根據(jù)可靠性測試數(shù)據(jù)，分析測試結(jié)果，提交測試報(bào)告。

2.2 可靠性測試過程中的角色

軟件可靠性測試涉及到以下角色：系統(tǒng)工程師、測試架構(gòu)師、軟件開發(fā)工程師、軟件測試工程師和質(zhì)量工程師。各角色各司其職，分工協(xié)作共同完成軟件可靠性測試。

各角色的職責(zé)和任務(wù)：

(1)系統(tǒng)工程師(SE)：跟客戶確認(rèn)對軟件產(chǎn)品的需求，編寫軟件特性設(shè)計(jì)規(guī)格文檔，并在特性設(shè)計(jì)規(guī)格文檔中給出針對軟件可靠性的相關(guān)技術(shù)方案和要求。

(2)測試架構(gòu)師(TSE)：根據(jù)軟件特性設(shè)計(jì)規(guī)格文檔，編寫可靠性測試策略與測試用例。

(3)軟件開發(fā)工程師：根據(jù)軟件特性設(shè)計(jì)規(guī)格文檔進(jìn)行編碼、處理軟件可靠性的各類故障問題。

(4)軟件測試工程師：搭建可靠性測試環(huán)境，編寫自動化測試用例腳本，執(zhí)行軟件可靠性測試。

(5)質(zhì)量工程師(RQA)：負(fù)責(zé)對軟件開發(fā)與軟件測試過程中各項(xiàng)流程的監(jiān)管與審核。

3 基于云網(wǎng)絡(luò)環(huán)境的軟件實(shí)例

該實(shí)例是一個(gè)云化通訊軟件產(chǎn)品開發(fā)項(xiàng)目，總的代碼量大約三百萬行?；谠骗h(huán)境進(jìn)行可靠性測試，在云網(wǎng)絡(luò)環(huán)境中注入故障，測試軟件產(chǎn)品對于環(huán)境的容錯能力。

3.1 云環(huán)境的層級結(jié)構(gòu)

軟件產(chǎn)品實(shí)例的云環(huán)境的層級結(jié)構(gòu)[13-15]如表1所示。

表1 軟件產(chǎn)品運(yùn)行的云環(huán)境層級結(jié)構(gòu)

3.2 云網(wǎng)絡(luò)環(huán)境的部署和軟件產(chǎn)品的安裝

3.2.1 配置硬件設(shè)備

S3900磁陣(存儲設(shè)備)與11塊E9000單板上架與連線；E9000單板與交換機(jī)系統(tǒng)連接，交換機(jī)系統(tǒng)可以連接局域網(wǎng)和廣域網(wǎng)；通過網(wǎng)絡(luò)登錄E9000單板的設(shè)備管理頁面，將所有的E9000單板下電之后的狀態(tài)設(shè)置為PXE(preboot execute environment，預(yù)啟動執(zhí)行環(huán)境)啟動狀態(tài)。

3.2.2 部署單位私有云

安裝FusionSphere軟件(華為云操作系統(tǒng)，F(xiàn)usionSphere云操作系統(tǒng)從5.0之后的版本全部基于OpenStack)，其中一塊E9000單板作為虛擬機(jī)軟件的控制節(jié)點(diǎn)，將剩余的E9000單板通過PXE的方式加載到FusionSphere的硬件管理頁面上；通過FusionSphere軟件配置網(wǎng)絡(luò)平面、對接存儲設(shè)備、劃分管理節(jié)點(diǎn)與服務(wù)節(jié)點(diǎn)等。

3.2.3 創(chuàng)建虛擬機(jī)

在管理節(jié)點(diǎn)下創(chuàng)建FusionSphere Openstack虛擬機(jī)；創(chuàng)建管理節(jié)點(diǎn)與服務(wù)節(jié)點(diǎn)；創(chuàng)建管理節(jié)點(diǎn)與服務(wù)節(jié)點(diǎn)的用戶。

(1)登入管理節(jié)點(diǎn)用戶，創(chuàng)建管理節(jié)點(diǎn)所需要的網(wǎng)絡(luò)。

(2)登入計(jì)算節(jié)點(diǎn)用戶，創(chuàng)建計(jì)算節(jié)點(diǎn)所需要的網(wǎng)絡(luò)。

古代封建專制政權(quán)家天下，皇家也是基因論的忠實(shí)擁躉?；实厶柗Q真龍?zhí)熳?，代替上天行事?；首影⒏缰髯匀豁樌沓烧碌亍吧朴巍?。甭管他們是否天天只知拈弓彈雀、提籠架鳥、不務(wù)正業(yè)，只要生在皇家，便是龍子龍種，將來是一定要子承父業(yè)做皇帝的。打著君權(quán)神授的幌子，蒙蔽百姓，妄想家天下，歷朝歷代的皇帝概莫能外。秦始皇是第一個(gè)從皇帝名號上動此腦筋的，所以他自稱“始皇帝”，妄想子子孫孫二世三世乃至萬世地傳承下去，可惜只傳到二世，秦王朝就壽終正寢了。

(3)在管理節(jié)點(diǎn)用戶下創(chuàng)建搭建CGP所需要的第三方用戶。

創(chuàng)建16個(gè)虛擬機(jī)，虛擬機(jī)的規(guī)格數(shù)據(jù)包括操作系統(tǒng)、CPU、內(nèi)存、系統(tǒng)盤、數(shù)據(jù)盤以及網(wǎng)絡(luò)配置等。在虛擬機(jī)上配置網(wǎng)卡，在網(wǎng)卡上配置私有云IP地址。這些虛擬機(jī)組成VLAN局域網(wǎng)。

3.2.4 安裝CGP網(wǎng)絡(luò)管理平臺(安裝OMU虛擬機(jī))

上傳CGP(carrier grade platform)的版本包以及鏡像包，虛擬機(jī)上添加網(wǎng)卡與浮動IP地址之后，分別安裝主、備OMU虛擬機(jī)。OMU安裝完成后，組成基于Client/Server結(jié)構(gòu)的網(wǎng)絡(luò)系統(tǒng)。OMU的客戶端工具為LMT(local maintenance terminal)。

LMT工具通過MML(man-machine language)命令，對網(wǎng)元進(jìn)行操作和維護(hù)。通過網(wǎng)絡(luò)系統(tǒng)的管理用戶(用戶名admin)負(fù)責(zé)網(wǎng)絡(luò)系統(tǒng)管理。

3.2.5 部署安裝軟件產(chǎn)品

通過LMT客戶端工具安裝軟件產(chǎn)品，上傳產(chǎn)品軟件的版本包以及鏡像包之后，安裝軟件產(chǎn)品，給產(chǎn)品業(yè)務(wù)虛擬機(jī)配置網(wǎng)絡(luò)環(huán)境。軟件產(chǎn)品安裝完成后，涉及到故障注入的虛擬機(jī)如表2所示。

表2 虛擬機(jī)功能描述

4 搭建測試環(huán)境

4.1 故障注入方法

在本軟件實(shí)例中，通過五種方法注入故障。

CFE(common fault-injection entry)工具是公司自研的Linux操作系統(tǒng)下的故障注入工具，可以針對軟件產(chǎn)品進(jìn)行CPU消耗故障、內(nèi)存消耗故障以及多種網(wǎng)絡(luò)故障的注入。

4.1.2 TC工具注入

TC(traffic control)流量控制器[16]，是Linux系統(tǒng)下的開源軟件，可以為各類數(shù)據(jù)提供不同的帶寬，從而控制它們的傳輸速度。在測試云化軟件的可靠性時(shí)，可以使用TC工具注入網(wǎng)絡(luò)丟包、錯包以及時(shí)延等故障。

4.1.3 通過MML命令注入

通過LMT客戶端登錄OMU，通過執(zhí)行MML命令實(shí)現(xiàn)軟件模塊重啟、虛擬機(jī)復(fù)位，模塊主備倒換故障注入。

4.1.4 通過ifconfig命令注入

ifconfig命令是Linux操作系統(tǒng)的環(huán)境配置命令，通過執(zhí)行ifconfig命令，改變虛擬機(jī)網(wǎng)絡(luò)配置，用于注入虛擬機(jī)網(wǎng)絡(luò)平面端口故障。

4.1.5 通過openstack nova命令注入

在云環(huán)境中通過openstack虛擬化軟件管理所有的虛擬機(jī)，執(zhí)行可靠性測試時(shí)，可以通過openstack nova命令注入故障，故障類型為虛擬機(jī)重啟與虛擬機(jī)遷移。

4.2 性能測試工具NTE

NTE(network traffic emulator)工具是公司自研的性能測試工具，可以對通訊軟件產(chǎn)品在實(shí)際使用環(huán)境中的客戶呼叫進(jìn)行計(jì)算機(jī)仿真。在進(jìn)行軟件產(chǎn)品的可靠性測試時(shí)，需要在用戶呼叫仿真的背景下，注入各種故障，來獲取測試數(shù)據(jù)。根據(jù)測試數(shù)據(jù)分析軟件產(chǎn)品的可靠性。

4.3 搭建測試環(huán)境

(1)部署軟件實(shí)例的私有云網(wǎng)絡(luò)環(huán)境；

(2)通過LMT客戶端登上OMU后，執(zhí)行MML命令部署軟件實(shí)例的業(yè)務(wù)虛擬機(jī)與進(jìn)程；

(3)通過LMT客戶端登上OMU后，使用LMT上的“文件傳輸服務(wù)”將CFE工具和TC工具上傳到OMU虛擬機(jī)之后，再通過scp命令將這兩個(gè)工具安裝到執(zhí)行故障注入的虛擬機(jī)上；

(4)將性能測試工具NTE與自動化腳本工具GTR安裝到指定執(zhí)行機(jī)上。

5 基于云環(huán)境的可靠性測試

結(jié)合軟件實(shí)例，介紹基于云環(huán)境的可靠性測試工作。

5.1 測試用例設(shè)計(jì)

測試架構(gòu)師分析軟件的產(chǎn)品的功能與性能測試特性之后，選定可靠性測試模型和注入故障類型，對虛擬機(jī)或者軟件模塊注入故障，開展可靠性測試，共設(shè)計(jì)40個(gè)可靠性測試用例，如表3所示。

表3 可靠性測試用例分類

5.2 可靠性測試流程

云化通訊軟件實(shí)例的可靠性測試流程如圖2所示。在測試環(huán)境中在啟動業(yè)務(wù)軟件和性能測試工具后，通過注入故障，開展測試工作。

圖2 基于故障注入的云化軟件可靠性測試流程

圖2中專業(yè)術(shù)語注解：

CAPS(call attempt per second，每秒呼叫次數(shù))：這里所指的呼叫次數(shù)包括成功呼叫(即呼叫接續(xù)成功，雙方進(jìn)行通話)次數(shù)和不成功呼叫(呼損)次數(shù)。

T1(業(yè)務(wù)故障時(shí)間)：故障注入時(shí)間到故障發(fā)生時(shí)間之間的時(shí)差，目前采用的故障注入時(shí)間到故障告警出現(xiàn)時(shí)間的差值。

T2(業(yè)務(wù)中斷時(shí)間)：不成功呼叫(呼損)占用的時(shí)間；每隔固定的時(shí)間間隔查詢讀取呼叫器上業(yè)務(wù)呼損數(shù)sn；t=sn/CAPS，計(jì)算t的數(shù)值并且寫入fail_caps數(shù)組中；最后選擇數(shù)組中的最大值作為T2。

T3(業(yè)務(wù)自動恢復(fù)時(shí)長)：開始出現(xiàn)呼損的時(shí)間到不再出現(xiàn)呼損的時(shí)間之間的時(shí)差；在呼叫器上查詢呼損數(shù)，一直到呼叫器上不再出現(xiàn)新的呼損(也就是呼損數(shù)sn不再增加)，然后取兩個(gè)時(shí)間差值作為業(yè)務(wù)自動恢復(fù)時(shí)長。

5.3 自動化測試

該軟件實(shí)例的可靠性測試采用自動化測試，腳本語言選擇TCL，通過調(diào)用spider庫中NTE的自動化的函數(shù)編寫腳本和測試套，通過GTR工具編輯、調(diào)試、運(yùn)行TCL腳本和測試套。

5.3.1 編寫測試套

測試用例評審之后，測試工程師需要根據(jù)測試用例特點(diǎn)編寫測試套完成測試環(huán)境的初始化，提供通用的測試模型參數(shù)，測試結(jié)束之后測試套進(jìn)行測試環(huán)境清理。目前使用的呼叫模型參數(shù)有2種：

(1)透傳模型：G711-G711，每秒20個(gè)呼叫(caps=20)，呼叫在線時(shí)長10 000 ms;

(2)轉(zhuǎn)碼模型：G711-G729，每秒5個(gè)呼叫(caps=5)，呼叫在線時(shí)長10 000 ms。

測試套的放置在指定路徑下，供TCL自動化腳本調(diào)用。

5.3.2 編寫自動化測試腳本

根據(jù)圖2編寫TCL腳本，主要對以下測試場景編寫TCL腳本。

(1)調(diào)用測試套進(jìn)行測試環(huán)境初始化，設(shè)置相關(guān)測試模型參數(shù)，啟動性能呼叫；

(2)在MEID=0的CGP網(wǎng)元下，執(zhí)行DSP TIME命令，并將查詢到的時(shí)間存入變量time1，根據(jù)測試用例中的故障類型開始執(zhí)行故障注入；

(3)在MEID=0的CGP網(wǎng)元下，執(zhí)行LST ALM命令查詢到告警產(chǎn)生的時(shí)間存入變量time2；

(4)將變量time2與time1的差值存入變量T1中，作為業(yè)務(wù)故障時(shí)間；

(5)執(zhí)行故障注入之后，每隔固定的時(shí)間間隔，查詢NTE上呼叫器的呼損數(shù)，呼損數(shù)除以caps，將結(jié)果寫入數(shù)組fail_caps中。最后從數(shù)組fail_caps中取出最大的數(shù)值，存入變量T2中，作為業(yè)務(wù)中斷時(shí)間；

(6)不斷查詢TTE工具上呼叫器的呼損數(shù)，一直到呼叫器上不再出現(xiàn)新的呼損(也就是呼損數(shù)不再增加)，將開始出現(xiàn)呼損到呼叫器上不再出現(xiàn)呼損之間的時(shí)長存入變量T3中，作為業(yè)務(wù)自動恢復(fù)時(shí)長；

(7)測試結(jié)束之后，統(tǒng)計(jì)到的數(shù)據(jù)T1、T2、T3以添加的方式寫入指定路徑下的csv文件中；

(8)清理測試環(huán)境，終止測試工作。

5.3.3 可靠性自動化腳本連跑

測試工程師完成自動化腳本編寫之后，腳本經(jīng)過測試架構(gòu)師審查通過后，所有的腳本提交到配置庫Git中，并將腳本同步提交到軟件產(chǎn)品的自動化工廠。每一輪迭代開發(fā)結(jié)束之后，通過全部腳本自動化連跑，對軟件產(chǎn)品進(jìn)行可靠性測試，這樣提高了測試效率。

5.4 測試結(jié)果分析

由測試工程師根據(jù)軟件產(chǎn)品的可靠性規(guī)格基線與可靠性自動化測試的結(jié)果進(jìn)行分析。表4給出了軟件實(shí)例在云環(huán)境中，進(jìn)程復(fù)位、倒換以及虛擬機(jī)復(fù)位這些場景對于T2(業(yè)務(wù)中斷時(shí)間)的測試分析結(jié)果。

從測試的結(jié)果可知，復(fù)位與倒換故障注入時(shí)，待測進(jìn)程與虛擬機(jī)上的業(yè)務(wù)中斷時(shí)間在允許范圍內(nèi)，產(chǎn)品的可靠性較好。

其他測試數(shù)據(jù)由于篇幅所限，文中不再介紹。在可靠性測試過程中，沒有達(dá)成軟件可靠性基線指標(biāo)的用例，測試工程師將測試的情況反饋給軟件開發(fā)工程師，并和開發(fā)工程師一起定位解決。

表4 T2(業(yè)務(wù)中斷時(shí)間)的可靠性測試分析結(jié)果

5.5 測試過程中遇到的典型問題

云化軟件在可靠性測試過程中，遇到的一些典型問題，舉例如下。

(1)測試過程中無法正常切換root用戶導(dǎo)致腳本執(zhí)行失敗。

測試虛擬機(jī)遷移的場景時(shí)，需要切換為root用戶，調(diào)用nova命令執(zhí)行虛擬機(jī)遷移。測試過程中發(fā)現(xiàn)登錄FusionSphere虛擬機(jī)化軟件后臺之后，腳本執(zhí)行失敗。經(jīng)過定位發(fā)現(xiàn)，完成FusionSphere軟件安裝之后，需要修改/ettc/ssh/sshd_config文件，去掉對root用戶加密限制；tcl自動化測試腳本才能正常切換到root用戶，執(zhí)行虛擬機(jī)遷移的nova命令。

(2)測試過程中未在腳本中加入環(huán)境恢復(fù)步驟。

測試虛擬機(jī)網(wǎng)絡(luò)平面故障的場景時(shí)，執(zhí)行ifconfig ethX down命令down掉虛擬機(jī)上的指定網(wǎng)口來實(shí)現(xiàn)故障注入；測試工作完成之后沒有對down掉的網(wǎng)口進(jìn)行恢復(fù)，直接進(jìn)行下一個(gè)相關(guān)用例測試，導(dǎo)致測試腳本執(zhí)行失敗。定位腳本運(yùn)行失敗的原因時(shí)，發(fā)現(xiàn)了這個(gè)問題，在測試腳本中增加了恢復(fù)環(huán)境的場景，以后再沒有出現(xiàn)這種情況。

在云環(huán)境中開展可靠性測試工作，有許多問題需要進(jìn)一步進(jìn)行深入探討和研究。

6 結(jié)束語

隨著云計(jì)算技術(shù)的高速發(fā)展，基于云化環(huán)境的軟件在各個(gè)領(lǐng)域的應(yīng)用不斷普及和拓展。許多傳統(tǒng)環(huán)境下的軟件產(chǎn)品需要推出云化的軟件版本，不僅需要關(guān)注軟件的各種功能測試與性能測試，可靠性測試的重要性也逐步提升?；谠骗h(huán)境的可靠性測試是軟件測試過程中的重要環(huán)節(jié)，尤其對于大型云化軟件顯得尤為重要。工作實(shí)踐表明，做好基于云環(huán)境的軟件可靠性測試工作，在軟件開發(fā)過程中不斷解決存在的各種問題，有助于提高軟件產(chǎn)品的質(zhì)量，提高上線后軟件的安全性與穩(wěn)定性，以更好地滿足客戶對軟件產(chǎn)品的需求。