当前位置：首页 > news >正文

Axe-core 集成指南：为 Puppeteer/Playwright 自动化测试添加无障碍检测

news 2026/7/8 16:51:04

1. 项目概述：为什么要在自动化测试中集成无障碍测试？

如果你正在用 Puppeteer 或 Playwright 做自动化测试，可能已经习惯了检查页面加载、点击按钮、验证文本这些常规操作。但你是否考虑过，你的网站或应用对于使用屏幕阅读器的视障用户、只能使用键盘操作的运动障碍用户是否友好？这就是无障碍测试（Accessibility Testing，常缩写为 a11y）要解决的问题。过去，无障碍测试往往依赖人工审查或独立的扫描工具，与开发流程脱节，问题发现晚、修复成本高。而将 Axe-core 这类引擎集成到你的自动化测试流水线中，意味着每次代码提交后，都能自动发现并报告无障碍合规性问题，将“可访问性”真正变成一项可度量、可回归的工程标准。

Axe-core 是由 Deque Systems 开发的开源无障碍测试规则库，它不是一个完整的测试工具，而是一个引擎。它的强大之处在于其基于 WCAG（Web Content Accessibility Guidelines）标准、Section 508 等法规的规则集，能精准识别出真实的、可操作的无障碍缺陷，同时将“需要人工审查”的项清晰标出，误报率相对较低。把它和 Puppeteer、Playwright 这类现代浏览器自动化工具结合，相当于给你的自动化测试套件装上了一双“发现无障碍问题的眼睛”。

我经历过从零开始搭建这套流程的整个过程，也踩过不少坑。比如，早期以为集成就是跑个脚本，结果发现报告看不懂、问题优先级分不清，集成后测试时间大幅增加却收效甚微。本文将分享如何高效、实用地将 Axe-core 集成到 Puppeteer 和 Playwright 项目中，不仅告诉你“怎么做”，更会深入解释“为什么这么做”，以及如何根据项目实际情况调整策略，让它真正为你的产品和团队创造价值，而不是沦为一份没人看的冗长报告。

2. 核心工具选型与集成原理深度解析

在开始动手之前，我们需要理清几个核心概念和工具之间的关系。很多人混淆了 Axe-core、axe-playwright、axe-puppeteer 以及更上层的测试运行器（如 Jest、Mocha）。理解它们的层次，是成功集成的第一步。

2.1 Axe-core：规则引擎，而非测试运行器

Axe-core 是一个 JavaScript 库，其核心是一系列测试规则（如“图片必须有 alt 文本”、“表单输入必须有关联的 label”）。它需要在一个浏览器环境中运行，因为许多无障碍问题（如焦点管理、ARIA 属性动态更新）必须通过真实的 DOM 和计算样式来检测。它本身不包含启动浏览器、导航页面或管理测试生命周期（如 before/after hooks）的功能。它只做一件事：给定一个 DOM 节点（通常是 document），运行所有规则，返回一个结果对象。

2.2 桥梁库：axe-puppeteer 与 axe-playwright

由于 Axe-core 需要注入到页面上下文中执行，直接使用稍显繁琐。因此，社区提供了官方的桥梁库（bridge libraries）：

axe-puppeteer: 为 Puppeteer 提供了AxePuppeteer类，封装了将 Axe-core 脚本注入 Page 对象并执行分析的过程。
axe-playwright: 为 Playwright 提供了类似的AxeBuilder类，但请注意，Playwright 的集成更现代，通常推荐使用@axe-core/playwright这个包。

这些桥梁库简化了调用，但它们仍然是“执行器”。测试的结构、断言和报告生成，需要依赖你已有的测试框架。

2.3 测试运行器：Jest、Mocha、Vitest 等

这是你组织测试用例、管理断言和生成测试报告的地方。例如，你可能会用describe和it块来组织测试。集成 Axe-core 的本质，就是在你的某个it(‘should be accessible’, …)测试用例中，调用axe-puppeteer或axe-playwright提供的方法来运行分析，然后使用测试运行器的断言库（如expect）来验证结果。

为什么选择 Playwright 或 Puppeteer？

