视觉回归测试：一种自动化测试方法，通过比较两个版本之间的用户界面截图来检测非预期的视觉变化——ISTQB 将其定义为应用于软件系统显示层的回归测试技术。
这里有一个在合规会议上没人会问的问题：当您的视觉测试工具对患者门户截图时，那张图去到了哪里？
那张截图显示了一个控制面板，上面有患者的姓名、出生日期、化验结果、当前处方，可能还有就诊历史。这是预发布环境，没错。但数据是接近真实的——因为用荒谬的数据测试等于什么都没测。而那张截图刚刚被发到美国一台云端服务器，去与一张参考图做像素级比较。
恭喜：您刚刚制造了一个潜在的合规事件。
本文面向医疗软件供应商、医院、诊所以及健康科技初创公司的质量经理、CIO 和 DPO，他们希望在不损害患者数据的前提下测试他们的界面。
医疗界面不是普通界面
医疗界面有一个少有其他领域共享的特点：它显示的信息会对患者的生命产生直接后果。
一个小数点错位的药物剂量。一个单位被截断的化验结果。一个 CSS 更新后颜色发生变化的严重程度指示器——"危急"的红色变成了"中度警觉"的橙色。一个日期格式错乱的就诊日历，让患者在错误的日期来做术前检查。
这些场景不是假设。法国 ANSM（国家药品安全局）和 FDA 定期记录与医疗软件显示错误相关的事件。FDA 2023年关于医疗设备软件召回的报告指出，用户界面错误是召回的第三大原因，仅次于计算错误和数据传输问题。
与其他行业的区别很简单：在电商中，一个视觉缺陷损失的是钱。在医疗中，一个视觉缺陷可能损失的是一条生命。这一现实从根本上改变了您必须如何思考界面测试。
使用您软件的医疗专业人员——医生、护士、药剂师、化验技师——在压力下工作，常常疲劳，同时管理几十名患者。他们没有时间去验证界面是否正确显示信息。他们相信他们看到的。而这种信任必须由严谨的测试流程来支撑。
HIPAA、HDS、GDPR：监管三联画及其对视觉测试的影响
医疗行业大概是数据保护方面监管最严格的领域。这些监管对您可以——和不可以——如何测试您的界面有直接影响。
HIPAA（Health Insurance Portability and Accountability Act）。 在美国，HIPAA 保护 PHI（Protected Health Information，受保护健康信息）——任何能识别患者并涉及其健康状况、所接受治疗或为之付费的信息。HIPAA 的 Security Rule 要求采取技术性安全措施保护电子 PHI，包括访问控制、审计追踪、数据完整性和传输安全。一张患者界面的截图，如果包含 PHI，本身就是 PHI。把它发给一个 SaaS 测试工具就意味着该供应商成为 HIPAA 下的 Business Associate，需要 BAA（Business Associate Agreement）——即便有 BAA，泄露发生时责任仍是共同承担。HIPAA 罚款从每次违规100美元到50,000美元不等，每个类别每年上限为150万美元。2024年，OCR（Office for Civil Rights）累计罚款超过1.3亿美元。
HDS（Health Data Hosting）。 在法国，HDS 认证对于任何托管个人健康数据的提供方都是强制的。该认证由2018年2月26日的法令引入并经2024年更新加强，要求托管在欧盟境内，并具备特定的技术与组织保障。如果您的视觉测试工具把含健康数据的截图发到一个未获 HDS 认证的云端，您就处于违规状态。HDS 认证不是走过场：它涉及 COFRAC 认可机构的审计、符合 ISO 27001 的信息安全管理体系，以及对数据所在地和访问的特定控制。
GDPR 与健康数据。 GDPR 把健康数据归类为敏感数据（第9条），受到加强保护。处理默认是被禁止的，仅有有限的例外——包括明确同意和重大利益。一张患者界面的截图，含健康数据，被发送到 SaaS 测试工具，构成对敏感数据的处理。这种处理必须有合法依据、记录在您的处理登记册中，且如果传输至欧盟之外还需做 DPIA（Data Protection Impact Assessment）。CNIL 的态度很明确：把健康数据传输至美国，即便在 Data Privacy Framework 下，也需要加强警惕。
这三项监管联合传达的是：出现在您截图里的健康数据不只是图片。它们是受严格法律框架保护的敏感数据。每次这些图片离开您的基础设施，您都创造了一个监管风险点。
为什么预发布数据是一种虚假的安全感
"我们不用真实数据测试。"这是您几乎在每个医疗开发团队都能听到的论点。而它在仔细推敲下站不住脚。
首先有"真实数据"是什么意思的问题。许多医疗预发布环境使用生产数据的匿名化或假名化副本。在医疗领域里，完美的匿名化是出了名的困难——研究表明，仅凭三项信息——邮政编码、出生日期和性别，就能唯一识别出87%的美国人口。一份保留了出生日期、邮政编码和主诊断的假名化患者记录并不匿名——它是可重新识别的。
然后是合成数据。是的，您可以生成虚构患者，带随机姓名、虚构的出生日期，以及算法分配的状况。但要让您的测试有意义，这些数据必须真实。一个使用 metformin 的2型糖尿病患者的 HbA1c 为6.4%。一个使用 warfarin 的患者的 INR 为2.3。这些值在医学上是连贯的——而正是这种连贯性，让一位谨慎的监管者在它们与足够详细的患者画像关联时可能将其归类为健康数据。
最后还有现实情况。开发者有时会复制生产数据到预发布环境以重现一个缺陷。一位医生报告某位患者记录的显示问题，开发团队需要重现确切上下文。这些"临时"副本有令人遗憾地变成永久副本的倾向。当您的视觉测试工具对那个环境截图时，它可能就捕获了真实患者数据。
从结构上消除这一风险的唯一方法，就是让截图永远不离开您的边界。无论它们包含什么——真实、假名化、合成或混合数据——只要它们留在您的机器上，未授权传输的风险就被设计性地消除了。
视觉测试作为无障碍守护者
医疗领域视觉测试有一个被讨论得太少的方面：无障碍。
医疗界面的使用者不只是医疗专业人员。他们也是患者本身——通过患者门户、监测应用、数字健康档案。这些患者中包括视力下降的老年人、无法分辨某些颜色的色盲人士、用键盘或辅助技术导航的运动障碍者。
在法国，RGAA（General Accessibility Improvement Framework）要求公共数字服务必须无障碍。公共医疗机构直接受其约束。私营部门也无法置身事外：欧洲 Web Accessibility Directive (2016/2102) 和 European Accessibility Act (2025) 在逐步扩展这些义务。
视觉测试检测在视觉上表现出来的无障碍回归。文本对比度跌破 WCAG 2.1 Level AA 要求的4.5:1 比率。可点击区域缩小到44×44像素以下。一次 CSS 大改后，可见的 focus 消失了。当用户在浏览器中放大字体时，文字未能正确放大。
对老年患者而言——随着人口老龄化和就医路径数字化，他们在患者门户用户中所占比例正在上升——这些回归不只是麻烦。化验结果上字体过小，意味着患者无法理解自己的结果。预约页面上对比不足的按钮，意味着错过的就诊。手机上叠加的处方续配表单，意味着患者无法获得他们的药物。
视觉测试不取代完整的无障碍审计。但它阻止回归——在初始审计已完成、挑战在于跨迭代和更新维持合规的场景中，视觉回归测试是最有效的安全网。
本地部署作为唯一的结构性答案
让我们重述一遍约束。HIPAA 要求保护 PHI 并与每位供应商签 BAA。HDS 要求在欧洲领土内的认证托管。GDPR 把健康数据归类为敏感数据并限制其传输。预发布数据不一定比生产数据更安全。无障碍则提出了持续的视觉要求。
面对这些约束，有两种方法。第一种是逐项满足每个要求：与您 SaaS 供应商签 BAA、核实他们的 HDS 认证、在 GDPR 登记册中记录传输、做一份 DPIA、在您预发布环境中实施匿名化控制。这是可行的，但是一座复杂的大厦，每个环节都必须站得住——而只要一个薄弱环节就足以制造突破口。
第二种方法是从根源上消除问题：如果截图永远不离开您的基础设施，那大多数这些要求就变得无关紧要。没有要记录的传输、没有要签的 BAA、没有要在第三方处核实的认证、没有为视觉测试需要做的 DPIA。您保持完全控制，您的合规姿态被极大简化。
这就是本地部署方法。在医疗行业，它不是保守或恐技术的选择。它是对一个不容许马虎的监管环境最理性的回应。
Delta-QA 与医疗行业的特殊性
Delta-QA 是一款完全在本地运行的无代码视觉测试工具。下面是这对医疗领域的具体含义。
零数据传输。 您患者界面的截图留在您测试人员的机器上。没有云端、没有外部 API、没有第三方服务器。无论您的患者门户显示的是真实、假名化还是合成数据，它都永远不离开您的边界。对于一名 DPO 来说，这是一份被极大简化的合规档案。
无需开发专业技能。 在医疗领域，QA 团队往往由功能型人员组成——他们了解就医路径、业务流程、监管要求，但不写代码。Delta-QA 通过浏览运作：您打开您的应用，像用户一样浏览屏幕，工具会进行记录和比较。这是任何功能测试人员已经具备的技能。
确定性且可审计的检测。 Delta-QA 的结构化算法分析的是真实的 CSS 而不是比较像素。当它检测到一处变化，它产生明确的报告：".patient-name 元素的字号从16px变为14px"、".confirm 按钮的对比度从4.8:1 变为3.2:1"。在每一项测试决策都必须可被解释的场景下——HDS 审计、ANSM 检查、HIPAA 调查时——这种可追溯性比起结果只是一个概率而非确定性的 AI 方案，是显著的优势。
无障碍回归检测。 由于 Delta-QA 分析 CSS 结构，它检测到那些影响视觉无障碍的变化：对比度修改、字号缩小、交互区域尺寸变化。它不是无障碍审计工具，但它是阻止无障碍回归在两次审计之间被忽视的工具。
免费起步。 Delta-QA 的 Desktop 版本免费，没有截图次数限制，也没有试用期。对于一家想在 EHR（Electronic Health Record）或患者门户上评估视觉测试的医院或诊所，无需启动采购流程。在做出任何预算决定之前，您都可以在真实环境条件下测试该工具。
需要注意的局限
视觉测试，即使是本地部署的，在医疗领域也不是万能方案。
它不测试业务逻辑。 视觉测试验证显示是否正确，而不是被显示的数据是否正确。如果您的剂量计算算法返回了一个错误值，视觉测试只有在那个错误改变了界面外观相对于参考图时才会检测到。一个产生视觉上看似合理结果的不正确计算会被忽视。功能测试和单元测试仍然不可或缺。
Delta-QA 不集成进云端 CI/CD 流水线。 如果您的组织已经投入到一条云托管的持续集成流水线，并希望每次 merge request 都自动触发视觉测试，那么 Delta-QA 不是为这种工作流设计的。它是一款桌面工具，为辅助手动测试和结构化测试活动而生。对于医疗组织，这种方式往往比完全自动化更现实，但仍是一个根据您 DevOps 成熟度需要评估的局限。
它不覆盖所有无障碍方面。 视觉测试检测视觉上的无障碍回归，而不是结构性问题。一台无法导航您表单的屏幕阅读器（因为 ARIA 角色配置错误）不会被视觉测试检测到。需要使用专门工具（axe、WAVE、Lighthouse）做完整的无障碍审计仍然必要。
覆盖度取决于您的场景。 视觉测试只测试您定义为测试场景的屏幕。如果一条关键的患者路径没有包含在您的场景中，那条路径上的视觉回归就不会被检测到。您的视觉测试覆盖的质量取决于您场景选择的质量。
常见问题
患者门户的截图在 HIPAA 下是 PHI 吗？
是的，如果它们包含 HIPAA 定义的18项标识符之一：姓名、出生日期、地址、社会安全号、病历编号或任何其他能识别患者的信息。一张展示姓名和化验结果的患者控制面板截图就是电子 PHI，受到与患者记录本身相同的保护要求。
在法国，SaaS 视觉测试工具必须有 HDS 认证吗？
如果工具接收并存储含个人健康数据的截图，即便是临时的，它就在扮演该数据的托管者。此时 HDS 认证就是必需的。在实际操作中，很少有 SaaS 视觉测试工具获得 HDS 认证——这不是它们的核心业务。这就是为什么本地部署方式——消除对第三方认证的依赖——在合规上结构性地更简单。
视觉测试如何帮助医疗界面的无障碍？
视觉测试检测视觉无障碍回归：文本对比度跌破 WCAG 2.1 比率（普通文本4.5:1、大字体3:1）、可点击区域尺寸缩小、可见 focus 消失、字号变化。对老年或视障患者来说，这些回归可能让界面变得无法使用。视觉测试不取代完整的 RGAA/WCAG 审计，但它能在两次审计之间阻止退化。
在 EHR 上搭建视觉测试需要多长时间？
使用 Delta-QA，初始搭建根据您 EHR 的复杂度需要1到3天。第一天确定关键路径（患者记录查阅、处方、化验结果、预约）。第二天创建测试场景和参考截图。第三天，如有需要，调整灵敏度阈值并培训 QA 团队。无需开发技能。
视觉测试能检测药物剂量显示错误吗？
视觉测试检测相对参考的显示变化。如果剂量在参考版本中正确显示（例如"500 mg"），而一次 CSS 更新修改了显示（例如截断为"500"丢失单位，或重新格式化为"5.00 mg"），视觉测试会检测到这一变化。然而，如果显示的剂量自参考版本以来就一直不正确（后端错误），视觉测试不会检测到——那是功能测试的职责。
医疗预发布数据的匿名化与假名化有什么区别？
匿名化使得即使有附加信息也无法识别一个人。它是一个不可逆过程。假名化用伪名替换直接标识符（姓名、社会安全号），但通过对应表仍可识别。GDPR 不适用于真正匿名化的数据，但适用于假名化数据。在实际操作中，对医疗数据完美匿名化是极难保证的，这进一步加强了本地部署的论据：如果您不能确定您的预发布数据完美匿名化，就别把它发到外面。
结语
医疗领域的视觉测试不是审美完美主义的问题。它是一个关于患者安全、监管合规和信任的问题。
医疗界面显示着存在的最敏感数据：患者的健康数据。这些界面的每一张截图都是一份可能受 HIPAA、HDS 认证和 GDPR 约束的文件。每一次将这些截图传输至第三方云端都是一个可衡量的监管风险。
本地部署方式不是妥协。它是从结构上消除未授权健康数据传输风险的唯一方式。借助 Delta-QA 这样的工具，这种方式既不需要可观预算、也不需要开发技能、更不需要专门基础设施。
您的患者把他们最私密的数据托付给您。您的测试截图理应得到同等水平的保护。