基于Cypress的醫療Web平臺自動化測試設計與實現

翟承玨，于泓濤，梁振

1. 安徽醫科大學 生物醫學工程學院，安徽 合肥 230032；2. 愛特美德（安徽）智能科技有限公司，安徽 合肥 230032

引言

隨著數字化轉型的推進，醫療軟件及平臺已成為現代醫療系統的核心組成部分[1]。這些平臺不僅提供醫療機構管理和電子病歷等核心功能，還包括預約、診斷、藥物管理等諸多關鍵模塊。這些功能的正確性、穩定性和安全性對于醫療機構和患者來說至關重要。然而，由于醫療Web 平臺（以下簡稱醫療平臺）的復雜性和平臺對數據的高度敏感性，多數醫療數據需要進行加密儲存，使后端接口測試難以在醫療平臺上開展，因此，醫療平臺質量和安全性保障成為一個巨大的挑戰。同時，隨著軟件開發周期的縮短和軟件交付的加速，單純依靠測試人員手動進行代碼檢測并完成繁瑣的測試任務是不切實際的[2-4]。此外，手動測試軟件的過程中還可能存在以下缺陷：① 手動測試依賴于測試人員的技能和經驗，測試人員可能會犯錯，比如遺漏某些測試用例、執行測試步驟時出現錯誤或者對測試結果作出錯誤的解釋；② 手動測試的結果可能受到測試人員主觀判斷的影響，不同的測試人員可能會有不同的理解和解釋，導致測試結果出現一致性問題；③ 手動測試的覆蓋范圍受限于測試人員的時間和資源，由于軟件系統變得越來越復雜，很難通過有限的測試用例集來覆蓋所有可能的情況和邊界條件。為了解決這些問題，測試團隊需要采用更高效、準確和可靠的測試方法。

在這個背景下，隨著自動化測試自動生成技術及面向對象技術在自動化測試中應用研究的不斷發展[5-8]，Cypress 測試框架的出現為醫療平臺的測試帶來了一種解決方案。Cypress 是一種現代化的端到端測試框架，以其強大的功能和友好的開發者體驗而備受歡迎。Cypress 提供了一套豐富的工具和應用程序編程接口（Application Programming Interface，API），使測試人員能夠輕松編寫、運行和維護高質量的自動化測試。

本文旨在探討將Cypress 測試框架與醫療平臺相結合的方法和優勢，通過分析被測醫療平臺的功能，搭建相應的測試框架并編寫測試用例，再結合Cypress 自動化測試框架編寫測試代碼，將自動化測試覆蓋醫療平臺的各個關鍵功能模塊[9]，從而實現醫療平臺自動化測試的無縫集成。

1 原理與方法

1.1 自動化測試的原理與流程

自動化測試的原理主要是通過模擬用戶的交互行為、訪問和修改瀏覽器的狀態自動輸入數據，同時通過驗證執行結果與預期結果是否存在差異進行模擬測試[10]。

自動化測試流程主要由3 部分組成：測試邏輯主體、測試數據輸入與斷言驗證。測試邏輯主體包括前期的測試準備工作，如需求分析、測試用例編寫、測試框架搭建等，測試人員需要進行需求分析并依據測試用例來編寫自動化測試代碼；測試過程中需通過變更測試輸入的數據以獲得不同的執行結果；測試邏輯流程執行完成后需要對自動化測試數據進行斷言，判斷測試的執行結果與預期結果是否一致[11]，最后返回得到最終的測試結果。測試過程中可將DevOps 工具和流程集成，靈活運用插件以提升測試時的效率。自動化測試流程與代碼執行如圖1 所示。

圖1 自動化測試流程與代碼執行

1.2 需求分析與用例編寫

選取醫療平臺中的常見功能，醫院管理人員（以下簡稱admin）登錄平臺，以添加的醫生（以下簡稱provider）作為測試對象進行需求分析和測試用例編寫。為了做到功能全覆蓋測試，通過對系統進行分析，將該項測試分為4 個測試用例以全面驗證該功能的完整性。以用例1 作為主測試用例，首先admin 輸入真實的provider 號碼并進行添加，其次provider 接受請求并添加成功，最后得到正確的期望結果。用例2 為admin輸入真實的號碼并進行添加，但provider 拒絕請求，其期望的返回結果為provider 拒絕請求成功。用例3 和用例4 分別為admin 輸入不存在的號碼和輸入已經添加的provider 號碼，其期望的返回結果為admin 端彈出相應的錯誤彈框。測試用例架構圖如圖2 所示。

