做QA的心历随笔

       2022年12月13日入职新公司，副经理，热情满满，准备从0到1大干一场，测试规范，人员梯队，人员培养等等，然后具体的活是找自动化测试供应商，忙活了2个多月，跟上级也是每天多次沟通。

       然后，上级的上级对我跟我领导的定位有了变化，我们是定义标准和新技术的引进与培训，然后感觉自己被定位成为了“质量工程师（QA）”。

      14年多工作经验，都在做测试工程师（QC）没做过，只能说见过猪走路，也要配合QA部门改进质量流程措施，

1. 出标准

依葫芦画瓢的整质量指标，改了几版，跟领导沟通来沟通去，

各种百度文档，请教朋友，看文章，输出了几版指标，如：

第一版：

分类	度量指标	指标内容	指标	说明
项目度量	规模	测试用例数量（月）
		测试用例/人月
	测试工作量	需求评审时间
		编写测试用例时间
		用例评审时间
		测试用例执行工作量
		回归测试执行工作量
	测试进度	计划开始结束时间
		实际开始结束时间
		计划工时数
		实际工时数
		计划完成率
		实际完成率
		测试用例执行率
		测试用例通过率
		测试用例问题发现率		覆盖缺陷的用例数/缺陷总数，不足100%，将缺陷生成新用例加入到用例库，并加入版本计划中
	测试覆盖率	测试用例覆盖率-需求覆盖率、功能点覆盖率		版本测试用例总数/需求总数
质量度量	缺陷率（阶段）	评审过程中出现的错误数量
		缺陷数量
		缺陷级别统计
		缺陷分布统计（模块）		客户发现的缺陷数+交付前发现的缺陷数，持续观察，应呈递减趋势
		缺陷分布统计（阶段）		阶段缺陷数量，应随着上线递减至0
		缺陷密度		千行代码缺陷数       缺陷数/千行代码数
		缺陷关闭率		版本已关闭的缺陷/版本所有的缺陷，上线前应达到100%
		缺陷逃逸率		客户发现的缺陷数/（客户发现的缺陷数+交付前发现的缺陷数），持续观察，应呈递减趋势
		缺陷修复时长		超修复时效的缺陷数/版本总缺陷数，重点关注修复超时且优先级高的缺陷

 舍弃，因为QC的行政归属 归业务线，无语，哈哈哈。

第二版

分类	指标	说明	公式	计算结果
软件质量指标	用例覆盖需求率	计算用例关联的需求数除以总需求数，主要查看是否有需求遗漏测试的情况。	有用例关联的需求数/所有的需求数	用例覆盖需求率=90/100=90%
	用例执行覆盖率	计算测试用例执行总数除以与之一一对应的测试数之和，主要查看是否有测试用例执行遗漏或有效的情况。	∑执行的测试用例个数（个） / ∑测试用例个数（个）*100%	用例执行覆盖率=100%
	缺陷修复率（截至于**年*月*日）	计算已修复（关闭）的缺陷总数除以有效缺陷总数，主要查看是否有测试用例执行遗漏或有效的情况。	∑修复（关闭）的缺陷数量（个） / ∑有效缺陷数量（个）	缺陷修复率=206/216*100%=95%
	缺陷遗留个数（截至于**年*月*日）	统计待分配、待修改、重新处理的缺陷数量	待分配+待修改+reopen状态的缺陷	缺陷遗留个数=10，且为C类以下bug(建议性缺陷)
	缺陷分布统计（模块缺陷率）	计算各模块的缺陷数除以总体缺陷之和，主要查看模块的质量的情况。 说明：此指标不能单纯看结果，要结合实际情况进行分析，如模块的粒度是否划分均匀，模块的重要性，模块包含的内容是否更容易发现bug等。	本模块的缺陷数（个） / ∑各模块的缺陷数（个）*100%
	缺陷分布统计（严重缺陷率）	计算各模块的严重缺陷数除以总体缺陷之和，主要查看模块的质量的情况。 说明：此指标不能单纯看结果，要结合实际情况进行分析，如模块的粒度是否划分均匀，模块的重要性，模块包含的内容是否更容易发现bug等。	本模块的严重缺陷数（个） / ∑各模块的严重缺陷数（个）*100%
	缺陷密度及收敛	计算各版本缺陷数除以测试模块，主要查看版本是否趋于稳定情况，通过数据图表等方式来衡量版本交付的风险大小，是衡量版本是否可交付的重要依据之一。 此指标不能单纯看结果，要结合实际情况进行分析，如模块的粒度是否划分均匀，模块的重要性，模块包含的内容是否更容易发现bug等。 如果缺陷密度逐渐收敛，说明版本逐渐稳定；如果趋势起伏不定，需要分析研究原因，查找不稳定的原因；如果缺陷密度趋势呈波状，一定要重视起来，说明版本及其不稳定，确认发布时要慎重。	本版本的缺陷数（个） / ∑已测各模块数（个）
