你是怎么制定项目测试通过标准的？

zhoward

软件测试开始时都会要求编写测试计划，而测试计划里面就会提到软件测试的通过标准。以往都是测试都不需要写计划，测试之后也是凭问题的严重性来判断项目是否通过测试。比如说有个很严重的bug没有解决，那就无法通过。现在需要在测试计划里面就开始体现通过标准，对于标准的制定很是混乱。目前，我的通过标准是根据不同严重程度缺陷的数量来决定，如严重程度有1-urgent，2-very high，3-high，4-medium，5-low，然后引入缺陷类型，其中包括建议类——建议类说明需求没有规定，但是按照常规建议功能实现的缺陷。
我目前的通过标准是：【未关闭】1，2级缺陷总数占总数百分比为0；3，4级缺陷占比少于5%；5级缺陷占比少于10%——注意：分母为每个模块的缺陷数。该标准适用于每个模块，但是对于总体标准，却又拿捏不住。
不知道各位在测试管理过程中，都是怎么制定的测试通过标准？或者针对我这个情况，给点建议？谢谢了！

愚人

根据不同产品特点，用户等来制定吧
然后讨论评审，签字，通过

然后再根据反馈修订……

msnshow

通过标准是相关人员一起定义的，每个项目都会不太一样

archonwang

一般通过以下几个方面
1。 测试的覆盖情况
2。 测试通过的情况
3。 所发现问题的等级
4。 β测试的结果

zhanghl

补充：
遗留缺陷类型及比列
对测试结果，测试过程的评审结果

zhoward

可以说的具体一点么，虽然我也知道每个项目的通过标准都不同，但是还是希望可以有个例子可以说明一下。有朋友说道用千行代码发现的bug数来判断，说的都有道理，不过从测试角度上来看，缺少可操作性。一般来讲，测试所能控制的也就是【用例通过率】【bug类型和比例】，也有人谈到【需求覆盖率】。【用例通过率】这个好计算，但是其他两个指标有疑问。
【需求覆盖率】
1. 需求不明确。开发就给你个软件，根本没有任何文档，只说明了要测试什么模块。那好吧，这样怎么明确需求？退一步吧，我们可以根据行业知识和使用习惯来编写测试用例，而这些测试用例，相信每个人都会坚信自己写的用例已经覆盖了需求。那么这样的需求覆盖率岂不是100%？
2. 需求明确。现在有文档了，可以编写用例了。还是刚才那话，用例写完了，也就相信需求全覆盖了。那也是覆盖率100%？
所以，个人觉得需求覆盖率是空话，而在实际中，我也没有采用这个指标。
【bug类型和比例】
这个是我比较重视的，也是我原帖里面提到的那么些标准。只是还存在问题
1. 类型可以自己定，但是在没有比照对象的情况下，怎么确定通过比例？如严重性bug不能超过2%等等...
2. 一般软件出来都要经过几个版本测试，而且在第一版本测试之后会有个初步测试报告产生。那么，此时的比例应该是针对新发现的bug而言，万一刚好只发现1个high严重性bug，9个low严重性bug，而且比例刚好为10%的话，这个版本岂不是通过测试了？
3. 软件测试中，bug肯定有关闭，拒绝等状态，因此我的标准是定为未处理的bug，也就是说bug状态为new的bug，除以总体bug-建议性bug数目，依次来定比例，不知是否正确？
4. 测试软件，一般会将软件按照模块逐个分解。这时制定通过标准时，应该是要制定每个模块的通过标准，这个没错吧？
5. 接第四点，如果针对每个模块制定标准，那么也应该制定整体通过标准吧？要不然判断这软件是否通过呢。如果是这样的话，这个整体标准又该怎么制定，俺迷糊了....
6. 至于什么评审讨论的话，这个就不用提醒了,因为根本就是嘴皮功夫.....难不成写测试计划时候，在测试通过标准写：根据评审结果决定么...
6. 规范性的测试报告需要在每个版本测试之后编写提交么？
欢迎讨论，也希望大家可以解答我的疑问，谢谢。

celiaMao

1.需求覆盖率是可以核查的，如果将需求拆分为功能清单，再与用例进行核照即可查明。也可以借助工具管理需求和用例，如IBM就有RQM工具，只有需求覆盖全了，才能保证后续的标志。
2、测试执行率，是否100%执行到位
3、测试通过率
4、剩余的缺陷等级要求，如一二级缺陷不含有，三四级缺陷不超过总缺陷的20%
以上四点即可作为通过准则，如覆盖率100%，执行了100%，通过率100%等。

helios

感觉我这里遇到的情况与楼主差不多，目前我这里处理的方式是：将BUG划分A/B/C类，A类问题是严重程度高，功能需求实现不彻底，BUG关系到系统稳定性，涉及到软件安全方面；B类问题是一般功能性问题，不影响功能，是一些小的缺陷，用户使用上不会出现危害或错误；C类是一些界面，布局，字符等问题。
  一般评价是：A类只要有一个就不能通过，必须修复才能通过；B类不能多于2个存在；C类不能多于5个。如果存在B类是2个，C类有5个以下，将根据测试结果召集开发、产品、测试集中开会讨论，对问题确定原因和处理方案，根据讨论结果做出测试是否通过的结论。
这个判断也是不很全，我们也是因为没有好的判断标准，制定的一个测试通过标准，提交质量管理受控执行。有时，很多问题如果会上讨论结果放行，我们测试认为风险大，我们一般将该任务的发布提交与会领导签字放行，决定权上交，我们只针对报告负责，作为合同评审的发布版本。

zhoward

回复 8# helios


    开会讨论，并由上级决定是个可行的方法。这里问一下，你们这个ABC类的个数是怎么得出来的？这个数目用比例来计算不是会更合理一点么？按照你对B类的定义，我觉得一次测试下来，B类的缺陷应该很多，那岂不是基本都要修复才放行？

archonwang

回复 6# zhoward


    有点杯具~~不过是现状。工程化方法在软件领域并没有深入人心。

archonwang

这样的情况只能看着办了。所以我的感觉是你提供数据和现状说明，由决策层决定如何操作。集体开会是一定要的。否则，就变成了谁做谁负责——这样的情况都是类似的。