基于客運需求預測系統的Web應用測試研究

邱吉雨 宋欣悅

（北京交通大學計算機與信息技術學院 北京市 100044）

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

1 客運需求預測系統

客運需求預測系統由我們自行開發，能夠將十年客運歷史數據以圖表的方式展現并且對未來幾年客運趨勢進行預測的系統。該系統包括客運需求分析子系統、客運需求預測子系統、基礎數據管理子系統和預測模型管理子系統等四個子系統，各子系統又細分了不同的條目，系統具體結構見圖2。客運需求預測系統是一個典型的Web 應用系統，具有內容驅動性、及時性、安全性和美觀性等特性。

2 測試計劃及測試方案

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

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

3 單元測試

圖1：W 模型圖

圖2：客運需求預測系統功能圖

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

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

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

表2：CityServletData 函數功能測試用例表

表3：集成測試用例表

（1）業務邏輯模塊函數功能能否實現；

（2）數據存取單元能否實現數據存取；

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

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

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

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

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

（3）測試CityServletData 的所有方法能否實現預期功能（包括CityServletData 方法、show 方法以及toString 方法）；

（4）測試ForecastData 類中的所有方法是否能夠實現預期功能（包括ForecastData 方法以及toString 方法）。

4 集成測試

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

（1）測試該頁面中的下拉框選項與折線圖是否發生聯動；

（2）該折線圖中的數據是否與數據庫中相關年份的正確數據對應。

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

5 系統測試

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

5.1 功能測試

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

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

5.2 回歸測試

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

對于系統的回歸測試，測試人員在綜合考慮時間和成本等因素后，構造了一個精簡后的用例組來進行測試。回歸測試的測試集需要驗證的內容是：

（1）對系統的修改是否破壞了現有的功能；

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

由于回歸測試的工作具有重復性，一般會編寫對應的測試腳本，將重復的工作交給自動化測試，以達到節省人力物力的目的。本項目使用由IBM 開發的Rational Functional Tester 工具以及python 語言編寫腳本進行自動化測試。

5.3 性能測試

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

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

（2）將測試結果進行對比。從結果上來看：

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

2.在遠程服務器端進行測試時，5000 次請求在200s 內只有4321 個請求發送成功，且最長的反應時間為21855ms，較本地請求測試差了許多，但是請求成功率大于80%，因而系統在遠程端請求的并發能力較好。

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

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

圖4：Jmeter 測試結果樹圖

圖5：Jmeter 測試結果圖

圖6：Jmeter 測試匯總報告圖

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

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

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

5.4 數據庫測試

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

5.5 兼容性測試

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

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

6 驗收測試

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

7 結束語

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