Puppeteer: 直接控制 Chrome/Chromium，API 简洁，在纯 Chromium 项目和无障碍测试的保真度上表现优异。如果你的项目只面向 Chrome 系浏览器，它是轻量级的选择。
Playwright: 支持 Chromium、Firefox 和 WebKit，能进行跨浏览器无障碍测试（这一点很重要，因为某些无障碍特性或 bug 可能因浏览器而异）。其强大的上下文隔离、自动等待机制和更丰富的 API，使得编写稳定、复杂的无障碍测试场景更容易。对于现代前端项目，我通常更推荐 Playwright。

注意：不要试图在同一个测试项目中同时深度集成 Puppeteer 和 Playwright 来运行 Axe-core，这会让依赖管理和测试配置变得异常复杂。根据你的主要浏览器兼容性要求，选择其一即可。

2.4 集成的基本工作流原理

无论选择哪个工具，集成的核心工作流是相似的：

启动浏览器并创建页面：使用 Puppeteer 的puppeteer.launch()或 Playwright 的chromium.launch()。
导航到待测页面：使用page.goto(url)。
注入并配置 Axe-core：通过桥梁库，将 Axe-core 的源代码注入到页面上下文中。
运行分析：针对整个页面或某个特定元素运行无障碍规则。
获取并断言结果：分析返回一个包含violations（违规）、incomplete（未完成，需人工检查）、passes（通过）等属性的对象。你的测试将断言violations数组为空，或符合预期的阈值。
生成报告：如果测试失败，需要将违规信息以人类可读的格式（如控制台输出、HTML 文件、JSON 文件）输出，方便开发者定位问题。

理解了这些层次和原理，我们就能避免“盲目照搬配置”，而是根据项目需求进行定制。

3. 环境搭建与基础集成实战

理论清晰后，我们进入实战环节。我将分别演示在 Puppeteer 和 Playwright 项目中，从零开始集成 Axe-core 的完整步骤。假设你的项目已经初始化（npm init -y），我们将使用 Jest 作为测试运行器，因为它与这两种工具都有良好的集成生态。

3.1 方案一：在 Puppeteer + Jest 环境中集成

首先，安装必要的依赖：

npm install --save-dev puppeteer axe-core axe-puppeteer jest jest-puppeteer

puppeteer: 浏览器自动化本体。
axe-core: 无障碍测试规则引擎。
axe-puppeteer: 连接 Puppeteer 和 Axe-core 的桥梁。
jest: 测试框架。
jest-puppeteer: Jest 插件，简化 Puppeteer 的生命周期管理（可选，但推荐）。

步骤 1：配置 Jest在项目根目录创建或修改jest.config.js：

