電子招標投標系統性能測試實踐

張琳達 曹曉芳 宋世波

（中國軟件評測中心（工業和信息化部軟件與集成電路促進中心），北京 100048）

1.測試背景

在2020年新冠疫情形勢下，對比傳統的線下招標投標流程，線上的電子招標投標業務顯現出“減少人員聚集，阻隔疫情傳播”的優勢。各政府部門、公共資源交易中心、央企、國有企業、招標代理機構和第三方平臺都在大力推進本行業領域的招標投標流程電子化。

隨著電子招投標系統承載的招投標項目數量的日益增長，其業務執行壓力越來越大，系統運轉順利與否與系統性能息息相關。本文從電子招標投標系統的業務特點入手，通過一個實踐案例詳細剖析如何針對電子招標投標系統的性能進行分析。

2.測試案例分析

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

基于電子招投標系統的業務特點和長期積累的電子招投標系統的檢測經驗，項目組認為電子招投標系統的主要業務壓力集中在投標階段的上傳投標文件環節，具體分析如下：

2.1 測試需求分析

在上傳投標文件環節，根據電子招標投標的業務特點，需要考慮以下幾個方面：

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

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

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

（4）內外網環境：根據招標代理和投標人的反饋，偶爾會出現上傳和下載文件時間過長的問題，但運營單位使用過程中無此問題。因此，可能因為內外網環境的不同影響了投標文件上傳的效率。

基于以上分析，項目組認為影響投標文件上傳效率的主要因素為：同時上傳投標文件的用戶量、投標文件大小以及內外網環境。

2.2 測試方案設計

綜合測試需求分析結果，本次電子招標投標系統性能測試方案設計如下：

（1）測試環境設計。電子招標投標系統架構為B/S結構，且本次性能測試須模擬內外網2種環境下分別上傳投標文件的情況。因此，測試環境中需部署數據庫服務器一臺、應用服務器一臺以及內外網測試機各3臺。其中，數據庫服務器和應用服務器的操作系統均為CentOS 7.0，數據庫為MySQL 5.7，中間件為Tomcat 7.0、Nginx 1.10和Redis 3.0，瀏覽器為IE 9.0。網絡拓撲圖如圖1所示。

圖1 性能測試環境網絡拓撲圖

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

（2）測試場景設計。

場景1：在內網環境，模擬10個投標人并行上傳50MB文件；

場景2：在內網環境，模擬50個投標人并行上傳50MB文件；

場景3：在內網環境，模擬100個投標人并行上傳50MB文件。

場景4：在內網環境，模擬10個投標人并行上傳100MB文件；

場景5：在內網環境，模擬50個投標人并行上傳100MB文件；

場景6：在內網環境，模擬100個投標人并行上傳100MB文件。

場景7：在外網環境，模擬10個投標人并行上傳50MB文件；

場景8：在外網環境，模擬50個投標人并行上傳50MB文件；

場景9：在外網環境，模擬100個投標人并行上傳50MB文件。

以上內網、外網環境的網絡帶寬均為500Mb/s。

以上每個場景設置集合點執行1次，每個場景進行3組測試，計算平均值。

在執行性能測試過程中，記錄系統在不同并發用戶規模下的性能表現，同時監控每臺服務器的資源占用情況，包括以下幾類測試指標：

（1）并發用戶數：測試工具采用進程或者線程的方式模擬的虛擬用戶數量，每個虛擬用戶相當于模擬了一個真實用戶的業務操作行為，但測試期間不模擬用戶的思考時間，相對來說，訪問交互的頻率要遠遠快于真實的用戶操作。

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

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

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

2.3 測試結果分析

采用上述測試方案對該電子招標投標系統的上傳投標文件性能點進行了壓力測試，測試結果如表1所示。

表1 性能測試結果表

以上測試結果顯示，內外網環境下，50并發用戶上傳50MB文件的平均響應時間差別不大，均在1min以內。當并發用戶數上升至100時，平均響應時間分別增至78.32和76.51，差別也不大，但均已出現較多失敗交易，其中，外網環境下的失敗交易相對內網更多一些。由此可見，內外網環境對用戶上傳投標文件的平均響應時間影響較小，而之前系統使用用戶反應的內外網上傳時間差別可能是由用戶終端網絡質量造成的。

內網環境下，當上傳文件達到100MB時，50并發用戶進行上傳操作已經開始出現少量失敗交易，當并發用戶數增至100時，失敗交易數已經超過1/3，并且平均響應時間將近3min。由此可見，在此測試環境下，100并發用戶上傳100MB文件，已接近該系統上傳操作的處理能力上限。

服務器資源占用率方面，無論內外網環境，50或100并發用戶上傳文件操作時，數據庫服務器和應用服務器的CPU平均利用率均較少。

3.測試總結

在本次性能測試中，項目組通過分析運營單位的實際情況，結合《電子招標投標系統交易平臺認證技術規范》的要求，基于現有的性能測試結果，并經過與運營單位、開發方的共同討論確認后，建議對該平臺實施了如下調整：

（1）為減輕系統文件上傳的壓力，對單個投標文件的大小限制在100MB以內。

（2）修復系統瀏覽器的兼容性問題，解決用戶在使用Chrome瀏覽器上傳投標文件時出現的無法斷點續傳問題。

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

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