开发者学堂课程【ALPD 云架构师系列-云原生 DevOps36计：基于持续测试的质量守护：分层测试、测试自动化、单元测试（一）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/82/detail/1290
基于持续测试的质量守护：分层测试、测试自动化、单元测试（一）
内容介绍
一、基于持续测试的质量守护
二、整体测试策略
三、质量与成本之间的平衡
四、质量的成本
五、分层测试-平衡质量与成本
六、发布过程
七、测试自动化
八、自动化测试的分层
九、测试自动化用例的反模式检查清单
十、测试自动化落地建议
十一、基于（预防）成本考量的单元测试选择性的策略
一、基于持续测试的质量守护
要做到上图的要求，举例：基于web服务端的开发现在大部分都在用微服务的方式。
现在打开一个服务的结构，如下图：
从这个结构里面可以看到，里面有资源层（领域之间的映射）。服务层还有相应的网关，与外界构成通信。最后是持久化，做一些与层组相关的。以上是典型的微服务里面应用的例子。
如果要建立质量保障，做一些相应的质量测试来守护它，那么整体的测试策略是什么样子呢？
二、整体测试策略
1、红色斜线：做单元测试的时候就可以保证质量。因为只把小框测了，也就是可能是这一块里面的模块。比如只测 service 内层的某一个接口或者某一个函数或者domain 里面的某一个函数。在这几基础上，再将框放大。
2、集成测试：也就是组件之间相应的能不能交互，之间的接口是否是正确的。
3、组件测试：再更大一点，也就是组件里面。红色框中的排除掉外部的依赖（外部依赖有两个：1、数据依赖；2、网络的消息依赖。）排除完之后作为一个整体的应用，里面的测试是什么样的？这时接口部分在偏外面的一层，更多的是和网关的接口，与数据持久化这一层接口有关的测试。
4、契约测试：之后要与外部做相应的交流，应用A和B之间会有协议存在，两个服务之间的交互，服务之间的交互要基于协议或者契约。也就是两者之间要有约定，谁是生产者，谁是消费者。在这个基础上保证服务与服务之间的交互应该是worked。将上述定义为契约测试，也就是我们之间的约定是 worked。
5、端到端的测试：最外面的框指的是端到端的测试，但是这里面的端到端不只是一个服务，一个应用；而是多个应用组和在一起，一个完整的系统。站在整个用户或者客户的角度来说，站到整个业务的请求来看它的测试。
从这个整体测试策略来看，发现最终验证这个东西是否提供正常的业务服务，只要测试端到端的服务就可以了。但是最完整的而且最贴近用户的真实场景的，所以端到端测试看上去好像做一个就够了。但是站在开发组件的角度来说，上述东西是与之无关的，因为只负责 service layer 这一层的修改。只要用单元测试保护一下就好了。所以站在不同的角色来看选择的测试是不一样的，在不同的时间阶段内选择的测试也是不一样的。所以整个选择什么样的测试，最终的目的是为了保证质量。在选择测试的过程中，需要考虑小小的因素，这个因素就是成本。
三、质量与成本之间的平衡
在整个测试策略的选择上来说，其实是在质量与成本之间做相应的平衡。看上图：纵轴表示的是成本，横轴表示的是质量。
1、红色的线：是质量的成本的一条曲线。也就是成本的曲线会随着质量的要求做相应的变化。也就是一开始的成本就很高，队质量要求很低。拐角是在成本最小的时候才能够达到相对的质量。
2、斜虚线：往上走的虚线是指不做相应的测试。认为投入做质量会有一些相应的成本，所以在一开始不考虑使用相应的手段来保证它的质量。所以在一开始，没有成本。因为没有做任何与质量相关的测试，只写代码，出现问题改正。但是随着缺陷越来越多或故障越来越多，这时再管理质量的成本就会越来越高，然后成子数集上涨。
往下走的虚线：认为质量就应该做到极致。在一开始还体现不出质量的时候就投入了非常多的成本在里面，但是在这里面需要达到一个平衡点。图中标明了平衡点。
根据以上的阐述，可以给质量分一个类。
四、质量的成本
1、低质量的成本
不愿意做会花什么成本。就会导致内部缺陷的成本。因为研发的过程中由于缺陷给研发过程带来种种制约，所以会有内部缺陷的成本。
外部缺陷的成本，这个问题一直留到了客户端，就可能会导致业务的损失。但是缺陷成本对研发者来说很低很低，其实就不用做这个质量。
例如只能做一次 poc，这个 poc 成不成，大概率是不成功的。做下去就不会再用它了，那么就无需再考虑后面质量的事情了。
2、高质量成本
另外需要得到特别好的质量，是需要付出成本的。一个是预防成本，一个是验证成本。验证成本在正在的质量管理的教科书内叫做评估成本。也就是需要评估一下质量的好坏。在这里改为较好理解的验证成本。
预防成本：在需求分析阶段，就应该将需求做的特别好，防止后面会出现各种各样的问题。在写代码的时候，也做的十分极致，这中间要花费的成本。
验证成本：怎么知道这个制品质量是特别好的，需要定义一些验收的案例，来去验证并且执行它。到底是否符合预期或者有什么问题是没有想到的。基于这些成本角度来说会发现选择什么样的测试在哪一个阶段里面，是取决于这些成本去考虑的。而且产品的生命周期处在哪一个阶段里面也是需要考虑的。（就如刚刚提到的poc阶段内其实是不关心的，那么投入的很多测试手段在里面要投入很多测试机器，需要很多人写测试用例，测试自动化的脚本，甚至有些测试的成本很高，一台测试设备就会需要上百万。这时候的投入就会太大了，是不经济的。从这个角度来看选择什么的测试策略是从经济学的角度考虑的。）
五、分层测试-平衡质量与成本
分层测试就是一种平衡质量与成本的手段。上图认为单元测试等级是最低的，接口/服务测试其次，UI 测试是最高的。所以在金字塔底座会有大量的单元测试，腰部是通过接口和服务测试支撑的，最上面才是少量的 UI 测试。但在实际情况下并没有这么理想，如果系统运行了很久，要构建单元测试的成本非常高。需要先制作框架、代码重构等各种各样的测试才能够探索单元测试，到时候的金字塔可能不是这个样子的，这只是一个范例，但可以依据现在的团队情况，业务场景自己画金字塔图，基本会画出三层结构。
如果现在能够投入的成本只能做相应简单的事情，那么就做 UI 测试。
如果投入了更多的成本，可以做相应的接口或者服务测试。
但是真正要把质量做到机制，那么就需要将每一个材料都用最好的。那么保证每一块材料的质量都很好。但是付出要与收益成正比，因为可能会投入很多但是收益非常少。这时成本就会很高。
在整个交互过程中，这些测试是怎么分布在发布过程中的。
六、发布过程
从特性的预集成到日程的集成到预发验证再到线上发布。以上就是上节课讲到的比较简单的从发布到集成到代码提交的过程。
静态检查、单元测试这些成本相对来说很低，写代码的时候顺便就会看到了。但是对有些团队来说新增单元测试确实很难测，后面会在单元测试内给大家相应的策略。
随着流水线，越往右质量就越高。因为是分集的，因为流水线是基于制品去流转的，是可以逐步的把质量去提升的。越到后面投入的成本就会越高，希望投入少量的成本，快速得到反馈，这时去做相应的修改，这个制品才有机会享受更高的待遇。这是站在这个角度来说怎么做相应的分层。
