-------------------------------------------------
缺陷意味着返工，返工意味着浪费
有效的质量控制措施：
n 准确完整描述用户需求
n 关注非功能性需求
n 质量内建在开发过程之中
n 小循环快速获取验证反馈
n 自动化、自动化、自动化
n 信息公开透明，授权决策
n 适度架构，组织和架构匹配
n 从失败中吸取教训
--------------------------------------------------------------------------
测试金子塔和测试受创面
代码-->单元测试-->集成测试-->接口测试-->UI/功能测试-->生产环境部署
单元测试
n 自动/手工
n IDE/流水线内执行
n 单个代码文件即可执行
n 无需部署
n 速度快
n 职责：开发人员
n 工具:junit等测试框架
集成测试：
n 自动/手工
n IDE/流水线内执行
n 单个/多个代码文件即可执行
n 可能需要部署
n 速度比较快
n 职责：开发人员
n 工具：基于测试框架或者手工完成
接口测试：
n 自动/手工
n 特定环境中执行
n 单个服务部署完成(微服务)
n 需要部署
n 速度较慢
n 职责：开发/测试人员
n 工具：
UI/功能测试：
n 自动/手工
n 特定环境中执行
n 系统完整部署完成
n 需要部署
n 速度慢
n 职责：开发/测试人员
n 工具，Selenium
自动化测试是某种类型测试的一种状态
单元测试：不需要在部署环境中就能测试
测试金字塔和软件生命周期：
---------------------------------------------------------------------
微软测试管理策略的演进
L0:每次嵌入，只需要运行时文件就可以运行，在CI中执行，必须迅速可靠
L1:每次嵌入，但需要依赖环境资源
L2:必须针对特定的“环境运行，逐步清理”
L3:直接在生产环境运行
原则：
n 测试应用在最低代码层级编写
n 编写一次，可在所有环境运行(包括生产环境)
n 可测试性事设计的重要目标
n 将测试代码看作生产代码的一部分，仅保留可以稳定运行的测试代码
n 微测试提供可自动获取的共享资源
研发效能提升的核心秘籍
管理粒度：DevOps从管理角度优化永远实在通过控制“管理单元”的粒度来完成的。所谓的“管理单元”可能是团队、需求，任务，测试，交付物等任何研发中的被管理对象
研发效能提升：无论是敏捷，精益或者持续交付，其最终目的都是为了提升效能。所谓“效能”，就是单位投入的产出量(效率)和组织实现目标的能力
工程解耦：DevOps从技术角度的优化永远实在通过解除“工程对象”之间的耦合实现的。所谓“工程对象”可能是系统，工具，代码，模块，服务，平添，云或者任何在研发过程中存在或者交付的技术对象。