软件质量体系【测试】理念
1. 测试是Team所有成员的责任；
2. 测试的目的是：持续性，自动化，层次化，可视化，智能化的保证质量 ~ 而不仅仅是寻找缺陷
3. 测试人员的核心是对产品/技术/业务/场景的理解 + 多维度/多层次的质量保证体系；
4. 测试是贯穿整个产品规划/开发/交付流程，从产品设计 - 产品持续交付 ~ 而不仅仅在开发阶段；
5. 质量问题的成本随着时间呈指数级上升；
6. 测试的质量还包括用户体验，是否真正满足用户需求以及安全等问题。
1. 测试是Team所有成员的责任；
测试就像足球运动中的守门员，开发/产品/项目经理等角色就像在球场踢球的人。不失球的防守是从前锋开始，防守的最后一道关才到守门员。假设踢球的人不防守，请问守门员能防守的对方的进攻吗？
2. 测试的目的是：持续性，自动化，层次化，可视化，智能化的保证质量 ~ 而不仅仅是寻找缺陷
测试的四个原则：
1.自动化：测试任务的增加，要求测试人员必须把主要的精力用于将测试自动化，摆脱手动测试带来的沉重负担。当然，自动化测试必须足够稳定、稳健，不能动辄误报，否则反而会导致很高的维护成本。
2.层次化：这意味着采用分层次的测试方法，粒度由细到粗，范围由小到大。
3.可视化：为了降低交流成本，最好的办法就是让所有的测试结果可视化。这意味着将构建（Build）、测试（Test）、部署（Deploy）所有这些相关任务构建在一个流水线之中，让所有团队成员都可以随时监控项目进度，找到阻碍项目的瓶颈。
-
4.智能化：在架构设计，单元测试，集成测试，端到端测试，探索测试，线上日志等，智能的评估产品的质量体系，通过可视化的形式输出，持续性的改进质量。
智能化测试模型.jpg
五维测试模型：
- 单元测试（Unit Test）
用于验证微服务内部的类方法或函数的行为。它们会根据测试框架，执行代码文件里的类方法或函数，提供不同的输入，并验证与每一个输入相对应的输出。 - 集成测试（Integration Test）
用于验证微服务与外部模块的通信或者交互行为。测试框架会启动服务的一个实例，并调用服务的外部接口来执行业务逻辑。 - 组件测试 （Component Test）
即验证微服务能否起到预期的作用。这需要把微服务周边依赖的所有其他服务或者资源全部模拟化，从该服务外部“用户”的角度来检查服务能否提供预期的输出。 - 端到端测试（End-to-end Test）
验证整个系统的功能能否符合用户的预期，一般是从 UI 层面进行测试，确保用户体验完全达到客户要求。 - 探索测试（ Exploratory Test，即手动测试或随机测试）
3. 测试人员的核心是对产品/业务/场景的理解 + 多维度/多层次的质量保证；
测试人员的核心对产品/技术/业务/场景的理解，优秀的测试团队必须理解：
1. 用户的需求，产品的定义和边界；
2. 技术的框架、临界条件和核心pipline；
3. 用户使用的真实场景和场景内的变化环境；
测试(质量保证)是多维度/多层次，常见的测试体系包括：
1. 单元测试（Unit Test）
2.集成测试（Integration Test）
3.组件测试 （Component Test）
4.端到端测试（End-to-end Test）
5.探索测试（ Exploratory Test，即手动测试或随机测试）
除基本的测试之外，还包括
1. 用户体验/交互；
2. 专项测试(功耗，性能，内存等)；
3. 线上质量追踪；
4. 测试是贯穿整个产品规划/开发/交付流程，从产品设计 - 产品持续交付 ~ 而不仅仅在开发阶段；
测试的起点在产品规划，而非在版本交付。在产品设计阶段，测试需要深入了解客户需求，产品逻辑等。通过对需求，场景和产品的理解，设计整体的测试方案，测试用例，提前对单元测试，集成测试，组件测试等提出方案。
在产品前期，测试人员需要大量的工作准备测试方案，用例，自动化/可视化/智能化平台。通过测试驱动，对后续开发和交付阶段提出质量需求。
5. 质量问题的成本随着时间呈指数级上升；
如图所示，在不同阶段解决问题的成本随着时间的推移指数级上升。同样的问题，在系统测试的成本是在单元测试(开发人员设计单元测试)阶段的1000倍。更为重要的是，可能由于质量问题错过产品的窗口期，带来毁灭性的灾难；
下图为时间-成本示意图：
6. 测试的质量还包括用户体验，是否真正满足用户需求以及安全等问题。
商业的本质是满足需求，同样测试的核心目的之一是确认能否满足用户需求，以及其用户体验。一个产品的成功是为了用户价值，脱离用户价值，测试不具有意义。
用户体验包括两个维度，一是最终的用户体验，二是内部交付的用户体验；
在测试的过程中，需要满足安全等需求，例如：
1. 客户的隐私；
2. 数据的安全性；
3. 系统的安全性；
......；
参考：
