敏捷测试的基本原理流程，持续集成
敏捷测试的基本原理流程，持续集成1.修正质量指标敏捷测试的目的是为了持续地开展如下活动：自动化测试工具分类：目前主流的自动化测试工具自动化测试的优势
「持续集成 Continuous Integration」
「持续交付 Continuous Delivery」
「持续部署 Continuous Development」
自动化测试是在预设状态下运行应用程序；预设条件包括「正常」，「异常情况」
自动化测试工具分类：
- 性能测试工具
- 功能测试工具
- APP自动化测试工具
- 接口自动化测试工具
- 单元测试工具
目前主流的自动化测试工具
自动化测试的优势
敏捷测试四象限
敏捷测试的目的是为了持续地开展如下活动：
1.修正质量指标
2.明确测试策略
3.确认用户的有效需求能圆满完成
4.确保整个生成过程是安全的
5.能更及时地布最终产品
敏捷测试四象限
「敏捷测试四象限」是「敏捷测试」的核心面向不同象限的价值：
1.支持团队（支持编程）：单元测试，组件测试让程序员准确理解代码需要做什么（TDD测试驱动开发），及提供正确设计的指导从而保证质量
2.面向业务专家：目的是定义及验证质量，从而帮助了解核实完成
3.评估项目：业务人员或业务用户通过实际接触软件，从业务的整体去评判软件产品
4.面向技术人员：从技术角度去评价用户不一定能关注到的非功能性需求；帮助交付高质量产品
集成测试下的测试要求快速，便捷，及时，可信
测试金字塔
测试金子塔模型，“圆筒冰淇淋模式”不适用于持续集成
微服务构架下的测试金子塔
1. 单元测试：通常只测试一个函数或者方法的使用，验证结果是否符合预期；【高质量，高覆盖率的代码测试是代码质量的第一道保护伞】
2. 接口测试：主要的关注点是内部接口功能实现是否完整，比如说内部逻辑是不是正常，异常处理是不是正确。【它是单元测试和契约测试的过渡阶段，它是项目单个代码逻辑最终串联形成有价值业务逻辑的桥梁】
3. 契约测试分两种类型，一种是消费者驱动，一种是提供者驱动:其中最常用的，是消费者驱动的契约测试（Consumer-Driven Contract Test，简称 CDC）。核心思想是从消费者业务实现的角度出发，由消费者端定义需要的数据格式以及交互细节，生成一份契约文件。然后生产者根据契约文件来实现自己的逻辑，并在持续集成环境中持续验证该实现结果是否正确。对于基于Restful API的微服务来说，它的契约就是指 API 的请求和响应的规则【总的来说，就是判断是否真正能满足服务消费者的需求】
4. 集成测试：测试各个模块之间的交互是否正常，也占据了相当重要的地位；在微服务下，把各个子模块合并到一起；看看子系统是否存在问题；【检查模块之间的交互，或者通信是否顺畅，准确；是否以预期的方式进行协作】
5. 组件测试：在微服务架构中，组件实际上就代表了微服务本身；【组件测试就是检查内部功能是否完整，内部逻辑是否正确；异常处理是否正常】
6. 端到端测试：从UI层开始执行，目的是检查整个软件系统，是否符合用户的预期，需求；一个常规功能页面展示的背后，往往涉及多个服务；【运行端到端测试需要部署多个服务，这样测试能有更广的覆盖面；端到端测试的缺点：测试不稳定，定位问题难...等】
