08.持续交付中测试管理策略笔记

-------------------------------------------------

缺陷意味着返工，返工意味着浪费

 

 

 

有效的质量控制措施：

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从技术角度的优化永远实在通过解除“工程对象”之间的耦合实现的。所谓“工程对象”可能是系统，工具，代码，模块，服务，平添，云或者任何在研发过程中存在或者交付的技术对象。