google搜索 51Testing站内搜索                    软件测试门户 | 软件测试培 训 | 文章资料精选 | 软件测试论坛 | 软件测试博客 | 测试招聘求职 
打印

黑盒测试如何保证需求的覆盖度?(08-02-22)(获奖名单已公布)

本主题由 fishy 于 2008-3-28 14:25 移动
我的详细解答,请参考
http://www.51testing.com/?10851

TOP

个人觉得这个题目有歧义,需求覆盖度自然是按照根据需求文档写出的测试文档来控制的,测试文档越贴近需求文档,自然需求的覆盖度就高。
如果换成黑盒测试如何保证代码覆盖率,这题才有深究的意义,否则只是一道标准的“明知故问”型问题。

TOP

黑盒测试


黑盒测试要全面的覆盖需求
1.首先熟悉业务,对业务逻辑的熟悉有助于对需求功能点的把握
2.结合程序仔细分析需求,提取测试的功能点和重点
3.根据需求编写测试用例,测试用例尽量覆盖所有功能点
4.在测试的过程中完善测试的覆盖度
5.开始测试要兼顾需求、用例和开发环节中易发生错误的地方

TOP

黑盒测试方法


在对软件的质量监督中,黑盒测试起着重要的作用;而随着软件开发平台及软件设计思想的进步和发展,特别是rad技术的发展,对黑盒测试提出了更明确的要求,人们发现,必须遵循一定的测试理论,依赖于优秀的测试工具,才能进行科学、完备的测试。

TOP

不知道大家在平时工作中是否整理过测试需求!

如前面某位仁兄所说,分功能与性能.通过功能来计算覆盖率还好一点,那么通过性能呢?希望高手指教!!!

TOP

黑盒测试覆盖度保证的一些观点


看了楼上这么多人的答复我受益匪浅,我也说说自己的意见。
我们一般拿到需求说明书并且测试目的严格已需求说明书为根据,即使需求变动了,那也是先变需求说明书我们这边才跟着变动测试用例等,当然这是理想状态,但我们不就是向着理想前进吗?我想回答这个问题的前提应该是需求已经确定了,所以我觉得关于需求的确定问题就不应该是在这里讨论。单单只是讨论黑盒测试(或者说黑盒测试用例)如何保证需求的覆盖度。
1、对需求的分析:保证覆盖度首先要保证对需求点提取的覆盖率。测试一切以需求为根本和中心指导,如果在开始覆盖度就不高,那么你后面做的再好也就那样了。
2、设计测试用例:对于分析提取的需求点编写对应的测试用例,而用例的编写必须要依据科学的方法才能有权威、公正性,尽量减少个人因素的影响,那么可以使用等价类、边界值、因果法、错误推测法等,但同时使用这些方法编写测试用例是又很大的依赖与测试人员自身的素质(性格、专业知识等),所以我们在尽最大的可能平稳(公正)做好自己本分的工作那么就可以很大一部分覆盖率了。
3、测试用例评审:但每个人都是不同的,思考方式、方向等都是不同的,你想到而我没想到的情况是非常多了(随着经验的增多会逐步减少),这样就遗漏了方面,覆盖率也就不够了,所以评审是必然的,它可以确定并补全测试用例。此后黑盒测试覆盖率的前期发展至高了。
4、执行测试:测试用例编写确定好了后就是测试执行了,1、测试用例执行100%覆盖。2、但测试用例覆盖率还是未达到100%,其中等价类、边界值、因果法这些有逻辑依据的方法是很好覆盖且一般不容易出错,但是错误推测法这类方法主观性很强且不好推测,所以也要根据实际情况来做一些调整、增加的测试行为,同时也要更新测试用例来提高用例下一次的测试覆盖率。
以上!
个人拙见!

TOP

实践经验:将每个用例和需求都编号,然后做一张对应的映射表。
唯能极于情
故能极于剑

TOP

测试最难的是什么:是对需求的覆盖
通常情况下对于需求的完全覆盖测试是不可能实现的
所以这个问题需要从多个角度来分析
最重要是如何用最少的用例覆盖最多的需求
说白了就是用例设计的方法和原则
这个前面已经有不少朋友提到了:比如说设计用例时参照软件质量6大原则逐个验证;等价类边界值等等一些用例设计方法;……
但是还有其他一些因素会间接影响到这个问题
比如说测试规程的制定:如果测试规程不合理,可能会大幅导致效率的下降,从而没有足够的时间来执行已经设计完成的用例
另外像测试计划中对于风险估计的不足,对于资源分配的不合理等等,所有的一切都可能影响到最终的测试行为对需求的覆盖程度

