電子招標(biāo)投標(biāo)系統(tǒng)性能測試實踐

張琳達(dá) 曹曉芳 宋世波

（中國軟件評測中心（工業(yè)和信息化部軟件與集成電路促進(jìn)中心），北京 100048）

1.測試背景

在2020年新冠疫情形勢下，對比傳統(tǒng)的線下招標(biāo)投標(biāo)流程，線上的電子招標(biāo)投標(biāo)業(yè)務(wù)顯現(xiàn)出“減少人員聚集，阻隔疫情傳播”的優(yōu)勢。各政府部門、公共資源交易中心、央企、國有企業(yè)、招標(biāo)代理機構(gòu)和第三方平臺都在大力推進(jìn)本行業(yè)領(lǐng)域的招標(biāo)投標(biāo)流程電子化。

隨著電子招投標(biāo)系統(tǒng)承載的招投標(biāo)項目數(shù)量的日益增長，其業(yè)務(wù)執(zhí)行壓力越來越大，系統(tǒng)運轉(zhuǎn)順利與否與系統(tǒng)性能息息相關(guān)。本文從電子招標(biāo)投標(biāo)系統(tǒng)的業(yè)務(wù)特點入手，通過一個實踐案例詳細(xì)剖析如何針對電子招標(biāo)投標(biāo)系統(tǒng)的性能進(jìn)行分析。

2.測試案例分析

中國軟件評測中心（工業(yè)和信息化部軟件與集成電路促進(jìn)中心）承擔(dān)著依據(jù)《電子招標(biāo)投標(biāo)系統(tǒng)交易平臺認(rèn)證技術(shù)規(guī)范》對電子招標(biāo)投標(biāo)系統(tǒng)進(jìn)行標(biāo)準(zhǔn)符合性測試的檢測任務(wù)。在某次檢測任務(wù)實施過程中，電子招標(biāo)投標(biāo)系統(tǒng)運營單位提出希望在性能方面進(jìn)行額外的測試，以避免在未來的電子招投標(biāo)活動中可能因系統(tǒng)性能問題而導(dǎo)致招投標(biāo)流程的延誤。

基于電子招投標(biāo)系統(tǒng)的業(yè)務(wù)特點和長期積累的電子招投標(biāo)系統(tǒng)的檢測經(jīng)驗，項目組認(rèn)為電子招投標(biāo)系統(tǒng)的主要業(yè)務(wù)壓力集中在投標(biāo)階段的上傳投標(biāo)文件環(huán)節(jié)，具體分析如下：

2.1 測試需求分析

在上傳投標(biāo)文件環(huán)節(jié)，根據(jù)電子招標(biāo)投標(biāo)的業(yè)務(wù)特點，需要考慮以下幾個方面：

（1）投標(biāo)文件較大。在與運營單位的溝通中發(fā)現(xiàn)，雖然運營單位的招標(biāo)項目涵蓋種類較多，含工程類、貨物類、服務(wù)類等，但還是以工程類項目居多。工程類項目的招投標(biāo)活動相對于貨物類項目或服務(wù)類項目更加復(fù)雜。不同工程類項目對技術(shù)、設(shè)備、施工組織、投標(biāo)人資質(zhì)等均有不同要求。投標(biāo)文件通常包含工程量清單、踏勘文件、圖紙等多個大文件。所以工程類項目的投標(biāo)文件較大。

（2）投標(biāo)人較多。根據(jù)和運營單位的溝通情況，運營單位每月開標(biāo)的工程類項目約180個，已完成的工程類招投標(biāo)項目中，經(jīng)常出現(xiàn)較多投標(biāo)人的情況。曾經(jīng)在某次工程類項目的招投標(biāo)活動中，一個標(biāo)段就出現(xiàn)上百個投標(biāo)人參與投標(biāo)活動。

（3）投標(biāo)文件上傳時間集中。投標(biāo)截止時間前，投標(biāo)人會根據(jù)自身情況反復(fù)修訂并重新上傳投標(biāo)文件。根據(jù)系統(tǒng)的歷史記錄顯示，投標(biāo)文件上傳的高峰期為投標(biāo)文件截止日期當(dāng)天的前幾個小時。

（4）內(nèi)外網(wǎng)環(huán)境：根據(jù)招標(biāo)代理和投標(biāo)人的反饋，偶爾會出現(xiàn)上傳和下載文件時間過長的問題，但運營單位使用過程中無此問題。因此，可能因為內(nèi)外網(wǎng)環(huán)境的不同影響了投標(biāo)文件上傳的效率。

