软件测试笔记

01初谈

一、概述

高质量的软件测试、用例设计不仅要考虑明确的显示功能性需求，还要设计兼容性、安全性、性能等一系列的非功能性需求，这些对软件系统的质量也有着举足轻重的作用。

测试工程师必须具有宽广的知识面，方能设计出针对性、更易发现问题的用例。

软件测试的用例设计是不可能穷尽的，受制于经济成本时间成本，所以要兼顾缺陷风险和研发成本之间的平衡。

---

02“好的”测试用例

一、概述

“好的”测试用例一定是一个完备的机核网，能覆盖所有等价类和各种边界值。

能否发现缺陷并不是衡量用例好坏的标准。

设计用例方法很多，但综合运用等价类划分、边界值分析、错误推断法可以满足大部分用例设计的需求。

“好的”用例在设计时、需要从功能需求出发，全面、无遗漏的识别出测试需求至关重要。

想设计一个好的测试用例，必须深入理解被测软件的架构设计、深入内部处理逻辑、需求覆盖率和代码覆盖率两个指标可以衡量测试执行的完备性。

---

03单元测试

一、概述

• 电子元件就像是软件中的单元，通常是class、def，对于单个元器件的测试就像是单元测试；

• 组装完成的功能电路板就像是软件中的模块，对电路板的测试就像是软件中的集成测试；

• 电视机全部组装完成就像是软件完成了预发布版本，电视机全部组装完成后的开机测试就像是软件中的系统测试。

单元测试是指，对软件中的最小可测试单元在与程序其他部分相隔离的情况下进行检查和验证的工作，这里的最小可测试单元通常是指函数或者类 。

单元测试都是以自动化的方式执行，所以在大量回归测试的场景下更能带来高收益。

二、如何做好单元测试

单元测试的对象是代码 。

1、代码的基本特征与产生错误的原因

要做到代码功能逻辑正确，必须做到分类正确并且完备无遗漏，同时每个分类的处理逻辑必须正确 。

开发考虑过程：

• 如果要实现正确的功能逻辑，会有哪几种正常的输入；
• 是否有需要特殊处理的多种边界输入；
• 各种潜在非法输入的可能性以及如何处理。

2、单元测试用例详解

单元测试的用例是一个“输入数据”和“预计输出”的集合 ；概括就是“在明确了代码需要实现的逻辑功能的基础上，什么输入，应该产生什么输出”。

3、驱动代码，桩代码和Mock代码

• 驱动代码（Driver）指调用被测函数的代码，在单元测试过程中，驱动模块通常包括调用被测函数前的数据准备、调用被测函数以及验证相关结果三个步骤。驱动代码的结构，通常由单元测试的框架决定。
• 桩代码（Stub）是用来代替真实代码的临时代码。 比如，某个函数A的内部实现中调用了一个尚未实现的函数B，为了对函数A的逻辑进行测试，那么就需要模拟一个函数B，这个模拟的函数B的实现就是所谓的桩代码。
• Mock代码和桩代码非常类似，都是用来代替真实代码的临时代码，起到隔离和补齐的作用。 Mock代码和桩代码的本质区别是：测试期待结果的验证（Assert and Expectiation）。 对于Mock代码来说，我们的关注点是Mock方法有没有被调用，以什么样的参数被调用，被调用的次数，以及多个Mock函数的先后调用顺序。所以，在使用Mock代码的测试中，对于结果的验证（也就是assert），通常出现在Mock函数中。

---

04自动化测试

一、概述

自动化测试是，把人对软件的测试行为转化为由机器执行测试行为的一种实践，对于最常见的GUI自动化测试来讲，就是由自动化测试工具模拟之前需要人工在软件界面上的各种操作，并且自动验证其结果是否符合预期。

自动化测试的本质是先写一段代码，然后去测试另一段代码，所以实现自动化测试用例本身属于开发工作，需要投入大量的时间和精力，并且已经开发完成的用例还必须随着被测对象的改变而不断更新，你还需要为此付出维护测试用例的成本 。

当你发现自动化测试用例的维护成本高于其节省的测试成本时，自动化测试就失去了价值与意义，你也就需要在是否使用自动化测试上权衡取舍了。

二、自动化测试优劣

