[入门]测试层级-ApiHug准备-测试篇-005

  🤗 ApiHug × {Postman|Swagger|Api...} = 快↑ 准√ 省↓

1. GitHub - apihug/apihug.com: All abou the Apihug   
2. apihug.com: 有爱，有温度，有质量，有信任
3. ApiHug - API design Copilot - IntelliJ IDEs Plugin | Marketplace

这里的测试自动化包括两个方面：

1. 开发人员
2. QA 人员

#层级

1. 单元测试 Unit Testing
2. 集成测试 Integration Testing
3. 系统测试 System Testing
4. 用户接受测试 Acceptance Testing

#单元测试

单元测试（unit testing），是指对软件中的最小可测试单元进行检查和验证。至于“单元”的大小或范围，并没有一个明确的标准，“单元”可以是一个函数、方法、类、功能模块或者子系统。

单元测试通常和白盒测试联系到一起，如果单从概念上来讲两者是有区别的，不过我们通常所说的“单元测试”和“白盒测试”都认为是和代码有关系的，所以在某些语境下也通常认为这两者是同一个东西。

还有一种理解方式，单元测试和白盒测试就是对开发人员所编写的代码进行测试， 概念这个东西大概理解是什么意思即可。

这个教程主要针对开发人员， 所以提前透露下， 你现在理解的单元测试没有那么复杂，就是你平时接触到的 比如java 世界里的 Junit, mockit, powermock 等等工具。

#谁来做

单元测试简单理解就是对开发人员所编写的代码进行测试，既然和代码相关我们第一感觉那应该是“开发人员来做”；

再一看单元测试包含“测试”两个字，那么“测试人员来做”也应该是合理的吧。

单元测试一般是有开发人员或测试人员来做。谁来做并没有一个绝对的标准，要根据公司的实际情况来决定。接下来我们分析一下开发人员或测试人员做单元测试的优缺点：

开发人员做单元测试：

优点：开发人员对代码最熟悉，而且开发人员编程技能相对比较强，所以开发人员自己写单元测试效率上和覆盖率上都比较高 缺点：开发人员平时写业务代码就要花费很多时间，有时候确实没有时间写单元测试；而且大部分开发人员没有太好的测试思想，单元测试可能只是写个最简单的用例就完了；自己写的代码自己测，往往都是不靠谱！

测试人员做单元测试：

优点：测试人员有比较系统的测试思想，可以更好地保证用例的覆盖。而且通过写单测测试能更好地了解具体代码结构、流程，对于后续的业务测试也非常有利。 缺点：测试人员的编程技能相对比较弱，如果不同编程是无法开展单元测试的。并且测试人员对代码没有开发人员熟悉，效率会比较低。

#如何做

单元测试的实现方式包括：人工静态检查、动态执行跟踪

人工静态检查：就是通常所说的“代码走读”，主要是保证代码逻辑的正确性 动态执行跟踪：就是把程序代码运行起来，检查实际的运行结果和预期结果是否一致

#人工静态检查

人工静态检查包含的主要内容：

1. 检查算法的逻辑正确性
2. 模块接口的正确性检查
3. 输入参数有没有作正确性检查
4. 调用其他方法接口的正确性
5. 异常错误处理
6. 保证表达式、SQL语句的正确性
7. 检查常量或全局变量使用的正确性
8. 程序风格的一致性、规范性
9. 检查代码注释是否完整

#动态执行跟踪

动态执行跟踪需要编写测试脚本调用业务代码进行测试，为了更好的管理维护测试脚本，一般会采用单元测试框架来管理，不同的语言有不同的单元测试框架：

1. Java：JUnit、TestNG
2. Python：UintTest、pyTest

单元测试的一个重要的衡量标准就是代码覆盖率，尽量做到代码的全覆盖。常见单元测试覆盖标准：

1. 语句覆盖
2. 分支覆盖
3. 条件覆盖
4. 分支-条件覆盖
5. 条件组合覆盖
6. 路径覆盖

#集成测试

集成测试，也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求（如根据结构图）组装成为子系统或系统，进行集成测试。

集成测试主要目的是测试模块之间的接口。 由于多种原因，仅单元测试是不够的，例如：

1. 模块/单元通常由单独的软件开发人员设计，其技术和编程逻辑与其他程序员不同
2. 通常在模块开发时，用户需求会发生变化，并且这些新需求可能未经过单元测试。这引发了问题
3. 在单元测试期间，有时会遗漏诸如数据格式，错误陷阱，硬件接口和第三方服务接口之类的问题

因此，无论每个模块/单元的运行效率如何，如果它们未正确集成，都会影响软件程序的功能。

集成测试目的：

1. 确保集成模块按预期正常工作
2. 它检测与模块之间的接口有关的错误
3. 帮助模块与API和其他第三方工具进行交互
4. 通常覆盖大量系统，因此效率更高
5. 增加测试范围并提高测试的可靠性

#如何做集成测试

集成的含义非常简单–将经过单元测试的模块一个接一个地组合，然后测试组合单元的功能。

通常，集成测试是在单元测试之后进行的。一旦创建并测试了所有单个单元，我们便开始组合那些经过测试的模块并开始执行集成测试：

1. 准备测试整合计划
2. 确定集成测试方法的类型
3. 相应地设计测试用例，测试场景和测试脚本
4. 一起部署所选模块并运行集成测试
5. 跟踪缺陷并记录测试结果
6. 重复上述步骤，直到测试完整个系统

