最近有朋友问了这样一个问题：想在团队内推动质量度量落地，对每版本迭代的交付质量有更好的评估，但没有太多的实践经验，有没有什么落地方法或者注意事项。 首先聊聊质量度量本身，即质量需不需要度量？ 答案显而易见：质量需要度量，而且需要持续的度量！为什么呢？ 我们所从事的软件测试工作(随着技术不断发展，现在也叫作质量保障)，工作对象就是软件系统。经过需求设计、需求评审、技术设计、代码开发、测试验证、上线发布等多个环节，才能保障这些软件的最终交付质量。 这一整套复杂的流程，实际上就是将不确定性(需求)转化为确定性(具有严密逻辑的软件系统)的过程。确定性，需要一定的衡量标准来评估它是否满足预期的设计，因此需要一定的数据来进行度量。 而持续度量的原因，是业务和技术本身就处在一个不断变化发展的状态，需要持续的度量和评估，才能保障软件系统的质量长期处在一定的水准之上，满足用户需要和保障业务目标达成。 质量度量的本质，是具体的定量，而非抽象的定性。 其次聊聊质量度量的注意事项，这些注意事项是我个人结合工作经历和实践总结的经验教训，仅供参考。 质量保障是一个体系化和长期建设的过程，而质量度量作为最重要的一环之一，在落地过程中需要持续跟进和优化。 1.质量保障不仅仅是QA同学的事情，因此质量度量也不能只关注测试维度。 2.度量指标需要根据团队特性和业务具体情况来制定，并且需要评估是否合理，而不是强行制定强行执行。 3.质量度量是为了保障最终交付质量能更好的满足用户需要，进一步达成业务目标，而非为了度量而强行度量。 4.质量度量并非一蹴而就，在软件不同的生命周期和团队成熟度阶段，度量的范围和执行严格程度要灵活变通。 最后，分享一些我对于软件质量度量的一些思考。 1、不要为了度量而度量，找到合适的度量对象很重要。 比如听一些同学说他们的质量度量指标，就有首次测试用例执行通过率，以及累积测试用例执行通过率。 这两个指标是为了解决什么问题？如果只是看到别人有，那我也要做，只是浪费时间和资源。而且你花大力气去做，大概率也得不到整个技术团队的认可。 2、度量指标一定要和具体的问题挂钩，否则指标没有意义。 最常见的，测试用例覆盖率，测试用例通过率。这个度量指标的作用是什么，要解决什么问题。 比如提测冒烟通过率必须100%，否则证明了主流程存在block，影响测试进度。这个度量指标要解决的是可测性和测试进度，提高从编码到测试环节的交付产出物质量。 3、度量的指标和数值一定要和直接干系人达成一致。 还是以冒烟提测通过率为例，如果研发团队不认可，怎么办？ 很多时候测试团队没有太大话语权，没办法影响到研发团队。这个时候要学会迂回策略。即如果冒烟提测通过率不达标，导致了什么结果，这个结果的风险是什么，会带来什么不好的影响。然后向更上一层汇报，暴露风险。 4、度量指标和数值不能解决问题，只能证明发生了什么。 设置度量指标和衡量的数值后，要明确一点：度量产生的数据不能直接解决问题，而是证明产生了什么结果。 要分析数据背后的原因，什么原因导致了这个结果，这个原因的风险和对交付质量有什么不好的影响，然后才是拿着数据和分析的结果去推动改进。 5、落地质量度量有很多前置条件，质量度量不是单一存在的。 举个例子，通过度量缺陷数量和用例数量以及对应的百分比，来评估每版本的编码质量。 这个逻辑没问题，但不是单单搞个对比数据就可以的。缺陷&用例需要和对应的代码分支关联，代码又要和需求关联。否则只有数据，没有因果关系，证明不了问题，也解决不了最本质的需求不完善和代码质量不高的问题。 6、质量度量是一个复杂的技术工程，更需要大量的沟通和协作。 工作真正要解决的是人的问题，技术不存在难点，难点在于思路，以及说服其他人配合你行动。 想清楚再行动，先从小范围试点，从最痛的点开始，这样推进的动力更大。

