开发者学堂课程【ALPD 云架构师系列：云原生 DevOps 36计-阿里云云效出品：全方位测试质量守护体系，保障交付质量】学习笔记，与课程紧密连接，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/772/detail/13517
全方位测试质量守护体系，保障交付质量
全方位测试质量守护体系，保障交付质量
这有一个简单的象限图，就是把日常生活当中和工作当中遇到的这些测试做了一个简单的一个分类，分类是怎么来看呢？
靠下的基本都是靠记，以技术实现为导向，而网上的都是从业务结果为导向，就是偏问题，另外一个靠右的是站在整个产品的角度来去看，有什么样的质量，靠左是站在整个团队在功能实现的过程当中涉及到的一些视角，看一下第一个标准的这一块象限。
基本上是单元测试和组件测试都放在这里，因为是偏技术实现的，而且是团队内部要搞定，像功能测试、工作流和场景性的测试包括用户体验测试和结对测试，是偏业务层的片功能级别的，但是也是属于团队，要去再做，实现的过程当中需要去做一些。
测试这里把它放在第二层，那第三里头来去看，就是站在整个产品的角度讲，偏业务的文件，所以有可用性测试，探索测试和客户绝对测试和用户验收测试。另外一块就是通过也是偏技术实现的角度来说，但是站在整个产品的完整性的角度来说验证下非功能性的测试项，押车性能测试，安全测试，数据迁移测试，扩展性和复合的这种，这里也给出了一些，具体是哪一部分应该是手工的，哪一部分应该是自动化的去完成。
有了这么多测试，要是把这些东西都做好，其实是投入的成本特别高，列出这么多，说明整个就是有分类的是有整个的包含的流程，在整个研发中的阶段也不一样，这些测试并不是都需要一股脑地拥上去，放到一个地方去做，所以基于这一个，有了一些完整的一些测试分类，看一下在整个软件交付的整个生命周期是如何来去合理安排他们的？
每一个测试应该放在哪些阶段，其实是有一个质量保障体系来去定义的，这是一个企业里比较常见的一个质量保障体系，让我们来去看：
从左往右来看一下整个交付过程，看有哪些质量。比如从上面需求，因为从最开始软件交付的一开始是拿到了需求，开始做需求评审，开始做架构设计，这时其实需求的质量和价格的质量就是非常重要的。如果这时候的质量出问题之后，后面做的所有的事情可能都是有问题的。
然后需求和架构明确下来之后，开始做编码，做开发，所以这时代码质量，安全的质量就是就上来了，因为安全在地方，就是在一开始的时候，就需要做的事情做一个安全的考量，接下来就到了整个编码的测试验证阶段，所以整个的测试质量，数据质量，稳定性质量，然后当测试告一段落之后，就需要上系统去压测了，所以就开始考虑性能，考虑用户体验，所以就有了性能质量，用户质量。
发布之后还要考虑发布之后的运维的一个情况，线上用户的反馈是什么样子，所以整个会有一个非常全面的一个质量评估到底，系统是什么样子的，往下看，就是看到中间有很多很多的实践，比如自动化测试的各种实践，稳定性测试的实践，用性能测试的实践和安全测试的实践，每个里面都有很多，现在可能已经在用，或者将要用的一些实践方式，然后再往下是整个基础平台和流程支撑，就是要承载上面这么多的测试，需要很多的基础的，比如环境这些，然后还有整个事情做得如何，做得好不好，有没有什么问题，需要一双眼睛来看，所以这是我们最后小项，是一个相对来说比较完整的一个保障体系，当然层次比较高，比如可能对于一线的工程师来讲，比较关注的是怎么来去做这种图片对比的测试，或怎么来去做这种演练，在过程当中，后面可以再简单的给大家做一些相应一些介绍，有了一个完整质量保障体系，接下来已经知道，要去做质量保障，要有相应的一些措施，由谁来去做这件事情呢？
中间其实从需求到开发到测试。都在这条生命周期上。觉得应该做质量保证的事情，所以从这角度来讲如果需求质量的话，很容易想到应该是产品，应该来去把需求质量，代码质量应该开发了，那比如像素试质量和发布质量，这时是应该测试或者运维同学来去保证，所以这时候在整个过程当中，涉及到的角色是方方面面的，而且每一个角色都应该是为这些质量负责。
如果是按整个生命交付周期的话，偏左这一侧，认为是上游下面偏右这一侧的，认为是下游，也就是整个软件完整的交付的周期当中，上下游所有的角色都应该参与，所以可以简单看一下，质量是团队所有人。左边看有一个很有意思的一个漫画。
胶水的都在内侧，也是很常见的，看需求质量不好快去改，去改好等着你，就是这种情况，其实我们很多人都遇到过，比如质量我是测试该负责的质量是需求，该负责的货质量或者用来打底的，都有这样的情况。但事实上，我们每个人都只是在船上，同一条船上，船要漏了，其实我们一起下去，这里有一个比较有意思的一个例子就是有的团队，他说要开发，要自测，之所以质量不好，是一种开发，自测的质量不好，站在开发的角度来说，有测试，之所以质量不好，是因为测试兜底不够，在整个过程当中其实如比如大家是站在所有明确的一个标准，作为一个需求，需要达到一个什么样的一个标准，作为代码需要达到一个什么样目标。每一个阶段有相应的一个标准的一个定义，这是需要明确的是这种药物。
还有另外一个，每一个上游永远要考虑下游，能很好的帮助下一个很好的把工作给做好，如果不去考虑，比如在做架构的过程当中，不测试，等到要测试的时候，是没有办法去做这件事情的。会非常非常麻烦去遇到问题，其实在可靠性这一点上，记得之前遇到过一个非常有意思的例子，因为当时架构升级事情做完的时候才看到是怎么做的，然后就发现一个非常严重的问题，单纯把应用假设要想部署起来是完全没法测，一定要跟生产环境，在一块才能测试，这就非常扯了，因为为了改一个东西，让他上生产环境，但是如果固在一起，发现没法测试，因为在整个架构设计里面把他写死。这样就带着客户就说大家发现为了测试，现在改代码，让代码能够在生产环境以外的地方测试，然后才做后续的事情。
另外一块一个点一般来讲测试，有的时候如果做测试自动化的话，会有相应的一些测试代码，测试代码可能会涉及到像有一些通用的一些部分，可能会涉及到几个团队都要去共用的，这时如果没有很好的去分配，不会没有一种ownership的叫collective Co ownership，就是代码集体所有制，没有建立好标准化，测试代码也容易成为一个工地危机，所以在这事情上来讲，质量还是团队的所有人的事情，而且刚才强调的一个质量，团队所有人的事情的时候，上游的人，应该配个更重大的一个角色，就是做的更好一点，下游可以省了很多很多事情，待会可以在质量和成本的里可以做更多的一个讨论，现在已经知道质量的负责应该是谁来负责。
具体在哪个阶段里应该由谁负责，这时取决于定义的一个标准是什么整个在要去做到持续的交付，或者易发的频繁要发的频繁，意味着要做持续的发布，因为既然是持续发布，那就意味着要持续的代发，要持续待发布，一定要有持续的测试来保证在发布，所以一定要有持续的测试，才能够有持续的质量守护。