#集成测试的方法

#全量整合测试

在这种测试方法中，一旦所有模块分别开发和测试，它们将被集成一次并立即一起测试。这种测试的唯一优点是，它非常适合于较小的系统。

缺点

1. 故障定位很困难
2. 测试之前有很多延迟
3. 关键问题没有得到优先解决
4. 很难找到问题的根本原因

#增量集成测试

通过将逻辑上相关的两个或更多模块连接在一起来执行增量测试。

后来又添加了更多模块，并对其功能进行了测试。直到完成所有模块的集成并成功测试为止。

它又分为自上而下方法，自下而上方法。

#自上而下的集成测试

自上而下的方法从测试最顶层的模块开始，然后逐步地逐步降到最低的一组模块。

测试按照软件系统的控制流程从上到下进行。由于在测试顶层模块时有可能未开发出较低级别的模块，因此我们使用存根而不是那些尚未就绪的模块。

对于简单的应用程序，存根将简单地将控件返回其上级模块。对于复杂的应用程序，他们将模拟整个响应范围。

优点

1. 故障定位更容易
2. 测试产品极为一致
3. 与驱动程序相比，可以以更少的时间写存根
4. 关键模块经过优先级测试
5. 尽早发现主要设计缺陷

缺点

1. 需要几个存根
2. 对早期发布的支持不佳
3. 在周期结束时测试基本功能

#自下而上的集成测试

自下而上的方法从测试应用程序的最低单元开始，然后逐步地逐步进行。

从控制流的底部到向上进行测试。同样，在测试较低的模块时，可能尚未开发出较高级别的模块。

在这种情况下，我们通过使用驱动程序来模拟缺少的模块的功能。这些驱动程序执行一系列任务，例如调用被测模块，传递测试数据或接收输出数据。

优点

1. 在这里，开发和测试可以一起完成，从而使产品高效
2. 测试条件很容易创建

缺点

1. 需要几个驱动程序
2. 数据流测试很晚
3. 需要驱动程序使测试数据管理变得复杂
4. 对早期发布的支持不佳
5. 关键接口缺陷发现较晚

#系统测试

系统测试包括测试完全集成的软件系统。通常，计算机系统是通过软件集成制成的。

换句话说，一组软件的计算机系统执行各种任务，但只有软件才能执行任务; 软件必须与兼容的硬件接口。

系统测试是一系列不同类型的有目的的测试行使和审查针对需求的集成软件的计算机系统的全部工作。

1. 测试包括外部外围设备在内的完全集成的应用程序，以检查组件之间以及整个系统之间如何交互。这也称为端到端测试方案。
2. 验证对应用程序中每个输入的全面测试，以检查所需的输出。
3. 测试用户对应用程序的体验。

#UAT 测试

UAT，(User Acceptance Test),也就是用户验收测试，或用户可接受测试,这时相关的用户或独立测试人员根据测试计划和结果对系统进行测试和接收。

在产品上线前，我们需要对整个项目每个细节功能都测试一遍，以确认功能没有问题的前提下，才能上线推出市场给真正的用户使用；

这个过程，也是产品上线前的必经阶段，少了这个环节，可能会发现上线后面临急需修复或者影响用户的体验的问题。

系统测试和UAT测试的差别？

1. 系统测试：系统测试是在系统未交付使用制作方自行进行的测试，无用户参与。只有本方用户参与。
2. UAT测试：是本方人员和用户方一起实行的测试。

#步骤编辑

百度百科， 比较全面

1. 用户培训手册准备（就是针对要进行UAT测试的对象，及要进行培训的用户，准备一些培训资料：一般是测试对象使用/功能手册及要培训的用户的个人资料等等：就跟教师上课进行备课差不多）
2. 测试脚本发放（如果你公司采用自动化测试，那么每一个功能或一个模块等都有对应的测试脚本，可以把这些测试脚本分发给特定的人员；如果采用手工测试，就要把详细描述一个功能或模块的文档分给相关人员（当然自动化测试也要分发）
3. 用户补充业务测试场景和测试数据（就是：请有代表性的一些最终用户根据实际应用环境及一些常用处理的数据，来给一些补充与建议，越贴近实际应用越好）
4. 顾问补充测试步骤（你可以请项目专家，测试经理，或专门的测试，开发等顾问对测试步骤进行补充）
5. 培训资料及测试脚本文档的确定与最终输出(一般到此，各种资料都基本确定，这时可以将它们进行打印，或形成特别的电子文档）
6. 测试策略的制定
7. 测试用户的确定（大体上从培训人员中选取，因为不是每个接受培训的人员都能有资格去测试的，这里你可以通过一些考核来实现人员的筛选等等）
8. 由专门的测试组织机构确定测试地点，并发出通知
9. 测试网络环境的搭建和保障（包括网络，系统，硬软件，包括一些case工具等）
10. 组织进行测试
11. 评审分析提交的问题（这就进入了一般bug处理过程，形成了一个循环）

#成功关键

1. 培训的资料表述要准确全面，易懂等（这是理论基础）
2. 人员选择，要典型有代表性（用户基础）
3. 测试流程步骤（要周密）
4. 测试策略制定（确定一个适合测试对象及测试人员的测试策略）
5. 问题的表达与处理(因为测试者不是专业开发测试人员，对于问题的表达可能不能到位，或根本就不是那种问题，这就存在如何复现与转化问题等）

所有的测试都是保证软件高质量的交付！

我们