邱吉雨 宋欣悅

（北京交通大學(xué)計算機(jī)與信息技術(shù)學(xué)院 北京市 100044）

據(jù)統(tǒng)計，在軟件開發(fā)的多個階段中，同比代碼、系統(tǒng)設(shè)計等階段，需求分析階段的產(chǎn)物——需求規(guī)格說明書是軟件缺陷出現(xiàn)最多的地方。由經(jīng)驗可知，需求分析階段的錯誤會隨著產(chǎn)品開發(fā)進(jìn)度而被無限放大，且開發(fā)越接近于尾聲，改正錯誤所需要的代價越大。為了保障軟件質(zhì)量，降低缺陷發(fā)生時的修復(fù)成本，本文中系統(tǒng)的測試采用W 模型（如圖1）。同理，為了項目的風(fēng)險控制，大多數(shù)的Web 應(yīng)用的測試都是伴隨著需求規(guī)格說明書的完成而展開的。

1 客運需求預(yù)測系統(tǒng)

客運需求預(yù)測系統(tǒng)由我們自行開發(fā)，能夠?qū)⑹昕瓦\歷史數(shù)據(jù)以圖表的方式展現(xiàn)并且對未來幾年客運趨勢進(jìn)行預(yù)測的系統(tǒng)。該系統(tǒng)包括客運需求分析子系統(tǒng)、客運需求預(yù)測子系統(tǒng)、基礎(chǔ)數(shù)據(jù)管理子系統(tǒng)和預(yù)測模型管理子系統(tǒng)等四個子系統(tǒng)，各子系統(tǒng)又細(xì)分了不同的條目，系統(tǒng)具體結(jié)構(gòu)見圖2?？瓦\需求預(yù)測系統(tǒng)是一個典型的Web 應(yīng)用系統(tǒng)，具有內(nèi)容驅(qū)動性、及時性、安全性和美觀性等特性。

2 測試計劃及測試方案

在本項目的需求分析以及設(shè)計階段，測試人員對階段產(chǎn)物——需求規(guī)格說明書進(jìn)行評審，即測試人員拿到需求規(guī)格說明書之后，首先通讀并分析規(guī)格說明書，將模棱兩可以及晦澀難懂的部分記錄下來。直到參加需求評審會議的時候，與與會人員討論并明確存在異議的需求，并根據(jù)自己以往的測試經(jīng)驗和對系統(tǒng)的理解，從用戶的角度提出意見。評審會議后，完善的需求規(guī)格說明書發(fā)布時，測試人員便著手設(shè)計相關(guān)的測試計劃以及初步的測試方案。

測試計劃是基于管理者角度所寫，對測試全過程進(jìn)行管理的計劃書，其內(nèi)容包括測試項、被測特性、各階段的測試任務(wù)、時間進(jìn)度、安排測試任務(wù)的執(zhí)行者和風(fēng)險控制。測試方案是以測試計劃為指導(dǎo)，在軟件生命周期中的概要設(shè)計后，根據(jù)其階段性產(chǎn)物——概要設(shè)計說明書及之前的需求規(guī)格說明書撰寫而成的。測試方案的制定條目包括明確測試策略、細(xì)分測試子項、根據(jù)測試計劃編寫測試用例和選擇測試工具[1]。測試方案撰寫完成后，所有參與本次測試的測試人員組織開會，進(jìn)行測試方案的評審。本文采用單元測試——集成測試——系統(tǒng)測試——驗收測試的步驟對本系統(tǒng)進(jìn)行分步測試。當(dāng)測試方案過審后、開發(fā)人員完成代碼自檢時，由測試組進(jìn)行單元測試。

3 單元測試

圖1：W 模型圖

圖2：客運需求預(yù)測系統(tǒng)功能圖

圖3：全國客運量分析界面中的單元測試元素圖

