干货 | 告别人工测试困局，携程 BDD 驱动的自动化测试落地与效能跃迁-优快云博客

作者简介

飞阳，携程前端开发专家，专注高性能、用户友好的前端应用，关注效率工具与新技术探索。

昶宜，携程前端开发专家，致力于提供高效便捷的工具提高研发和测试效率。

泽恒，携程资深测试开发工程师，专注测试质量，致力于测试效率提升。

导读：在软件测试领域，如何提升测试效率、降低研发成本并保障测试质量一直是亟待解决的问题。本文从人工测试向自动化测试转型的实践，详细阐述基于Jest的自动化测试在人工编写测试case到通过BDD（基于行为驱动开发）生成测试case的完整解决方案，以及在实施过程中遇到的挑战和取得的成果。

一、概述
二、背景与现状：从人工测试到 HTA 的转型困境
2.1 人工测试阶段的痛点
2.2 什么是基于HTA的自动化测试？
2.3 HTA自动化现阶段的瓶颈
三、BDD生成HTA的核心目标
3.1 覆盖率提升
3.2 成本优化
3.3 发布效率提升
四、技术方案：BDD 驱动的 HTA 自动化体系构建
4.1 BDD 用例规范：从模糊描述到精准定义
4.2 自动化生成 HTA：从人工编写到BDD生成
4.3 Mock 数据管理：持久化存储管理和维护更新
4.4 测试用例平台：可视化调试验证步骤
五、实施成果：效率与质量的双重提升
5.1 景点玩乐-活动填写页治理案例
5.2 项目周期对比
六、发布流程重构：自动化驱动的质量门禁
七、未来规划
7.1 Mock 数据自动化采集录入
7.2 测试用例平台可视化调试接入标准流水线
八、总结：自动化测试的演进之路

一、概述

文章将探讨某项目从人工测试转型为自动化测试的过程，重点介绍BDD和HTA（Headless TA）相结合的测试体系优化方案。在提高测试效率、降低研发成本以及确保测试覆盖率方面，将深入分析通过自动化测试实现的优势，并展示在实际实施过程中遇到的挑战及解决方案。通过实践案例，总结该方案在提升软件质量、缩短测试周期及提高开发效率方面取得的成效，为其他项目提供有益的参考和借鉴。

二、背景与现状：从人工测试到 HTA 的转型困境

2.1 人工测试阶段的痛点

覆盖率低且不稳定

在软件测试领域，测试人员的资源紧张常常导致无法全面覆盖所有测试场景。尤其是依赖人工测试时，由于人员有限且容易受到人为测试经验的影响，往往会导致一些潜在的线上问题被遗漏，进而影响产品质量。随着项目的复杂性增加，单纯依靠人工测试已无法满足高效、全方位的质量保障需求。

因此，转向自动化测试成为了解决这一问题的关键。自动化测试不仅能够提高测试效率，还能在更大程度上降低研发成本，确保测试过程的准确性与可重复性，从而减少人工测试中的错误和疏漏。通过实施自动化测试提升整体测试的有效性和质量保障能力。

用例管理混乱

由于测试工作主要依赖人工回归测试，测试用例的依赖性逐渐削弱，许多测试场景往往只存在于测试人员的记忆中。这种做法长期以来会导致测试用例的覆盖性逐渐变差，甚至一些关键的场景可能被忽略。此外，随着时间的推移，测试用例的描述变得模糊不清，无法清晰表达预期的行为和结果。

这种情况下，研发与测试人员之间的理解往往出现歧义，导致测试执行时的沟通成本和错误率显著增加。由于没有清晰、标准化的测试文档，执行测试时的效率也大大降低。测试人员需要花费更多时间在理解和验证测试用例上，而不是关注更高价值的测试活动。

这种低效的回归测试方式不仅影响了产品质量的保障，还使得团队在面对复杂的项目时，无法有效应对快速迭代和高频更新的挑战。因此，为了提升测试覆盖率和质量，减少沟通误差，提高执行效率，迫切需要实现测试的标准化、自动化和系统化。

2.2 什么是基于HTA的自动化测试