基于以上分析，項目組認(rèn)為影響投標(biāo)文件上傳效率的主要因素為：同時上傳投標(biāo)文件的用戶量、投標(biāo)文件大小以及內(nèi)外網(wǎng)環(huán)境。

2.2 測試方案設(shè)計

綜合測試需求分析結(jié)果，本次電子招標(biāo)投標(biāo)系統(tǒng)性能測試方案設(shè)計如下：

（1）測試環(huán)境設(shè)計。電子招標(biāo)投標(biāo)系統(tǒng)架構(gòu)為B/S結(jié)構(gòu)，且本次性能測試須模擬內(nèi)外網(wǎng)2種環(huán)境下分別上傳投標(biāo)文件的情況。因此，測試環(huán)境中需部署數(shù)據(jù)庫服務(wù)器一臺、應(yīng)用服務(wù)器一臺以及內(nèi)外網(wǎng)測試機各3臺。其中，數(shù)據(jù)庫服務(wù)器和應(yīng)用服務(wù)器的操作系統(tǒng)均為CentOS 7.0，數(shù)據(jù)庫為MySQL 5.7，中間件為Tomcat 7.0、Nginx 1.10和Redis 3.0，瀏覽器為IE 9.0。網(wǎng)絡(luò)拓?fù)鋱D如圖1所示。

圖1 性能測試環(huán)境網(wǎng)絡(luò)拓?fù)鋱D

本次性能測試采用LoadRunner 11.00實現(xiàn)負(fù)載壓力模擬和自動化測試。性能測試過程中，通過測試工具錄制腳本模擬大量用戶并發(fā)上傳文件操作，并記錄相關(guān)的系統(tǒng)資源使用情況。

（2）測試場景設(shè)計。

場景1：在內(nèi)網(wǎng)環(huán)境，模擬10個投標(biāo)人并行上傳50MB文件；

場景2：在內(nèi)網(wǎng)環(huán)境，模擬50個投標(biāo)人并行上傳50MB文件；

場景3：在內(nèi)網(wǎng)環(huán)境，模擬100個投標(biāo)人并行上傳50MB文件。

場景4：在內(nèi)網(wǎng)環(huán)境，模擬10個投標(biāo)人并行上傳100MB文件；

場景5：在內(nèi)網(wǎng)環(huán)境，模擬50個投標(biāo)人并行上傳100MB文件；

場景6：在內(nèi)網(wǎng)環(huán)境，模擬100個投標(biāo)人并行上傳100MB文件。

場景7：在外網(wǎng)環(huán)境，模擬10個投標(biāo)人并行上傳50MB文件；

場景8：在外網(wǎng)環(huán)境，模擬50個投標(biāo)人并行上傳50MB文件；

場景9：在外網(wǎng)環(huán)境，模擬100個投標(biāo)人并行上傳50MB文件。

以上內(nèi)網(wǎng)、外網(wǎng)環(huán)境的網(wǎng)絡(luò)帶寬均為500Mb/s。

以上每個場景設(shè)置集合點執(zhí)行1次，每個場景進(jìn)行3組測試，計算平均值。

在執(zhí)行性能測試過程中，記錄系統(tǒng)在不同并發(fā)用戶規(guī)模下的性能表現(xiàn)，同時監(jiān)控每臺服務(wù)器的資源占用情況，包括以下幾類測試指標(biāo)：

（1）并發(fā)用戶數(shù)：測試工具采用進(jìn)程或者線程的方式模擬的虛擬用戶數(shù)量，每個虛擬用戶相當(dāng)于模擬了一個真實用戶的業(yè)務(wù)操作行為，但測試期間不模擬用戶的思考時間，相對來說，訪問交互的頻率要遠(yuǎn)遠(yuǎn)快于真實的用戶操作。

（2）響應(yīng)時間：測試期間統(tǒng)計系統(tǒng)成功交易的平均響應(yīng)時間。響應(yīng)時間的快慢反映了系統(tǒng)的響應(yīng)速度，響應(yīng)時間越短真實用戶將得到越好的用戶體驗。