• 优势

  1、可以替代大量的手工机械重复性操作，可以把更多的时间花在更全面的用例设计和新功能的测试上；
  2、可以大幅提升回归测试的效率，非常适合敏捷开发过程；
  3、 可以更好地利用无人值守时间，去更频繁地执行测试；
  4、可以高效实现某些手工测试无法完成或者代价巨大的测试类型，比如关键业务7×24小时持续运行的系统稳定性测试和高并发场景的压力测试等；
  5、可以保证每次测试执行的操作以及验证的一致性和可重复性，避免人为的遗漏或疏忽 ；

• 劣势

  1、自动化测试并不能取代手工测试，它只能替代手工测试中执行频率高、机械化的重复步骤。你千万不要奢望所有的测试都自动化，否则一定会得不偿失。
  2、 自动测试远比手动测试脆弱，无法应对被测系统的变化，其根本原因在于自动化测试本身不具有任何“智能”，只是按部就班地执行事先定义好的测试步骤并验证测试结果。对于执行过程中出现的明显错误和意外事件，自动化测试没有任何处理能力。
  3、自动化测试用例的开发工作量远大于单次的手工测试，所以只有当开发完成的测试用例的有效执行次数大于等于5次时，才能收回自动化测试的成本。
  4、手工测试发现的缺陷数量通常比自动化测试要更多，并且自动化测试仅仅能发现回归测试范围的缺陷。
  5、 测试的效率很大程度上依赖自动化测试用例的设计以及实现质量，不稳定的自动化测试用例实现比没有自动化更糟糕。
  6、实行自动化测试的初期，用例开发效率通常都很低，大量初期开发的用例通常会在整个自动化测试体系成熟，和测试工程师全面掌握测试工具后，需要重构。
  7、业务测试专家和自动化测试专家通常是两批人，前者懂业务不懂自动化技术，后者懂自动化技术但不懂业务，只有二者紧密合作，才能高效开展自动化测试。
  8、自动化测试开发人员必须具备一定的编程能力，这对传统的手工测试工程师会是一个挑战。

三、什么项目适合自动化

1、需求稳定，不会频繁变更 ；

2、研发和维护周期长，需要频繁执行回归测试 ；

3、需要在多种平台上重复运行相同测试的场景；

4、某些测试项目通过手工测试无法实现，或者手工成本太高。对于所有的性能和压力测试，很难通过手工方式实现 ；

5、被测软件的开发较为规范，能够保证系统的可测试性。 （开发过程规范、GUI空间命名规范、预留可测试接口）；

6、具备一定的编程能力。

05 开发各阶段的自动化测试技术

说到自动化测试时，第一反应很可能就是GUI自动化测试。然而， 在软件研发生命周期的各个阶段都有自动化测试技术的存在，并且对提升测试效率有着至关重要的作用。

单元测试、代码级集成测试、 Web Service测试和GUI测试阶段的自动化技术 。

一、单元测试自动化

从广义上讲，单元测试阶段的“自动化”内涵不仅仅指测试用例执行的自动化，还应该包含以下五个方面：

• 用例框架代码生成的自动化；
• 部分测试输入数据的自动化生成；
• 自动桩代码的生成；
• 被测代码的自动化静态分析；
• 测试覆盖率的自动统计与分析。

二、代码级集成测试的自动化技术

通俗地讲，代码级集成测试是指将已经开发完成的软件模块放在一起测试 。

从测试用例设计和测试代码结构来看，代码级集成测试和单元测试非常相似，它们都是对被测试函数以不同的输入参数组合进行调用并验证结果，只不过代码级集成测试的关注点，
更多的是软件模块之间的接口调用和数据传递。
代码级集成测试与单元测试最大的区别只是，代码级集成测试中被测函数内部调用的其他函数必须是真实的，不允许使用桩代码代替，而单元测试中允许使用桩代码来模拟内部调用的其他函数。

三、Web Service测试的自动化技术

Web Service测试，主要是指SOAP API和REST API这两类API测试，最典型的是采用SoapUI或Postman等类似的工具。但这类测试工具基本都是界面操作手动发起Request并验证Response，所以难以和CI/CD集成，于是就出现了API自动化测试框架。

四、GUI测试的自动化技术

发展时间最长、应用最广的自动化测试技术。它的核心思想是，基于页面元素识别技术，对页面元素进行自动化操作，以模拟实际终端用户的行为并验证软件功能的正确性。

目前， GUI自动化测试主要分为两大方向，传统Web浏览器和移动端原生应用（Native App）的GUI自动化。虽然二者采用的具体技术差别很大，但是用例设计的思路类似。

06测试覆盖率

一、概述