一种使用 Jest 测试框架来执行自动化单元测试和集成测试的实践。Jest 是一个由 Facebook 开发的 JavaScript 测试框架，广泛用于 React 和 Node.js 应用的测试。它提供了简单的 API，支持自动化运行测试，生成测试报告，以及对代码进行验证。

它有以下特点：

简单易用： Jest 提供了简洁的 API，易于上手，适合快速编写和执行测试用例。
自动化执行：测试可以通过命令行自动运行，支持测试用例的自动化执行和结果输出，减少了手动测试的工作量。
快照测试（Snapshot Testing）： Jest 提供快照测试功能，可以对组件渲染结果、API 输出等进行快照保存，并与后续的运行结果进行对比，帮助检测 UI 变动和输出差异。
内置断言： Jest 提供了一组强大的断言方法，如 toBe(), toEqual(), toHaveBeenCalled() 等，用于验证代码执行的正确性。
并行测试： Jest 支持并行执行多个测试，提高测试速度，尤其适用于大型项目和复杂测试场景。
集成持续集成工具： Jest 可以很容易地与持续集成（CI）工具集成，如 Jenkins、Travis CI 和 GitHub Actions，帮助实现自动化的回归测试和持续测试。
广泛的社区支持： Jest 拥有活跃的开发社区和丰富的插件生态，可以方便地进行扩展，适应不同项目的需求。

2.3 HTA自动化现阶段的瓶颈

覆盖缺口明显：依赖人工编写case，代码行覆盖和分支覆盖较难达标（行覆盖90%，分支覆盖70%）。

在测试过程中，覆盖率是衡量测试质量的重要指标，尤其是代码行覆盖率和分支覆盖率。由于过度依赖人工编写测试用例，测试的覆盖性和全面性往往存在显著缺口。特别是在复杂的业务逻辑和多分支的代码中，人工编写测试用例在实现Jest测试代码的过程中往往会夹杂自身的理解导致很难做到每一行代码和每一种可能的执行路径都得到充分验证。

具体来说，代码行覆盖率通常指测试过程中执行到的代码行数与总行数的比例。尽管可以通过手动编写大量测试用例来增加覆盖率，但由于测试用例的编写依赖人工，往往只能覆盖一些明显的、常规的代码路径。而对于一些边界条件、特殊输入或异常处理路径，往往容易遗漏，导致行覆盖率难以达到理想的水平（如 90%）。

分支覆盖率则是衡量测试中每个条件分支是否都被执行过的指标。由于软件中的许多代码包含大量的条件判断，人工编写测试用例很难确保每一种可能的分支都经过验证。特别是当代码中有多个条件组合时，可能只会覆盖到某些常见的分支路径，而忽略了其他不常见的组合路径，从而导致分支覆盖率较低（如 70%）。

这种覆盖缺口的存在，意味着许多潜在的错误和缺陷未能在测试阶段被及时发现，尤其是那些难以触发的边界条件和复杂的分支路径。随着软件功能的不断扩展和复杂性的增加，单靠人工编写测试用例已经很难保证全面的覆盖率。为了提高代码质量，降低风险，必须采取更加系统化和自动化的测试方法，来弥补人工编写测试用例中的不足，确保更高的行覆盖率和分支覆盖率，从而提升软件的稳定性和可靠性。

研发成本激增：HTA 编写效率仅 2-3 条 / 小时，占研发成本 25%

在软件开发和测试过程中，开发团队通常需要面对如何平衡效率与质量的问题。随着系统复杂度的增加，研发人员的工作负担也随之增加，尤其是在自动化测试框架的开发和维护方面。例如，基于 HTA 的自动化测试，虽然具有很强的灵活性和扩展性，但其编写效率相对较低，通常每小时只能编写 2 到 3 条测试用例。这意味着，测试人员需要投入大量时间和精力来编写和维护自动化测试脚本，尤其是在面对复杂的应用场景时。

这种低效率的测试脚本编写会对整体研发成本产生显著影响。测试团队不仅需要消耗大量时间编写测试用例，还需要不断进行测试脚本的更新和维护，以保证测试框架与开发代码同步。当系统功能不断扩展时，工作量也会成倍增加，导致测试工作的成本大幅攀升。根据估算，这种自动化测试工作占据了研发成本的 25%左右，成为开发过程中不可忽视的开销。

