一、质量保证的核心目标
这个话题在实际的项目或团队中很少有明确的约定或口径，实际经验而言，可以归于一条：线上故障的减少。这个经验得来的目标实际是一个非常宽泛的目标了，通过团队成员的多方努力，这个目标仍然是“若即若离”。
站在不同人员的角度，对测试目标会有共同的期望：故障的减少 & 人效的提升 & 迭代周期的缩短。
但对测试结果的期望，可以归纳出最核心的一条目标： 线上故障的减少。
二、产品故障的广泛定义
- 硬性质量引发的问题。指上线/配置修改等直接引发的线上不可用问题(用户直接不可用)
- 软性质量的引发的问题。指新功能上线/改版等引发的不好用问题(用户直接产生不好用的感受，当然，这部分实际项目中往往不被直接当成线上故障通过回滚版本的方式来处理。)
- 需求定义引发的问题(推翻之前的实现；走回头路；由于大boss推翻3周的实现；)。指新功能上线/改版后立即重新上线推翻修改。
以前的博客(典型故障分析，故障的坑)介绍了故障的种种可能发生的情况，这更多的是从狭义来定义故障的，即：给用户带来不可用的问题，并常常通过回滚版本的方式进行处理，对应硬性质量引发的问题。
从广义上来说，故障同时包括了：硬性质量引发的问题、软性质量引发的问题、需求定义引发的问题。
三、如何减少线上故障
-
减少故障需要考虑的研发阶段
由于故障可能在需求、技术设计、开发、漏测、上线不规范等过程产生，因而，故障的控制必须从各个阶段分别入手。
-
针对已有的故障，在复盘时找到最根本的原因
线上的故障，最多的呈现形式往往是某个边缘功能的漏测，上线新功能问题等等，但这些问题的出现需要更深层次的深挖。例如，某个功能的漏测，可能是QA/开发人员对影响点评估不足，但也可能是频繁快速的超负荷迭代，导致无暇东顾； 上线新功能问题，可能是因为开发人员/QA人员对上线checklist 评估不到位，也可能是项目管理混乱导致，抑或是线上线下环境gap导致。
-
根据业务成熟度、团队成员特点有针对性应对
在之前的博客测试的本质 中介绍过，不同阶段的业务需要不同程度的质量侧重，例如，在产品的野蛮增长期，为了实现产品原型的快速上线，允许不影响使用的问题存在。
不同团队成员(产品、研发)有略微不同的合作模式，例如，有的团队人员都特别有经验，本身需求、提测质量都很高，这时不妨和团队成员一起制定更加成熟的产品质量数据；相反，则需要从最基础的需求变动、提测等流程开始一点一滴的实践起来了。
-
具体评估整个项目迭代成熟度
- 整个迭代周期是否合适，保证反复迭代时不会对质量产生风险。具体来说就是，需求变动方面、开发周期、测试后期、上线周期等是否存在时间过紧的情况。或许偶尔几次的赶上线，对质量没有太大问题，但长期如此，出问题可能就是必然了。
- 测试人力的效率。主要指为了测试的深度和广度，是否采用了性价比较高的测试执行手段，当然了，这里并一定说自动化执行就一定比手工执行效率高，关键在特定场景下，哪种效率更高。
- 测试覆盖度。指整个测试方案是否足够深、广，保证了测试的覆盖度。
- 需求特点。根据需求量做特别考虑，例如，重写代码的时候往往过于乐观，结果过于乐观，此时就需要周知团队成员特别重视了。
- 业务耦合度。需要考虑紧密耦合的业务，在开发/测试方面是否合理。记得很久之前接触过一个业务B，强依赖与业务A, 而业务A,B 是隶属于两个团队的，带来的问题就是：不仅开发的时候需要多方周知，测试的时候往往需要找业务A的人员创造场景，当然了，因此也引发了一些耦合度太高导致的测试不充分，进而引发了线上故障。
- 风险控制(故障降级，灰度发布，迭代频次/发布周期)。 需要针对不同的业务特点，制定不同的风险控制方案。 比如，有的业务本身就多个业务强依赖，一旦出问题，原因特别难排查，那么就可以提供debug工具/方案来更加精准、快速定位问题；有的业务本身新增的功能/服务特别多，那么就需要提供上线演练/预发布等方案，来尽量降低上线不规范/误操作/环境gap等引发的问题了。