單元測試，顧名思義，是指對系統(tǒng)中最小單位進(jìn)行驗證以及問題排查。后來，單元模塊也特指程序中的最小模塊——類。本系統(tǒng)共有12 個html 頁面、6 個數(shù)據(jù)存取類、8 個業(yè)務(wù)邏輯Servlet 以及1 個數(shù)據(jù)庫關(guān)聯(lián)類。為了能夠更有效地發(fā)現(xiàn)缺陷，我們將單元測試分為靜態(tài)單元測試和動態(tài)單元測試。靜態(tài)測試，即在不運行代碼的情況下對程序進(jìn)行檢測。與之相反，動態(tài)測試就是通過運行代碼來對程序進(jìn)行檢測。由于編碼結(jié)束后才開始單元測試會增加軟件缺陷的風(fēng)險，且缺陷發(fā)現(xiàn)的越晚，對于項目的人力物力損失越大，因而在開發(fā)人員完成單元模塊的代碼自檢后，測試人員便開始對該模塊的所有子功能進(jìn)行測試。測試人員檢測時，首先使用SourceMonitor檢測代碼復(fù)雜度，當(dāng)代碼復(fù)雜度大于50，或者且代碼深度超過6 時，將該結(jié)果記錄下來并且報告給開發(fā)人員。在完成代碼復(fù)雜度檢測之后，便開始準(zhǔn)備對代碼實現(xiàn)的功能進(jìn)行檢測。此時便要為上述的測試方案逐步增添測試用例。每當(dāng)開發(fā)組完成一個系統(tǒng)子模塊時，我們就要為該子模塊設(shè)計相關(guān)的測試案例。根據(jù)本系統(tǒng)的系統(tǒng)特點，將單元測試詳細(xì)劃分為對以下幾部分的測試：

表1：全國客運量分析界面元素單元測試表

表2：CityServletData 函數(shù)功能測試用例表

表3：集成測試用例表

（1）業(yè)務(wù)邏輯模塊函數(shù)功能能否實現(xiàn)；

（2）數(shù)據(jù)存取單元能否實現(xiàn)數(shù)據(jù)存取；

（3）Html 頁面上所有的模塊能否正確顯示。

下面以客運需求預(yù)測系統(tǒng)的全國客運量分析界面為例，詳細(xì)分析該系統(tǒng)中單元測試的用例。圖2 為該html 頁面中可測試的功能點，表1 是對圖3 所要檢測的單元功能點的表述。

對該html 頁面進(jìn)行測試之后，測試與之相關(guān)的業(yè)務(wù)邏輯及數(shù)據(jù)存取類中的模塊函數(shù)是否能夠正確完成其功能。仍然以全國客運量分析子模塊為例，展示其相關(guān)的單元代碼模塊測試條目（模塊代碼測試用例表以CityServletData 中的CityServletData 函數(shù)為例，見表2）：

（1） 測 試NewPassengerDF.src.dao.DBConnector.java 是 否能夠與數(shù)據(jù)庫連接成功（此處“.”代表目錄分隔，即“dao.DBConnector.java”代表dao 目錄下的DBConnector.java 文件）；

（2）測試User 類中的方法能否實現(xiàn)其預(yù)期的功能（包括isUser 方法、getUsrName 方法、addUser 方法、setUsername 方法、setName 方法、getUsername 方法、setName 方法、getName 方法、setPassword 方法、getPassword 方法以及User 方法）；

（3）測試CityServletData 的所有方法能否實現(xiàn)預(yù)期功能（包括CityServletData 方法、show 方法以及toString 方法）；

（4）測試ForecastData 類中的所有方法是否能夠?qū)崿F(xiàn)預(yù)期功能（包括ForecastData 方法以及toString 方法）。

4 集成測試

在系統(tǒng)的子模塊分支進(jìn)行單元測試之后，便進(jìn)行集成測試的設(shè)計。集成測試，即將通過單元測試的模塊根據(jù)系統(tǒng)要求組裝集成，來檢查這些單元模塊之間的接口是否存在問題[2]，包括接口參數(shù)一致性的引用，集成后的模塊是否滿足需求規(guī)格說明書中該子模塊的預(yù)期功能。在集成測試的模式方面，為了及早發(fā)現(xiàn)模塊中的錯誤、明確錯誤的具體出錯點，本系統(tǒng)采用漸增式集成模式及自底向上的集成方式對通過測試的單元模塊進(jìn)行集成。首先，將底層模塊組合成實現(xiàn)某些特定功能的族；其次為該族編寫一個用以測試的驅(qū)動模塊并對該族進(jìn)行測試；然后組合其他單元模塊，當(dāng)單元模塊全部組裝完成測試后，沿著軟件結(jié)構(gòu)上移，并對新的子模塊進(jìn)行集成；最后反復(fù)執(zhí)行該過程直到模塊集成到系統(tǒng)最頂層。下面以客運需求預(yù)測系統(tǒng)中的需求側(cè)影響因素下的GDP 變化模塊集成為例展開論述本系統(tǒng)的集成測試，即：

