翟承玨,于泓濤,梁振
1. 安徽醫(yī)科大學 生物醫(yī)學工程學院,安徽 合肥 230032;2. 愛特美德(安徽)智能科技有限公司,安徽 合肥 230032
隨著數(shù)字化轉(zhuǎn)型的推進,醫(yī)療軟件及平臺已成為現(xiàn)代醫(yī)療系統(tǒng)的核心組成部分[1]。這些平臺不僅提供醫(yī)療機構(gòu)管理和電子病歷等核心功能,還包括預約、診斷、藥物管理等諸多關(guān)鍵模塊。這些功能的正確性、穩(wěn)定性和安全性對于醫(yī)療機構(gòu)和患者來說至關(guān)重要。然而,由于醫(yī)療Web 平臺(以下簡稱醫(yī)療平臺)的復雜性和平臺對數(shù)據(jù)的高度敏感性,多數(shù)醫(yī)療數(shù)據(jù)需要進行加密儲存,使后端接口測試難以在醫(yī)療平臺上開展,因此,醫(yī)療平臺質(zhì)量和安全性保障成為一個巨大的挑戰(zhàn)。同時,隨著軟件開發(fā)周期的縮短和軟件交付的加速,單純依靠測試人員手動進行代碼檢測并完成繁瑣的測試任務是不切實際的[2-4]。此外,手動測試軟件的過程中還可能存在以下缺陷:① 手動測試依賴于測試人員的技能和經(jīng)驗,測試人員可能會犯錯,比如遺漏某些測試用例、執(zhí)行測試步驟時出現(xiàn)錯誤或者對測試結(jié)果作出錯誤的解釋;② 手動測試的結(jié)果可能受到測試人員主觀判斷的影響,不同的測試人員可能會有不同的理解和解釋,導致測試結(jié)果出現(xiàn)一致性問題;③ 手動測試的覆蓋范圍受限于測試人員的時間和資源,由于軟件系統(tǒng)變得越來越復雜,很難通過有限的測試用例集來覆蓋所有可能的情況和邊界條件。為了解決這些問題,測試團隊需要采用更高效、準確和可靠的測試方法。
在這個背景下,隨著自動化測試自動生成技術(shù)及面向?qū)ο蠹夹g(shù)在自動化測試中應用研究的不斷發(fā)展[5-8],Cypress 測試框架的出現(xiàn)為醫(yī)療平臺的測試帶來了一種解決方案。Cypress 是一種現(xiàn)代化的端到端測試框架,以其強大的功能和友好的開發(fā)者體驗而備受歡迎。Cypress 提供了一套豐富的工具和應用程序編程接口(Application Programming Interface,API),使測試人員能夠輕松編寫、運行和維護高質(zhì)量的自動化測試。
本文旨在探討將Cypress 測試框架與醫(yī)療平臺相結(jié)合的方法和優(yōu)勢,通過分析被測醫(yī)療平臺的功能,搭建相應的測試框架并編寫測試用例,再結(jié)合Cypress 自動化測試框架編寫測試代碼,將自動化測試覆蓋醫(yī)療平臺的各個關(guān)鍵功能模塊[9],從而實現(xiàn)醫(yī)療平臺自動化測試的無縫集成。
自動化測試的原理主要是通過模擬用戶的交互行為、訪問和修改瀏覽器的狀態(tài)自動輸入數(shù)據(jù),同時通過驗證執(zhí)行結(jié)果與預期結(jié)果是否存在差異進行模擬測試[10]。
自動化測試流程主要由3 部分組成:測試邏輯主體、測試數(shù)據(jù)輸入與斷言驗證。測試邏輯主體包括前期的測試準備工作,如需求分析、測試用例編寫、測試框架搭建等,測試人員需要進行需求分析并依據(jù)測試用例來編寫自動化測試代碼;測試過程中需通過變更測試輸入的數(shù)據(jù)以獲得不同的執(zhí)行結(jié)果;測試邏輯流程執(zhí)行完成后需要對自動化測試數(shù)據(jù)進行斷言,判斷測試的執(zhí)行結(jié)果與預期結(jié)果是否一致[11],最后返回得到最終的測試結(jié)果。測試過程中可將DevOps 工具和流程集成,靈活運用插件以提升測試時的效率。自動化測試流程與代碼執(zhí)行如圖1 所示。
圖1 自動化測試流程與代碼執(zhí)行
選取醫(yī)療平臺中的常見功能,醫(yī)院管理人員(以下簡稱admin)登錄平臺,以添加的醫(yī)生(以下簡稱provider)作為測試對象進行需求分析和測試用例編寫。為了做到功能全覆蓋測試,通過對系統(tǒng)進行分析,將該項測試分為4 個測試用例以全面驗證該功能的完整性。以用例1 作為主測試用例,首先admin 輸入真實的provider 號碼并進行添加,其次provider 接受請求并添加成功,最后得到正確的期望結(jié)果。用例2 為admin輸入真實的號碼并進行添加,但provider 拒絕請求,其期望的返回結(jié)果為provider 拒絕請求成功。用例3 和用例4 分別為admin 輸入不存在的號碼和輸入已經(jīng)添加的provider 號碼,其期望的返回結(jié)果為admin 端彈出相應的錯誤彈框。測試用例架構(gòu)圖如圖2 所示。
圖2 測試用例架構(gòu)圖
自動生成測試數(shù)據(jù)的方法包括隨機生成、通過約束條件生成和使用上一次請求的響應數(shù)據(jù)[12]。為確保斷言的準確性及便捷性,將數(shù)據(jù)結(jié)構(gòu)與測試結(jié)果分離。在測試開始時,將所有在測試用例中使用的測試數(shù)據(jù)以常量的形式存入到Data.js 中作為測試數(shù)據(jù)儲存調(diào)用,例如admin/provider 的測試賬號和密碼、各項用于斷言的賬號信息等。測試人員可通過修改Data.js 中的數(shù)據(jù)來變更測試時輸入的數(shù)據(jù)和斷言時的數(shù)據(jù)。同時為確保代碼的簡潔性和可復用性,將函數(shù)層與測試控制層分離,再將所需要使用的函數(shù)通過封裝的形式存入到Commands.js 中。測試時,測試控制層通過解析調(diào)用Command.js 中的函數(shù)進行測試操作。測試框架結(jié)構(gòu)圖如圖3 所示。
圖3 測試框架搭建
被測系統(tǒng)是一款包含患者在線問診、醫(yī)生在線診療以及醫(yī)院信息管理等功能的一站式醫(yī)療平臺。該平臺主要包括前臺預約診療和后臺管理兩大部分:前臺模塊的功能包括用戶注冊、登錄、加好友、創(chuàng)建預約、線上視頻診療、醫(yī)療購物等功能;后臺管理模塊包括商品管理、訂單管理、醫(yī)院收費管理和用戶個人信息管理等功能。
在平臺自動化測試框架初步實現(xiàn)后,為驗證自動化測試的使用效率,需選取被測平臺的相應功能進行自動化測試和手動測試對比。測試開始前,測試人員在被測計算機上配置好測試環(huán)境和自動化測試軟件,計算機和軟件的主要配置信息如表1 所示。環(huán)境和軟件配置完成后,測試人員選取被測平臺的6 項功能模塊進行需求分析,通過PingCode 編寫相應的測試用例(圖4a),之后搭建測試框架并編寫相應的自動化測試代碼(圖4b)后進行自動化測試(圖4c)。測試時,將所遇到的系統(tǒng)錯誤記錄到相應的文檔中,以便技術(shù)人員進行修復(圖4d),再利用Cypress 可視化平臺進行代碼調(diào)試(圖4e),同時記錄自動化測試相應的前期準備時長和執(zhí)行用例時長,并與手動測試時間進行對比。利用公式(1)計算單次測試的自動化測試收益X,用公式(2)計算進行多次回歸測試后的自動化測試收益Y。
表1 計算機及測試軟件的主要配置信息
圖4 實際測試應用
式中,aT為手動測試所耗費的時長;bT為自動測試所耗費的時長;
式中,Tsp為手動測試準備時間;Tsr為手動測試執(zhí)行用例時長;Tzp為自動化測試準備時間;Tzr為自動化測試執(zhí)行用例時長;n為回歸測試次數(shù)。
其中,手動測試準備時長包括測試需求分析和測試用例編寫時長;自動化測試準備時長包括測試需求分析、自動化測試用例編寫、測試框架搭建以及自動化測試代碼編寫時長。在測試完成后,記錄本次測試時間及測試方式,以便測試人員進行定期的回歸測試(圖4f)。
引入自動化測試主要是為了通過提升測試人員的工作效率,使測試變得簡單高效,從而達到節(jié)約開發(fā)成本的目的[13]。在該醫(yī)療平臺的自動化測試實施期間,該系統(tǒng)共經(jīng)歷了5 次版本升級。每次版本更新或內(nèi)部底層代碼環(huán)境變動都需要通過大量的功能測試和回歸測試,以完成對系統(tǒng)的驗證。該平臺測試項目目前已有約200 個手動測試用例,其中近20個測試用例已實現(xiàn)自動化測試,有80 個測試用例正在向自動化測試過渡,這些測試用例覆蓋了該系統(tǒng)前端模塊的大部分功能測試。雖暫時還未做到自動化測試的全覆蓋,但其中10%的測試用例已可通過自動化測試執(zhí)行。
自動化測試與手動測試相應功能的測試時長如表2所示。
表2 手動測試和自動化測試耗時比(h)
根據(jù)表2 數(shù)據(jù)計算單次功能測試自動化的測試收益為-88%,不如手工測試效益,這是因為自動化測試在執(zhí)行前需要大量的準備時間來設(shè)計測試用例和搭建自動化測試框架。此外,沒有一個產(chǎn)品只進行一輪測試就可以通過并上線,一個軟件產(chǎn)品的發(fā)布往往需要經(jīng)過多輪回歸測試才能保證軟件質(zhì)量。
多次回歸測試后的自動化收益率如表3 所示,隨著回歸測試的次數(shù)增加,自動化測試的收益率顯著提高。雖然自動化測試在前期需要開發(fā)大量的測試腳本,做大量準備工作,但當自動化測試部署完成后,自動執(zhí)行的測試用例效率遠高于人工測試,驗證了本研究自動化測試框架設(shè)計的實用性和有效性。
表3 手動測試和自動化測試收益表
將“患者創(chuàng)建診療預約”和“患者發(fā)送病歷文檔”功能的多次手動測試和自動化測試的結(jié)果進行比對可得,數(shù)據(jù)滿足正態(tài)分布,數(shù)據(jù)以±s的形式表示。利用SPSS 26.0 統(tǒng)計學軟件進行數(shù)據(jù)分析,對手動測試和自動化測試執(zhí)行用例所用時長進行比較。結(jié)果顯示,自動化測試速度明顯快于手動測試(P<0.001),見表4。
表4 手動測試和自動化測試時間對比(±s,h)
表4 手動測試和自動化測試時間對比(±s,h)
項目患者創(chuàng)建診療預約患者發(fā)送病歷文檔手動測試12.11±1.526.04±0.98自動化測試0.39±0.020.26±0.01 t值16.5412.57 P值<0.001<0.001
自動化測試與手動測試在一段時間內(nèi)對醫(yī)療平臺單一功能進行測試所發(fā)現(xiàn)的問題數(shù)目如圖5 所示。結(jié)果表明,自動化測試因測試速度快,可在一天內(nèi)對單一功能進行不同數(shù)據(jù)的多次測試,因此,自動化測試在相同時間內(nèi)測試出的問題數(shù)目普遍多于手動測試。
圖5 發(fā)現(xiàn)問題數(shù)目折線圖
為更好地開展針對醫(yī)療平臺的自動化測試,測試人員將Cypress 與其他測試框架如Selenium、Puppeteer 和TestCafe 的區(qū)別與優(yōu)勢進行了對比。
Selenium 是ThoughtWorks 公司開發(fā)的一套非常強大的開源工具[14-19],支持多種編程語言,如Python、Java、C#等,可使測試人員用各自熟悉的語言編寫測試腳本,提高了測試的靈活性和易用性[20]。但Selenium在使用時需安裝相應瀏覽器的驅(qū)動程序,這可能增加部署和配置的復雜性,增加測試人員的學習成本[21]。Puppeteer 的主要優(yōu)勢是擁有無頭瀏覽器測試功能,允許用戶自行控制并與Chromium 的無頭版本交互,對于需要在無可見瀏覽器窗口下執(zhí)行自動化操作的場景非常有用[22]。但Puppeteer 對Chrome 版本的依賴性較強,不同的Chrome 版本可能會導致測試結(jié)果不一致[23]。TestCafe 支持實時并行測試,可在多個瀏覽器實例中同時運行測試用例,提高了測試效率[24]。但與一些其他測試工具相比,TestCafe 的功能相對較少,可能無法滿足某些特定的測試需求[25]。
相較于上述自動化測試框架,Cypress 的優(yōu)勢是擁有簡單直觀的API,使開發(fā)人員和測試人員可輕松編寫和維護測試。Cypress 具有清晰簡潔的語法,使初學者也能進行自動化測試[26]。同時,該框架采用的交互式測試運行器和可視化平臺使測試人員可實時查看測試過程中的各種元素和狀態(tài),以便更好地理解測試結(jié)果[27]。因此,在面對功能復雜及使用瀏覽器版本可能不一致的醫(yī)療平臺自動化測試環(huán)境時,Cypress 以其簡單、易用、穩(wěn)定的特性更優(yōu)于其他自動化測試框架。
雖然使用自動化測試可提升醫(yī)療平臺在上線時的測試效率[28],但僅僅依靠自動化測試進行醫(yī)療平臺上線時的維護測試是不現(xiàn)實的。醫(yī)療平臺功能復雜性高,輸出不確定,測試難度與其他軟件也較為不同[29],且Cypress 自動化測試無法覆蓋到全部的測試環(huán)節(jié),諸如接口測試、服務器后端測試、入侵測試、隨機測試是無法通過Cypress 進行自動化測試的[30]。因此,為保證醫(yī)療平臺上線時的質(zhì)量,依舊需要人工測試輔助自動化測試進行平臺測試。
Cypress 是一款功能強大的Web 應用程序測試框架,具有易于使用、自動等待和實時重新加載等優(yōu)點。本文通過將Cypress 測試框架與醫(yī)療平臺相結(jié)合,提高了測試效率,減少了人為錯誤率,降低了測試成本,確保了醫(yī)療平臺的質(zhì)量和安全性,可為醫(yī)療平臺開發(fā)提供可靠的技術(shù)參考,從而為患者提供更高質(zhì)量的醫(yī)療服務。但在使用自動化測試醫(yī)療平臺的同時,也需要注重質(zhì)量管理機制和測試管理規(guī)范的作用。根據(jù)人工定期檢測自動化測試的返回結(jié)果和狀態(tài),定期維護以及對自動化測試未覆蓋的部分進行人工測試,是醫(yī)療平臺上線前保證產(chǎn)品質(zhì)量的重要環(huán)節(jié)。