（3）交易完成情況：測試期間統(tǒng)計系統(tǒng)完成交易的情況，包括成功的交易數(shù)量和失敗的交易數(shù)量，其中失敗的交易數(shù)量導(dǎo)致的原因主要包括服務(wù)器端報錯導(dǎo)致的交易失敗、服務(wù)器響應(yīng)超時，測試工具能夠自動判斷上述類型的失敗交易。嚴(yán)格意義上而言，系統(tǒng)不建議出現(xiàn)交易失敗，否則在現(xiàn)實情況下，真實的用戶將不能在業(yè)務(wù)系統(tǒng)上完成正常的操作。單位時間內(nèi)完成的交易數(shù)量越大反映了系統(tǒng)吞吐能力越好。

（4）CPU平均利用率：測試期間統(tǒng)計CPU資源的使用情況，通過采樣方式測試工具自動完成平均利用率的計算。CPU資源利用率從側(cè)面反映了系統(tǒng)在承載一定用戶的并發(fā)訪問下系統(tǒng)資源的使用情況，值越低反映系統(tǒng)的負(fù)載越小，相對更有潛力承擔(dān)更高的并發(fā)訪問。

2.3 測試結(jié)果分析

采用上述測試方案對該電子招標(biāo)投標(biāo)系統(tǒng)的上傳投標(biāo)文件性能點進(jìn)行了壓力測試，測試結(jié)果如表1所示。

表1 性能測試結(jié)果表

以上測試結(jié)果顯示，內(nèi)外網(wǎng)環(huán)境下，50并發(fā)用戶上傳50MB文件的平均響應(yīng)時間差別不大，均在1min以內(nèi)。當(dāng)并發(fā)用戶數(shù)上升至100時，平均響應(yīng)時間分別增至78.32和76.51，差別也不大，但均已出現(xiàn)較多失敗交易，其中，外網(wǎng)環(huán)境下的失敗交易相對內(nèi)網(wǎng)更多一些。由此可見，內(nèi)外網(wǎng)環(huán)境對用戶上傳投標(biāo)文件的平均響應(yīng)時間影響較小，而之前系統(tǒng)使用用戶反應(yīng)的內(nèi)外網(wǎng)上傳時間差別可能是由用戶終端網(wǎng)絡(luò)質(zhì)量造成的。

內(nèi)網(wǎng)環(huán)境下，當(dāng)上傳文件達(dá)到100MB時，50并發(fā)用戶進(jìn)行上傳操作已經(jīng)開始出現(xiàn)少量失敗交易，當(dāng)并發(fā)用戶數(shù)增至100時，失敗交易數(shù)已經(jīng)超過1/3，并且平均響應(yīng)時間將近3min。由此可見，在此測試環(huán)境下，100并發(fā)用戶上傳100MB文件，已接近該系統(tǒng)上傳操作的處理能力上限。

服務(wù)器資源占用率方面，無論內(nèi)外網(wǎng)環(huán)境，50或100并發(fā)用戶上傳文件操作時，數(shù)據(jù)庫服務(wù)器和應(yīng)用服務(wù)器的CPU平均利用率均較少。

3.測試總結(jié)

在本次性能測試中，項目組通過分析運營單位的實際情況，結(jié)合《電子招標(biāo)投標(biāo)系統(tǒng)交易平臺認(rèn)證技術(shù)規(guī)范》的要求，基于現(xiàn)有的性能測試結(jié)果，并經(jīng)過與運營單位、開發(fā)方的共同討論確認(rèn)后，建議對該平臺實施了如下調(diào)整：

（1）為減輕系統(tǒng)文件上傳的壓力，對單個投標(biāo)文件的大小限制在100MB以內(nèi)。

（2）修復(fù)系統(tǒng)瀏覽器的兼容性問題，解決用戶在使用Chrome瀏覽器上傳投標(biāo)文件時出現(xiàn)的無法斷點續(xù)傳問題。

（3）為更好地提升用戶的使用體驗，同時兼顧運營單位管理成本和人力成本，建議將系統(tǒng)服務(wù)器遷至云環(huán)境部署。

另外，項目組在本次測試中遇到了技術(shù)上的挑戰(zhàn)，在使用LoadRunner 11.00版本嘗試150M文件并發(fā)上傳時，LoadRunner工具的mmdrv應(yīng)用程序出現(xiàn)了內(nèi)存沖突問題，屬于測試工具自身的缺陷。在以后的類似測試中將探索使用其他工具或其他方法解決此問題。