（1）測試該頁面中的下拉框選項與折線圖是否發(fā)生聯(lián)動；

（2）該折線圖中的數(shù)據(jù)是否與數(shù)據(jù)庫中相關(guān)年份的正確數(shù)據(jù)對應(yīng)。

本次集成的模塊包括：DBConnector.java、數(shù)據(jù)庫中的china_base_data 表、GDPServlet.java 以及相對應(yīng)的html 頁面。測試用例見表3。

5 系統(tǒng)測試

系統(tǒng)測試開始前，各模塊間的接口問題已被消除，原本被分解的模塊被繼承，形成相對完整的體系。系統(tǒng)測試是將經(jīng)過集成測試后的模塊，作為計算機(jī)系統(tǒng)的一個部分，與計算機(jī)硬件、某些支持軟件、數(shù)據(jù)和平臺等系統(tǒng)元素結(jié)合起來，在真實運行環(huán)境下對計算機(jī)系統(tǒng)進(jìn)行一系列嚴(yán)格有效的測試來發(fā)現(xiàn)軟件的潛在問題，以保障系統(tǒng)的正常運行。測試條目包括功能測試、回歸測試、性能測試、安全測試、容錯性測試、兼容性測試以及可靠性測試[3]。根據(jù)甲方要求以及系統(tǒng)特性，本系統(tǒng)的系統(tǒng)測試分別從功能測試、回歸測試、性能測試以及兼容性測試幾個方面展開。

5.1 功能測試

系統(tǒng)測試中的功能測試不僅要衡量單元模塊功能是否實現(xiàn)以及模塊接口是否能夠正常運作，還要考慮系統(tǒng)的應(yīng)用環(huán)境。它的衡量標(biāo)準(zhǔn)是產(chǎn)品規(guī)格說明書上所要求的所有功能是否都已實現(xiàn)，需要實現(xiàn)的功能包括程序的正常安裝啟動、每項功能符合實際的產(chǎn)品要求、html 元素的正常、功能邏輯清楚、系統(tǒng)符合用戶的使用邏輯、能支持多種應(yīng)用環(huán)境等。

本系統(tǒng)的功能測試使用Selenium 編寫自動化測試腳本對系統(tǒng)中所有的已有功能仿照用戶操作進(jìn)行驗收。Selenium 的核心部分是由純JavaScript 編寫，因而能夠直接運行在瀏覽器上面，方便了Web 系統(tǒng)的測試[4]。其次，在下載Selenium 時，由于seleniumIDE是Firefox 的一個插件，依附于Firefox，所以需要先安裝Firefox 瀏覽器，而后在火狐瀏覽器的組件中找到Selenium 進(jìn)行下載。

5.2 回歸測試

當(dāng)系統(tǒng)出現(xiàn)缺陷時，測試組將缺陷報備給開發(fā)組，在開發(fā)組改正缺陷后，在其它受影響的區(qū)域很有可能出現(xiàn)新的缺陷。倘若此版本就此發(fā)布，會給用戶帶來嚴(yán)重不便?；貧w測試是在系統(tǒng)完成修改原有BUG 或者增加新的功能后，為了保證程序中其他模塊沒有受到影響而破壞原有的功能，即為了發(fā)現(xiàn)回歸缺陷所做的測試。

對于系統(tǒng)的回歸測試，測試人員在綜合考慮時間和成本等因素后，構(gòu)造了一個精簡后的用例組來進(jìn)行測試。回歸測試的測試集需要驗證的內(nèi)容是：

（1）對系統(tǒng)的修改是否破壞了現(xiàn)有的功能；

（2）驗證修改工作本身是否存在缺陷，其過程如下[5]：首先識別出系統(tǒng)中被修改的地方；其次從原有的測試集中刪除不適用的測試用例，保留對修改后的系統(tǒng)有效的測試用例，形成新的測試集[6]。若回歸測試集的測試用例覆蓋率沒有達(dá)到規(guī)定的量級，測試人員需要為之增添新的測試用例，形成新的測試用例集[7]。

