一.项目上线质量指标
你认为用什么质量指标可以反映项目。上线的一个质量?你可能会想那不是有很多质量指标么?多数和BUG相关,例如BUG数量、重新打开BUG数、 BUG解决时长等等，好像都能体现上线质量啊。可仔细想想，我们衡量上线质量,不能只看这些，质量不应该简简单单的关联上BUG就可以了。
二、研发过程质量
既然不能只看结果，那我们就从源头开始看起。首先是需求质量，想要最终的.上线质量高,那么源头的需求质量就不能太低，否则后续的研发工作做的再优秀，也不算好，很有可能一开始就跑偏了。
我们需要在需求评审的阶段,从用户使用场景的角度出发,通过提问，把需求逐步澄清，并形成验收条件(可以用思维导图的形式记录下来)，
产、研、测三方共同确认，形成共识，以保证大家对需求的认知不发生偏差,为后续团队做正确的事提供有价值的指导。根据用户故事的基本特性(我之前使用的是jira管理项目，户故事就是当时敏捷团队提出来的，它可以对需求进行故事拆分)，做到业务可验收、研发可实现、测试可验证、部署可上线。
再来看看研发过程的质量体现，对于代码质量，开发自有代码规范。 我们主要从更宏观的角度来看，个人认为有两个指标需要关注:构建成功率和缺陷趋势图。
构建成功率能很大程度上反映研发的提交质量,如果经常性地编译失败或者自动化测试不能通过,那么就需要引起重视，尝试去了解原因并找出解决方案，因为构建失败意味着最基本的业务保障都出问题了。
缺陷趋势图可以很好地反映缺陷的整体变化趋势和处理缺陷的时效性问题。如下图，大体上可以看到迭代缺陷的变化过程，缺陷在迭代中期被集中消灭的比较多，没有拖延到迭代后期，有利于测试的回归和其他方式的验证，降低风险。
再来看看上线到生产的质量评估，这里主要提两个维度:上线时长和缺陷存留。上线时长体现了 团队的上线能力,是否可以在用户期望的时间内完成上线，如果时长太长，用户的满意率下滑，你很难说本次上线的质量很高。因为最终评估标准是用户用上了，才能算好。
再来说说缺陷存留。曾经遇到过一个版本，遗留了20多个问题，测试报告也写测试通过,然后发布上线。虽然那些问题都是小问题，但是这么多的遗留问题，如果让用户遇上了，那会产生什么样的糟糕体验?
我们可以允许有部分问题延期到下个迭代修复，但总要有个底线吧。
三、用户使用质量
如果仅仅从研发团队的角度来看，上面的那些指标好像也够了。 但是，我们常说以终为始，上线增量功能并不是我们的终点，用户的使用才是迭代上线的终点。所以我们在评估项目上线质量的时候，也要把这方面的指标加上。
线上缺陷遗漏率:指的是线上发现的缺陷。不论你的研发过程再优秀，测试发现bug再多，如果线上缺陷被较为轻易的发现，我们也很难说上线质量很好。虽然可以找很多的理由，但还是希望能够去避免类似的情况出现。
包括我的领导一直在强调:我们现在不仅要完成上线，还要追求过程可回顾、可追溯、可总结、可提升,关联到我们部门流程或者整个协作流程的一个提升，关联到大家实际工作结果回顾提升,关联到大家质量把控能力的提升。
这真的是说到点了,我自己现在也在抓上线质量，我相信我的团队还有很大的提升空间!
用户反馈:这里指的是用户的真实反馈，有机会去听听用户的心声。不要总是自我感觉良好。如果用户反馈使用很不方便，或者难以接受,那么我们的上线质量也不可能太好。这点可以和前面提到的需求质量相关联，因为这是需求质量的最直观体现。
数据埋点:如果说用户反馈过于主观，那么必要的数据埋点，有利于我们更加客观的去分析.上线质量，比如改版前后比较，新功能的点击率,关键路径转化率，错误率,等等。如果你迭代的功能没人用，谁比较尴尬呢?要注意的是，埋点数据可能会有延迟，参考这类数据时，我们要把把时间线放长一些。
四、非业务特性指标
理论上来说，上面那些指标， 已经能够比较客观地反馈出迭代的上线质量了。但是在敏捷的场景下，时间短，任务重。有些在瀑布模式下比较注重的东西被忽略了，那就是非产品特性的质量。
最典型的,就是可维护性和可扩展性。在瀑布模式下,我们会比较关注这两类的问题，因为上线时间长,如果不注意，后期的运维难度会很大。而在敏捷的环境中，因为上线任务重，加上敏捷提倡重构,所以研发对于代码的维护性和可扩展性并不会考虑太多(都想着会重构,但往往都没有重构的时间)， 在迭代中也没有预留相应的时间做技术债务的偿还，日积月累，屎山代码就慢慢产生了。目前我团队的技术需求也是挺多的。
五、结语
以上，从三个方面讲述了关于项目.上线质量的一些个人思考。作为研发侧的同学,可能关注的是过程质量,如果对代码或者研发有些追求的话，还需要关注非业务特性的上线质量。对于结果质量,这个看团队的追求。但是我觉得做一件事情，不仅要把它做完,还需要把它做好!
【整整200集】超超超详细的Python接口自动化测试进阶教程合集，真实模拟企业项目实战