摘要：
本文探讨了在新的形势下IT企业对于质量的重视程度是否转变？对研发质量的度量和研发人员的度量如何进行，其利与弊？如何建立良好的度量机制，测试团队的职责转变和面临了什么新的挑战？
正文：
近些年来，随着互联网的飞速发展，企业IT部门的软件工程实践发生了天翻地覆的变化。层出不穷的声音开始质疑IT部门中质量和测试团队的价值。互联网企业追求“唯快不破”的特征在广泛的本土公司中体现的淋漓尽致。“快速试错”意味着把一些或大或小的产品瑕疵遗留给了用户；团队Leader在权衡交付时间和整体质量指标的时候大多会倾向于前者；质量和测试团队急于寻求自己的新价值，通过横向扩展，增加了研发质量工具建设和系统运维的职责，大大减少了功能测试工程师的比例。基于这种现状，广大质量和测试团队的一线工程师都在拼命挣扎，力求转型。
随着经济寒冬到来，互联网红利即将结束的言论广泛流传，“唯快不破”的神话是否还能继续？
前段时间朋友圈传播的“任正非公开信：投入20亿美元全面提升华为软件质量”，让我们眼睛一亮，质量的春天要来了吗？
“寒江水冷鸭先知”
笔者不得不给大家泼一泼凉水，整个环境都是寒冬，质量这个小圈子应该也不会有多暖。不过有些一线的工程师确实体会到组织内部开始把质量作为考核指标了。那这又是为何？那么就从组织考核的层面做一下分析和思考：
首先，大形势的寒冬必然导致不再适合把“快速增长”作为唯一的考核指标。互联网跑马圈地时代宣告结束，各个行业供用户可选择的产品和服务都是五花八门，那么质量这个竞争指标的重要性便逐渐体现出来了。
其次，企业的紧缩政策不得不增加对研发成本的控制。不得不说很多本土的互联网企业仍然是“劳动密集型”的，大多数团队对“人海战术”已经应用的得心应手。“996”这个杀手锏可以通过增加研发人员的工作时长以应付交付的压力。在疯狂扩张的阶段，这种粗放式的策略没有问题，但是在成本日趋重要的今天，组织不得不通过提升产品交付各个阶段质量来减少浪费，通过研发提交的代码质量作为门槛考核并评价一线工程师是否“合格”。
量化考核
那么作为一线研发人员，有很多人是天生有代码洁癖的。这种追求尽善尽美的工作方式，以前在代码交付量上往往会吃亏。那么既然开始追求质量，是不是就可以沉下心来气定神闲地一步步去设计并编写优美的代码了呢？
答案是否定的，软件开发也许对于某些有追求的程序员来说是一门精雕细琢的艺术，但对于更加务实和追求效率的组织来说，软件开发亦是一种工业流水线上的劳作，效率永远是重要的。
纯数字的量化考核，是很多组织常用的快速有效的方法。产出效能可以通过提交代码行数、完成需求个数和修改BUG数量等指标来考核。软件质量多数以缺陷数量、单元测试用例数量和用线上问题反馈数量等。当然这种追求数量维度的考核属于初级阶段的质量保障手段，对于很多管理者来说是“简单、有效”的。
一线研发人员如果想要代码写得即快又好，就需要借助一些工具了。比如通过“SonarLint”等代码扫描工具在本地IDE中实时扫描代码级别的违规和缺陷并及时修改。
细化到人
作为组织的管理者，评判下属工作优劣的手段无外乎“观其言而察其行”。“Talk is cheap，show me the code”，这句话虽然存在争议，但是已经成为很多程开发人员的座右铭。那么提交的代码将成为量化考核的重要数据来源。
随着现在很多IT研发团队已经把代码放到SVN或GIT等代码管理工具上集中管理，细化到人的量化数据正在变成一种可能。如果是使用GIT工具，比如细化到人的固定时间范围内的提交代码量这个数据，就可以通过调用GIT的开放API接口获取个人维度一定时间范围内所有的Commit信息，然后对Commit信息进行分析和统计计算，是可以得到个人维度代码提交量的。个人维度的单元测试数量也是可以通过这种方式获取到的。
除此之外，Devops工具链的建设，使研发过程中的产生缺陷数量、修改缺陷数量和线上问题反馈数量等，都可以通过系统收集起来。那么只要对数据经过加工处理，便可以得到精确到每个工程师维度的相关数据。
持续反馈
从“原始”的粗放阶段过渡到关注质量数据的初级阶段，这种纯数字的量化考核是能够起到一定的作用的。广大的一线研发人员大多是可以适应的，要什么数据，就在什么数据上多付出些努力。
不过经过一段时间的积累，纯粹增量的数据考核会逐渐成为一种负担。因为提交代码量并不是越多越好，长此以往系统将会存在大量的冗余代码，需要通过重构来为系统减负才行；测试用例的数量也不是越多越好，仅仅在数量上的累积会增加执行的负担，无效用例的执行会白白消耗服务器资源，一旦用例执行失败也会耗费大量时间去分析和定位问题；以绝对的缺陷数量来考核质量会逐渐加重开发与测试两个角色的对立；如果不区分影响范围地对线上问题反馈进行个人的问责，会造成一种害怕承担责任而踢皮球和推诿责任的行为。
那么较好的实现方法是，逐渐取消绝对数量值的量化考核。取而代之，一方面可以在研发过程中设置基础的一些门槛原则，在研发过程的不同阶段加以实时检测并能够及时反馈给研发人员；另一方面，通过周期性的度量来发掘优秀的工程师加以鼓励，并且也可以看到数据差的一些后进的工程师并加以辅导和培训。
设置关卡
整个研发的交付过程有很多节点，可以通过在一些关键的节点设置检查点这种层层过滤的方式，把缺陷和问题拦截在真正交付给用户之前。那么又会存在这样的问题，设置关卡的节点过多，势必会影响交付效率，一点不设置关卡，又无法及时对风险进行预警。
一个很好的实践就是持续集成，该理论推荐的是频繁集成，每次提交都需要执行集成步骤，多数团队都无法真正做到。很多人推崇敏捷只看到了敏捷所推崇的灵活性，而又不想遵守敏捷要求的纪律性。那么也可以采取折中的办法，可以考虑只在以下节点设置检查节点：
1. 上线发布前的检查
包含代码违规检查、单元测试通过率和覆盖率、集成和功能测试是否通过、其他测试和校验通过
2. 交付给专职测试团队前的检查
代码违规检查、单元测试检查、可部署校验等等
以上两个典型的节点分别代表两个阶段性工作的完成，实际情况还可以根据具体的代码分支管理策略和不同的研发流程来设置检查点。
要想达设置关卡的真正目的，必须要确保所有检查流程的完全自动化，并且要确保快速执行。目前对于实现快速而且准确的自动化测试执行是一个挑战。
综合度量
综合度量是指多个维度指标的综合考量，比如包含代码行数、代码复杂度、代码冗余度、代码违规和缺陷数量、代码覆盖率等。这些指标是相互影响的，比如想要达到较高的单元测试覆盖率，并实现单元测试的自动化执行，那么很可能要首先通过重构代码来降低代码复杂度才行。
当然，通过机器来自动化的度量手段来发掘优秀的代码一直是我们的理想。可是实际上很多工具仍然达不到很好的效果，也许机器可以告诉我们什么样的代码是不好的，但是很难告诉我们什么样的代码是好的。因为好的代码不仅仅是语法和结构层面的，其中还会包含业务场景逻辑的设计。
测试团队的挑战
大多研发组织对测试和质量团队的要求，仍然是期望用尽量少的人来贡献尽量多的价值。因此对于既没有业务门槛，又没有技术含量的测试工作很可能会采取外包方式来实现。在普遍高开发测试比的的情况下，仍然需要继续通过构建务实而且易用的研发质量工具和平台，通过提供便利的自动化工具和合理的度量准则把一部分质量工作转移给研发人员；并且还需要更加深入了解相关业务领域，发现更多业务相关的，对用户的使用感受造成深刻影响的缺陷，把更多精力他投入到提升最终交付的业务产品质量中去。
总结
经济寒冬的到来，一些IT企业和组织会阶段性的增加对于软件质量的投入，但是应该不会一下子就把质量作为一个长远且首要的目标。只是在前期粗放增长的阶段积累了过多的技术债务甚至是管理债务，那么到了被动降低增长指标的时候，便会把质量作为一个手段来补偿原来由于不关注质量造成的系统技术债务和由于欠缺良好的工程技术人员管理机制而造成的人员冗余亦或技术水平不够的债务。通过一定阶段持续投入，
质量的收益才会逐步显现出来，这时候大多组织才会真正感受到在整个研发交付过程中构建一个质量与效率平衡的良好机制是非常有益处的。
[如需转载，请在转载时注明出处，并保证本文的完整性]