测试覆盖率通常被用来衡量测试的充分性和完整性，从广义的角度来讲，测试覆盖率主要分为两大类，一类是面向项目的需求覆盖率，另一类是更偏向技术的代码覆盖率。

• 需求覆盖率是指测试对需求的覆盖程度，通常的做法是将每一条分解后的软件需求和对应的测试建立一对多的映射关系，最终目标是保证测试可以覆盖每个需求，以保证软件产品的质量。
• 代码覆盖率简单来说，代码覆盖率是指，至少被执行了一次的条目数占整个条目数的百分比。

二、代码覆盖率的价值与局限性

• 统计代码覆盖率的根本目的是找出潜在的遗漏测试用例，并有针对性的进行补充，同时还可以识别出代码中那些由于需求变更等原因造成的不可达的废弃代码。
• 高的代码覆盖率不一定能保证软件的质量，但是低的代码覆盖率一定不能能保证软件的质量。

三、代码覆盖率工具的实现原理

实现代码覆盖率的统计，最基本的方法就是注入（Instrumentation）。简单地说，注入就是在被测代码中自动插入用于覆盖率统计的探针（Probe）代码，并保证插入的探针代码不会给原代码带来任何影响。

---

07软件缺陷报告

一、概述

软件缺陷报告是测试和卡法交流沟通的桥梁，也是测试日常工作的重要输出。其质量直接关系到缺陷被修复的速度以及开发的效率，同时影响到测试工程师的信用，和开发协作的有效性。好的缺陷报告不是大量信息的堆叠，而是高效地提供准确的信息。

二、组成及关键点：

1、标题

最先看到的部分，对缺陷地概括性描述。“什么情况下发生了什么事”。

• 清晰简洁，足够具体。不能笼统的描述。
• 尽可能描述问题本质，而避免停留问题表面。（“数字输入框，可以输入英文和字符”-->"数字输入框，没有对输入内容做校验")
• 不宜过长，更详细地描述应放在“缺陷概述”中。

2、缺陷概述

缺陷概述会提供更多对缺陷地本质和现象的描述，是标题的细化。其目的是清晰简洁的描述缺陷，快速聚焦本质。

3、缺陷影响

问题对用户或业务的影响范围以及影响程度。决定优先级(priority)和严重程度(severity)。

4、环境配置

测试环境的配置细节，如版本、浏览器种类，配置信息等。按需描述，也就是只描述重现缺陷的环境敏感信息。

5、前置条件

步骤开始时系统应处在的状态，目的是减少缺陷重现步骤的描述。（用户已完成登录）

6、缺陷重现步骤

报告的核心内容，目的是用简洁的语言像开发展示缺陷重现的操作步骤。重现步骤前，测试需要反复执行，确保缺陷的可重现性、找到最短的重现路径。

7、期望结果

期望结果来自对需求的理解，实际结果来自测试执行的结果。

• 期望：应该发生什么
• 结果：发生了什么

8、优先级&严重程度

• 缺陷优先级是指缺陷必须被修复的紧急程度
• 缺陷严重等级是指因缺陷引起的故障对软件产品的影响程度

严重程度是缺陷本身的属性，确定后不在变化。
优先级是工程属性，会随着进度、成本等因素而变化。

9、变通方案

提供一种临时绕开当前缺陷而不影响产品功能的方式。

10、根因分析

Root cause analyses

11、附件

证据支持、截图、测试用例日志、服务端日志、GUI测试执行视频。

---

08测试计划

一、概述

运筹帷幄之中，决胜千里之外。预先计划是很重要及必要的。

测试计划表现形式不再是传统的庞大正式的测试文档了，而更多的体现在每个sprint的计划环节。短期测试计划可以迅速根据项目情况实时调整。

所以，测试计划依旧存在，从原来一次性集中制定变成了以迭代方式持续制定的测试计划。

二、测试计划重要性

没有测试计划的问题：

• 很难确切的指导测试范围，以及应采取的具体的测试策略
• 很难预估工作量和测试资源，还会造成分工不明确，用例重复测试和遗漏
• 进度不可控，很难指导目前测试的完成情况，难以预估完成时间节点
• 对风险的抵抗能力很弱，难以应对需求变更和其他突发事件

三、一份好的测试计划

1、测试范围

描述被测对象的主要测试内容。因不可能进行穷尽测试，所以要有取舍，范围要明确“测什么，不测什么”；

2、测试策略