TOP

正确使用软件与非法使用软件,这两种情况都试一下,把能想到的使用软件的方法都试一下

TOP

刚进入测试方向,看了这么多,真是受益匪浅阿,我应该多来这看看,

TOP

黑盒测试虽然无法保证需求的覆盖度的全面性,但  可以通过编写测试用例,可在不断增加和扩大需求的覆盖度,个人认为:在设计测试用例时,1、应尽力编写得详细点,2、在测试过程中,可以不断地去完善测试用例。


以上纯属个人见解。。。。。
The best tester is not the one who finds the most bugs or who embarrasses the most developers. The best tester is the one who gets the most bugs fixed

最好的测试人员不是那些发现最多bug的人,或使最多开发人员尴尬的人。最好的测试人员应该是能够使最多的bug得以修复的人

TOP





这个问题我经常拿来考面试的(高级)测试工程师。
对于问题的回答每个人都有自己的见解:
1。理解URS/UIS/FRS等之类的需求说明书很重要,因为测试用例一般从需求输出,保证测试的覆盖度一般需要建立一个需求说明书和测试用例之间可追踪的矩阵表格,哪些需求点没有覆盖到,自动提醒或者标红表示,比如DOORS具有这个功能。
2。说到覆盖度,这里要谈到测试工程师的测试经验问题,测试工作执行力度问题,即使再多的测试用例也会如同虚设的测试。你们会问测试工程师跟需求的覆盖度有什么关系?理解测试流程工作的人员相信都会明白。
3。需求评审很重要,但不排除有些所谓的管理人员或专家平时都听人家的意见多的,自己心里压根就没有什么想法。一般建议评审在产品经理,项目经理,需求工程师,测试工程师,第三合作方等中进行,保证项目的里程碑的时间点前提下,尽可能安排几次需求评审。需求的完整和清晰度大大增加了测试的假想空间,特别是有些项目经常变更需求的。

回到这个问题暂时归结三个方面:需求和测试用例之间建立追踪的矩阵,有良好测试经验的测试工程师执行测试工作,保证需求的完整和清晰度。
软件个性化

TOP

引用:
原帖由 sky.pei 于 2008-2-24 12:47 发表
需求的测试,其实大部分都是业务的测试。常规的业务流程都是固定单一的。这个问题其实就转化成了业务流程的不规范情况的测试。
这种测试时不可能穷举的。
说的太对了,对业务有一定了解,所做的需求分析也能达到一定程度!

TOP

根据各种测试方法尽量多写测试用例,测试用例越详细,覆盖率越搞

TOP

需求的测试,其实大部分都是业务的测试。常规的业务流程都是固定单一的。这个问题其实就转化成了业务流程的不规范情况的测试。这种测试时不可能穷举的。

这个我也同意,但一些约定俗成的检查点还是必须验证到的,比如表单传递页面,对于刷新页面是否会产生的表单重复投递等等类似问题,也是我们用例必须覆盖到的。

TOP

我认为软件是给客户的,所以考虑功能覆盖的话,应该从客户的角度考虑覆盖范围,即客户所能及的范围。再从这用户范围用各种测试方法可以缩小测试范围。之后用常用的比如18楼的那种应该能保证覆盖度了。

TOP

首先要根据需求编写出详细的测试计划包括测试用例,这其实就是遍历需求的一个过程,在这个过程中首先要了解客户的业务流程,然后按每个模块实现的业务功能来设计用例,在测试的过程中,先把握整体流程,然后到各个模块,最后细化到字段页面的层面
朝着梦想的方向前进!前进!

TOP

看了好多回贴,忘了自己本来要说什么来着

TOP

引用:
原帖由 xiaomayi0323 于 2008-2-22 21:38 发表
我认为要达到一定的覆盖度,首先应该将需求吃透,细分需求,才能保证设计出来的测试用例最全面的覆盖需求.
同意你的说法。但同时也补充一点,测试用例一定要通过评审,这样需求才能更明确,针对性的覆盖率更高

TOP

这是一个开放性问题。没有什么标准答案。面试的时候很多人喜欢问这种问题。经验是最重要的因素。

TOP

 
当前时区 GMT+8, 现在时间是 2008-5-12 06:47Copyright(C)上海博为峰软件技术有限公司 2001-2007 电话:021-64471599-8017
当您在访问网站、论坛及博客过程中遇到问题时可发送email:webmaster@51testing.com或发送论坛短信至管理员风在吹