51Testing软件测试论坛

标题: 如何量化评估被测试软件的质量？（08-03-07）（获奖名单已公布） [打印本页]

作者: 51testing 时间: 2008-3-7 17:54
标题: 如何量化评估被测试软件的质量？（08-03-07）（获奖名单已公布）
在测试过程中，我们需要根据各种度量数据从不同角度来对被测软件的质量进行分析评估，找出软件的质量薄弱点、评价软件发布的风险、预估软件测试结束的时间等等，这些分析评估涉及到各种角度、不同指标，也有一些从工程中总结的分析模型，欢迎大家踊跃讨论，分享各自在工作中所使用的评估方法，共同进步。

非常感谢各位会员积极参与，截止至3月14日１７：３０分，从该贴所有评论中选出部分作出精彩评论的会员予以奖励。礼品和积分将在下周内送出。

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	charles	当当购物卡50元	31#
二等奖	cityyard	300论坛积分	3#
三等奖	lzz	100论坛积分	8#

作者: misfit 时间: 2008-3-8 10:50
这个问题我理解起来很是费劲，软件评价标准需要考虑的方面很多啊。

坐个沙发，提供一下我在工作中用到的一些评价评估指标吧。

1、根据软件的规模的进行初步划分：大型软件、中型软件、小型软件
2、根据软件的在整个系统中的等级进行初步划分：关键软件、重要软件、一般软件、辅助软件
3、根据对软件影响的程度进行bug等级的划分：关键缺陷、严重缺陷、一般缺陷、建议改进
4、根据软件测试周期和工作结点来划分：提前完成、按时完成、项目滞后、项目中断

评价软件质量的原则就是上面四种划分的组合，从而得到一个相对完整的质量评价。
组合标准是明确软件的类型和软件的重要度，然后对bug的分布进行统计。
如果关键缺陷的概率过高，那么这个软件可以说已经不用进行评价了。
然后是根据这个软件的测试周期进行评价，过多的中断或者长时间的项目滞后也不是优秀的软件产品。

个人经验吧，可能有些文不对题了，仅供参考

[ 本帖最后由 misfit 于 2008-3-8 11:41 编辑 ]

作者: cityyard 时间: 2008-3-9 10:47
量化评估，最重要的一点是经验。同时科能需要大量统计工作作为铺垫。
下面我主要从bug统计来说一下我的经验。

1。测试项目数和摘出bug数预测
一般来说我们可以根据软件代码行数来粗略估计一个产品可能包含的bug数目和需要的测试项目。
现在有些公司流行每千行bug数的标准来制定测试计划，这个标准是通过以往测试经验总结出来的，
一般来说，同类的产品，尤其是同一个开发流程的产品，这些数值不应该相差太多，
如果相差一个数量级以上，我们几乎可以说，要么是QA出问题了，要么是开发出问题了。

2。测试bug分级
使用bugzilla或者Jira之类的缺陷管理系统何以很容易的实现bug分级，一般至少有
Fatal, Major, Minor, cosmatic这几种，还有一种特殊的叫做blocker，意思是这个bug
会影响测试进度。产品发布前，可以根据实际情况，定一个界限级别，比如要求
新出Major为0，并且所有已有的Major全部close。

3。测试bug收敛
量化评估必不可少的是bug收敛，这个要通过统计每日新出bug并跟踪已有bug
制作收敛曲线来实现。收敛曲线的形状发散表明目前产品极其不稳定，收敛曲线
开始收敛表示目前产品趋于稳定，完全收敛之后可以认为是发布的时机。

4。测试bug分布
   bug分布是决定下面测试重点的一个重要的参考数据。首先还是需要统计，
   找出所有已有的不同级别的bug在各个模块的分布，假如ABC三个模块，
   A模块占了bug的60%，C模块占了bug的8%那么，我们可以得出这样的结论，
   软件的不稳定瓶颈在于A模块，是一个薄弱点，需要开发人员集中力量对应。
   但是C模块也是一个可疑模块，因为出现bug率太低，如果不是开发的太好
   就是测试方法不当。

5。测试bug的周期
   一个bug的生命历程是一个完整的轮回，从他出生(open)开始，到调查(Accept)
到修复(Fix)，再到确认(Verify)是最简单的路线，这个周期越短，说明项目进展越顺利
反之则意味着项目进度目前有很大的阻碍。

