51Testing软件测试论坛

标题: 面试题：如何判断软件比较稳定了？ [打印本页]

作者: applejuzi 时间: 2010-7-8 20:33
标题: 面试题：如何判断软件比较稳定了？
如何判断软件的稳定性，光从bug数量上说是肯定不行的，那还考虑什么呢？bug曲线分布图？？请测试同行发表建议啊，谢谢。

作者: Jackc 时间: 2010-7-13 13:09
面试的时候，最好分三部分描述比较好：

1、宏观上说，在一段时间内经过交叉测试、性能测试和代码走查后（我只列举国内企业常用的手段，其实还可以适当增加一些内容，比如API测试。），重要缺陷数持续位于安全范围内，则可认定该测试软件处于稳定状态。

2、解释1中的几个关键词。

A、一段时间：
通常指2个以上的释放周期，可根据项目实际进度需求调整。

B、重要缺陷：
在不同的阶段，对重要缺陷的解释也不尽相同。主要体现在“研发初、中期”与“产品发布前期”。

在产品发布前期，用户发现率和用户影响度两个属性在对于重要缺陷的定位中，占的比重会提高不少。

总体来说，如果缺陷一共分为五级，大概三级以上都算是重要缺陷了。

C、安全范围：
这个数据的定义与三个元素有关：缺陷等级、企业文化和项目规模。
一般来说，一个周期重要缺陷发现率为3个以下时，都属于安全范围。

注意，缺陷等级的影响应特别处理，比如，一个周期内，发现1个1级故障，则可能会认定此软件仍不稳定。

D、稳定：
稳定是相对的。也就是说，稳定是相对于期望得到结果而言的。
比如，期望软件能进入贝塔测试阶段，那么对稳定的标准相对较低，也许安全范围标准就变成1个周期内10个以下重要缺陷了。

3、附加描述

在实际项目中，还有一些信息也可以作为参考。
比如遗留缺陷数/等级
缺陷曲线状态（我认为，只要曲线处于安全范围内，则不需要针对稳定性考虑曲线状态）
执行测试的完成率（貌似探讨这个问题的时候，完成率都默认为100%的，当然，不排除某些不知趣的面试官非得考察这点）
硬件测试状态（如果是产品的话，需要特殊说明参考这个信息）

PS：在回答的最后，可以补充说一点：软件稳定性判断一般都是在软件研发周期的中后期进行的，如果初中期出现软件稳定的状态，则需要着重考虑测试覆盖率的问题。

综述，上述所描述的信息其实都应该写在测试计划中的里程碑出口检测信息中。

[ 本帖最后由 Jackc 于 2010-7-13 13:11 编辑 ]

作者: chengning 时间: 2010-7-13 14:43
学习了楼上牛人啊

作者: linda84 时间: 2010-7-14 18:44
请问jackc,什么叫释放周期？

作者: linda84 时间: 2010-7-14 18:55
一般来说，一个周期重要缺陷发现率为3个以下时，都属于安全范围。

注意，缺陷等级的影响应特别处理，比如，一个周期内，发现1个1级故障，则可能会认定此软件仍不稳定。-----------------------------------------------------------------对于这句话能否再解释一下，不是很明白。缺陷发现率为3个以下时？？一个周期内，发现1个1级故障，为什么可能会认定此软件扔不稳定？谢谢

作者: Jackc 时间: 2010-7-15 10:37

原帖由 linda84 于 2010-7-14 18:44 发表
请问jackc,什么叫释放周期？

呵呵，我忘记加定语了。

“释放周期”指的一个测试版本的测试时间，在国内也经常叫做“bulid 周期”或“build release 周期”

作者: Jackc 时间: 2010-7-15 11:29

原帖由 linda84 于 2010-7-14 18:55 发表
一般来说，一个周期重要缺陷发现率为3个以下时，都属于安全范围。

注意，缺陷等级的影响应特别处理，比如，一个周期内，发现1个1级故障，则可能会认定此软件仍不稳定。----------------------------------------- ...

软件的稳定状态通常会在项目的中后期出现，一是因为软件从开始研发到稳定，需要一些必要的时间；另一个则是判断稳定性的信息收集也需要时间。

实际项目进度往往有各种情况，一两句话说不完，就先说简单的情况，假设项目在研发过程中不再添加新的需求和功能。
在这种项目的中后期，产品质量的主要的风险会由“未察觉的缺陷”转变为“修复带来的缺陷”。（当然，前提是充分测试，这也是为什么在判断软件稳定性时，先得做1中的那些非常规测试了。）

所以，在判断稳定性期间，修复缺陷的类型和级别，影响着整个软件质量评估。
而修复一个“中间层的数据传输缺陷”的风险会远远大于修复一个“UI层字符显示错误缺陷”。最简单的原因就是：中间层的修复可能会涉及N个不同模块；而UI层的修复往往只需要修改一个模块即可。

作为测试和质量人员，一般情况下是不可能知道缺陷在修复时，具体是修改了哪些代码。但是故障缺陷等级则可以体现这点。（下面一段话又有点理想理论了，实际效果与各公司测试流程有关）

不同公司对缺陷等级的划分略有不同，不过大方向上基本一致。都是针对缺陷的“危害程度（指功能）”、“几率（包括重现率和用户使用率）”、“用户影响程度（指用户感受方面）”三方面来说的。
而在“危害程度”中，自然包括了危害范围这个系数。比如1级的死机缺陷和3级的日历程序crash，它俩的缺陷级别差异其实就只是危害影响范围的差异而已。

综上，缺陷等级越高，对产品带来的风险越大，自然对产品稳定性的影响也越大。

PS：题外说一下关于实际项目中，存在边研发边增加需求的情况。这种项目整体流程通常使用的是迭代，那么对应的测试流程也就应该是迭代的。所以，针对迭代的每个周期，完成相对独立的软件稳定性判断是有必要性的。
在一个未知状态的软件中，迭代一个新的功能，可能会让整个项目质量在相当长的一段时间中都无法控制和评估，风险还是挺大的：）

作者: hadywei 时间: 2010-7-15 11:48
以上观点是需要慢慢消化一下的~都是建立在丰富的项目经验基础之上的~

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)