module.exports = { preset: 'jest-puppeteer', testMatch: ['**/__tests__/**/*.test.js'], setupFilesAfterEnv: ['<rootDir>/jest.setup.js'], // 用于全局配置 };

步骤 2：创建全局设置文件创建jest.setup.js。这里我们配置一个全局的page对象，并注入 Axe-core 的辅助函数：

const { configureToMatchImageSnapshot } = require('jest-image-snapshot'); const toMatchImageSnapshot = configureToMatchImageSnapshot({ failureThreshold: 0.01, failureThresholdType: 'percent', }); expect.extend({ toMatchImageSnapshot }); // 全局注入 axe-core 运行函数 async function runAxeAnalysis(page, context, options) { const { AxePuppeteer } = require('axe-puppeteer'); const axe = new AxePuppeteer(page); if (context) axe.include(context); if (options) axe.options(options); return await axe.analyze(); } global.runAxeAnalysis = runAxeAnalysis;

步骤 3：编写你的第一个无障碍测试创建__tests__/accessibility.test.js：

describe('首页无障碍测试', () => { beforeAll(async () => { // jest-puppeteer 会自动管理 browser 和 page await page.goto('http://localhost:3000'); // 替换为你的应用地址 // 等待关键内容加载，这是减少误报的关键！ await page.waitForSelector('#main-content'); }); it('应不存在任何 WCAG 2.1 AA 级别的违规', async () => { // 使用全局注入的函数运行分析 const results = await runAxeAnalysis(page); // 断言 violations 数组为空 expect(results.violations).toHaveLength(0); // 如果测试失败，将违规信息友好地打印出来，这是调试的关键 if (results.violations.length > 0) { console.log( `发现 ${results.violations.length} 个无障碍违规：`, JSON.stringify(results.violations, null, 2) ); } }); it('主导航区域应无障碍', async () => { // 只测试页面的特定部分，提高测试效率和针对性 const navSelector = 'nav[role="navigation"]'; await page.waitForSelector(navSelector); const results = await runAxeAnalysis(page, navSelector); expect(results.violations).toHaveLength(0); }); });

步骤 4：运行测试在package.json中添加脚本：

"scripts": { "test:a11y": "jest __tests__/accessibility.test.js" }

然后运行npm run test:a11y。Jest 会启动浏览器，打开页面，执行 Axe-core 分析，并根据断言输出结果。

实操心得：在beforeAll或测试用例开头使用page.waitForSelector等待动态内容加载完成至关重要。Axe-core 分析的是当前的 DOM 快照，如果组件还在加载或异步数据未填充，会导致分析结果不准确，误报“缺少文本标签”等问题。

3.2 方案二：在 Playwright + Jest 环境中集成

Playwright 的集成更为现代和强大。首先安装依赖：

npm install --save-dev @playwright/test axe-core @axe-core/playwright

注意，这里我们使用@playwright/test这个官方测试运行器，它比 Jest + Playwright 组合更原生、功能更集成。

步骤 1：配置 Playwright Test运行npx playwright install安装浏览器。然后创建或修改playwright.config.ts(或.js)：

// playwright.config.js const { defineConfig, devices } = require('@playwright/test'); module.exports = defineConfig({ testDir: './tests', // 测试文件目录 fullyParallel: true, forbidOnly: !!process.env.CI, retries: process.env.CI ? 2 : 0, workers: process.env.CI ? 1 : undefined, reporter: 'html', use: { baseURL: 'http://localhost:3000', // 设置基础URL trace: 'on-first-retry', screenshot: 'only-on-failure', }, projects: [ { name: 'chromium', use: { ...devices['Desktop Chrome'] }, }, // 可以添加 firefox 和 webkit 项目进行跨浏览器无障碍测试 ], });

步骤 2：创建自定义 Fixture 和 Expect 断言Playwright Test 的核心概念是 Fixture 和自定义 Expect。我们创建一个文件来扩展它们，以便在所有测试中方便地使用 Axe-core。

创建tests/a11y-fixture.js：

const { test: baseTest, expect } = require('@playwright/test'); const AxeBuilder = require('@axe-core/playwright').default; // 扩展基础的 test fixture，注入 axeBuilder const test = baseTest.extend({ makeAxeBuilder: async ({ page }, use) => { const makeBuilder = () => new AxeBuilder({ page }); await use(makeBuilder); }, }); // 扩展 expect，添加自定义的无障碍断言 expect.extend({ // 自定义断言：toBeAccessible async toBeAccessible(page, builder, options = {}) { const { violations, incomplete, passes } = await builder.analyze(); const { maxViolations = 0, rules } = options; let filteredViolations = violations; if (rules) { filteredViolations = violations.filter(v => rules.includes(v.id)); } if (filteredViolations.length > maxViolations) { const violationsMessage = filteredViolations .map(v => `\n规则 [${v.id}]: ${v.help}\n影响元素: ${v.nodes.map(n => n.target).join(', ')}\n帮助链接: ${v.helpUrl}`) .join('\n---\n'); return { pass: false, message: () => `预期无障碍违规不超过 ${maxViolations} 个，但实际发现 ${filteredViolations.length} 个。${violationsMessage}`, }; } return { pass: true, message: () => `无障碍测试通过（违规数：${filteredViolations.length}， 未完成项：${incomplete.length}）`, }; }, }); module.exports = { test, expect };

步骤 3：编写 Playwright 无障碍测试创建tests/homepage.a11y.spec.js：

const { test, expect } = require('./a11y-fixture'); test.describe('首页无障碍测试 (Playwright)', () => { test('整个页面应满足 WCAG 2.1 AA 标准', async ({ page, makeAxeBuilder }) => { await page.goto('/'); // 使用 config 中配置的 baseURL await page.waitForLoadState('networkidle'); // 等待网络空闲 const accessibilityScanResults = await makeAxeBuilder() .withTags(['wcag2a', 'wcag2aa', 'wcag21a', 'wcag21aa']) // 指定标准 .analyze(); // 使用自定义断言 await expect(page, makeAxeBuilder()).toBeAccessible({ maxViolations: 0 }); }); test('登录表单应无障碍', async ({ page, makeAxeBuilder }) => { await page.goto('/login'); const form = page.locator('form#login-form'); await expect(form).toBeVisible(); // 针对特定元素进行分析 const builder = makeAxeBuilder().include(form); await expect(page, builder).toBeAccessible({ maxViolations: 0 }); }); test('允许存在已知的、低优先级的违规', async ({ page, makeAxeBuilder }) => { await page.goto('/some-page'); // 假设我们已知“color-contrast”规则在此页面有1处非关键性问题，且短期内不修复 await expect(page, makeAxeBuilder()).toBeAccessible({ maxViolations: 1, rules: ['color-contrast'], // 只检查特定规则 }); }); });

步骤 4：运行测试在package.json中添加脚本：

"scripts": { "test:a11y:pw": "playwright test --grep \"a11y\" --reporter=html" }

运行npm run test:a11y:pw。--grep \"a11y\"只运行包含 “a11y” 标签的测试。测试完成后，会生成一个 HTML 报告，其中包含详细的测试结果和截图，对于无障碍违规，报告会清晰列出问题元素、违反的规则和修复建议。

实操心得：Playwright 的locatorAPI 和自动等待机制，使得定位动态元素并确保其在分析前完全渲染变得非常可靠，这能极大减少因时机问题导致的无障碍误报。自定义 Fixture 和 Expect 断言将测试逻辑封装得极其简洁，是更优雅的集成模式。

4. 高级配置、规则定制与性能优化

基础集成跑通后，你会发现可能面临报告冗长、测试缓慢、规则不符合项目实际等问题。接下来，我们深入高级配置，让无障碍测试更智能、更高效。

4.1 理解与配置 Axe-core 规则

Axe-core 的规则有不同的类型和严重性：

violations: 确定性的失败，必须修复。
incomplete: 无法自动判断，需要人工审查。
passes: 通过的检查项。
inapplicable: 不适用于当前页面的规则。

你可以通过.withTags()和.withRules()方法来精细控制检查范围。

常用标签（Tags）:

wcag2a: WCAG 2.0 A 级成功标准。
wcag2aa: WCAG 2.0 AA 级成功标准（最常用，也是法律合规常要求的级别）。
wcag21a,wcag21aa: WCAG 2.1 版本的标准。
section508: 美国 Section 508 法规。
best-practice: 社区最佳实践。

示例：针对性配置

// 只检查 WCAG 2.1 AA 和最佳实践 const builder = new AxeBuilder({ page }) .withTags(['wcag21aa', 'best-practice']) .disableRules(['region']) // 禁用“页面应包含地标区域”这条规则，如果你的项目结构特殊 .options({ runOnly: { type: 'tag', values: ['wcag21aa'], }, // 设置规则的具体检查参数 rules: { 'color-contrast': { enabled: true }, 'link-name': { enabled: false }, // 完全禁用某条规则 }, });

为什么需要定制规则？不是所有 Axe-core 规则都适用于所有项目。例如，一个内部管理后台，可能对“页面必须有主标题（page-has-heading-one）”的要求可以放宽。或者，你的设计系统确保了足够的颜色对比度，但 Axe-core 在计算某些渐变或复杂覆盖层时可能误报。这时，选择性禁用或配置规则，可以让测试聚焦于真正重要的问题。

4.2 测试范围控制：页面、组件与上下文

全页面扫描固然全面，但耗时且容易产生“噪音”。更佳实践是分层测试：

全局页面扫描：针对关键页面（如首页、核心流程页）进行，确保整体框架无障碍。

组件级扫描：针对可复用的 UI 组件（如模态框、下拉菜单、导航栏）。这在组件驱动开发（如 React、Vue）中尤其有效。你可以将组件渲染到测试容器中，然后针对该容器 DOM 节点运行 Axe-core。

// 以 Playwright + React 测试为例 test('Modal 组件应无障碍', async ({ page }) => { await page.goto('/storybook/iframe.html?id=modal--default'); // 访问 Storybook const modal = page.locator('[data-testid="modal-root"]'); const results = await new AxeBuilder({ page }).include(modal).analyze(); expect(results.violations).toEqual([]); });

动态上下文测试：测试交互后的状态。例如，打开一个下拉菜单后，检查菜单项是否可以通过键盘访问。

test('下拉菜单交互后应保持无障碍', async ({ page }) => { await page.goto('/page-with-dropdown'); const trigger = page.locator('button[aria-haspopup="true"]'); await trigger.click(); const menu = page.locator('ul[role="menu"]'); await expect(menu).toBeVisible(); // 在菜单打开的状态下进行分析 const results = await new AxeBuilder({ page }).include(menu).analyze(); expect(results.violations).toEqual([]); });

4.3 性能优化策略

无障碍测试会增加测试套件的执行时间。以下策略可以优化：

并行执行：利用 Jest 的--maxWorkers或 Playwright 的fullyParallel: true并行运行测试。
选择性运行：在 CI/CD 流水线中，可以将无障碍测试作为独立的流水线阶段，或只针对变更的文件关联的页面运行。可以使用--grep或自定义标签。
缓存与快照：对于静态内容页面，可以考虑将 Axe-core 的分析结果（passes部分）进行快照测试。只有当violations或incomplete发生变化时才报错，但这需要谨慎设计，因为 DOM 的微小变化可能导致大量规则重算。
分阶段集成：
- 阶段一（警告）：将测试配置为只报告而不阻塞构建（maxViolations设一个较高的值），让团队先了解问题规模。
- 阶段二（逐步收紧）：每周或每迭代降低maxViolations阈值，推动问题修复。
- 阶段三（零容忍）：最终目标设为maxViolations: 0，并集成到 PR 检查中，阻止新的违规合入。

4.4 生成可操作的报告

控制台输出 JSON 对开发者不友好。我们需要生成易于阅读和分享的报告。

使用axe-reporter等工具：可以安装axe-html-reporter等包，在测试失败时生成 HTML 报告。

const { createHtmlReport } = require('axe-html-reporter'); const fs = require('fs'); // 在测试失败后的 afterEach 或 afterAll 钩子中 if (results.violations.length > 0) { const htmlReport = createHtmlReport({ results, options: { projectKey: 'MyProject', doNotCreateReportFile: false, outputDir: './a11y-reports', }, }); fs.writeFileSync(`./a11y-reports/report-${Date.now()}.html`, htmlReport); }

集成到 CI/CD 可视化平台：一些 CI/CD 平台（如 GitHub Actions, GitLab CI）支持上传测试结果文件（如 JUnit 格式）。可以将 Axe-core 的violations转换为 JUnit XML 格式，这样违规就会在 CI 的测试结果面板中显示为失败的测试用例，并提供链接查看详情。

5. 常见问题排查与实战避坑指南

即使配置正确，在实际运行中你也会遇到各种问题。以下是我在实践中总结的常见坑点及解决方案。

5.1 问题：测试不稳定，时而过时而不通过

可能原因与排查：

动态内容未加载完成：这是最常见的原因。Axe-core 分析的是调用瞬间的 DOM。如果数据是通过异步请求加载的，或者组件有动画过渡，分析可能发生在内容更新之前。
- 解决：在运行analyze()前，使用更精确的等待条件。Playwright 的page.waitForLoadState(‘networkidle’)或locator.waitFor()是更好的选择，而不是固定的page.waitForTimeout。
```
// 好：等待特定元素出现 await page.waitForSelector(‘[data-testid=“loaded-indicator”]’); // 更好：等待某个元素处于稳定状态 await expect(page.locator(‘.data-list’)).toHaveCount(10); // 等待列表项加载完毕
```
Shadow DOM 或 iframe 内容未被分析：Axe-core 默认只分析主文档的 DOM。Shadow DOM 和 iframe 内的内容需要显式包含。
- 解决：使用.include(‘#shadow-root-host’)或切换到 iframe 上下文。
```
// 处理 iframe const frame = page.frame({ name: ‘my-iframe’ }); const results = await new AxeBuilder({ page: frame }).analyze(); // Shadow DOM 处理更复杂，可能需要先获取 shadowRoot 的引用
```
浏览器扩展或开发者工具干扰：某些浏览器扩展会修改 DOM 或注入样式，影响分析结果。
- 解决：在启动浏览器时使用无痕模式或禁用扩展。
```
// Puppeteer const browser = await puppeteer.launch({ headless: ‘new’, args: [‘—incognito’] }); // Playwright const context = await browser.newContext({ viewport: null });
```

5.2 问题：报告中的违规项看不懂，不知道如何修复

排查与行动：

利用help和helpUrl：Axe-core 结果中每个违规项都包含help（简短描述）和helpUrl（指向详细规则和修复方案的链接）。这是第一手资料。
审查nodes属性：每个违规项都有一个nodes数组，列出了页面上所有违反此规则的元素及其选择器（target）。在浏览器开发者工具中使用这些选择器定位元素。
使用浏览器扩展辅助：安装 “Axe DevTools” 浏览器扩展。在手动测试时，它可以实时高亮出问题元素，并提供交互式的修复指导，这比看 JSON 报告直观得多。
优先处理高影响问题：并非所有违规都同等重要。优先处理：
- 阻断性错误：导致键盘无法操作、屏幕阅读器无法读取内容的问题（如keyboard,aria相关规则）。
- WCAG A 级违规：这是最基本的要求，不满足会导致部分用户完全无法使用。
- 高频出现的问题：同一个问题在多个页面出现，修复它性价比最高。

5.3 问题：测试运行太慢，拖慢了 CI/CD 流程

优化策略：

减少扫描范围：如前所述，使用.include()只扫描关键区域，而非整个页面。
限制规则集：初期可以只启用wcag2aa标签，甚至只启用wcag2a。或者通过.disableRules()禁用那些对你项目不重要的规则（如meta-viewport对于非响应式管理后台可能不重要）。
在 CI 中复用浏览器实例：避免每个测试文件都启动和关闭浏览器。Jest-Puppeteer 的 preset 和 Playwright Test 的全局配置已经在这方面做了优化。
考虑抽样测试：对于大型应用，不必每个页面都测试。可以定义一套“核心用户旅程”页面（如注册、登录、核心功能操作流）进行全覆盖测试，对其他页面进行定期（如每周）的抽样扫描。

5.4 问题：如何处理“incomplete”（未完成）项

incomplete结果意味着 Axe-core 无法自动判断规则是否通过，需要人工审查。常见于：

颜色对比度：对于复杂的背景图、渐变、CSS 混合模式，工具可能无法准确计算。
自定义交互组件：一些复杂的、非标准的 ARIA 组件，其键盘交互和焦点管理逻辑需要人工验证。
动态内容：内容变化过快，工具无法捕捉稳定状态。

处理流程：

审查列表：定期（如每个冲刺）查看incomplete项的报告。
手动测试：对于列出的元素，使用键盘 Tab 键导航和屏幕阅读器（如 NVDA、VoiceOver）进行手动测试。
标记为“已审查”：如果确认没问题，可以在测试配置中通过.options()或自定义逻辑忽略该元素/规则的incomplete结果。但务必记录审查结论。
如果发现问题：则将其转为需要修复的工单。你可以通过自定义断言，将特定的、已知的incomplete项设置为允许，直到它们被修复。

5.5 与组件库和设计系统的协作

这是将无障碍测试落到实处的关键。如果你们的 UI 组件库（如 Material-UI, Ant Design, 或自研组件库）本身已经内置了较好的无障碍支持，那么应用层的测试负担会大大减轻。

推动策略：

在组件库中集成 Axe-core 测试：为每个基础组件（Button、Modal、Select 等）编写无障碍单元测试。确保从源头保障无障碍性。
建立设计系统无障碍规范：与设计师合作，在设计阶段就约定颜色对比度、焦点状态样式、交互反馈等规范。使用 Figma 等工具的插件（如 Stark, Able）进行设计稿的无障碍检查。
教育开发者：在 PR 模板中添加无障碍检查清单，鼓励开发者在提交代码前，使用浏览器扩展快速自查。

将 Axe-core 集成到自动化测试中，不是一个一劳永逸的配置工作，而是一个需要持续优化、与团队流程紧密结合的工程实践。从配置基础测试，到定制规则、优化性能，再到处理复杂场景和推动团队协作，每一步都需要根据项目实际情况做出判断。我的体会是，起步时宁可范围小、规则松，先让流程跑起来并产生可见的价值（哪怕是暴露出大量问题），再逐步收紧标准、扩大范围，这样阻力更小，也更容易获得团队的支持。最终目标不是一份完美的测试报告，而是让创造无障碍的产品，成为团队开发习惯的一部分。

查看全文

http://www.jsqmd.com/news/1148893/