1)软件测试工程师如何制定测试完成的出口准则?

一般应该包含哪些指标?

测试项目进展的什么时候可以结束测试?

用什么数据说明产品已经符合上线的要求?

这四个问题我觉得是同一个根本问题：

测试完成标准到底应该如何制定

我认为这不是软件测试工程师一个人的事

甚至不是软件工测试工程师能决定的事

这是从上到下的决策过程

整个研发组织管理层甚至包括产品、销售等管理层应该首先制定研发结束标准

在这个大标准下测试经理负责制定测试完成标准

最后软件测试工程师在两大标准指导下制定自己负责的那部分测试的完成标准

总体而言软件研发结束有两种标准

第一：对软件制定明确的KPI并达标

比如Must have功能全部实现并没有严重问题

所有已实现的Better to have功能没有严重问题

软件能继续运行两个星期无死机无性能明显下降，等等

第二：资源耗尽

最常见的就是到了承诺的发布日期

还有一种是所有计划的工作量都已完成

举例来说

一个火箭发射点火程序软件应该是第一种标准

事先制定谨慎、严格、详尽、可量化的KPI

不达到KPI宁可推延火箭发射日期也不能对付着上线

(我猜的。。。我没参与过这么高端的软件研发啊)

但如果知乎想推出一个新版本添加点儿类似点赞送花之类的小功能

就更可能采用第二种标准

反正出了bug也没啥大损失

(也是我猜的啊。。。)

而微软想推出Windows version 250

则是两个标准的折衷平衡

商用软件运用折衷的标准更普遍一些

折衷方式取决于公司的管理文化、产品的市场策略、产品质量对市场的影响力等等

有了研发结束标准(就算没有成文的但肯定上层也都有一个默契)

那么测试经理据此制定一个可行的测试出口标准

而这套标准应该是与整个测试管理的其它方面相关的

比如测试用例的管理、bug的管理这些都会影响到出口标准的制定

测试用例应该有分级分类

bug应该有优先级和严重程度分类

这样出口标准里才可以说

1)一级的回归测试用例全部完成

2)一到三级的新功能测试用例全部完成

3)所有已发现的一级bug都已解决并通过测试

4)连续两个测试周期没有新的严重等级高于二级bug

5)拟发布版本在性能平台上已无故障运行满一周

(以上是我负责过的一个软件的大版本发布测试出口标准。。。嗯。。。大意如此不完全一样)

等等

再高级一点的还要用上数据分析

比如bug open/close trend达到或低于过去同类版本发布前的水平

再高端大气上档次还可以运用什么Six Sigma理论

(我没用过哈。。。看有人用过)

即使同一个软件

大版本发布和小版本发布的测试出口标准也可能是不同的

测试经理的一项职责就是制定这些标准

当然好多好多好多公司软件测试出口标准是

feeling。。。。

就是“我觉得好象似乎可能大概齐也就差不多这样了哈”

2)一个版本发现了10个bug，令一个版本之发现了2个bug，这可以说明什么?

如何看待bug的数目与软件质量之间的关系?

这两个问题也是同类问题一起回答

做测试永远要记住bug的数量没有bug的质量重要

离开bug的严重程度说bug数是没啥意义的

100个严重程度很低的bug不如一个严重程度顶级的bug重要

这就好象两个人出去玩

一个在树林子里被树枝划了全身都是血道道

另一个摔个大跟头断了一条腿

你说能一样么?能一样么?能一样么?

所以bug必须一定坚决要按严重程度分级

每级应该有明确的标准

而且这个标准应该是整个研发团队共同认可的

不能是测试工程师自己拍脑袋决定的

也不是测试经理一厢情愿决定的

事实上光是bug的严重程度也不是理想的指标

很多bug管理软件会有两个指标来衡量bug

严重程度和优先级

比如一个bug只要发生软件就会关闭重启

严重程度绝对高

但这个bug发生的几率是万分之一

那么到底这个bug优先级高不高就不一定了

对火箭发射来讲这极可能仍然是一个非常严重需要马上修复的bug

但对大部分商务软件来讲大概都不要着急修

3)如何评估软件产品的质量?

这个问题挺难回答的

从直观的和用户的角度说

评估软件的质量应该考虑以下几个方面：

- 易用性：界面友不友好、提示明不明确、功能顺不顺手

- 可靠性：bug多不多、性能好不好

- 局限性：软件适用范围多大、有哪些使用限制

- 用户反馈如何、post-release bug多不多严重不严重

等等

从研发的角度应该评估：

- 需求是否明确、需求返工率高不高

- 设计合不合理、可维护可扩展性如何

- 代码可读性好不好、版本管理是否高效

- bug/line of code比率如何

等等

关键的关键是如何合理量化上述指标

这个很难搞

比如怎么评估设计合不合理、代码可读性好不好

它在软件质量评估中占多大的权重合适

太多基础数据的收集、分析

既要相信数据又不能只相信数据

最后搞不好又成了大概好象差不多还行吧

——————————补充回答的分割符——————————

的确有把预测bug数目做为测试出口标准的

但我个人不赞同这种做法

我认为测试过程中产生的bug数目可以做为一个参考项

而且是个很重要的参考项

我自己在测试项目的管理中会每天监控这一项

如果它明显低于经验值

我会马上看是不是测试进度落后了

还是测试用例设计出了问题

如果明显高于经验值

会马上分析bug并与开发团队讨论看是不是开发方面出现了什么异常

进而确定项目是否有可能延误

尽管如此

我还是不赞同bug数目做为出口标准

我的理由有以下两点：

1)bug数目的多少受很多因素影响

比如一个测试人员从需求讨论开始就参与的项目

bug数会明显低于直到开发中、后期测试人员才介入的项目

又如一个研发团队稳定的项目

bug数也会明显低于一个人员变动较多的项目

研发团队内部沟通畅通的项目 bug少

研发资源充足、日程安排不太紧张的项目bug少

项目管理好的项目bug少

当然功能模块简单、直观的项目bug也少

等等等等

2)以我的经验

当bug数量成为与绩效相关的指标

测试与开发之间会更容易形成对立态度

而且会就一个bug到底是有效的还是无效的扯皮

另外测试人员也更容易丢西瓜捡芝麻

因为搞定一个西瓜明显比搞定一颗芝麻费劲却不讨巧

测试效率也会有所下降

夸张点儿说界面一个错别字跟开发吼一嗓子就解决的事

也要写到bug库了走一遍流程这就是形式主义瞎扯淡

最终结果并不利于提高产品质量

所以我不赞成拿测试过程产生的bug数做为出口标准

也不赞成用这个数目做为产品质量好坏的标准

但我认为post-release的bug数是产品质量的重要标准

你问“所有的测试用例都执行完了，没发现几个bug”

这种情况到底能不能说明产品质量已经达标

我认为要看你的测试流程怎么样

测试用例在设计完成后应该有review

象我负责的项目至少要经过测试小组内部review和与开发review

重要的项目还要与产品经理review

确保没有设计盲区才能开始测试

测试执行期最好留出一定时间让测试人员丢掉测试用例做探索式测试

如果可能尽量安排交叉测试(让测试人员A测试B写的测试用例)

这些都做了那么测试结果应该九成可靠了

再分析一下这个项目有什么特殊性可能造成bug明显少

如果能找到原因那么测试结果基本上是可靠的

但如果这些都没有

那我只能说这测试做得不及格