一、质量保障的思考
定义
先引用一段 百度百科 上对软件质量保障的解释：软件质量保障是建立一套有计划、系统的方法，来向管理层保证拟定出的标准、步骤、实践和方法能够正确地被项目所采用。软件质量保障的目的是使软件过程对于管理人员来说是可见的。它通过对软件产品和活动进行评审和审计来验证软件是合乎标准的。软件质量保障人员在项目开始时就一起参与建立计划、标准和过程。这些将使软件项目满足机构方针的要求。
从我个人对软件质量保障的理解来说，软件质量保障不能只从测试（QA）的角度来看待问题，需要把自己抽离出来从更高的角度（公司/老板）来看待问题，无论哪一个环节出了问题，都是质量问题。可能是产品在设计之初时就存在缺陷，可能是开发在编码之前就存在设计上的缺陷，也可能是QA在测试时存在漏测的情况。需要关注整个过程当中的所有环节存在的问题和风险。
对于软件质量保障的思考，我们可以从测试前、测试中、测试后三个阶段来进行，重点应该关注如下五个方面：
- 代码质量问题
- 效率问题
- 流程问题
- 机制问题
- 沟通问题
如何思考
对于不同公司、不同团队甚至不同业务，质量体系的建设不是千篇一律的，每一个公司/团队/业务都有其自身的特点，我们需要根据这些特点来思考如何建设质量体系。但是通常我们可以将它划分为三个阶段：
测前
1、差异性分析
- 业务特点
- 对各自负责业务的差异性分析
- 分析各自业务测试时的痛点、难点
- 团队人员组成特点
- 开发和测试技术水平如何，把人员安排在合适的位置
- 整个团队的技术栈，包括测试和开发
- 产品部署使用方式
- 阿里云
- 实体服务器
差异性分析主要是为后面的测试方法和手段做准备的，比如说：开发人员的水平不行，那我们测试时可能就要考虑使用 白盒测试 + 接口测试，因为单单只根据需求和接口文档来做接口测试，很多情况测试不到。如果开发水平足够高，那么可以考虑不用做白盒测试，直接做接口测试。另外，做白盒测试时，可以根据本次版本修改的方法上游被哪些地方调用，下游调用了哪些方法从而确定测试的范围，而不是盲目的拍脑袋来决定测试范围。
2、基本测试手段/方法
- 接口测试 + 白盒测试
- 性能测试 + 稳定性测试
- 业务功能测试 + 自动化测试
3、流程及机制
- 测试流程的建立
- 问题发现/解决的流程
- 风险暴露机制
- 线上问题跟进
- 故障处理机制
- 信息同步机制
- 奖惩机制
- 新人培养计划
4、基本保障手段
- Mock 服务
- 数据构造
- 持续集成
- 环境建设
- 线下告警平台
- 线下压测平台
测中
- 测试
- 联调
- 预发
测后
- 上线流程机制
- 稳定性建设：保障系统在全年的不可用时间在什么范围之内
- 考虑建设目标和业务上的目标是否一致
- 梳理现有的能力情况
- 监控报警是否完善
- 核心业务是否都有监控
- 监控的添加是否合理
- 监控的优先级设置是否合理
- 监控报警的准确率/误报率
- 如何提高监控的准确率，减少误报率
- 监控报警的添加思路
- 系统级别的报警(CPU、内存、磁盘)
- 业务级别的报警(按 日/周/月 这些维度进行统计)
- 数据采集类监控(统计不同渠道支付的成功率，推动智能路由的开发)
- 监控报警是否完善
- 为线上系统进行分级
- 哪些是核心系统/核心模块(线上系统资源分配，优先保障核心系统)
- 对非核心系统/核心模块进行限流、熔断配置
- 混沌工程、故障注入
- 有目的性的去停掉一些服务，查看业务是否能正常服务
- 服务停掉以后，是否有及时报警，团队人员响应情况
以上，测前、测中，测后三个阶段，大家可以从这些大的方面去考虑，再根据自己公司和团队的特点进行细化和实践，最终得出适合自己公司和团队的质量体系。
另外，大家可能会问，在经验不足够多的情况下，我们如何知道哪些细节点是我们需要去关注的呢，这里有个简单的方法：如果大家每天都做大量的重复工作，那么这里就是一个问题点。如果没有大量重复的工作，但是工作都非常耗时，那么这里也是一个问题点。当我们遇到这些问题点的时候，是不是就要进行反思，有没有什么办法去解决这些问题？慢慢的培养自己的质量意识、全局思维，这样日积月累，就会对产品质量有一个深刻的认识。
二、质量体系建设
对于软件的质量保障，更多的是一些思考，考虑要从哪些阶段、哪些方面和大概的方向去保障，而它的延申就是质量体系的建设。通过分析测试过程中的痛点、难点，然后给出对应的解决方案，可以是工具和服务的开发，也可能是流程机制的优化。每一个痛点、难点，我们给出一个解决方案，这样把所有痛点、难点都解决以后，就形成了整个质量体系的建设。下面我们来举个例子：
在支付业务中，通常我们会有很多支付渠道，少的三五个，多的几十个。这些渠道特点不一样，被测系统和他们的交互也不一样，渠道的处理逻辑和策略也差异较大，最重要的是很多支付渠道没有测试环境提供给我们联调，需要我们用真实的资金支付去测试，这样显然是不合适的。针对这个情况，我们如何思考和解决这个问题呢？
我们需要开发三层服务，第一层服务，我们对发往各个渠道的请求做差异化处理，这么做的目的是为我们第二层的 Mock 服务来服务的，不管发往哪个渠道的支付请求，经过差异化处理以后，都可以被我们的第二层的 Mock 服务接收并进行有效的处理。
第二层服务是 Mock 服务，接收经过差异化处理的支付请求，经过一系列逻辑处理并调用第三层的数据生产服务，最终将结果返回给客户端。
第三层服务是数据生产服务，如果我们要对不同的请求，给出不同的返回结果，验证不同的测试场景，我们在第三次服务这里进行处理。
有了这三层服务以后，不管有多少个支付渠道，我们内部测试都可以依赖这三层服务来完成（但是后面的联调测试也必不可少）。这样我们就解决了当下这个痛点和难点。对于质量保障体系的建设来说，每一个痛点、难点，我们都可以输出这样一套方案，最终把所有的痛点和难点都输出了对应的方案以后，就形成了一套基础的质量保障体系，为我们产品的质量提供了有力的保障。