如何在质控团队推进软件工程质量管理的效率和质量提升

如何推进软件工程质量管理的效率和质量的提升

质量管理的本质是质量的可控，对质量的追求是没有极限的，在平衡质量和成本时需要考虑根本诉求。互联网公司更多要快速试错，相对来说更倾向于高效（低成本）维持质量在一定的水准。具体来讲，就是在快速支持项目迭代的过程中，保证业务稳定，无资损，无用户可感知的功能障碍（这个区分用户体量和比率）；并且，在出现业务不稳定时，能够快速恢复，定义问题并避免问题的重复出现。

鉴于此，从质量层面来讲，质量控制工作就分为两部分：① - 代码质量；② - 运行稳定性。

如何做好代码质量的把控？

代码质量更多又分为两部分：代码基本语法逻辑；代码实现的业务逻辑匹配。

针对代码语法逻辑错误，在具体质量控制工作中，能够实施的手段有很多：无论是静态代码走读、自动代码规则校验，单元测试。都能够在一定程度上对代码的逻辑异常进行检测。但在一般团队而言，更多的是未在这个层面进行控制，更多是在业务逻辑测试中发现代码基本异常。

业务逻辑匹配错误的测试比较依赖于产品的业务设计，虽然在具体的测试中根据开发设计做一定考量，但更多是从业务逻辑层面来实施测试，这个也是现有着重实施手段。从产品经理提供的一系列需求文档中梳理出应该实施的测试覆盖用例，在评估覆盖率与成本中找到一个平衡。

据现在实际情况来看，这两种测试手段实施成本（耗时）比率大概在 2:8 左右。这个除了从成本层面反应，从实际的缺陷发现占比也能反应。

软件质量控制应该尽可能早的发现问题，在考虑质量指标设定时，应该综合各个实施方案所花费的成本；包括长期成本和短期成本，长期收益和短期收益。从另一个方面来说，成本强调的就是效率，效率高，耗时自然少，项目迭代速度会更快。在一个质量稳定的研发团队中，如何提高效率，提高研测比是一个综合问题。站在质量控制的角度，将更多的缺陷在更早的阶段通过非人工的方式捕获，是我们所应该追求的方向。

基于这一点。我们所能够实施的手段如下：

① 提高场景自动化覆盖率，包括冒烟测试、回归测试、全量覆盖测试

② 提高白盒测试覆盖率，并持续优化白盒测试策略

③ 提高单元测试覆盖率

④ 提高服务契约覆盖率

⑤ 提高UI自动化覆盖率，包括一切自动化手段

以上手段使我们所能够采取的方案，可以综合考量落地成本与计划。目前业务系统仍处于告诉迭代中，无论是GUI、WEBAPI、ServiceAPI、DataBase、Config或其他的技术路线。

分析以上方案实施条件和成本

主要从：支持工具、框架支持、接入成本、维护成本(成本越高则分越低)、覆盖率满足度、技术要求、接受程度 这些角度考量，每个指标5分。

场景自动化覆盖，这个放在第一个原因是实施手段目前较为成熟，门槛低。但长期维护成本较高，针对用户角度业务场景覆盖较为切合。

白盒测试覆盖，通过一定的规则对代码静态扫描，自动发现代码中的一些基本错误，降低低级错误导致后续工作重复工作，提高代码的质量。

单元测试覆盖，开发编写单元测试代码，通过单元测试对所编写代码进行基本的方法级测试，保证方法逻辑符合编写预期结果，降低原子级逻辑对上次逻辑的影响。对后续迭代存在极大价值。

服务契约覆盖，通过对相对稳定的服务接口的覆盖，在后续的迭代开发中，以较低的成本保证迭代不会对历史业务产生影响。

UI自动化覆盖，以更贴近用户视角，保证系统为用户所提供的核心功能。是唯一能够覆盖前端代码逻辑的自动化手段。但对实际业务迭代频次有一定要求，如果迭代频次较高，维护成本相应会提高很多，可操作性较低。

通过上面数据梳理与可视化分析，我们的实施路径应该如下：单元测试、场景自动化、服务契约、白盒测试、UI自动化。

根据实施路径，具体分析各种方案实施计划与步骤。

单元测试，有开发发起实施，质控组暂不参与。

场景自动化已经实施中，场景自动化主要分为几个阶段：冒烟测试、回归测试、覆盖测试。目前处于回归测试阶段，基于对现有业务系统的了解和梳理。整理并不断维护业务系统场景用例，根据计划安排，不断增加场景覆盖。

服务契约已经在实施中，主要分为以下几个阶段：接口覆盖、代码覆盖率覆盖、长期维护。目前处于接口覆盖阶段，由于支持工具尚在建设中，此阶段预计于6月份完成。

白盒测试，尚未开始实施，前期自动化测试小组经过调研，基于SonarQube构建白盒测试方案，目前尚处于调研阶段，不清楚自动化测试小组实施到哪个阶段。后续咨询清楚后，需要介入维护规则。

UI自动化，尚未开始实施，前期自动化测试小组经过调研，基于网易Airtest构建UI自动化测试方案，目前尚处于调研阶段。AItest在本项目暂未实施，且未与测试平台进行打通，脚本的调用和维护，结果跟踪机制暂无，无法形成有效的长期方案。需要和自动化小组跟踪确认具体后续计划。