由于回歸測試的工作具有重復(fù)性，一般會編寫對應(yīng)的測試腳本，將重復(fù)的工作交給自動化測試，以達(dá)到節(jié)省人力物力的目的。本項目使用由IBM 開發(fā)的Rational Functional Tester 工具以及python 語言編寫腳本進(jìn)行自動化測試。

5.3 性能測試

性能測試是在用戶的操作環(huán)境以及特定的負(fù)載中為了發(fā)現(xiàn)系統(tǒng)的性能問題或為了獲取系統(tǒng)的相關(guān)性能指標(biāo)而進(jìn)行的測試[8]。系統(tǒng)的性能指標(biāo)包括系統(tǒng)資源的使用率以及系統(tǒng)的行為表現(xiàn)[9]。根據(jù)需求規(guī)格說明書，為本系統(tǒng)制定的測試方案中性能測試包括了系統(tǒng)負(fù)載測試、壓力測試、容量測試[10]。本系統(tǒng)使用測性能測試工具是Jmeter，測試過程如下：

（1）測試人員模擬100 個用戶并發(fā)訪問系統(tǒng)，設(shè)定每個用戶的啟動時間為2 秒，循環(huán)50 次。模擬過程中，共存在5000 次請求。由于本地請求和遠(yuǎn)程服務(wù)器端請求所耗費的時間不同，因而將兩個服務(wù)器端分離開來測試。

（2）將測試結(jié)果進(jìn)行對比。從結(jié)果上來看：

1.本地段請求5000 次請求在200s 內(nèi)全部成功，平均訪問時間為87s，最大訪問時間為1086s，因而在本地端系統(tǒng)的并發(fā)能力很好。

2.在遠(yuǎn)程服務(wù)器端進(jìn)行測試時，5000 次請求在200s 內(nèi)只有4321 個請求發(fā)送成功，且最長的反應(yīng)時間為21855ms，較本地請求測試差了許多，但是請求成功率大于80%，因而系統(tǒng)在遠(yuǎn)程端請求的并發(fā)能力較好。

本系統(tǒng)分別采用匯總報告、圖形結(jié)果、結(jié)果樹的方式來觀察其性能變化（相關(guān)的結(jié)果見圖4 至圖6）。各反饋方式代表的含義見下：

3.通過匯總報告可查看到label、samples、Average、Median、Min、Max、Error%以及Throughput 等量化指標(biāo)。Label 是請求類型，如HTTP，F(xiàn)TP 等請求；#Samples 是圖形報表中的樣本數(shù)目，即發(fā)送到服務(wù)器的總樣本數(shù)；Average 是圖形報表中的平均值，計算法則是總運行時間除以發(fā)送到服務(wù)器的請求數(shù)[11]；Median 是圖形報表中的中間值，是代表時間的數(shù)字，在請求測試中有一半樣本的服務(wù)器響應(yīng)時間低于該值而另一半高于該值[12]；Min 是時間數(shù)字，代表服務(wù)器響應(yīng)的最短時間；Max 同樣也是時間數(shù)字，代表服務(wù)器響應(yīng)的最長時間；Error%代表請求的錯誤百分比；Throughput 是圖形報表中的吞吐量，代表服務(wù)器每單位時間處理的請求數(shù)，單位為秒或分鐘；KB/sec 是每秒鐘請求的字節(jié)數(shù)。

圖4：Jmeter 測試結(jié)果樹圖

圖5：Jmeter 測試結(jié)果圖

圖6：Jmeter 測試匯總報告圖

表4：市面上常見的屏幕尺寸及其分辨率表

4.通過結(jié)果樹可觀察HTTP 請求是否發(fā)送成功，綠色為發(fā)送成功，紅色為失敗。單擊每一條HTTP 請求后可了解該條請求的相關(guān)參數(shù)。

5.通過圖形結(jié)果可以觀察樣本數(shù)、最新樣本、吞吐量、中間值以及偏離。樣本數(shù)目是發(fā)送到服務(wù)器的請求總數(shù)[13]；最新樣本是時間數(shù)字，代表服務(wù)器響應(yīng)最后一個請求的時間；吞吐量代表服務(wù)器每分鐘處理的請求數(shù)；平均值即總運行時間除以發(fā)送到服務(wù)器的請求數(shù)；中間值是時間數(shù)字，測試樣本中，有一半的服務(wù)器響應(yīng)時間低于該值而另一半高于該值；偏離表示服務(wù)器響應(yīng)時間變化、離散程度測量值的大小即數(shù)據(jù)分布。

