• 0
  • 0
分享
  • 项目上线质量如何评估——软件测试圈
  • 北极 2022-10-08 14:23:30 字数 2023 阅读 2460 收藏 0

一、项目上线质量指标

你认为用什么质量指标可以反映项目上线的一个质量?你可能会想那不是有很多质量指标么?多数和BUG相关,例如BUG数量、重新打开BUG数、BUG解决时长等等,好像都能体现上线质量啊。可仔细想想,我们衡量上线质量,不能只看这些,质量不应该简简单单的关联上BUG就可以了。

二、研发过程质量

既然不能只看结果,那我们就从源头开始看起。首先是需求质量,想要最终的上线质量高,那么源头的需求质量就不能太低,否则后续的研发工作做的再优秀,也不算好,很有可能一开始就跑偏了。我们需要在需求评审的阶段,从用户使用场景的角度出发,通过提问,把需求逐步澄清,并形成验收条件(可以用思维导图的形式记录下来),产、研、测三方共同确认,形成共识,以保证大家对需求的认知不发生偏差,为后续团队做正确的事提供有价值的指导。根据用户故事的基本特性(我之前使用的是jira管理项目,用户故事就是当时敏捷团队提出来的,它可以对需求进行故事拆分),做到业务可验收、研发可实现、测试可验证、部署可上线。

再来看看研发过程的质量体现,对于代码质量,开发自有代码规范。我们主要从更宏观的角度来看,个人认为有两个指标需要关注:构建成功率和缺陷趋势图。

构建成功率能很大程度上反映研发的提交质量,如果经常性地编译失败或者自动化测试不能通过,那么就需要引起重视,尝试去了解原因并找出解决方案,因为构建失败意味着最基本的业务保障都出问题了。

缺陷趋势图可以很好地反映缺陷的整体变化趋势和处理缺陷的时效性问题。如下图,大体上可以看到迭代缺陷的变化过程,缺陷在迭代中期被集中消灭的比较多,没有拖延到迭代后期,有利于测试的回归和其他方式的验证,降低风险。

1.png

再来看看上线到生产的质量评估,这里主要提两个维度:上线时长和缺陷存留。上线时长体现了团队的上线能力,是否可以在用户期望的时间内完成上线,如果时长太长,用户的满意率下滑,你很难说本次上线的质量很高。因为最终评估标准是用户用上了,才能算好。

再来说说缺陷存留。曾经遇到过一个版本,遗留了20多个问题,测试报告也写测试通过,然后发布上线。虽然那些问题都是小问题,但是这么多的遗留问题,如果让用户遇上了,那会产生什么样的糟糕体验?我们可以允许有部分问题延期到下个迭代修复,但总要有个底线吧。

三、用户使用质量

如果仅仅从研发团队的角度来看,上面的那些指标好像也够了。但是,我们常说以终为始,上线增量功能并不是我们的终点,用户的使用才是迭代上线的终点。所以我们在评估项目上线质量的时候,也要把这方面的指标加上。

线上缺陷遗漏率:指的是线上发现的缺陷。不论你的研发过程再优秀,测试发现bug再多,如果线上缺陷被较为轻易的发现,我们也很难说上线质量很好。虽然可以找很多的理由,但还是希望能够去避免类似的情况出现。包括我的领导一直在强调:我们现在不仅要完成上线,还要追求过程可回顾、可追溯、可总结、可提升,关联到我们部门流程或者整个协作流程的一个提升,关联到大家实际工作结果回顾提升,关联到大家质量把控能力的提升。这真的是说到点了,我自己现在也在抓上线质量,我相信我的团队还有很大的提升空间!

用户反馈:这里指的是用户的真实反馈,有机会去听听用户的心声。不要总是自我感觉良好。如果用户反馈使用很不方便,或者难以接受,那么我们的上线质量也不可能太好。这点可以和前面提到的需求质量相关联,因为这是需求质量的最直观体现。

数据埋点:如果说用户反馈过于主观,那么必要的数据埋点,有利于我们更加客观的去分析上线质量,比如改版前后比较,新功能的点击率,关键路径转化率,错误率,等等。如果你迭代的功能没人用,谁比较尴尬呢?要注意的是,埋点数据可能会有延迟,参考这类数据时,我们要把把时间线放长一些。

四、非业务特性指标

理论上来说,上面那些指标,已经能够比较客观地反馈出迭代的上线质量了。但是在敏捷的场景下,时间短,任务重。有些在瀑布模式下比较注重的东西被忽略了,那就是非产品特性的质量。最典型的,就是可维护性和可扩展性。在瀑布模式下,我们会比较关注这两类的问题,因为上线时间长,如果不注意,后期的运维难度会很大。而在敏捷的环境中,因为上线任务重,加上敏捷提倡重构,所以研发对于代码的维护性和可扩展性并不会考虑太多(都想着会重构,但往往都没有重构的时间),在迭代中也没有预留相应的时间做技术债务的偿还,日积月累,屎山代码就慢慢产生了。目前我团队的技术需求也是挺多的。