这种高成本的现象有几个原因：

测试用例多：根据调研，一个10人日的研发项目，测试用例一般在20至30条。
维护压力：由于测试框架要不断适应快速发展的代码库，测试脚本的维护成为了一个持久性的问题。在每次代码更新后，自动化测试脚本需要及时修正和调整，以保持与开发代码的同步，否则就可能错失对潜在问题的验证。
测试场景的复杂性：对于大型系统，尤其是包含多个模块、接口和平台的应用，测试场景繁多且复杂。这使得手动编写测试用例变得更加耗时。需要开发人员深入分析和编写。

本文结合以上测试痛点，提出BDD生成HTA的自动化测试方案。

三、BDD生成HTA的核心目标

目标维度	现状指标	优化目标	核心价值
覆盖率	行覆盖 50% 分支覆盖 50%	行覆盖 90% 分支覆盖 70%	降低生产漏测风险
成本优化	研发成本 25%	研发成本 5%	释放研发资源聚焦核心功能
效率提升	手工测试比例 20%	手工测试比例 2%	缩短发布周期至 14 天内

目标维度

现状指标

优化目标

核心价值

覆盖率

行覆盖 50%

分支覆盖 50%

行覆盖 90%

分支覆盖 70%

降低生产漏测风险

成本优化

研发成本 25%

研发成本 5%

释放研发资源聚焦核心功能

效率提升

手工测试比例 20%

手工测试比例 2%

缩短发布周期至 14 天内

3.1 覆盖率提升

通过缩短测试case与实际生成HTA差异，来降低理解歧义，提升覆盖率。

3.2 成本优化

通过BDD语法生成HTA，释放研发在此前HTA方案中编写case的成本。

通过将部分人工测试的case转化为HTA生成的case和UI自动化case，降低人工测试成本。

3.3 发布效率提升

通过降低编写HTA的成本和人工测试的成本，缩短测试时间，提升整体的测试效率，缩短项目周期。

四、技术方案：BDD 驱动的 HTA 自动化体系构建

4.1 BDD 用例规范：从模糊描述到精准定义

4.1.1 为什么要用BDD描述用例的步骤？

通过BDD步骤描述，规范用例步骤，减少理解歧义，实现相同case，不同的人执行结果是一致的。

BDD的测试case和普通测试对比：

普通case描述：

步骤1：进入门票填写页，一张一人场景，选择1成人，1儿童；

预期结果1：出行人下方展示人群标题，例如：成人/儿童；

步骤2：人群未选择时；

预期结果2：展示对应人群暗纹：需选择一位成人票/需选择一位儿童票

步骤3：人群已选择时；

预期结果3：回显出行人信息，点击可以进入到出行人列表，不展示暗纹

存在问题：

原case也有一些关键词描述，"回显出行人信息"，不同人的理解可能不一样，回显哪些信息未说明；

点击进入出行人选择列表，点击哪里未说明；容易产生歧义。

BDD case描述：

步骤1：点击[SKU模块]下的[增加份数01]（增加成人一份）

步骤1.1：点击[SKU模块]下的[增加份数02]（增加儿童一份）

预期结果1：[出行人模块]展示"需选择一位成人票/需选择一位儿童票"

步骤2：点击[出行人模块]下的[成人1]（选择1位成人）

步骤2.1：点击[出行人模块]下的[儿童1]（选择1位儿童）

预期结果2：[出行人模块]展示"成人1","儿童1"

步骤3：点击[出行人模块]下的[选择/新增]

预期结果3：展示“新增出行人”（进入出行人列表页面）

4.1.2 为什么要自动化生成HTA？

降低研发测试沟通成本，避免研发实现的HTA与测试描述不一致，提高case准确性
降低研发写HTA的成本

BDD生成HTA弊端？

测试人员成写case成本变高

BDD有哪些语言？