6。降级bug数
降级bug的多少对于软件质量评估也是一个重要参考标准，降级bug也就是由于修正一个bug
又作了一个新bug，降级bug数目过多意味着现在的产品在越修越坏。

一个新的QA团队，在2，3，4，5，6步骤可能会有所迷惑，不知道阈值应该怎样选
但如果每次都坚持这样做，很多次之后2，3，4，5，6会给这个团队大量的经验积累，
完全可以做到看着统计图估计出一个产品处于什么状态，需要加强哪些方面等等。

作者: csd20 时间: 2008-3-9 22:07
我是一个新手,我觉得软件的质量可以从bug的分布,以及bug的收敛两方面考虑.
我们公司对软件质量的看法是从客户的反馈来评定的

作者: 水上飘 时间: 2008-3-10 11:25
在没发布之前先由测试人员和项目经理来评估，还有就是需求制定者
发布之前先让用户测试一下，让用户评估一下
发布之后主要就是让用户来评估了，用过之后才能发现软件的优势和缺点所在，做综合评价

作者: zilter 时间: 2008-3-10 12:52
标题: 回复 1# 的帖子
每轮结束进行一个评审，评审案例覆盖度和执行覆盖度。
按模块统计BUG数，找出BUG多的模块，说明这个模块是软件的薄弱的地方或是研发人员比较差。
执行度会统计每轮漏测的地方，与绩效挂钩。
案例分析后进行补充优化，直到测试的BUG有明显收敛。

作者: 今天有雾 时间: 2008-3-10 16:24
个人觉得首先得先确认测对象的规模，大小，复杂度吧，工期，等相关信息

然后再详细的定义出对bug的标准，严重，优先级，详细划分功能点，规划测试的整个工期
收集编写测试用例，然后根据以前相似的项目经验，预先得出一个测试用例数，和bug率，做参考
当然我个人觉得需要的是经验，和之前很好的数据收集
然后得出实际的bug率，或是遗漏的测试设计，并且客户的反馈也在收集之内，当然针对模块的复杂度，也应该有不同的标准，或是根据过往的数据，得出一个千行代码的bug数，也可以是参考之内的东西

作者: lzz 时间: 2008-3-10 17:47
同意 3# cityyard 按bug的统计进行评估量化，实际工作中，我们也是这样执行的。
另外，我们还从test case的执行情况进行统计，如每一轮测试，会统计其test case的执行率、成功率、失败率等作为参考
软件版本release后，要看客户的反馈情况，为release的版本打patch的数量
从整个项目或产品角度看，还要考核被测试的软件能否及时release.

作者: imdoudou 时间: 2008-3-11 15:40
我认为应该从以下几个方面的量化管理:
一:提交BUG的数量和执行测试用例的数量.
二:测试用例的覆盖率.
三:BUG的严重程度
四:测试的相关文档的编写质量.

不补的地方,请指教噢.

作者: lqr 时间: 2008-3-12 08:41
标题: 回复 10# 的帖子
我想说的，楼上已基本提到了
但我要说的是，软件的应用环境和行业
要分析客户注重、关注的是软件哪方面的质量（质量当然包括功能、性能、。。。。）

作者: lily_liuyun 时间: 2008-3-12 09:32
标题: "预估软件测试结束的时间"
"预估软件测试结束的时间" ，经常感觉要预估这个时间非常困难，因为经常要依赖于非测试团队的因素。
目前我们项目遇到最多的情况是：
1. 开发团队解决bug的速度。特别是中后期，测试团队经常是在等待状态
2. 开发团队解决bug的质量。经常出现把哑巴治成瘸子，导致多处小范围的重复再重复的测试，象一个无底洞。
从测试的角度来说，完全不知道要怎样预估这个时间。

作者: janedeng 时间: 2008-3-12 12:16
标题: 如何量化评估被测试软件的质量
从我所在的公司的情况看，评估一个被测软件的质量主要是从三个方面来进行。
1：系统的性能。这其中包括了系统的稳定性，运行时的速度，安全性等。即，性能稳定，运行时，不报错，不因数据量过大而造成速度慢，死机之类的原因。
2：后期提交的bug数量及等级。即，在软件开发、测试的后期，提交的bug数量越少，严重程度越低，这个软件的质量就越好。当然，在bug数量和质量上是不可以造假的。呵呵
3：user acceptance testing中返回的bug数量和其他的意见。即，用户在UAT测试过程中发现的bug数量越少，对系统的其他建议越少，这个软件质量就越好。

