当前位置: 首页 > ds >正文

怎样使用数据度量测试

在测试项目中会遇到一些难点,如测试进度量化、测试表现量化、工作量和预期时间的管理。作为一名致力于往管理方向靠的同学应该都会思考的问题。每个人执行的内容不一样,遇到的问题不一样,测试难度不一样,还有一些不确定的客观和主观因素,那如何才能在实际的项目组很好的使用数据度量测试呢?主要从下面几个方向进行分析,测试进度,测试有效性和测试工程师的表现。

测试进度:

测试计划与实际测试的差异往往是不可忽视的,作为测试经理或主管在测试计划的时候就需要对整个相关的开发周期和里程碑时间确定清楚。然后根据测试内容进行量化评估,以确保合理安排人力和排期顺利交付合格产品。

  • 测试计划:

    • 项目里程碑:通常项目都会与一个开发时间计划里程碑表,在各个时间阶段需要交付对应的产品。以确保后续产品能够按照预订时间进行发布上线。一般情况,是不会轻易变动的,这里我们默认固定时间。
    • 工作量评估:测试工作需要对测试内容,测试项,多寡以及自动化程度,测试人力可投入资源等多方评估后才能确定。
      • 专项测试:性能专项、兼容专项、安全专项、弱网专项等
      • 功能测试:主要以模块负责的方式进行责任制管理,将模块耦合度高的尽量做拆分
      • 人力资源:现阶段测试人力,每天投入与产出评估,人力不足时需要调整测试策略或增加人手已满知足项目测试需求
      • 测试内容:项目按照模块划分后,对应模块的工作量化。需要对模块复杂程度和测试点判断,然后给出工时。
    • 测试计划:测试计划排期主要是根据任务量所需工时,然后结合里程碑时间进行各个阶段的测试计划。
      • 测试准备:前期准备阶段,需要与开发跟进需求,需求评审后就开始陆续编写用例和用例评审,环境准备等
      • 测试执行:按照用例执行,并做好相关记录。(需要收集执行用例数量,发现bug数量,执行时长等相关数据)
      • 专项并行:这部分在功能验收阶段可以根据测试包体的完整性进行择机测试。在测试计划中体现大致的时间范围。
    • 预留时间buff:项目开发本身是变化的,因此,在设计测试计划时预留buff时间,以应对各种突发情况。
  • 实际测试时间:

    • 实际时间:测试工程师不可能100%投入到工作中,根据数据统计每天的经力的60%时间投入属于正常。测试工程师在执行过程中还需要应对各种问题,如沟通,会议,学习等
    • 执行记录:做好用例执行记录,以版本维度做好模块执行耗时、用例数量、bug数量,严重级别等数据
    • 修正计划:通过真实数据,对测试计划进行适当的修正,使其更合理
  • 结果偏移:

    • 实际完成时间和计划时间的差异就是结果偏移,在日常执行的过程中合理范围内做一些内容的前置,每天多做一点,以保证如期交付。

测试有效性:

测试有效性(Test Effectiveness,TE)是指执行用例发现的有效bug的数量。公式:测试有效性 = 有效bug数/执行用例数 ;在版本迭代,模块管理过程中可以通过此预测该版本或者模块大致会有多少bug。比如:版本——测试有效性为:0.060 ,目前还有30个用例没有执行,这个时候我们可以预测还有大概2个bug。工程师——测试有效性:工程师B的有效性为0.099,如果还有40个用例没有执行,那可以预测还会发现4个bug。

不同维度,可以让我们直观的看到版本在迭代过程中质量的变化。如下趋势是说明版本越来越稳定,bug数量呈现收敛,且严重级别高的bug修复,符合发布标准。

版本维度:

版本——测试有效性量度
版本缺陷用例执行数缺陷/用例执行数
新增总计发布总计发布总计
开发版本134345705700.0600.060
开发版本24781123018000.0380.045
开发版本339 12089026900.0440.045
开发版本41813849031800.0370.043
开发版本5614422034000.0270.042

版本——严重级别趋势
版本严重级别
致命严重一般建议总计
开发版本171313134
开发版本241130247
开发版本32334039
开发版本41212318
开发版本500606

工程师维度:

工程师——测试有效性
工程师工程师A工程师B工程师C工程师D工程师E总计
用例执行数1517179100169570
有效bug9763934
缺陷/用例0.0600.0990.0760.0300.0530.060

测试工程师的表现:

测试工程师的表现,最终通过绩效方式直接提现,那我们怎么才能激励员工的同时尽可能通过数据公平决策。实际项目中评价绩效,一言难尽,很多时候都没有标准,确实也是个难题。

在上述过程中,我们在执行用例过程中就已经开始做这部分工作了。基本衡量维度有:用例执行数量、bug数量。但是直接粗暴的比较会出现很多弊端,比如恶性竞争只追求数量不要求质量。

用例执行数量:阶段时间所执行的用例数,如一个月或一个季度

bug数量:阶段时间发现的bug数量,如一个月或一个季度

评价方式:用例执行量为总的执行量的占比,bug数量为总的bug数量的占比,通过占比进行计算。同时增加不同等级bug的权重如:

严重级别权重
致命严重一般建议
10531

通过调整权重,使得评价更加客观多元化。当然,理论上,这样做是非常可行的,但是在执行的过程中,还会有很多问题。如这些数据的收集整理(日常工作就挤破头了,根本没有时间做好记录,所以规范化流程化管理是非常必要的),其他维度贡献的评价。

总结:

本文提供一些量化方向,可以使得我们在管理和计划过程中有数据做支撑,而不是一味的拍脑袋决策。同时,在量化过程中也间接的做好了执行过程的监督和抽查工作。作为一个成熟的测试负责人,不至于被动,可以通过数据进行判断当前版本质量变化及时的发现测试进度问题,灵活的做出调整,高质量交付。

http://www.xdnf.cn/news/18058.html

相关文章:

  • Spring 条件注解与 SPI 机制(深度解析)
  • 社区物业HCommunity本地部署手册
  • 51单片机-驱动蜂鸣器模块教程
  • 力扣400:第N位数字
  • 我的学习认知、高效方法与知识积累笔记
  • 【Docker】搭建一个高性能的分布式对象存储服务 - MinIO
  • 国标调查:构建餐饮满意度动态优化体系,驱动体验价值升级​
  • Linux程序内存布局分析
  • rent8 安装部署教程之 Windows
  • Python采集微店商品详情 API 返回值说明,json数据返回
  • MySQL(多表查询练习)
  • 《嵌入式Linux应用编程(六):并发编程基础:多进程exec函数族及多线程基础》
  • swift多卡并行训练微调qwen3-8B
  • QT开发中QString是怎么转char*类型的
  • ARM Cortex-M7 Thread Mode与Handler Mode
  • 数据结构:严格二叉树 (Strict Binary Tree)
  • PyTorch的安装-CPU版本或者GPU安装有什么区别吗
  • Unity_导航网格
  • 我的第一个音乐元素浏览项目上传至Github啦!
  • MyBatis 与 MyBatis-Plus 的区别
  • STM32L051同时处理Alarm A和Alarm B中断
  • SSH协议的GIT转换
  • 系统介绍pca主成分分析算法
  • flutter开发(二)检测媒体中的静音
  • Day59--图论--47. 参加科学大会(卡码网),94. 城市间货物运输 I(卡码网)
  • 【DDIA】第二部分:分布式数据
  • 应用层协议——HTTP
  • 抽奖程序web程序
  • JavaScript 基础实战:DOM 操作、数据类型与常见需求实现
  • 项目管理工具