测试过程质量指标	缺陷探测率	计算内部发现的缺陷数除以内部发现的缺陷数与用户发现的缺陷数之和，主要查看内部发现缺陷的能力。 说明：缺陷探测率越高，即内部发现的bug数越多，发布后客户发现的bug数就越少，质量成本就越低。	内部发现的缺陷数（个） / （内部发现的缺陷数（个）+用户发现的缺陷数（个））*100%	缺陷探测率=80/(80+5)=94%
	有效缺陷率	计算被开发人员确认的BUG数总和除于本人上报BUG的总和，可用于查看测试人员的个人测试质量，也可用于查看整个测试组的测试质量。 无效BUG状态包括：问题重复、不是问题、不可复现状态。这项指标用于考察测试人员发现的、被确认为缺陷的缺陷数高低或者百分比，数和比率越高测试质量越高。 注意：由于系统框架根本性的、初始化参数设置错误引发的、错误数据、错误环境等而开发人员因无法修正、可以通过改变环境而无需修改程序、重新导入数据、再次发布而解决的BUG为有效BUG	测试人员发现的有效缺陷数（个） /测试人员发现的总缺陷数（个）*100%
	用例执行效率	计算测试人员执行的用例数除以执行测试的时间，主要查看测试人员执行测试的效率。 说明：此指标的统计需要有一定的前提条件：用例的执行步骤相对来说分布较均匀，执行时间在一个较长的时间段内	∑测试人员执行的用例数（个） / ∑执行用例的时间（小时）
	缺陷重开率	有重开的缺陷数除以测试阶段缺陷总和	有重开的缺陷数/测试人员发现的总缺陷数（个）*100%
	缺陷重开次数大于1的缺陷个数	缺陷重开次数>1的缺陷数	重开次数大于1的个数
	缺陷发现率	计算测试人员各自发现的缺陷数总和除于各自所花费的测试时间总和。 由于执行效率不能足够代表测试人员是否认真工作，那么，每小时发现的缺陷数就是重要的考核指标，测试的工作可以通过这项指标得到反馈。 注意：此项指标的统计可作为测试质量的一个依据，但实际工作中如果用此指标作为考核测试人员的唯一依据会带来很多问题，比如，缺陷数可通过减小缺陷粒度、增加微小缺陷、增加不能确定bug数来提高分子数，这样会增加缺陷流转处理成本，会带来更多的问题。建议慎用。
交付质量	发版回滚率	计算一年内发版回滚次数除以版本数，主要看看发布质量。	发布回滚次数/上线次数	发布回滚率=1/20*100%=5%
	加载回退率	计算计划上线需求个数减去加载回退的需求个数之差除以计划上线需求个数，主要查看新需求上线交付质量。 说明：上线加载当日无法满足上线条件，导致回退。	（上线需求数（个）-加载当时回退需求数（个））/上线需求数（个）*100%	加载回退率=（15-1）/15*100%=93%
	故障回退率	计算计划上线需求个数减去故障回退的需求个数之差除以计划上线需求个数，主要查看新需求上线交付质量。 说明：上线加载次日，用户无法使用，引发投诉，进行故障回退。	（上线需求数（个）-故障回退需求数（个））/上线需求数（个）*100%	故障回退率=（16-2）/16 *100%=88%

2. 实际落地的小步快跑

第一版月报，包括：缺陷修复率、重开率、严重程度占比。

领导们又提出新需求，想让我们统计每个产品的测试次数 

3. 第二步小跑- 增加需求转测的次数统计

计算规则

用缺陷的部署版本号+“冒烟测试不通过”标签统计次数；

规则1：只要有“冒烟测试不通过”标签，都算未能一次性通过；

规则2：在没有“冒烟测试不通过”标签的情况下，统计该需求/用户故事关联的缺陷，数量>0 ，都算未能一次性通过；

规则3：没有“冒烟测试不通过“标签，也没有关联缺陷，此需求/用户故事 为 “转测一次性通过” 。

规则4：如果有缺陷，统计缺陷里面的部署版本号，第一次提交时的部署版本号，验证缺陷修复情况时的部署版本号不一致，按版本号个数计算次数。

路还很长，需要先出方案，指导手册，然后跟业务线沟通，落地实施，监控测试规范的执行情况。