5.4 數(shù)據(jù)庫測試

由于本系統(tǒng)不存在并發(fā)數(shù)據(jù)操作數(shù)據(jù)庫，所以不會存在丟失數(shù)據(jù)、不可重復(fù)讀數(shù)據(jù)以及讀臟數(shù)據(jù)等問題，因而測試方案中沒有設(shè)計數(shù)據(jù)庫的并發(fā)測試方案。只是在單元測試中驗證了數(shù)據(jù)庫的一致性。

5.5 兼容性測試

軟件的兼容性測試是指驗證軟件之間是否正確地交互和共享信息，包括同步共享、異步共享、本地交互以及遠(yuǎn)程通信交互[14]。由于本系統(tǒng)是Web 項目，因而做了瀏覽器兼容性測試以及分辨率兼容性測試。

瀏覽器兼容性測試是指從不同的瀏覽器登錄本系統(tǒng)，核對該系統(tǒng)在每個瀏覽器中html 元素的位置、大小以及該元素以及元素中存在的業(yè)務(wù)邏輯是否能夠正常顯示。分辨率兼容性測試指的是測試在不同分辨率的屏幕中Web 界面元素的位置能否按照原定比例顯示。常見的瀏覽器內(nèi)核可以分四種：Trident、Gecko、Blink、Webkit，例如：IE 瀏覽器為Trident 內(nèi)核，也稱為IE 內(nèi)核；Chrome瀏覽器：Webkit 內(nèi)核，現(xiàn)在為Blink 內(nèi)核；火狐瀏覽器：Gecko 內(nèi)核，俗稱Firefox 內(nèi)核；Safari 瀏覽器：Webkit 內(nèi)核。本系統(tǒng)的瀏覽器兼容性測試中選取了以下三種瀏覽器：ie 瀏覽器、火狐瀏覽器以及360 瀏覽器進(jìn)行測試。在三種瀏覽器中，界面元素的置大致相同且相應(yīng)的功能都可以實現(xiàn)。關(guān)于屏幕分辨率測試，表4 是市面上最常見的電腦屏幕分辨率，在本系統(tǒng)的分辨率兼容性測試中，在尺寸為14、15、22 的屏幕上分別選取兩個分辨率作為測試環(huán)境。

6 驗收測試

驗收測試是在軟件進(jìn)行系統(tǒng)測試之后、產(chǎn)品發(fā)布前所做的測試[15]。因代表著技術(shù)測試到了尾聲，驗收測試也被稱之為“交付測試”。驗收測試與系統(tǒng)測試最主要的區(qū)別是測試的人員相異，前者是由用戶來執(zhí)行測試操作的[16]，其主要目標(biāo)是向用戶展示所開發(fā)出來的軟件符合用戶需求，并驗證該軟件在實際場景中的有效性和可靠性，以確保用戶能使用該系統(tǒng)順利完成既定的任務(wù)和功能。通過了驗收測試，該產(chǎn)品便可發(fā)布。然而，在實際交付之后，開發(fā)人員是無法預(yù)測該軟件用戶的實際使用方法。因此，從用戶的角度出發(fā)，測試人員應(yīng)當(dāng)設(shè)計Alpha 測試和Beta 測試這兩種情形的測試。Alpha 測試是系統(tǒng)在開發(fā)環(huán)境下由用戶進(jìn)行的測試。Alpha 測試主要是對照需求規(guī)格說明書從軟件產(chǎn)品的功能、局域化、界面、可使用性以及性能等方面進(jìn)行評價。而Beta 測試是由多個用戶在實際環(huán)境中對其進(jìn)行測試，并將測試過程中發(fā)現(xiàn)的錯誤有效反饋給系統(tǒng)開發(fā)人員。本系統(tǒng)的驗收測試測試人員包含了系統(tǒng)的開發(fā)人員、測試人員以及隨機(jī)用戶。

7 結(jié)束語

本文以客運需求預(yù)測系統(tǒng)中的測試條目為案例，延伸分析了一種優(yōu)化后Web 系統(tǒng)的測試思路、步驟以及每個步驟中相關(guān)的測試方法和測試工具。旨在為Web 項目中的軟件測試提供一條清晰的測試分析思路。