质量体系

1、对于一个系统而言，常有的组成部分有，服务器、基础服务、业务逻辑和第三方服务。而我们要保障整个系统的质量，就需要在这几个方面着手。

 

2、流量预估

在系统构建初期，也就是需求阶段，除了理解需求之外，还需要知道系统的受众是谁，将来大概会有多大的流量，根据估算的数值，采取相应的措施：

1. 服务器分布式部署，根据流量大小选择几台服务器
2. 根据业务实际情况选择基础服务
3. 是否需要缓存方案，以及方案的选择
4. 数据库的选择和设计，是否需要分库分表

 

3、由于以上措施均针对系统流量，故系统的流量、性能监控，对我们而言也是非常重要。在服务器和基础服务层面，我们可以如下做：（以PHP + Nginx + Redis + Mongo 为例）

1. 机器硬件指标监控及报警。监控机器CPU、内存、硬盘的使用率
2. 基础服务的监控与报警。监控PHP、Nginx的错误日志和慢查询日志；监控Redis、Mongo服务器的使用情况
3. 定时清理系统日志，保持硬盘空间可用
4. 创建Mongo表的查询索引

 

4、在业务层面，最主要的是保障业务逻辑正常。在这期间通过设计测试方案（深度、广度）、多轮线下测试、自动化回归测试、小流量测试以及灰度发布的方式来减少我们系统的问题。

1. 一个好的测试方案可以帮助我们发现80%的问题。测试方案中至少包括测试方法、测试策略以及测试用例
2. 线下测试可以是代码的单元测试、接口的测试、系统的整体测试。对后端而言，接口测试就可以发现大部分的问题，而前端除了接口联调外，mock测试可以发现大部分APP的crash和ANR
3. 自动化测试在成熟稳定的系统中作用较大。接口的全自动化应该是可以达到90%的代码覆盖率的。它可以在系统更新时，自动检测之前的功能是否受影响。多用于预发布环境
4. 小流量和灰度发布是在用线上的真实流量来测试我们的系统功能，只让一小部分人可以看到新功能，即使有问题，影响面也不会太大

 

5、当然我们有了上面的一些措施，仍然不可避免线上出现问题，所以我们需要业务监控

1. 系统级错误监控
2. 业务异常逻辑监控
3. 接口超时监控
4. 主要业务指标监控
5. 系统只要接口流量监控

 

6、在系统中往往存在一些第三方服务，在测试时，碰到第三方服务不可用时，可以使用mock server代替。第三方服务一般不需要我们测试，但是我们仍需要关注调用时的处理

1. 查询服务的超时处理
2. 订单类服务的订单唯一性

 

7、上面的措施会将问题暴露出来，这时候就需要快速定位问题，来有效止损（日志快排）

1. 构建日志规范化标准
2. 日志统一管理
3. 构建日志一键查询平台