如何控制开发提交的版本质量以及版本评估

hxc21st

目前公司有好几个产品组，有些产品组的水平较低，提交的版本质量差，有没有什么途径可以改善开发提交的版本质量。

另外，在测试完一个版本后，需要从哪些方面给出评估，来决定版本是否可以对外发布。最好有详细一点的说明。

luoyear

1、冒烟测试，根据测试情况把版本退回去；
2、提交测试前需要提交开发部的测试报告，以证明开发部相应的测试活动都进行了并且修复了相应的bug；
3、利用泄漏率指标、测试缺陷密度、测试版本通过率等度量反向促进开发部改善提交版本的质量。

luoyear

原帖由 hxc21st 于 2006-11-20 18:35 发表
目前公司有好几个产品组，有些产品组的水平较低，提交的版本质量差，有没有什么途径可以改善开发提交的版本质量。

另外，在测试完一个版本后，需要从哪些方面给出评估，来决定版本是否可以对外发布。最好有详 ...

测试完成后
可以基于绝对bug数、bug收敛趋势等指标去判定交付与否

lingzhen

如果不能做到对测试覆盖率的比较细致的评估的话，bug统计的不同情况应该就是主要的指标了，好的过程还应该是可以通过别的方面的指标的评价一个经过测试的版本的质量等级的．同时风险也是很常用的指标．
可以看看ＲＵＰ里几种覆盖率的说明，和度量相关的一下资料，应该可以整理出个方案，弄个简单的方案先执行了在逐步根据项目组的执行能力和意愿来进行改进．

hxc21st

谢谢两位，我目前就想知道应当从哪些指标来评价版本，各指标如何计算，有没有相应的工具。
另外，开发人员提交的测试报告应包含哪些测试项，是只包含BUG验证结果还是说除了BUG验证外还要验证基本功能，应包含哪些功能

lingzhen

"开发人员提交的测试报告应包含哪些测试项，是只包含BUG验证结果还是说除了BUG验证外还要验证基本功能，应包含哪些功能"

---应该不用验证功能了，毕竟测试人员已经验证了，如果不放心则需要像QA一样测试其测试用例执行情况，测试用例覆盖的满足程度（评审测试用例的工作进行怎么样？）。如果实在需要验证功能，可以有点想Beta测试一样只验证正面的用户经常使用的和失败风险比较大的功能。

bug指标
可以是不同模块的bug数量对比，需要衡量以下模块间规模和性质以及实现的业务，以及开发人员的熟悉程度，以及开发所用的时间，包括设计和需求分析的时间（毕竟很多情况下是由于时间不足而工作不充分引起的）

还可以是bug的统计曲线，按日统计，需要考虑当日投入的测试资源的多少。

以及回归的情况，回归了多少测试用例，或对出现过bug 的地方的回归测试。

并抽样在某些区域用重火力猛测一段时间，看发现bug 的数量和严重程度，在类推相关的模块和整个系统。

上述多是指基于手工测试时的情况。