五、结语

2.png

以上,从三个方面讲述了关于项目上线质量的一些个人思考。作为研发侧的同学,可能关注的是过程质量,如果对代码或者研发有些追求的话,还需要关注非业务特性的上线质量。对于结果质量,这个看团队的追求。但是我觉得做一件事情,不仅要把它做完,还需要把它做好!


作者:好好先生&Mr.Li

原文链接:https://blog.csdn.net/weixin_44275820/article/details/123557514


  • 【留下美好印记】
    赞赏支持
登录 后发表评论
+ 关注

热门文章

    最新讲堂

      • 推荐阅读
      • 换一换
          • UI自动化是自动化测试中不可分割的一部分,是黑盒测试的一种重要手段。在UI自动化测试过程中,我们不可避免会遇到各种各样的问题,现将自己在测试过程中遇到的问题进行汇总,希望可以为大家提供帮助。1、启动浏览器报错报错信息:Exception in thread "main" org.openqa.selenium.WebDriverException: unknown error: call function result missing 'value'...
            0 2 2186
            分享
          • 摘要:许多敏捷软件开发中的自动化测试的工作都失败了,或者并没有发挥它们最大的潜力。本文研究分析了自动化测试也许不能满足测试人员和其他利益相关者期望的两个主要原因,然后列举了六个能够避免陷入这些陷阱的步骤。以下是在敏捷环境中成功实现测试自动化的方法。为了能够跟上因敏捷软件开发而不断缩短的发布周期,很多开发团队都采用了自动化测试的方法,从而不断保证每个软件版本都符合所需的质量水平。这是传统软件开发实践的一个重要转变:测试经常被卡在开发过程的最后,被视为了测试过程的负担,而并不是好处。因此,一个在采用敏捷软件开发,转变为DevOps文化并采用持续集成和持续交付的组织中工作的测试人员,必须对于如何有效...
            0 2 3107
            分享
          •   CNMO从外媒了解到,印度新德里将在2024年底前实施价值约1400亿卢比(折合人民币约120亿)的人工智能交通系统。该系统可以监测道路上的车流量、平均车速、停车时间等信息,除此之外,还将根据新德里的面积和地形,实时预测可能会出现的拥堵情况,以减少此类事情发生。  据外媒给出的数据,与世界上其他城市的驾驶员相比,新德里的驾驶员在交通上花费的时间大约多58%,因此新德里决定实施由AI驱动的交通管理系统(ITMS)。报道称,在印度第七届道路安全会议上,交通警察特别专员SurenderSinghYadav提到,智能交通管理系统(ITMS)还需要一年或一年半的时间才能全面实施,目前已耗资约140亿...
            0 0 758
            分享
          •   苹果 iOS 17 相机应用在现有的“网格”(Grid)辅助线基础上,还引入了全新的“水平线”(Level)辅助线,帮助用户调整角度,拍摄出更合适的照片。  在 iOS 此前版本中,用户开启“网格”(Grid)辅助线之外,还可以启用隐藏的十字准星选项,帮助用户调正拍摄主体。  在 iOS 17 系统中,用户可以选择启用“水平线”(Level)辅助线,会在取景框中间配有一根线条,当用户拍歪情况下会显示白色,拍正会显示黄色。  IT之家注:“水平线”(Level)辅助线仅在某个角度区间内出现,不会影响用户拍摄某些大角度的照片。作者:佚名原文链接:IT之家(ithome.com)
            0 0 1148
            分享
          • 看到这个问题你是不是已经笑了?当然我也做好了挨喷的准备了。我搜了一下知乎,同样的问题可以翻好几页,回答的观点也各式各样,但是没有一个统一的高赞答案,今天我姑且谈谈我的个人看法,欢迎大家一起讨论。来来来,坐好啦,先给大家说说我自己关于选择的故事。一、学习 Java 有前途么?我是 2005 年开始学习 Java 的,应该是相当早了(暴露年龄了),那时的我还没大学毕业,所以在学习前、学习中、学习后的所有阶段,「Java 是否有前途」的问题,一直让我惶惶不得终日,我当时也上网搜了很多次这个问题,看了几乎所有的观点,结果和现在一样,并没有一个统一的高赞答案。有说很有前途的,毕竟当时的 Python 还...
            3 1 1449
            分享
      • 51testing软件测试圈微信