圖2 測試用例架構圖

1.3 測試框架搭建

自動生成測試數據的方法包括隨機生成、通過約束條件生成和使用上一次請求的響應數據[12]。為確保斷言的準確性及便捷性，將數據結構與測試結果分離。在測試開始時，將所有在測試用例中使用的測試數據以常量的形式存入到Data.js 中作為測試數據儲存調用，例如admin/provider 的測試賬號和密碼、各項用于斷言的賬號信息等。測試人員可通過修改Data.js 中的數據來變更測試時輸入的數據和斷言時的數據。同時為確保代碼的簡潔性和可復用性，將函數層與測試控制層分離，再將所需要使用的函數通過封裝的形式存入到Commands.js 中。測試時，測試控制層通過解析調用Command.js 中的函數進行測試操作。測試框架結構圖如圖3 所示。

圖3 測試框架搭建

1.4 測試方法與配置環境

被測系統是一款包含患者在線問診、醫生在線診療以及醫院信息管理等功能的一站式醫療平臺。該平臺主要包括前臺預約診療和后臺管理兩大部分：前臺模塊的功能包括用戶注冊、登錄、加好友、創建預約、線上視頻診療、醫療購物等功能；后臺管理模塊包括商品管理、訂單管理、醫院收費管理和用戶個人信息管理等功能。

在平臺自動化測試框架初步實現后，為驗證自動化測試的使用效率，需選取被測平臺的相應功能進行自動化測試和手動測試對比。測試開始前，測試人員在被測計算機上配置好測試環境和自動化測試軟件，計算機和軟件的主要配置信息如表1 所示。環境和軟件配置完成后，測試人員選取被測平臺的6 項功能模塊進行需求分析，通過PingCode 編寫相應的測試用例（圖4a），之后搭建測試框架并編寫相應的自動化測試代碼（圖4b）后進行自動化測試（圖4c）。測試時，將所遇到的系統錯誤記錄到相應的文檔中，以便技術人員進行修復（圖4d），再利用Cypress 可視化平臺進行代碼調試（圖4e），同時記錄自動化測試相應的前期準備時長和執行用例時長，并與手動測試時間進行對比。利用公式（1）計算單次測試的自動化測試收益X，用公式（2）計算進行多次回歸測試后的自動化測試收益Y。

表1 計算機及測試軟件的主要配置信息

圖4 實際測試應用

式中，aT為手動測試所耗費的時長；bT為自動測試所耗費的時長；

式中，Tsp為手動測試準備時間；Tsr為手動測試執行用例時長；Tzp為自動化測試準備時間；Tzr為自動化測試執行用例時長；n為回歸測試次數。

其中，手動測試準備時長包括測試需求分析和測試用例編寫時長；自動化測試準備時長包括測試需求分析、自動化測試用例編寫、測試框架搭建以及自動化測試代碼編寫時長。在測試完成后，記錄本次測試時間及測試方式，以便測試人員進行定期的回歸測試（圖4f）。

2 結果

引入自動化測試主要是為了通過提升測試人員的工作效率，使測試變得簡單高效，從而達到節約開發成本的目的[13]。在該醫療平臺的自動化測試實施期間，該系統共經歷了5 次版本升級。每次版本更新或內部底層代碼環境變動都需要通過大量的功能測試和回歸測試，以完成對系統的驗證。該平臺測試項目目前已有約200 個手動測試用例，其中近20個測試用例已實現自動化測試，有80 個測試用例正在向自動化測試過渡，這些測試用例覆蓋了該系統前端模塊的大部分功能測試。雖暫時還未做到自動化測試的全覆蓋，但其中10%的測試用例已可通過自動化測試執行。

2.1 單次功能測試

自動化測試與手動測試相應功能的測試時長如表2所示。

表2 手動測試和自動化測試耗時比（h）

根據表2 數據計算單次功能測試自動化的測試收益為-88%，不如手工測試效益，這是因為自動化測試在執行前需要大量的準備時間來設計測試用例和搭建自動化測試框架。此外，沒有一個產品只進行一輪測試就可以通過并上線，一個軟件產品的發布往往需要經過多輪回歸測試才能保證軟件質量。

2.2 多次回歸測試