语法	描述	例子
输入	输入动作	[出行人编辑浮层]下的[姓名输入框]输入张三
点击埋点	点击埋点验证	存在点击埋点 {@Trace: { key: "xxx", value: {"xxx": "xxx"} }}
点击	点击操作	点击[出行人模块]下的“选择/新增”按钮
曝光埋点	曝光埋点验证	存在曝光埋点 {@Expo: { key: "xxx", value: {"xxx": "xxx"} }}
展示、存在	验证展示、存在一段文案	[出行人模块]下展示“选择/新增”文案 [底部模块]下存在[价格明细]
不展示、不存在	验证不展示、不存在一段文案	[出行人模块]下不展示“选择/新增”文案 [底部模块]不存在[价格明细]
Toast提示	验证toast文案	点击[去支付按钮]，toast提示"请选择出行人"
[testID]	验证某个模块下具体内容	[出行人模块]
""	一段文案的描述	"出行人"

4.1.3 为什么使用以上BDD语法?

在软件开发和测试的过程中，BDD（行为驱动开发）是一种十分流行的开发方法论，其核心思想是通过描述软件行为来促进开发人员、测试人员和业务人员之间的沟通与协作。BDD 使用一种自然语言的语法来表达业务需求和行为，而这种语法通常遵循某种规范，以便团队成员能够轻松理解并共同参与到测试用例的编写和执行中。

为了尽可能降低复杂度并满足测试使用场景，调研业内的 BDD 语法是非常必要的。目前，市场上有多种 BDD 工具和语法标准，例如 Gherkin 和 Cucumber，它们已经被广泛应用于自动化测试中。以下是一些针对如何通过调研和选型降低复杂度，同时保持测试高效性和可读性的建议。

1）简化语法：避免过度抽象

在选择和设计 BDD 语法时，避免使用过度复杂和抽象的表达方式。虽然 BDD 的目的是将业务需求转化为易于理解的行为描述，但如果语法设计过于复杂，会增加团队成员的理解成本，并且可能导致在实际应用过程中出现歧义。为了降低复杂度，应当选择一种直观且易于理解的语法格式。

例如，Gherkin 语法（广泛应用于 Cucumber 等工具）提供了简单的关键词（如 Given, When, Then），这些关键词可以清晰地表达前置条件、执行的操作以及期望的结果。它的语法通常如下所示：

gherkinFeature: 登录功能  Scenario: 用户输入正确的用户名和密码    Given 用户在登录页面    When 用户输入正确的用户名和密码    Then 用户应该看到首页

通过这种简单易懂的语法，可以将复杂的测试场景转化为易于沟通和共享的格式。

2）场景模块化，减少重复

在BDD中，测试场景的重用和模块化非常重要。很多时候，测试场景中的某些部分是可以复用的（如相同的前置条件或相似的行为）。为了降低复杂度并提高效率，应该尽量将公共部分提取出来，使用**场景背景（Background）和步骤重用（Step Reusability）**来避免重复的代码。

例如，在多个场景中都需要验证用户登录功能时，可以通过将公共步骤提取到 Background 部分，减少冗余的代码：

gherkinFeature: 用户登录功能
Background:   Given 用户已在登录页面
Scenario: 用户输入正确的用户名和密码  When 用户输入正确的用户名和密码  Then 用户应该看到首页
Scenario: 用户输入错误的密码  When 用户输入错误的密码  Then 用户应该看到错误信息

3）语义化场景，增强可读性

BDD 的一个核心优势是其对业务人员的友好性。在进行 BDD 语法设计时，应尽量保持场景描述的语义清晰，使得非技术人员也能够理解并参与到测试流程中。通过使用自然语言的方式，描述业务流程中的每个步骤和行为，可以减少沟通成本，提高团队的协作效率。

例如，Given 部分应该描述系统的初始状态，When 部分描述用户操作的行为，Then 部分描述期望的结果。这种标准化的语法使得每个场景都具有清晰的结构，便于理解。

gherkinGiven 系统处于未登录状态When 用户点击登录按钮Then 系统应该提示用户输入用户名和密码

4）灵活性与适应性：根据业务需求调整语法

尽管 BDD 语法具有较强的标准化，但在不同的业务需求和应用场景下，BDD 的实现方式可以根据具体情况进行调整。在某些复杂的业务流程中，可以引入自定义的步骤关键字（例如 And, But）来扩展语法，并确保测试脚本能够覆盖不同的测试用例和边界条件。