作者: villawzs 时间: 2008-3-12 12:45
首先套用一个定义来说明一个软件的质量：
GB/T 16260.1 提供了一个软件质量评价的通用模型，定义了6种软件质量特性：
1、功能性：（子特性）适合性、准确性、互操作性、保密安全性、功能依从性
2、可靠性：成熟性、容错性、易恢复性、可靠依从性
3、易用性：易理解性、易学性、易操作性、吸引性、易用依从性
4、效率：时间特性、资源利用、效率依从性
5、可维护性：易分析性、易改变性、稳定性、易测试性、维护依从性
6、可移植性：适应性、易安装性、共存性、易替换性、可移植依从性

所以对一个软件的质量评定，可以以以上各个方面去进行衡量。当然，各个方面都能够符合，这不大实际，但是主要看这软件的侧重点，以及客户的需求。从而检测在这一方面的质量是否过关，是否令人满意。而这满意度主要还是需要从最终用户的角度出发进行评测。

以上是小弟的一些愚见，也是从黑盒测试方面进行评论。大家讨论讨论而已。

作者: zyhuestc 时间: 2008-3-12 14:40
这个问题非常好,感谢.下面谈谈我对这的理解:
我认为主要从两方面来衡量：
1、需求方面：
1）、肯定得保证测试用例100%覆盖用户需求。
2）、用例通过率：全部用例通过率95%以上。基本用例通过率100%。
3）、通过BUG曲线，分析BUG已经降低到了正常状态。
4）、没有致命问题。按我们的定义，P0--P2级别的BUG必须全部修理。
2、代码方面：有代码覆盖率工具来检查测试用例代码覆盖率。按我的理解，这个如果能做到覆盖70%，应该很不错了。

说明一下：上面我说的用例，包含前面大家讨论的功能、性能等方面。

作者: xuwh 时间: 2008-3-12 15:15
标题: 软件质量如何评估？
我们公司软件质量的评估，首先要看测试出来的问题等级和数量，另外重要的是客户的使用情况，不过我想公司现状和软件的现状无法制定出一个更好的评估标准。下面谈一下我个人的想法：
首先，需求的覆盖率是软件质量的根基，这就要求我们对需求的管理非常规范
其次，在软件各个阶段出现的bug情况（单元、集成、系统），是软件质量的表现
最后，客户验收测试的满意程度，这个不应该用BUG的数量来衡量，应该以客户的实际反应状况为标准，因为客户提出的不一定是软件的质量有问题，而是从客户的使用情况来说明软件是不是适合客户使用

[ 本帖最后由 xuwh 于 2008-3-12 15:17 编辑 ]

作者: blackboyzb 时间: 2008-3-12 17:58
量化是个很复杂的工程，实现是很困难的。
量化包含的方面很多
比如
各项度量指标的量化（用例覆盖率要达到多少，残留缺陷密度的指标，并发访问量的指标，点击率的指标、还有有很多）
工作量的量化（需要统计人员的工作效率，在做计划时预计总的工作任务，分解工作任务，这些都需要有很多的度量数据的积累作为参考）
工作时间的量化（根据工作量来计划工作时间）
工作任务的量化（根据每个人的情况来分配工作任务）
总之呢，牵扯的方面很多
目前在初步学习之中，现在只了解了皮毛

作者: xuxiangpan888 时间: 2008-3-12 18:35

作者: 凤凰山 时间: 2008-3-12 18:50
不同的软件应该有不同的评定标准，行业不同要求也不一样，看针对哪个领域。
不过不管哪个领域的软件，我认为首先要考虑软件的安全性，数据安全很重要，客户用你的软件数据丢失或者什么的，你想会有什么后果，还有就是好不容易开发个软件一下就被破解了.......

其次看软件的稳定性与响应速率，如果一个软件运行就死或者打开要等几分钟才出来，相信没有人用
再次就看正确性了或者叫准确性，对小数点的精确程度，如果一个财务软件经常算错，或者航天的软件。。。。。。
再看界面与操作的友好程度，因为这些是直接与用户接触的，长期对着一个界面极不美观，操作极不方便的软件可想会有好心情么？
。。。。。。
只是业余的人发表的看法哈，呵呵，理论的东西书上多的是，就不知道了。。。。。。。