“先测什么、后测什么”&“如何来测”。重要的先，明确测试重点，先后顺序。

测试策略还需要说明，采用什么杨的测试类型和方法，具体的实施方法。

3、测试资源

人员和测试环境。目的是保证有限资源下的产出最大化。明确“谁来测”&“在哪里测”。

4、测试进度：

描述开始时间、所需工作量、预计完成时间，并以此为据来建议最终产品上线时间。

5、测试风险预估：

计划赶不上变化、需求变更一定要重新进行测试需求分析，确定变更后的测试范围和资源评估。制定计划时要预估测试过程中可能存在的潜在风险以及相应的应对策略。

---

09核心竞争力

一、测试工程师核心竞争力

1、测试策略设计能力

测试策略设计能力是指，对于各种不同的被测软件，能够快速准确地理解需求，并在有限的时间和资源下，明确测试重点以及最适合的测试方法的能力。明确回答关键问题：

• 测试要具体执行到什么程度；
• 测试需要借助于什么工具；
• 如何运用自动化测试以及自动化测试框架，以及如何选型；
• 测试人员资源如何合理分配；
• 测试进度如何安排；测试风险如何应对。

2、测试用例设计能力

测试用例设计能力是指，无论对于什么类型的测试，都能设计出高效地发现缺陷，保证产品质量的优秀测试用例。

平时多积累，对常见的缺陷模式、典型的错误类型以及遇到过的缺陷，要不断地总结、归纳，逐渐形成体系化的用例设计思维。

同时，阅读一些好的测试用例设计实例开阔思路，日后遇到类似的被测系统时，可以做到融会贯通和举一反三。

3、快速学习

• 对不同业务需求和功能的快速学习与理解能力；
• 对于测试新技术和新方法的学习与应用能力。

4、探索性测试思维

不断学习被测系统，同时结合基于自己经验的错误猜测和逻辑推理，整理和分析出更多的有针对性的测试关注点 。

5、缺陷分析能力

• 对于已经发现的缺陷，结合发生错误的上下文以及后台日志，可以预测或者定位缺陷的发生原因，甚至可以明确指出具体出错的代码行 。
• 根据已经发现的缺陷，结合探索性测试思维，推断同类缺陷存在的可能性，并由此找出所有相关的潜在缺陷；
• 对一段时间内所发生的缺陷类型和趋势进行合理分析，由点到面预估整体质量的健康状态，并能够对高频缺陷类型提供系统性的发现和预防措施，并以此来调整后续的测试策略。

6、自动化测试技术

从大量的重复性手工劳动中解放出来，把更多的时间花在更多类型的测试上。

自动化测试的核心价值还是“测试”本身， “自动化”仅仅是手段，实际工作中不能本末倒置。

7、良好的沟通能力

沟通能力会直接影响事务开展的效率。

二、测试开发工程师的核心竞争力

1、测试系统需求分析能力

2、宽广的知识体系

---

10掌握的非测试知识

1、网站架构的核心知识

2、容器技术

3、云计算技术

4、DevOps思维

5、前端开发技术

---

11互联网产品测试策略

一、概述

互联网产品与传统软件产品因研发流程不同而决定了测试策略不同。

研发最大的不同是互联网的“快”；互联网产品上线周期通常是day甚至是hour，而传统软件多以月甚至年为单位。

发布周期巨大差异决定其传统软件产品的测试策略不适用于互联网产品的测试。二者测试策略在执行时间和执行环境上有很大差异。

通常互联网产品要求全回归测试的执行时间不超过4h。

如何缩短时间保证测试质量和测试覆盖率？

• 引入测试的并发机制、用包含大量测试执行节点的测试执行集群来并发执行用例
• 从测试策略上找到突破口

二、传统软件测试策略设计

金字塔模型：

• 单元测试：最底部、通常有开发自己完成、越早发现修复成本越低，所以传统软件产品测试策略提倡对单元测试的高投入。
• API测试：针对各模块暴露的借口，灰盒测试介于白盒与黑盒之间的技术，核心思想是利用测试执行的代码覆盖率来指导测试用例的设计。以API接口测试为例，首先以黑盒方法设计测试用例，执行过程统计覆盖率、根据情况针对性补充测试用例。总体来看，数量少于单元测试但多于GUI测试。
• GUI测试：端到端（E2E）测试，最接近用户真实使用行为。优点：能实际模拟用户的行为。缺点：执行代价较大，就算是自动GUI，维护的代价依然大，要避免对GUI测试的过度依赖。