例如，若要在场景中加入多个条件判断，可以使用 And 来描述多个预期行为：

gherkinScenario: 用户输入不完整的用户名和密码  Given 用户处于登录页面  When 用户输入不完整的用户名  And 用户输入不完整的密码  Then 系统应该提示用户用户名和密码不完整

通过调研业内的 BDD 语法并在实际使用中进行优化，可以有效降低测试用例编写和执行的复杂度，同时保证测试的全面性和可读性。简化语法、模块化场景、增强语义清晰度和灵活调整，是实现高效 BDD 测试的关键步骤。结合自动化工具和持续集成的支持，可以进一步提升测试流程的效率，确保软件开发过程中的质量保证工作不因复杂性而受到影响。

4.2 自动化生成 HTA：从人工编写到BDD生成

在进行 BDD 测试时，将业务需求转化为可执行的自动化测试是一个关键步骤。这个过程通常分为几个重要环节，包括：以及准备 Jest 运行环境、解析测试用例、生成测试步骤、将步骤转化为 Jest 测试代码。

以下是每个环节的详细描述，将一个测试用例从 BDD 语法转化为 Jest 测试代码。

4.2.1 准备 Jest 运行环境

安装 Jest 和 React Testing Library 等相关依赖。
设置 Jest 配置文件（例如 jest.config.js），以支持对 React 组件的测试。
配置 babel（如果使用 ES6+ 特性），确保测试代码能顺利运行。

项目下新增hta.config.js