作者: lyufan 时间: 2008-3-12 18:55
软件不外乎是为了实现某个功能而实现的一段代码，所以我认为衡量软件的质量，最关键的是测试case覆盖率。case的覆盖当然需要是多个方面的，最基本的是：性能、功能、安全、易用性，由于软件需要不断升级和维护，同时很重要的还包含：可移植性、可维护性。以上每个方面的case都有覆盖到，且case都能通过的话，就说明这个软件具有很高质量了。
当然case的覆盖，需从两方面出发，一方面是：客户的需求；另一方面是：系统开发的结构。这样的case才能尽可能的保证覆盖的完整。所以现在很多测试管理软件，类似：TD,TM等...都有把case跟需求关联起来，统计覆盖率，不过我认为这还是不够的，这个只是能统计到case覆盖需求的覆盖率，但是实际还有一部分case，跟需求没有直接关系，是系统结构设计引起的，这部分如果也能纳入关联管理，就很好了！

另外谈一下对bug的是否能够衡量软件质量的看法把，我个人觉得这个可以做个参考，但是不能作为重要依据。因为bug的来源跟开发人员、测试人员、架构设计人员、需求调研人员有很大的，而且直接的关系，作为评价质量的量化依据不太客观。

以上是我的看法，供参考...

作者: 阿七 时间: 2008-3-13 08:57

原帖由 cityyard 于 2008-3-9 10:47 发表
量化评估，最重要的一点是经验。同时科能需要大量统计工作作为铺垫。
下面我主要从bug统计来说一下我的经验。

1。测试项目数和摘出bug数预测
一般来说我们可以根据软件代码行数来粗略估计一个产品可能包含的 ...

我觉得这个说的很好

作者: 水印无痕 时间: 2008-3-13 11:06
呵呵
量化评估么
给实际最终用户试用让他打分(alpha测试...)

我不否认数据积累的重要性
但是我认为数据积累的目的并不是为了能够自己对自己开发的系统进行评估
而是为了更有效地进行量化管理

作者: qrz2000 时间: 2008-3-13 11:27
我们公司现在也在做这一块的内容。
其中我想的是首先我们要区分，量化的目的是什么？
是同级产品之间做比较，还是单纯分析一个产品的质量好外？
如果是同级产品之间做比较，那必须需要度量软件的规模。
度量软件规模了之后，才可以再量化相应的评估数据出来。

作者: wuyunga 时间: 2008-3-13 13:14
评估软件质量的标准不是绝对的，是相对的。一个软件的质量特性包括：功能，性能，安全性，易用性，可靠性，可维护性，可移植性等，还有一些行业特性。而让这些特性达到什么样的指标，则是根据用户的需求来规定的。软件测试就是要验证软件的这些特性与需求的符合程度，符合程度越高表明质量就越好。

所以个人认为量化的依据应该包括：
1.测试用例的密度--用例密度直接影响bug的数量和严重级别
2.测试用例覆盖率--因为覆盖率很小发现的bug很少时能说明质量很好吗？
3.bug数量--用户使用过程中出现很多bug，用户一定是不会再认可这个软件了
4.bug的严重级别--严重的bug会使用户无法使用软件更别说能接受这个产品了

[ 本帖最后由 wuyunga 于 2008-3-13 13:21 编辑 ]

作者: 兰兰 时间: 2008-3-13 14:35
所谓系统应该包括数据、软件和文档，作为评估是不是应该从流程实现和控制上来进行判断，不单只看软件的bug。还应考虑数据和文档的正确性，以及过程执行中的评审的正确性！

作者: hehekouke 时间: 2008-3-13 14:59
大家说的都好棒哦！
吸收ing……

作者: 87950461 时间: 2008-3-13 15:33

软件质量的量化评估就是所有数据的整合,经过对数据的加工得到的数据便是软件的质量级数。
具体数据包含以下几个：1.功能实现率，2.性能达标率，3.测试覆盖率（功能，性能，压力等等），4.BUG质量，5.BUG的CLOSE质量，6.客户试用满意度，7.员工工作效率，等几个方面的数据。各项数据按其在项目中的重要级别对数据进行+-*/运算，最后得到的数据便是软件的质量级数。
楼上几位前辈写的很好，吸收ING

[ 本帖最后由 87950461 于 2008-3-14 09:20 编辑 ]

