其实大家平时都有在做，比如各个方面的评审（需求评审、设计评审、用例评审、上线计划评审）、codereview、单元测试、开发联调、静态代码审查（sonar）、bug回顾和分析、产品验收、项目复盘等等。
但是仅有这些步骤还不够，还需要有输入输出标准要求。就拿开发联调来举例，研发同学做完自己模块的开发工作，与其他上下游模块能调通就算联调完成，那这个质量要求就太低了。
至少也需要对于本次需求的业务场景的主流程能跑通才算是联调完成，如果能涉及到异常场景就更好了。
因为大家都有这个常识，就是质量问题越前置，所需要花费的修复成本就越小。
如果所有问题都等到测试人员介入去发现，都落到运行态测试这一关，那投入的成本将至少是开发加测试，有时还不仅仅是这些。
但问题又来了，如果所有质量保障工作都前置了，是不是就不需要测试了呢？
这个问题偷换了概念，把测试人员和测试工作划了等号。质量保障工作都前置，并且做到完美，是有可能不需要测试人员的，但是相应的测试工作并没有减少，只不过是以其他形式做了拆分，然后分摊到其他岗位上去了而已。
构建质量保障系统的要点
知道了质量保障与测试的关系，我们来看看以测试部门来推动质量保证体系的建设有哪些要点。
首先，质量保障必须要落实在系统上，这是为了规范的统一、数据的自动采集和度量操作的一致，也就是标准化。
其次，质量保障系统要尽可能自动化，将规则的判断交给系统，减少人为干预，也减少人工操作的成本；
再次，质量保障需要有量化评估模型对质量进行评估，进而评价质量保障的效果。
最后，有时候换个角度看问题，你会发现塞翁失马、焉知非福。
既然大多数人都认为质量保障是测试的事，质量问题要测试负责，那么作为测试就可以反过来要求这些人对他们的输出负责，从而反向推动大家质量意识的提升。
简单介绍下我们天鹅到家正在建设的质量保障系统：
在需求提出时，就要确定出明确的需求范围，功能点，团队成员以及预期收益；需求评审通过后，功能点自动在用例管理系统中创建出本次的测试用例初稿；
团队成员根据需求在排期系统中做任务拆解和时间安排。详设阶段，研发同学根据需求确定改动的功能模块，将模块与需求关联；
在关联模块时，会根据需求的团队成员确定可见的模块范围，不是团队成员的工程，或者团队成员没有develop/master权限的工程，将无法关联。需求和详设阶段这样安排，目的是为了使需求边界尽量清晰，减少后续“反复拉抽屉”的成本。
模块关联完成，进入开发阶段，会有三个动作，一是研发人员可拉取需求关联的模块所对应工程的分支代码，非本需求团队成员，无法在开发阶段对模块进行拉分支的操作，即使该同学具有该模块的develop/master权限；这个是人工通过系统进行操作，会受系统中规则的限制。
二是模块所对应的容器镜像&系统运行所需服务的镜像均开始准备，并在容器中进行测试环境搭建；
三是被拉取工程及上下游模块所对应的测试用例与前一步创建的测试用例初稿（TestCase_Original）在测试用例管理系统中一并形成本次需求的测试用例初始集合，测试人员可在此基础上快速完成测试用例的设计；这两个动作都是系统自动完成。
这样就建立了一条需求id、功能点、代码分支、环境、用例版本的数据链，便于回溯。
开发在联调完成后进行提测，走持续集成，这个很多公司都有，此处不过多赘述。
只是特别说明一下，多数可能做的是全量的代码覆盖率，最好是做增量部分代码覆盖率。一方面是为后续测试工作做一个基线，一方面是能更准确评估单测的精准度。因为除非100%覆盖，否则80%以上的代码覆盖也无法保证改动部分是被全覆盖了。
线下测试环节没有特别特殊的地方，稍有特点的，可能就是不论什么环境测出来的bug都要求是需求负责人（产品经理）来进行处理，是关闭还是带bug上线，而不是由测试人员来处理，这就反向推动需求负责人（产品经理）关注质量，提早并持续进行验收动作。
线下测试完成，进入沙箱测试之前要制定上线计划，否则系统无法打包并部署沙箱环境。很多时候上线事故都是由于上线步骤混乱、或者遗漏某个操作环节、或者没有完善的回滚计划造成的。
这一步要做到的目标是所有执行操作尽量自动化，减少人工干预。
包括：沙箱准备工作中数据库执行操作及顺序、ES索引执行操作、MQ主题申请、配置文件及配置中心上的设置、数据字典配置、菜单及权限的配置、角色及数据权限的配置等，线上环境数据准备，编排集群上线顺序，回滚方案等等。
这样就能在沙箱环境将上线计划也一并进行验证。沙箱环境环境部署好后，将准备好的线上流量在沙箱环境进行回放，监控系统检测系统运行情况、业务运转情况，验证本次需求上线后是否会对现有生产系统以及业务运转造成影响。
测试人员更集中精力在沙箱环境中验证本次需求的新增和改动。
几个核心要点：调用链反查流量入口、流量复制、流量回放、流量染色、监控系统、熔断、影子库/影子表等。
质量评估通过，将允许上线。质量评估也是一个比较大的话题，有机会再做详细介绍，这里给大家提供几个指标，分别是：缺陷对应到模块的一个分布情况、缺陷处理结束的时长、缺陷探测率或者缺陷遗漏率、帕累托图、代码的圈复杂度、测试覆盖的精准度、代码规模等。
上线过程就是将沙箱验证过的上线计划再重新执行一遍，上线后测试人员进行回归，需求负责人（产品经理）进行验收。
通过后收集相关数据自动形成测试报告模板，测试人员在其中填入测试评价后，由系统发给相关干系人。
上线并不代表着质量保障结束，后续还有收益回收、质量保障效果评价、项目复盘等环节。为本次需求而做这些动作仅仅是一方面，主要的目的还是为后续怎么持续优化质量保障来做思考。
源自公众号 小白转IT