三、互联网产品的测试策略设计

菱形测试策略：重量级API、轻量级GUI、轻量级单元测试

• GUI测试：上线周期决定了GUI测试不能大范围展开。1、迭代周期短，留给GUI自动化测试的时间有限；2、互联网产品端界面频繁变化，GUI自动化效率低。

  由此、其GUI以手工为主、自动化为辅，手工往往采用探索性思想，针对新开发或修改的界面进行测试，自动化关注点在相对稳定且核心业务的基本功能验证上。所以GUI测试只覆盖最核心且直接影响业务流程的E2E场景。
  互联网GUI测试是轻量级的。

• API测试：如何保证质量？把测试重点放在API测试上。
  1、API测试用例开发与调试效率比GUI高得多；
  2、API用例稳定；
  3、单个用例执行时间短，可方便的并发执行，段时间内完成大量API用例执行；
  4、微服务架构、客户端应用的实现都时基于对后端微服务的调用；
  5、API接口一般很少改动。

• 单元测试：应用层和后端服务层。后端服务层有必要开展全面的单元测试。对于核心算法和关键应用，第三方支付集成接口等要做较全面的单元测试。 总结讲：互联网产品的全面单元测试只会应用在相对稳定和最核心的模块和服务上，而应用层或上层业务服务很少大规模开展单元测试。

12Selenium

Selenium 1.0的核心是，基于JavaScript代码注入；而Selenium 2.0的核心是，运用了浏览器原生支持的WebDriver。

13脚本和数据的解耦

• “测试脚本和数据解耦”的本质是实现了数据驱动的测试，让操作相同但是数据不同的测试可以通过同一套自动化测试脚本来实现，只是在每次测试执行时提供不同的测试输入数据。
• “页面对象模型”的核心理念是，以页面为单位来封装页面上的控件以及控件的部分操作。而测试用例使用页面对象来完成具体的界面操作。

14业务流程

操作函数的粒度是指，一个操作函数到底应该包含多少操作步骤才是最合适的。

业务流程的优点：

1. 业务流程（Business Flow）的封装更接近实际业务；
2. 基于业务流程的测试用例非常标准化，遵循“参数准备”、 “实例化Flow”和“执行Flow”这三个大步骤，非常适用于测试代码的自动生成；
3. 由于更接近实际业务，所以可以很方便地和BDD结合。 BDD就是Behavior Driven Development，即行为驱动开发，

业务流程抽象是，基于操作函数的更接近于实际业务的更高层次的抽象方式。基于业务流程抽象实现的测试用例往往具有较好的灵活性，可以根据实际测试需求方便地组装出各种测试用例。
业务流程的核心思想是，从业务的维度来指导测试业务流程的封装。由于业务流程封装通常很贴近实际业务，所以特别适用于组装面向终端用户的端到端（E2E）的系统功能测试用例，尤其适用于业务功能非常多，并且存在各种组合的E2E测试场景。

---

15测试数据

GUI测试中两种常见的数据类型：

1. 测试输入数据，也就是GUI测试过程中，通过界面输入的数据。
2. 为了完成GUI测试而需要准备的测试数据。比如， “用户登录”测试中，我们需要事先准备好用户账户，以便进行用户的登录测试。

从创建的时机来讲，创建测试数据的方法主要分为两种：

1. 测试用例执行过程中，实时创建测试数据，我们通常称这种方式为On-the-fly。
2. 测试用例执行前，事先创建好“开箱即用”的测试数据，我们通常称这种方式为Out-of-box。

实际上，往往很多测试数据的创建是基于API和数据库操作两者的结合来完成，即先通过API创建基本的数据，然后调用数据库操作来修改数据，以达到对测试数据的特定要求。

对于相对稳定的测试数据，比如商品类型、图书类型等，往往采用Out-of-box的方式以提高效率；而对于那些只能一次性使用的测试数据，比如商品、订单、优惠券等，往往采用On-the-fly的方式以保证不存在脏数据问题。

一、基于数据库操作创建测试数据

二、综合运用API调用和数据库操作创建测试数据

三、实时创建数据： On-the-fly

GUI测试脚本中，在开始执行界面操作前，我们往往会通过调用测试数据工具实时创建测试数据，也就是On-the-fly方式。

问题：

1. 在用例执行过程中实时创建数据，导致测试的执行时间比较长。
2. 业务数据的连带关系，导致测试数据的创建效率非常低。
3. 实时创建测试数据的方式对测试环境的依赖性很强。