多次回歸測試后的自動化收益率如表3 所示，隨著回歸測試的次數增加，自動化測試的收益率顯著提高。雖然自動化測試在前期需要開發大量的測試腳本，做大量準備工作，但當自動化測試部署完成后，自動執行的測試用例效率遠高于人工測試，驗證了本研究自動化測試框架設計的實用性和有效性。

表3 手動測試和自動化測試收益表

將“患者創建診療預約”和“患者發送病歷文檔”功能的多次手動測試和自動化測試的結果進行比對可得，數據滿足正態分布，數據以±s的形式表示。利用SPSS 26.0 統計學軟件進行數據分析，對手動測試和自動化測試執行用例所用時長進行比較。結果顯示，自動化測試速度明顯快于手動測試（P＜0.001），見表4。

表4 手動測試和自動化測試時間對比（±s，h）

表4 手動測試和自動化測試時間對比（±s，h）

項目患者創建診療預約患者發送病歷文檔手動測試12.11±1.526.04±0.98自動化測試0.39±0.020.26±0.01 t值16.5412.57 P值＜0.001＜0.001

自動化測試與手動測試在一段時間內對醫療平臺單一功能進行測試所發現的問題數目如圖5 所示。結果表明，自動化測試因測試速度快，可在一天內對單一功能進行不同數據的多次測試，因此，自動化測試在相同時間內測試出的問題數目普遍多于手動測試。

圖5 發現問題數目折線圖

3 討論

為更好地開展針對醫療平臺的自動化測試，測試人員將Cypress 與其他測試框架如Selenium、Puppeteer 和TestCafe 的區別與優勢進行了對比。

Selenium 是ThoughtWorks 公司開發的一套非常強大的開源工具[14-19]，支持多種編程語言，如Python、Java、C#等，可使測試人員用各自熟悉的語言編寫測試腳本，提高了測試的靈活性和易用性[20]。但Selenium在使用時需安裝相應瀏覽器的驅動程序，這可能增加部署和配置的復雜性，增加測試人員的學習成本[21]。Puppeteer 的主要優勢是擁有無頭瀏覽器測試功能，允許用戶自行控制并與Chromium 的無頭版本交互，對于需要在無可見瀏覽器窗口下執行自動化操作的場景非常有用[22]。但Puppeteer 對Chrome 版本的依賴性較強，不同的Chrome 版本可能會導致測試結果不一致[23]。TestCafe 支持實時并行測試，可在多個瀏覽器實例中同時運行測試用例，提高了測試效率[24]。但與一些其他測試工具相比，TestCafe 的功能相對較少，可能無法滿足某些特定的測試需求[25]。

相較于上述自動化測試框架，Cypress 的優勢是擁有簡單直觀的API，使開發人員和測試人員可輕松編寫和維護測試。Cypress 具有清晰簡潔的語法，使初學者也能進行自動化測試[26]。同時，該框架采用的交互式測試運行器和可視化平臺使測試人員可實時查看測試過程中的各種元素和狀態，以便更好地理解測試結果[27]。因此，在面對功能復雜及使用瀏覽器版本可能不一致的醫療平臺自動化測試環境時，Cypress 以其簡單、易用、穩定的特性更優于其他自動化測試框架。

雖然使用自動化測試可提升醫療平臺在上線時的測試效率[28]，但僅僅依靠自動化測試進行醫療平臺上線時的維護測試是不現實的。醫療平臺功能復雜性高，輸出不確定，測試難度與其他軟件也較為不同[29]，且Cypress 自動化測試無法覆蓋到全部的測試環節，諸如接口測試、服務器后端測試、入侵測試、隨機測試是無法通過Cypress 進行自動化測試的[30]。因此，為保證醫療平臺上線時的質量，依舊需要人工測試輔助自動化測試進行平臺測試。

4 結論

Cypress 是一款功能強大的Web 應用程序測試框架，具有易于使用、自動等待和實時重新加載等優點。本文通過將Cypress 測試框架與醫療平臺相結合，提高了測試效率，減少了人為錯誤率，降低了測試成本，確保了醫療平臺的質量和安全性，可為醫療平臺開發提供可靠的技術參考，從而為患者提供更高質量的醫療服務。但在使用自動化測試醫療平臺的同時，也需要注重質量管理機制和測試管理規范的作用。根據人工定期檢測自動化測試的返回結果和狀態，定期維護以及對自動化測試未覆蓋的部分進行人工測試，是醫療平臺上線前保證產品質量的重要環節。