# 测试相关知识
# 1.单元测试
金字塔最底部是单元测试，属于白盒测试的范畴，通常由开发工程师自己完成，由于越早发现缺陷其修复成本越低，所以传统软件产品的测试策略提倡对单元测试的高投入，单元测试这一层通常都会做得比较“厚”。
另外，传统软件产品，生命周期都比较长，通常会有多个版本持续发布，为了在后期的版本升级过程中能够尽早发现并快速定位问题，每次build过程中都会多次反复执行单元测试，这也从另一个角度反映出单元测试的重要性。
# 2.API测试（灰盒测试（利用代码覆盖率）或者黑盒测试）
金字塔中间部分是API测试，主要针对的是各模块暴露的接口，通常采用灰盒测试方法。灰盒测试方法是介于白盒测试和黑盒测试之间的一种测试技术，其核心思想是利用测试执行的代码覆盖率来指导测试用例的设计。
以API接口测试为例，首先以黑盒方式设计如何调用API的测试用例，同时在测试执行过程中统计代码覆盖率，然后根据代码覆盖率情况来补充更多、更有针对性的测试用例。
总体来看，API测试用例的数量会少于单元测试，但多于上层的GUI测试。
# 3.GUI测试（Graphical User Interface，简称GUI，又称图形用户接口）
金字塔最上层的是GUI测试，也称为端到端（E2E，End-to-end）测试，是最接近软件真实用户使用行为的测试类型。通常是模拟真实用户使用软件的行为，即模拟用户在软件界面上的各种操作，并验证这些操作对应的结果是否正确。
GUI测试的优点是，能够实际模拟真实用户的行为，直接验证软件的商业价值；缺点是执行的代价比较大，就算是采用GUI自动化测试技术，用例的维护和执行代价依然很大。所以，要尽可能地避免对GUI测试的过度依赖。
另外，GUI测试的稳定性问题，是长期以来阻碍GUI测试发展的重要原因。即使你采用了很多诸如retry机制以及异常场景恢复机制等方式，GUI测试的随机失败率依旧高居不下。
后端服务又可以进一步细分为应用服务和基础服务。
总结来讲，互联网产品的全面单元测试只会应用在那些相对稳定和最核心的模块和服务上，而应用层或者上层业务服务很少会大规模开展单元测试。
页面对象模型和业务流程封装
在正式讨论测试数据的创建方法前，我先来分析一下GUI测试中两种常见的数据类型：
- 第一大类是，测试输入数据，也就是GUI测试过程中，通过界面输入的数据。比如“用户登录”测试中输入的用户名和密码就就属于这一类数据；再比如，数据驱动测试中的测试数据，也是指这一类。
- 第二大类是，为了完成GUI测试而需要准备的测试数据。比如，“用户登录”测试中，我们需要事先准备好用户账户，以便进行用户的登录测试。今天我分享的测试数据创建的方法，也都是围着这一部分的数据展开的。
综合运用API调用和数据库操作创建测试数据
GUI自动化测试稳定性，最典型的表现形式就是，同样的测试用例在同样的环境上，时而测试通过，时而测试失败。
五种造成GUI测试不稳定的因素：
非预计的弹出对话框；
GUI自动化测试用例执行过程中，操作系统弹出的非预计对话框
被测软件本身也有可能在非预期的时间弹出预期的对话框
页面控件属性的细微变化；
被测系统的A/B测试；
随机的页面延迟造成控件识别失败；
测试数据问题。