发布标准是什么?可以修改吗?

 
背景：<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

有项目组到了要上线了，经测试组测试后最后一个版本的测试报告中描述如下：

“按照测试用例执行测试，发现问题16个，级别为High有6个，测试用例通过率为80%，上个版本未实现的内容出现的新问题较多。

回归问题单43张，ReOpen 8张，ReOpen率为19%。

从该版本回归测试情况来看，缺陷数有明显减少的趋势，但是目前送测的内容中存在30个问题待修复验证，其中严重的问题有11个，未达到发布标准，该版本不能对外发布。”

 

项目经理问，测试负责人“什么是发布标准？我可以修改发布标准吗”

 

如果你是这位测试负责人，你会如何回答，或者有什么改进建议？

 

一位测试负责人给了我以下的回复：

发布标准在测试计划中就已经说明：

1、软件需求分析说明书中定义的所有功能已全部实现，性能指标全部达到要求。

2、在验收测试中发现的错误已经得到修改，各级缺陷修复率达到标准。

3、所有测试项没有残余Very High或High的BUG。

4、需求分析文档、设计文档和编码实现一致。

5、验收测试工件齐全。

因为项目中还存在11个High（Very High）的问题单未修复，未达到100%的修复率，所以不能对外发布。

* 修改发布标准只能在测试计划发布评审的时候修改，到项目的后期修改是不允许的。

* 可以针对未修复的问题单进行等级和优先级的重新划分，确认最后是否需要修复，对发布是否造成影响。

两天后该项目的部门经理给了如下的回复：

这个项目再推迟上用户方测试环境的话，面临的用户压力会非常大，所以由项目组按原计划上用户方测试环境，项目经理需要和客户沟通好这里面潜在的问题和风险。
4000

测试部的后续处理方式：

 根据公司的规定，测试部有发布的否决权，开发部门的部门经理有发布权,所以该项目在开发部门经理同意后，可以给客户。但测试部要根进用户的反馈情况，及时收集客户反馈信息，并分析缺陷情况。给项目质量改进提供数据。

我的思考：

1． 发布是否应该再细化为不同的情况，例如：给客户测试的版本和上正工生产系统的版本对质量的要求是否可以不一致呢？

2． 项目组对发布流程不熟悉。

3． 质量方面的压力传递没有做好，目前还是主导在测试部，发现问题是从修改发布标准的角度去解决，不是最好办法。

4． 如何收集客户提出的缺陷，做好漏测分析。

5． 质量目标有做，但没有深入人心，如果将质量目标落实到人。

6． ……