采用IN值对项目组交付质量评价方法：

概述：

• 对产品质量主要是通过度量版本的in值，大于某阀值的话不能提交测试、发布，
• In值小于阀值的版本才可以执行下面的环节；
• 经过两个讨论，一个是“是否没有必须修改的缺陷了”，另一个“是否没有必须实现的功能”。

注意： 而且并不是讨论通过就没责任了，测试经理和PM都会为发布后出现的问题承担责任的。

 

一、IN值是工程内部评价交付质量的评价标准

每个bug都有一个严重问题分值，除非后来证明不是bug，或者决定不改了。

这样每个版本的缺陷分值之和=in值，如果这个in值超过阀值A，就认为这次递交失败。

对不同的规模的产品in值的测试阀值不变，也就是质量标准是不变的

二、IN值计算方法

这个in值由很多参数组成的，包括严重程度、功能类别属性、哪类缺陷、发生频率、是否极限测试、普通测试＝＝

举例说明一个某模块的bug，其功能类别，使用极限测试与否，产生严重问题

0.7×0.5×20

0.7是该功能类别的分值、极限测试分值0.5，严重问题分值20

（名词解释：极限测试指超出正常使用范畴，但保不定哪位用户会使用到的比如打开一个2G的图片）

 

三、IN值合理性分析

1）这个in值采用缺陷分值累计值来计算和度量，而不是类似缺陷率一类的平均值，原因如下：

因为我们不知道总共会有多少bug，所以我们需要用已经发生的bug来评估现有产品质量。

发布版本不可能是0缺陷，所以剩余的缺陷IN低于阀值，才可以考虑发布，

而评审则确定不改的bug可能会导致客户的感知程度

 打个比方：

就是说在养鸡场范围内，无论多大的筐，一框超过20个臭鸡蛋已经达到客户的底线了，故就不能发布。

其它测试计划等等的，都不是强制要求，而恰恰是这个阀值。

 

 

2）可能有人认为in值的阀值主观，如何确定这个阀值是合理值，其他值就不合理呢

实际上，这个阀值是比较严格的，是通过比较经验和实践检验来确定的

开发组织的大拿们，经过经验积累，我们的测试缺陷给客户带来的感受值到达某个in值范围内

这样就能达到客户的容忍极限。

 

 

3）采用统一标准阀值，对于大规模产品或者项目是公平的：

就拿WPS和MS Office来说吧

你发现，Excel保存成PDF乱码，刚好WPS保存成PDF也乱码，对于前者你会觉得值得表扬吗

产品总是从小到大做出来的，其实我们每一次交付给客户的更新部分并不大

你不能说，你总是重复地在修改整个系统

假设每个组件都是经过验证被通过了，原则上，他就不应该源源不断的产生缺陷

 而且，测试也不能随随便便的说，这是以前就有的bug，只是没发现而已

举例说明

如果大约每周递交2次，三天时间内的代码量应该都是有限的吧，这部分修改引入的

缺陷应该是可以控制的，所以并非10倍大的产品就应该有10倍的阀值，否则客户换供应商了