开发者学堂课程【ALPD 云架构师系列-云原生 DevOps36计：全方位的测试质量守护体系，保障交付质量】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/82/detail/1289
全方位的测试质量守护体系，保障交付质量
内容介绍
一、象限图
二、质量保障体系
三、质量是团队所有人的事
四、基于持续测试的质量守护
一、象限图
在这里有一个简单的象限图，把日常生活的当中和工作当中遇到的测试做了简单的分类。
靠下的都是以技术实现为导向的，上面的是以业务结构为导向的，偏问题。
右面的是站在整个产品的角度来考虑问题的。左边的是整个团队在功能实现过程中的问题。
1、单元测试、组件测试
因为是偏技术实现的，团队内部就可以决定。
2、功能测试、工作流/场景实例测试、用户体验测试、结对测试
这种是偏业务型的，偏功能级别的，但是也是团队要做实现的过程中做一些测试。因此放在二象限。
3、可用性测试、探索测试、客户结对测试、用户验收测试
站在整个产品的角度，是偏业务类型的。
4、非功能性测试（压测、性能测试）、安全测试、数据迁移测试、扩展性测试、负荷测试
偏技术实现的角度。但是站在整个产品的完整性来说做了验证。
图中也给出了哪一部分是手工的，哪一部分是自动化的。
有了以上测试，想要将以上东西都做好，讨论的成本是特别高的。象限图是有分类的，包含整个的流程，在研发中的阶段是不一样的。这些测试并不是一次性都用在一个地方。
二、质量保障体系
有了完整的测试分类，接下来看一下在整个软件交互的整个生命周期内是怎么来合理安排他们的。每一个测试应该放在什么阶段实际上有一个质量保障体系来定义的。下图是企业中常见的质量保障体系：
整个交互过程从左到右看有哪些质量。
例如上面的需求，在软件交互的一开始拿到需求，开始做需求拼设，架构设计。
这时的需求质量和架构质量是非常重要的。如果这个时候质量出了问题后面做的所有的事情都会出现问题。需求和架构明确下来之后开始做编码和开发，这时的代码和安全质量就有所提升。
安全：在一开始就要队所有做的事情进行安全考量。接下来就到了编码的测试验证阶段，所以整个的测试质量、数据质量和稳定性质量就提高了。
当测试告一段落之后就需要上系统测试了，就需要考虑性能质量、用户质量。发布之后还要考虑运维情况和线上用户的反馈情况。整个会有一个非常全面的质量评估，到底系统是什么样子的。
往下看会发现在中间有很多实践：自动化测试的各种实践、稳定性测试的实践、性能测试的实践、安全测试的实践。每个里面都有现在要用或者将要用的一些实践方式。
再往下是基础平台和流程支撑，就是要承载上面的测试需要很多的基础，例如：环境等技术用来支撑。
整个事情做的好不好、有没有什么问题，需要一双眼睛来看。这是最后的度量。
以上是一个比较完整的保障体系，当然层次比较高可能对于一些工程师来说关注的是怎么来做这种图片对比的测试、怎么进行容灾演练后面会做相对应的介绍。
有了以上完整的质量保障体系，已经知道要做质量保障有相应的一些测试，那么由谁来做这个测试呢？
在这个中间从需求到开发到测试到运维都在这条生命周期上。那么质量保障的事情由谁来做呢？从这个角度来说，如果是需求质量的话很容易想到是产品应该保证需求质量。但是转化到代码质量之后，好像又不是产品了。测试质量和开发质量由运维来保障。所以这时会发现在整个过程中涉及到的角色是方方面面的，每一个角色都应该为这些质量负责。
如果按照整个生命的交互周期的话，偏左一侧认为是上游，偏右一侧是上游。也就是说整个软件的完整的交互周期当中，上下游所有的角色都应该参与到这个里面中。
三、质量是团队所有人的事
1、质量应该有明确的标准
上图中左面有一副漫画，一个人在说：sure glad the hole isn‘t at our end。指的是幸亏这个洞不在我这一侧，因此浇水的人都在另一侧。也就是很常见的需求质量不好需要去修改好。例如：质量是测试该负责的，质量是需求该负责的或者运维来打底的，都有这样的情况。但事实上每个人都在同一条船上，这个船要漏了是会导致一起掉到水中的。
2、开发、测试、运维都需要参与质量保证
有些团队要开发、要自测，之所以质量不好是因为开发自测的质量不好。站在开发的角度来看，我们有测试，之所以质量不好是因为测试兜底兜的不好。所以在整个过程中，不论是站在所有明确标准作为一个需求能够达到什么样的标准。作为代码需要达到什么样的标准。每一个阶段有一个相对标准的定义，这是需要明确的。
3、将可测性作为架构设计的重要原则
另外每一个上游永远要考虑能不能帮助下游把工作做好。例如在做架构的时候，不去考虑可测性的问题。等到要测试的时候是没有办法来做这件事情的，遇到这个问题是非常麻烦的。
可测性：当架构升级做完之后才看到是怎么做的，之后发现非常严重的问题，当时只是单纯将应用部署起来是完全没办法测的。必须要把生产环境部署在一块才能测试。但是这就很麻烦了，因为只是为了改一个东西使它上市上环境，但是不把他们部署在一起，是没有办法测试的。因为在整个架构测试里面就把它写死了。这样带来的后果就是为了测试天天都在写代码，让代码能够在生产环境以外的地方测试然后再做后续的事情。
4、避免测试代码的“公地危机”
一般来说做测试优化的话会有测试代码，而测试代码可能会涉及到一些通用的部分。可能会涉及到几个团队大家都要去共用，这时如果没有很好的维护，没有建立好代码集体所有制的话，那么测试代码也会成为一个“公地危机”。
因此质量是团队所有人的事情。而且质量是团队所有人的事情，上游应该take更重大的角色，做的更好一点，下游会省很多事情。这个之后会在质量和成本内做更多的讨论。
所以现在知道质量的负责是谁来负责，具体的在哪一个阶段里由谁负责，这时取决于定义的标准是什么。
四、基于持续测试的质量守护
所以整个做到持续的交互的话，例如发的容易、发的频繁，意味着需要做持续的发布，持续发布的话就要持续的待发布，持续待发布就要持续的测试来保证持续的待发布。
所以一定要有持续的测试才能够有持续的质量守护。