作者: tdj602 时间: 2008-3-13 18:59
标题: 活到老学到老
学习，学习

评估软件质量：
1.最大限度满足了用户的需求
2.符合软件质量模型项
3.能应变不断的需求变更

[ 本帖最后由 tdj602 于 2008-3-13 19:02 编辑 ]

作者: guansnow 时间: 2008-3-13 21:29
标题: 经验不足！：（
量化主要有两个目的：1.确定问题以便解决问题。
2.与可替换的产品进行比较，或对照需求比较产品质量。
如果，标度分两类是满意/不满意；
标度分为四类是：超出要求，目标范围，可接受的最低限度，不可接受。

作者: lichao_lc4 时间: 2008-3-14 08:46
各种软件的衡量指标不同，偏重点不同，我认为软件只要达到各自的标准就可以了。

作者: huior 时间: 2008-3-14 09:19
好像本周回答问题的朋友比较少哦！不过这个问题的确不太好回答，问题比较发散！
我的回答
http://www.51testing.com/?10851/ ... e_itemid_76932.html

作者: charles 时间: 2008-3-14 10:55
1、软件需求规格说明书的功能点尽可能的量化；
2、测试用例设计要通过评审，要求需求覆盖率达100％；
3、查看缺陷分别按时间的趋势图、按模块的饼状分布图，按时间的趋势图是否是下降的趋势，按模块的分布图可以发现缺陷集中的相关模块；
4、完成系统的性能、安全、易用性等其他隐式需求的测试；
5、测试用例的执行覆盖率要达到100％；
6、程序代码语句覆盖率不低于80％；
7、缺陷修复率情况：
   1)  致命、严重的缺陷修复率要达到100％以上；
   2) 一般不太严重的缺陷修复率要达到80％以上；
   3) 易用性不影响系统应用的缺陷修复率达到60％以上；
8、系统通过需求人员的确认测试，系统满足需求规格说明书的说明。

作者: sense 时间: 2008-3-14 12:48
标题: 如何量化评估被测试软件的质量？
评估被测软件质量可分为从内部、外部看两方面，内部评价软件质量时多用功能、可靠性、可用性、可维护性、可移植性、性能等多个衡量指标，但不同的软件衡量质量的指标权重是不一样。WEB应该更看重功能、安全、性能，应用程序偏重于功能、可用性、可维护性等方面。
功能性看程序对用户需求的覆盖率，但超出用户需求的部分不一定是好的，从BUG定义的角度来看，也是一种缺陷。
可靠性看程序能无故障运行时间、容错、可恢复、安全性等，与需求初始定义去比较。
可用性看程序的设计是否符合用户场景中的使用习惯，是否方便用户的操作，是否是用户操作的最快捷步骤。
可维护性是指工程实施时是否方便，维护基础数据方便，能快速解决用户维护方面的问题。
可移植性是指能否支持多个平台的使用，各平台、版本之间是否有快速切换的解决方案。
性能是否满足客户需求，能否满足不断增长的数据量和用户量，而程序的性能不下降。
从外部看，一般从用户验收测试、使用过程中的BUG反馈来评价质量。
用户验收是从用户的角度去看程序是否实现既定的需求，是否满足他们工作场景中的使用习惯，操作是否方便等多方面，可以设计问卷，调查结果的分值可以体现用户对软件质量的评价。
使用过程中的BUG反馈，是指用户购买软件后，在使用的过程中发现的BUG量，可以与公司内部发现的BUG进行对比，这个比值可以来衡量软件的质量，同时也可以衡量软件测试的质量。具体的衡量值可以根据不同的软件项目、产品经验来设定。

作者: naotang 时间: 2008-3-14 17:34
标题: 如何量化评估被测试软件的质量？
首先是需求需要量化：
a、有功能的规格列表以及每个功能的重要级别,市场定位等。
b、给出性能指标。
根据以上信息,定义产品的完成标准及质量,首先在客户层定义好质量标准.

下面就是根据测试情况定义,更多的是测试人员自己的理解与定义：
1、产品所运用技术的可扩展性、可移植性、安全性，当然这个跟产品的定位有关。
2、重要功能是否全部实现，就算存在问题，是否有规避措施。次要功能在要求上可以低些。
3、性能是否达到预期结果，就算没达到，是否能满足当前的市场。
当然上面的结果取决于你测试列表的覆盖度及深度。

