基于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 测试框架与医疗平台相结合，提高了测试效率，减少了人为错误率，降低了测试成本，确保了医疗平台的质量和安全性，可为医疗平台开发提供可靠的技术参考，从而为患者提供更高质量的医疗服务。但在使用自动化测试医疗平台的同时，也需要注重质量管理机制和测试管理规范的作用。根据人工定期检测自动化测试的返回结果和状态，定期维护以及对自动化测试未覆盖的部分进行人工测试，是医疗平台上线前保证产品质量的重要环节。