这是我参与11月更文挑战的第16天，活动详情查看：2021最后一次更文挑战
测试策略是架构中重要的一环，它用于保证项目质量及代码质量。作为开发人员懂一些基本的测试知识也会有助于我们写出高质量的代码。
我们常见的测试方式有以下几种：
◎ 单元测试。
◎ 组件测试。含快照测试（Snapshot）。
◎ 契约测试/接口测试。相当于服务测试。
◎ E2E测试。端对端测试、集成测试。
◎ 回归测试
◎ 冒烟测试
◎ 驱动测试
◎ 增量测试
◎ 集成测试
◎ 自动化测试
单元测试
单元测试，是指对软件中的最小可测试单元进行检查和验证。它是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。
其实我们每天都在做单元测试。你写了一个函数，除了极简单的外，总是要执行一下，看看功能是否正常，有时还要想办法输出些数据，如弹出信息窗口什么的，这也是单元测试。可以说，进行充分的单元测试，是提高软件质量降低开发成本的必由之路。
养成对代码进行单元测试的习惯，不但可以写出高质量的代码，而且还能提高编程水平。
单元测试实现方式？
编写测试的时候，采用的往往也都是三段式风格Given-When-Then，对应的中文便是：假设-当-那么。三段式风格解释如下。
◎ 假设（Given）：一个上下文，指定完成测试所需要的条件。
◎ 当（When）：进行一系列操作，即所要执行的操作，如单击某个按钮。
◎ 那么（Then）：得到一系列可观察的后果，即需要检测的断言，如按钮被隐藏。
eact框架则推荐使用Facebook自家的Jest测试：
什么时候进行单元测试？
（1）必须进行测试的是通用、公用的Utils函数。
（2）复杂交互操作需要进行一定的测试。
（3）网络请求可以交给契约测试，或者不进行测试。
单元测试通常只用于测试代码中的逻辑，而对于隐藏在模板中的逻辑来说，单元测试往往难以进行测试。
组件测试
组件测试是指，对项目中编写的组件进行测试。
在选用第三方组件的时候，一般都是经过组件开发者测试过的，但是如果一个组件的测试不够、采用的范围比较小，那么我们在选型的时候需要慎重。
在组件测试中有一种更简单的测试方式——快照方式。
下面是React框架的快照的测试示例：
执行完测试后会生成视图对应的快照文件，用于后期对比快照。当组件中传入不同的参数，或者组件间进行相应的交互时会产生状态的变化。通过记录这些状态和属性的变化，便能验证组件是否被修改或是否受到影响。
契约测试
契约测试（Contract Test），即对前后端约定的API进行测试，这个API约定又可以称为契约。
对于前端来说，主要测试后台的Mock Server返回的API是否满足前端需求。对于有些不需要授权服务的API，则可以直接验证后台API是否和前端保持一致。
E2E 测试
E2E（End To End）即端对端测试，属于黑盒测试，通过编写测试用例，自动化模拟用户操作，确保组件间通信正常，程序流数据传递如预期。
站在用户角度的测试； e2e测试是把我们的程序堪称是一个黑盒子，我不懂你内部是怎么实现的，我只负责打开浏览器，把测试内容在页面上输入一遍，看是不是我想要得到的结果。
回归测试
回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
自动回归测试将大幅降低系统测试、维护升级等阶段的成本。
回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试，在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。
测试过程
（1） 识别出软件中被修改的部分；
（2） 从原基线测试用例库T中，排除所有不再适用的测试用例，确定那些对新的软件版本依然有效的测试用例，其结果是建立一个新的基线测试用例库T0。
（3）依据一定的策略从T0中选择测试用例测试被修改的软件。
（4）如必要，生成新的测试用例集T1, 用于测试T0无法充分测试的软件部分
（5）用T1执行修改后的软件。
注：第（2) 和第（3) 步测试验证修改是否破坏了现有的软件功能，第（4) 和第（5) 步测试验证修改工作本身。
冒烟测试
这一术语源自硬件行业。对一个硬件或硬件组件进行更改或修复后，直接给设备加电。如果没有冒烟，则该组件就通过了测试。在软件中，“冒烟测试”这一术语描述的是在将代码更改嵌入到产品的源树中之前对这些更改进行验证的过程，是对软件基本功能进行确认验证的手段。
驱动测试
测试驱动开发简称TDD，数据驱动指的是从数据文件中读取输入数据并将数据以参数的形式输入脚本测试，不同的测试用例使用不同类型的数据文件。
数据驱动模式实现了数据和脚本分离，相对于录制与回放测试技术，数据驱动测试极大地提高了脚本利用率和可维护性，但是对于界面变化较大的情景不适合数据驱动测试。
数据驱动测试主要包括以下几种：
（1）关键字驱动测试
关键字驱动是对数据驱动的改进，它将数据域与脚本分离、界面元素与内部对象分离测试过程与实现细节分离。关键字驱动的测试逻辑为按照关键字进行分解得到数据文件，常用的关键字主要包括被操作对象、操作和值。
（2）行为驱动测试
行为驱动测试指的是根据不同的测试场景设计不同的测试用例，需要开发人员、测试人员、产品业务分析人员等协作完成。行为驱动测试是基于当前项目的业务需求、数据处理、中间层进行的协作测试，它注重的是测试软件的内部运作变化，从而解决单元测试中实现的细节问题。
增量测试
单元测试完成后，开发人员进行集成测试。它是验证模块之间的接口和交互的过程。在集成的过程中，开发人员使用了很多技巧，其中之一就是增量方式。
在增量集成测试中，开发人员使用存根或驱动程序逐个集成模块以发现缺陷。这种方法被称为增量集成测试。相反，大爆炸是另一种集成测试技术，其中所有模块都集成在一个镜头中。
优缺点
-
增量集成测试的更大优点是，当较小的组件早期发现缺陷时，相对容易检测到该缺陷的根本原因。
-
缺点是，由于必须为开展这些测试而开发存根和驱动程序，所以可能耗时。