[ 本帖最后由 naotang 于 2008-3-14 17:43 编辑 ]

作者: DU_anjel 时间: 2008-3-15 21:44
不知道软件测试是否已建立了质量标准体系??类似国际标准ISO

感谢前辈们,新手的我学习了...

作者: huior 时间: 2008-3-18 09:18
本周的题目不是“量化评估”“软件质量”吗？
怎么看获奖答案都象是在回答“测试的结束标准”，呵呵

作者: 54111 时间: 2008-3-19 14:41
同意楼上说的，确实像测试结束标准

作者: wudamyw 时间: 2008-3-19 15:32
从产品本身，以技术来说那就复杂了。其实很简单，能满足客户需要就是好质量的软件，无论是否存在多少bug。比如播放软件的play功能，如果说连续快速点击playbutton，程序会挂掉。这问题从技术来说很严重，同时他属于极限压力测试，一般用户是不会发现的。

作者: lucky_snow 时间: 2008-3-31 13:56
标题: 回复 1# 的帖子
获奖名单有错误：charles 32#
charles 是 31#
sense 是 32#

作者: 51testing 时间: 2008-3-31 16:09

原帖由 lucky_snow 于 2008-3-31 13:56 发表
获奖名单有错误：charles 32#
charles 是 31#
sense 是 32#

谢谢纠错，已更改了．

作者: 冷ヅ漠然 时间: 2008-4-2 12:40

测试结束标准定位的高低就是对软件质量的量化评估哇？

作者: lovemiya 时间: 2008-4-25 16:45

上这些度量项，对于测试管理者来说应该都不陌生，全部整理到一起，真的还是蛮齐全的了。测试品质保证的乐趣，其实很多就在这些关键度量元素间。其一，这样的分析显然是颇具科学意义的，统计学嘛；其二，真正能通过管理这些度量项达到提高质量的效果，那是一件很美妙的事情。我个人而言，比较有实用感触的是1，2，3，5，15这几项。

1---客户反馈缺陷，即漏测。其实这是一个很直观的质量保证结果，本人非常崇尚用这个指标衡量测试人员的结果绩效。虽然漏测的原因不单单在于测试的疏忽，但终究能在很大程度上体现测试的质量。且通过对这个指标的线性观察，发现一些潜在的可能在未来会反馈回来的问题，我们还能亡羊补牢，出补丁提前堵漏。

2---模块缺陷密度。往往找到缺陷最多的地方也是潜在缺陷最多的地方。这个规律几乎是千真万确。就跟越是担心会出问题的时候一般都是会出问题的，类似。这个在测试过程中或者发布之后拿来分析都很有意义。

3---遗留缺陷。仅仅看一个绝对的数字并无太大意义，它的意义在于与之前拟定的交付标准做比对，假若在标准之内就放行，不在标准之内那就卡住。另外，被允许的遗留缺陷一般也是下一阶段启动任务之时开发任务的首要任务之一。

5---趋势分析。这是一个质量活动如期完成的强力证明工具，当然要真正看到收敛才对。

15--测试用例有效率。这个指标更大意义的是规范测试活动，其次才是提高测试用例的质量。想要统计出有效率，有个前提就是测试集驱动测试，即你开展每一轮测试之前，根据测试需求建立好测试集，并且集里面的测试用例也都已经确定好，之后照着逐一测试。很多测试人员说测试用例只不过是我用来熟悉需求的产物，等我拿到被测对象，我根本就不看测试用例就刷刷的往下测。殊不知，人的记忆往往是有漏洞的，当你脱离测试用例来测试，你就是在走向随机测试，大家想想随机的活动有没有可把握性？

简单评论之后，我再加一个度量项，尤其是在这提倡测试先行的年代。---需求review阶段发现的需求issue数/整个测试过程中发现的需求Issue的总数，这个指标体现测试人员在需求熟悉阶段对需求透析程度，透析度越深往往对促进需求精致化的贡献度越大，对测试用例的有效性的贡献也越大。我们毕竟不希望到了测试执行阶段才来不停的质疑需求这里有问题那里有问题。

作者: godn_1981 时间: 2008-4-28 22:08
标题: 受益匪浅
大家说的非常好~~~~~~~真的学到不少东西

作者: houzeal 时间: 2009-7-10 10:44
受益匪浅

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