四、事先创建测试数据： Out-of-box

Out-of-box的含义是开箱即用，在被测系统中预先创建好了充足的、典型的测试数据。

缺点 ：

1. 测试用例中需要硬编码（hardcode）测试数据，额外引入了测试数据和用例之间的依赖。
2. 只能被一次性使用的测试数据不适合Out-of-box的方式。 测试用例往往会需要修改测试数据，而且有些测试数据只能被一次性使用。比如（优惠券）
3. “预埋”的测试数据的可靠性远不如实时创建的数据。

五、On-the-fly和Out-of-box的互补

1. 对于相对稳定、很少有修改的数据，建议采用Out-of-box的方式，比如商品类目、厂商品牌、部分标准的卖家和买家账号等。
2. 对于一次性使用、经常需要修改、状态经常变化的数据，建议使用On-the-fly的方式。
3. 用On-the-fly方式创建测试数据时，上游数据的创建可以采用Out-of-box方式，以提高测试数据创建的效率。以订单数据为例，订单的创建可以采用On-the-fly方式，而与订单相关联的卖家、买家和商品信息可以使用Out-of-box方式创建。

16

1. 对于页面对象自动生成，商用测试软件已经实现了这个功能。如果选择开源测试框架，就需要自己实现这个功能了。
2. GUI测试数据自动生成，主要是基于测试输入数据的类型以及对应的自定义规则库实现的，并且对于多个测试输入数据，可以基于笛卡尔积来自动组合出完整的测试用例集合。
3. 对于无头浏览器，简单地想象成运行在内存中的浏览器，它拥有完整的浏览器内核。与普通浏览器最大的不同是，它在执行过程中看不到运行的界面。目前， Headless Chrome结合Puppeteer是最先进的无头浏览器方案。

17GUI测试稳定性

一、造成GUI测试不稳定的因素：

1. 非预计弹出的对话框
2. 页面控件属性的细小变化
3. 被测系统的A/B测试
4. 随机的页面延迟导致控件识别失效
5. 测试数据问题

二、解决思路

1、非预计弹窗

• 无法操作时，GUI自动化框架进入“异常场景恢复模式”
• 上述模式下，GUI自动化框架自动检测各种可能出现的对话框。确定后进行预定义操作（eg：确定）
• 发现一种潜在会弹出的对话框，将详细信息更新到恢复场景中

2、页面控件细微变化

实现自己的对象识别控制层：也就是在原本的对象识别基础上额外封装一层，在这个额外封装的层中加上模糊匹配的实现逻辑。

3、被测系统的A/B测试

测试脚本内部对不同的被测版本做分支处理，脚本需要能够区分A和B两个的不同版本，并做出相应的处理。

4、随机的页面延迟

加入重试（retry）机制。重试机制是指，当某一步GUI操作失败时，框架会自动发起重试，重试可以是步骤级别的，也可以是页面级别的，甚至是业务流程级别的。

5、测试数据问题

---

18GUI自动化测试报告

理想中的GUI测试报告应该是由一系列按时间顺序排列的屏幕截图组成，并且这些截图上可以高亮显示所操作的元素，同时按照执行顺序配有相关操作步骤的详细描述 。

一、开源GUI测试框架的测试报告实现思路

• 扩展Selenium原本的操作函数实现截图以及高亮显示操作元素的功能
• 在相关的Hook操作中调用screenshot函数实现截图以及高亮显示操作元素的功能

19大型项目中设计GUI自动化策略

大型全球化电商网站GUI测试的策略设计以及测试脚本管理的问题：
首先，要从前端组件的级别来保证质量，也就是需要对那些自定义开发的组件进行完整全面的测试。通常前端组件会基于Jest做比较严格的单元测试。
其次，每一个前端模块，都会构建自己的页面对象库，并且在此基础上封装开发自己的业务流程脚本。这些业务流程的脚本，可以组装成每个前端模块的测试用例。
最后，把各个前端模块组合在一起之后，站在终端用户的视角以黑盒的方式使用网站的端到端的测试。端到端的测试应该尽可能多地重用各个模块的页面对象库和业务流程脚本来完成。
而为了能够在端到端的GUI自动化测试中，复用各个模块的页面对象和业务流程脚本，我建议的方案是：对各个前端业务模块的页面对象库和业务流程脚本，实施版本化管理机制。

20移动应用测试方法与思路

现今移动互联网蓬勃发展