const path = require("path");const template = require("./template");
module.exports = {    // 项目类型枚举    type: "xtaro-tnt",    // 生成的dist目录下的源码路径    entry: path.join(__dirname, "../dist-crn/xtaro-tnt/src"),    srcEntry: {        dev: path.join(__dirname, "../dist/crn-072/src"),        pipeline: path.join(__dirname, "../dist-crn/xtaro-tnt/src"),    },    // dist目录路径    path: {        dev: path.join(__dirname, "../dist/crn-072"),        pipeline: path.join(__dirname, "../dist-crn/xtaro-tnt"),    },    // 多页面维护    pages: [        {            // 页面中文名称（与测试用例库下的页面名称对应）            name: "xxx页面",            // 页面名称标识            pageName: "new-product-detail",            // 页面模板路径            template: template.newProductDetail,            useNpmTest: true,        }    ]};

准备页面模版

describe('xxx页面', () => {  let PageComponent;  let RequestFolderId = global.RequestFolderId;  const urlQueryString = '?{{url}}';  const urlQuery = stringtoObject(urlQueryString);  beforeEach(async () => {    global.RequestFolderId = {{mock_data}};    global.BoundingClientRect = { height: 1500 };    PageComponent = await render(<div testID="global-testID"><Page /></div>);    await sleep(1000);  });  afterEach(async () => {    global.RequestFolderId = RequestFolderId;  });  {{BDD}}});

运行时，会根据hta.config.js内容结合模版文件生成jest.config.js。

4.2.2 解析测试用例

在将测试案例转化为代码之前，首先需要对测试案例（或场景）进行详细解析，了解每个场景中的需求、步骤和预期结果。这些步骤通常是基于自然语言描述的。

例如：

{@MockID:4684}[通用头部模块]展示"自营","xxx景区一日游【xx景区专线】"存在[a图标]点击[a图标] ♀ 存在[xx产品浮层]存在[b-右箭头]点击[b-右箭头] ♀ 存在[b-浮层]展示"浮层信息1","浮层信息2","浮层信息3"存在[b-浮层关闭按钮]存在[c图标]存在[d图标]

4.2.3 将测试步骤转化为 Jest 测试代码

接下来，将解析出来的步骤转化为 Jest 测试代码

describe("xxx页面", () => {    let PageComponent = null;    beforeEach(async () => {        global.BoundingClientRect = { height: 150 };        global.RequestFolderId = 4684;        PageComponent = await render(            <View testID="global-testID">                <Page />            </View>        );    });
    it("{5355344}-xxx模块展示逻辑", async () => {        await expectAttrsExistsAsync(screen, "通用头部模块", {            runnerId: "2_1",            children: [                "自营",                "xxx景区一日游【xx景区专线】",            ],        });        await expectAttrsExistsAsync(screen, "a图标", { runnerId: "3_1" });        var component = await expectAttrsExistsAsync(screen, "a图标", { runnerId: "4_0", children: [                "xx产品浮层"            ], });        await expectAttrsExistsAsync(screen, "b-右箭头", { runnerId: "8_1" });        var component = await expectAttrsExistsAsync(screen, "b-右箭头", { runnerId: "9_0" });        fireEvent(component, "click");        await expectAttrsExistsAsync(screen, "b-浮层", { runnerId: "9_1" });        await expectAttrsExistsAsync(screen, "global-testID", {            runnerId: "10_1",            children: [                "浮层信息1",                "浮层信息2",                "浮层信息3"            ],        });        await expectAttrsExistsAsync(screen, "carPopup_close_btn", { runnerId: "11_1" });        await expectAttrsExistsAsync(screen, "c图标", { runnerId: "12_1" });        await expectAttrsExistsAsync(screen, "d图标", { runnerId: "13_1" });    });});

解释：

render()：渲染组件。
fireEvent.change()：模拟输入框的输入行为。
fireEvent.click()：模拟点击事件。
expect()：断言检查。

4.3 Mock 数据管理：持久化存储管理和维护更新

需要运行 HTA，还需要有测试用例相对应的 Mock 数据作为支持，在过往人工编写 HTA 时，Mock 数据通常由研发将接口数据存储在代码仓库本地，在 .test.jsx 测试用例文件中手动引入该文件。

这样做会带来以下几个问题：

Mock 数据分散存储于业务代码仓库，不便于多页面多项目协同编辑。
Mock 数据无法从接口维度进行分类，进行批量管理（新增、删除、修改）。
Mock 数据与单个测试用例强绑定，不利于多个测试用例之间复用 Mock 数据。

因此引入了 Mock 用例平台（由旅游公共研发团队提供技术支持）作为 Mock 数据管理方案。

Mock 用例平台的数据在底层存储在 git 仓库，同时提供了平台可视化界面可进行快速编辑和更新 Mock 用例数据，只需将 git 仓库权限开放给测试同学，即可实现Mock数据的持久化存储管理和维护更新。

与单独的 git 仓库相比，Mock 用例平台还提供了以下增强的能力：

实时预览接口：上传到 Mock 用例平台的数据，可通过接口调用返回指定的 Mock 数据，配合业务代码接入，即可实现在测试环境预览 Mock 数据的实时效果。例如在页面链接上拼接 mockId=123 即可访问 Mock 用例 ID 为 123 下所有的接口数据，单个 Mock 用例下包含多个接口的数据，便于复杂业务场景下接口组合管理。

实时预览对于测试同学编写测试用例具有相当的提效作用，对于接口较多场景复杂的页面，往往需要准备数十个接口的 Mock 数据，极易出错，预览功能可以让测试同学提前在测试环境下确认 Mock 数据是否满足预期完成测试用例步骤。

NPM 包发布：考虑到 HTA 运行时的耗时较长，以及 Pipeline 环境下网络不通，平台还提供了 NPM 包的形式来获取 Mock 数据，实现 HTA 运行提速。配合 git 提交自动触发打包流水线，可实现测试同学提交 Mock 数据后自动打包发布 NPM 包，更新 Mock 数据。

4.4 测试用例平台：可视化调试验证步骤

在 BDD 测试用例编写完毕后，即可得到一条完整的测试用例，常规的测试流程，由研发或测试同学下载用例到本地代码仓库即可调试运行 BDD HTA，对于具备一定开发和排查能力的研发同学，这套流程并无实际操作的问题。

但对于不熟悉开发和排查流程的测试同学，由于编写用例时仅能依据需求文档和交互视觉稿，难免会出现遗漏和错误，如果在 IDE 中进行调试运行，错误信息（如下图所示）被淹没在海量日志中，很难精准定位到有价值的信息。

因此，测试用例平台实现了以下调试运行功能：

运行结果映射：（如下图所示）将每一个步骤的运行结果展示在测试步骤上。
生产代码预览：（如下图所示）点击后可查看该步骤通过 BDD 转换为 HTA 后的测试用例代码，可用于确认转换后的代码符合预期验证效果。
查看错误信息：（如下图所示）点击后可查看该步骤运行失败的原因，同时对于验证「展示」的步骤，会提示该 testID 下已有的文本节点。

五、实施成果：效率与质量的双重提升

5.1 景点玩乐-活动填写页治理案例

阶段	测试用例数量	测试用例步骤数	自动化行覆盖率	自动化分支覆盖率
人工编写 HTA	500	823	71%	60%
BDD HTA	214	1852	91%	74%

通过比较可以得出，BDD HTA 相较于人工编写 HTA，在测试用例质量方面有显著提升，并且可通过自动化代码覆盖率这一维度进行量化监控。

测试用例数量精简，提高了单用例的覆盖范围，减少了维护成本。
测试用例步骤提升，全面且有效提高了验证步骤的质量。
自动化覆盖率提升，确保业务代码均被执行到，减少测试用例遗漏的风险。

5.2 项目周期对比

合作模式	研发周期	测试周期	总周期
传统模式	10 天	5.5 天	15.5 天
测试左移模式	10 天	7.5 天	17.5 天
BDD HTA 模式	10 天	3.5 天 + （ 0.5 天手工测试）	14 天

与传统模式和左移模式（研发自测为主）相比，BDD HTA 模式可以显著降低测试周期，降低测试成本，发布周期缩短 10%、成本降低 15%。

同时人力成本方面，研发测试比从 4.4 : 1 优化至 7 : 1。

六、发布流程重构：自动化驱动的质量门禁

在完成 BDD HTA 后，自动化代码覆盖率将提升到较高的水准，以景点玩乐团队为例，按单页面引用依赖抽取后的产物代码（排除第三方依赖），要求行覆盖率 > 90%，分支覆盖率 > 70%。

在后续业务迭代过程中，还需要设置质量门禁来持续关注发布质量，确保不会因业务需求迭代而导致质量下降，以及新增业务需求功能漏测的情况。

在 Pipeline 中运行 BDD HTA 后会生成 coverage 报告，Gitlab 支持在 CI/CD 配置中可读取上传的 coverage 报告来设置 Merge Request 的红线配置（如左图所示）。

设置完成后，在 Merge Request 界面会出现右图所示的 UT Cov 覆盖率提示，未达标时无法通过 merge。

七、未来规划

7.1 Mock 数据自动化采集录入

当前 Mock 用例代码仓库的结构，可以较快实现已有数据的复用，例如 A 和 B 两个场景下所需的 Mock 数据中 10 个接口有 8 个接口数据完全相同，那仅需额外创建不同的 2 个接口数据，新增的 Mock 用例 B 可复用 A 的接口数据。

但对于首次创建的场景，其接口数据和 Mock 用例均需要依赖人工进行操作抓取接口数据和导入生成 Mock 用例，操作流程较为繁琐。

因此后续规划实现 Mock 数据自动化采集录入，主要包含：

1）打通与用户行为录制平台的自动化录制采集数据。

2）实现读取用户行为日志自动化创建 Mock 用例。

以此实现 Mock 数据录入创建的自动化提效。

7.2 测试用例平台可视化调试接入标准流水线

测试用例平台支持在本地运行项目，平台通过本地服务运行 HTA，这种形式存在以下问题。

需要在本地搭建开发环境和配置相关通信服务，对于不熟悉开发的同学有一定上手成本。
本地运行不支持多条用例、多个页面同时运行

将运行调试集成到 Gitlab 流水线后，可以实现标准化和批量操作。

八、总结：自动化测试的演进之路

从人工测试到 BDD HTA 的转型实践表明，测试体系的优化需要兼顾效率与质量的平衡。通过语义化的 BDD 用例规范、自动化的 HTA 生成能力以及与端到端测试工具的协同，成功实现了覆盖率提升、成本降低和发布效率优化的多重目标。未来，随着跨端测试能力的完善和智能化技术的引入，自动化测试将在软件质量保障中扮演更核心的角色。

【推荐阅读】