1.6 提交的有效问题数量
【指标名称】提交的有效问题数量
【指标定义】每个周期中，CQ中提交的有效问题数量
【设置目的】反映测试人员的一个周期的工作量
【计算公式】
【计量单位】个
【数据提供】POP
【数据审核】测试LTM 测试部经理
【统计周期】每个月
【考核对象】TE
【分区说明】
【目前统计办法】 目前暂未对此类数据进行考核。对测试人员提交的CQ进行审核，目前有两个难点：一、CQ上需要实现此功能；
二、测试的LTM能够从日常的测试工作中抽离出来，绝大部分精力投入到管理工作时，才有可能投入精力审核提交bug、维护测试用例、把握测试进度和测试方法。
结合下面的一个数据收集，目前进行统计的数据是每个周期中，CQ中每个测试人员提交的问题数量，反馈测试人员的一个周期工作量，反应软件模块的周期稳定性，暂不详细区分测试人员的效率和对业务的理解程度。
1.7提交的非有效问题数量
【指标名称】 提交的非有效问题数量
【指标定义】每个周期中，CQ中提交的非有效问题数量
【设置目的】 度量所有测试人员对系统理解的能力
【计算公式】
【计量单位】个
【数据提供】POP
【数据审核】测试LTM 测试部经理
【统计周期】月
【考核对象】角色：TE
【分区说明】
【目前统计办法】 同【提交的有效问题数量】
1.8回归问题单的数量
【指标名称】 回归问题单的数量
【指标定义】 每个周期中，测试人员回归问题单的数量
【设置目的】 衡量测试人员回归问题的数量，用于评估测试人员的工作量
【计算公式】
【计量单位】个
【数据提供】POP
【数据审核】测试LTM 测试部经理
【统计周期】每月
【考核对象】TE
【分区说明】
【目前统计办法】在CQ上通过设置查询条件，可以直接获取此类数据，因此数据和上述一些度量数据都为评估测试人员工作量的参考数据，而目前的工作中，还有很多不可量化的工作，所以此数据暂未采用推行。
1.9执行用例数
【指标名称】执行测试用例数
【指标定义】每个周期中，执行的测试用例数
【设置目的】用以反映测试人员的工作量
【计算公式】
【计量单位】个
【数据提供】POP
【数据审核】测试LTM测试部经理
【统计周期】每个星期
【考核对象】TE
【说明】
【分区说明】无
【目前统计办法】数据可由TD直接导出，目前TD在实际使用中存在颗粒度的问题，此数据在此阶段无实用价值。（参考测试用例执行度参数）
【重点难点】需要对TD的颗粒度和step进行规范，做到统计单位的基本一致，否则不同模块测试用例的执行统计无量化效果，也无横向纵向比较的意义。
1.10新创建用例数
【指标名称】新创建用例数
【指标定义】到产品GA点，新创建的测试用例数量
【设置目的】衡量测试人员的工作量
【计算公式】
【计量单位】个
【数据提供】POP
【数据审核】测试LTM、测试部经理
【统计周期】产品正式版本的测试完成
【考核对象】TE
【分区说明】
【目前统计办法】新创建用例数,可以统计，可以利用TD中的过滤条件（Creation Date)统计出来。
1.11
测试案例个数
【指标名称】 测试案例的个数
【指标定义】 每个周期中，提供的测试案例个数
【设置目的】 衡量测试人员的经验教训的总结情况
【计算公式】
【计量单位】个
【数据提供】IT
【数据审核】研发经理 测试部经理
【统计周期】季度
【考核对象】TE
【分区说明】
【目前统计办法】按季度按人在案例库中进行统计，业内的数据是按月统计，目前公司的量化标准是季度。
2
总结
在上文中，针对测试领域在业内的一些常用统计数据进行了分析，介绍了其统计方法，以及各项指标收集的重点难点，同时结合本公司现状，提出了一些解决方案和远景期望。
在此文中提到的数据主要分两类：测试质量类；TE工作量反馈类。
针对测试质量类，可以先行收集、分析，在收集的过程中，暴露问题和解决问题、优化测试的各环节，提取数据供项目组参考评判。
针对工作量反馈类，目前各组在实际工作中，存在大量的不可量化的工作内容，比如配合开发人员调试、重现问题、反复的回归测试；根据项目组实际情况出差、专项测试、临时任务等；
所以在此类数据中（测试用例执行度、提交的有效问题数量、提交的非有效问题数量、回归问题单的数量、执行用例数、新创建用例数）中，只取用了部分数据，通过一些数据来对应软件测试的阶段、软件测试暴露的质量问题，同时作为测试工程师在一个工作项内的工作量数据参考。
测试数据的统计和分析仅仅是第一步工作，收集上来的数据怎么使用？
数据能够真正的有价值，起到衡量软件质量、监控软件开发和测试工作、实现绩效考核的目的，还依赖于流程的贯彻和执行，产品线和各资源部门，从实际工作和数据收集的不同角度换位思考，不断的改进、优化和完善目前的各类辅助工具，形成
1013
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