最近收到不少朋友给我留言说，工作越来越卷，升职加薪没有，加班越来越多。领导整天摊派任务，白天不是开会就是整理数据写PPT，只有晚上才有时间干自己的本职工作，越来越觉得上班枯燥，没有成就感。 工作成就感这件事怎么说呢，每个人的感受是不一样的，有人在工作中的成就感来自于解决了很复杂的问题，有人的成就感则是帮助同事后获得认可，各有不同。 大体来说，工作中的成就感主要有两种：一种是自我满足，这是由内而外的自我实现；另一种则是外界群体认可带来的情绪价值，这是由外而内的群体评价体系。但无论哪一种，都需要在实际工作场景中来获得成就感。 一、主动解决问题，一切以结果说话 比如你目前遇到的情况是线上问题频发，你没有太多的线上权限，自己技术能力不够强，排查问题能力一般，那你可以从哪些方面入手呢？ 1、加入/组建线上问题反馈群，和一线的客服以及值班的运维开发保持紧密联系，发现问题及时关注。 2、推动线上监控体系的完善，以及线上回归和自动化巡检的落地，你可以暂时技术能力不够，但不能不行动。 3、问题复盘优化，线上问题oncall机制，都可以去推动建立，这些不怎么考验技术，更考验组织协调和沟通能力。 以上三种方式是针对线上问题频发最常见也最合适的解决方法，根据具体情况选择一种或同时推动多种方法，直至问题得到改善或者解决。这个过程中不仅自身能获得长足的进步，也能通过解决问题获得来自同事和上级的认可。 二、职场不是给你学习的，能快速解决问题才是根本 很多职场新人容易犯的一个错就是，我不会这个技术，公司加班多没时间让我学习提升，这其实是一个误区。公司招聘员工的目的是让他来做事和解决问题，而非学习。 比如你只会拿着别人的测试脚本改改满足日常工作需要，诚然这种方式也能应付工作，但势必会陷入低效区间，可能导致加班更久，也影响自己的心态。对此我有这些建议： 1、了解别人的脚本为什么这么写，你能否借鉴他的思路，实现自己的脚本。 2、自己实现的脚本，有没有其他人也能利用的共性，然后尝试开发一个小工具。 持续循环上面两点，你的技术能力才会得到提升，因为你是实打实的在实战解决问题。同时，如果你做的事情能帮助他人解决类似的问题，既能获得领导的肯定，也能获得同事的认可，何乐而不为。 三、所有的爆发性成长，都来自于长时间的厚积薄发 对于工作年限不长的同学来说，对业务的熟悉程度，技术实践的经验以及技术广度和深度，确实很难超过高级或者资深岗位的同事，但这不是你做不好事情的理由。 对业务的理解需要在日常工作中不断积累，和业务产品多沟通，在测试细节里总结。技术工程能力需要不断的练习，解决各种报错，做各种优化，这也需要时间的积累。 特别是对于初入职场的同学来说，你本身就是初中级的Title，接受自己经验和能力的不足，这是事实。但你可以通过学习的积累，辅以大量的实践，来成为高级、资深甚至专家级的角色。 职场，一定要认清你自己，有明确的定位，找到对的方向，同时辅以勤奋学习和大量思考。这个过程，除了收获技术和业务的成长，更多的，是你能对自己有更多的认同，以此来获得成就感。

前几天修复了一个历史遗留 Bug，和同事讨论时他提到了一个词——“严丝合缝的设计”。 这个词几乎瞬间击中了我，因为它与我过去坚持的设计理念完全一致，只不过我曾将其称为“设计正确”。 但过往经验也证明，这类“设计正确”反而制造过不少 Bug，彼时我将问题归咎于“抽象不完善”。 支持这一理念的典型论据是：人体的各器官就是严丝合缝合作的。作为万物之灵的人类，值得我们从中汲取灵感。 现在重新审视这个问题时，我发现过去的理解过于片面了。 疫情期间学到的医学常识给了我新视角：人体各器官的合作并非绝对的严丝合缝，而是充满冗余和容错机制。最简单的例子，你把手指上的血管割破了，并不会造成你整个手指的缺血。 同样，若必须依赖“完美抽象”才能避免 Bug，这样的“严丝合缝的设计”真的是理想方案吗？ 《程序员修炼之道（第二版）》中反复强调的核心观点是：代码应“易于修改”。 无论是设计模式还是编程准则，终极目标都是应对需求变化。无法灵活调整的设计，终将沦为技术债务。 而我曾经的“设计正确”理念，本质是落入了契约式编程（Design by Contract）的陷阱。 当时的逻辑是：A 模块调用 B 模块时已确保参数合法，因此 B 无需验证输入。 尽管我早年就意识到“设计闭环”的重要性，但在实际编码时，“性能强迫症”仍驱使我走向极端。 近年来随着对性能执念的淡化，我开始反思：这种追求“设计正确”的代码真的易于修改吗？答案显然是否定的。 精密代码如同多米诺骨牌阵列，看似严谨，却可能因一处微小改动引发系统性崩溃。过去踩过的坑已充分印证了这一点。 从“高内聚，低耦合”角度来重新审视这个问题。 若 B 模块要求调用方保证参数合法性，本质上已经形成了隐性耦合。用设计原则来描述，这违背了最少知识原则（Law of Demeter）。 根据多年经验，实现“高内聚，低耦合”的关键只有一条： 设计模块（函数/类/服务）时，永远不要假设调用方会遵守任何约定。 无论外部如何调用，模块内部必须维持自身数据一致性。 这既是我曾提过的“设计闭环”，也可称为防御式编程或容错冗余。 原则看似简单，实践却困难重重。 一个典型的开发场景是：先实现调用方 A，再开发被调用方 B。 当编写 B 时，由于已知 A 的实现细节，开发者会不自觉地利用这些信息优化 B 的性能。 这恰恰是坏的味道的开始——尽管短期运行高效，却埋下长期隐患。 假设需求变更后，需要用新模块 C 替换 A： 由于 C 与 A 的相似性，开发者容易忽略细微差异。若 B 的实现依赖了 A 的某些隐性特征，便可能催生极难发现的边界 Bug。 更棘手的难题在于：容错冗余的粒度如何把握？函数级、类级、模块级还是服务级？这需要开发者基于场景反复权衡，而每个人心中的天平刻度未必相同。 我自己现在的准则是： ​1.模块/类级/服务级：必须严格校验输入边界和状态约束，防止预期之外的调用弄乱内部数据。 2.​函数级：可根据情况相信传入的数据，这也有利于我们放心大胆的对于函数进行抽象，而不必担心性能的销耗。 ps. 函数的抽象绝不仅仅是代码复用，甚至可以说根本不是为了代码复用——抽象的本质是建立认知边界。只有深刻理解这一点，才有可能做出更好的抽象决策。