黑盒测试中如何保证需求的覆盖度

发表于:2010-11-23 12:11

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:未知    来源:51Testing软件测试网采编

  个人见解,大家一起讨论学习!!

  黑盒测试覆盖度保证的一些观点看了楼上这么多人的答复我受益匪浅,我也说说自己的意见。

  我们一般拿到需求说明书并且测试目的严格已需求说明书为根据,即使需求变动了,那也是先变需求说明书我们这边才跟着变动测试用例等,当然这是理想状态,但我们不就是向着理想前进吗?我想回答这个问题的前提应该是需求已经确定了,所以我觉得关于需求的确定问题就不应该是在这里讨论。单单只是讨论黑盒测试(或者说黑盒测试用例)如何保证需求的覆盖度。

  1、对需求的分析:保证覆盖度首先要保证对需求点提取的覆盖率。测试一切以需求为根本和中心指导,如果在开始覆盖度就不高,那么你后面做的再好也就那样了。

  2、设计测试用例:对于分析提取的需求点编写对应的测试用例,而用例的编写必须要依据科学的方法才能有权威、公正性,尽量减少个人因素的影响,那么可以使用等价类、边界值、因果法、错误推测法等,但同时使用这些方法编写测试用例是又很大的依赖与测试人员自身的素质(性格、专业知识等),所以我们在尽最大的可能平稳(公正)做好自己本分的工作那么就可以很大一部分覆盖率了。

  3、测试用例评审:但每个人都是不同的,思考方式、方向等都是不同的,你想到而我没想到的情况是非常多了(随着经验的增多会逐步减少),这样就遗漏了方面,覆盖率也就不够了,所以评审是必然的,它可以确定并补全测试用例。此后黑盒测试覆盖率的前期发展至高了。

  4、执行测试:测试用例编写确定好了后就是测试执行了,

  1)、测试用例执行100%覆盖。

  2)、但测试用例覆盖率还是未达到100%,其中等价类、边界值、因果法这些有逻辑依据的方法是很好覆盖且一般不容易出错,但是错误推测法这类方法主观性很强且不好推测,所以也要根据实际情况来做一些调整、增加的测试行为,同时也要更新测试用例来提高用例下一次的测试覆盖率。

  以上!

  个人拙见!

  个人看法:在测试方法方面,可做如下注意:

  其一,分析出口入口。从入口分析,将可能出现的环境,条件,操作等内容分类组合,然后根据各位测试达人的方法进行整合,逐一验证。从出口分析,将可能出现的结果进行统计,根据结果的不同追根溯源,再找到不同的操作以及条件等内容,统计成文档,逐一验证。

  其二,多种测试手法的学习和使用。大家可能更多的关心测试方法,但是具体操作的手法也是需要注意的。毕竟测试方法比较容易找到,各位达人都很熟悉。如果将每个人不同的测试手法总结出来并在自己的测试实施中加以使用,可能会收到意想不到的成果。

  在测试流程方面,可作如下注意:

  其一,初期要做好需求分析。将需求逐渐细化到小功能点,针对每个功能点进行测试设计。对于完成的测试设计文档,经过项目相关人员的检查评审,做成所需要的初稿。

  其二,在测试过程中,根据需求变更和具体测试执行过程中遇到的问题完善测试设计文档。

  其三,测试执行结束后,对于出现的问题进行总结。其中包含自己本身发现的问题,也可能会有客户提出的问题。将总结出来的结果融合到测试设计当中去,进一步完善测试设计文档。

  对于一次测试,是不可能有覆盖度全面的测试的。需要多次去总结积累,才会使测试越来越全面。

  在测试流思维方面,可作如下注意:

  其一,测试全面不等于全面测试。不同阶段对于软件测试有不同的要求,比如在0.8版本以前,对于不重要的画面问题或是细小的功能问题就不需要关心。但是在验收阶段,这些内容可能更需要注意。

  其二,学无止境,只有不断的去学习不断的去思考,才能使自己测试的能力更强,测试对象的全面性也更完整。

22/2<12
《2023软件测试行业现状调查报告》独家发布~

精彩评论

  • msw_cn
    2010-11-23 16:00:17

    正常的V模式开发,在看到需求之前,需要经过合格的单元测试(根据详细说明书),集成测试(根据概要说明书),才能达到系统测试而看到需求说明书。在这个时候,时间和流程的跨度已经相当大了。我们经常听到从需求到测试用例,好像我们从需求开始一直持续忠于需求直到开发测试用例。实际上,在v模式里,能横向建立需求和系统测试的对应关系已经难能可贵了。举个例子,同一份需求说明书,让unix程序员和windows程序员完成,你肯定得到两个完全不一样的结果。

    从理想状态出发,根据需求说明书,尽量分析里面的所有测试点,编写成测试用例,你可以100%覆盖需求。实际情况是,你不能这么做。肯定有什么阻碍了我们100%覆盖需求。

    首先,等价类划分,边界值等方法并不是覆盖需求的,它们是覆盖输入输出的。我们用这些方法设计单元测试,集成测试。如果没有合格的单元测试,集成测试;单独谈覆盖功能,有些虚幻。保证功能覆盖,你必须保证代码的运行和整合状况良好,这也是系统测试(主要根据需求说明书)的前提。

    其次,需求到底是什么?提倡产品忠于客户需求的不光是软件开发,还有汽车,时装等等。需求很可能仅仅是个口号,而不是一份专业的文档。如果你口才够好,你可以让客户把你自己的想法当成是他的需求。有些软件的客户,根本提不出什么需求;或者你完全按照他的需求完成产品,结果并不能让客户满意。一份能指导开发和测试的需求说明书,本身就是个梦想。我们经常说代码覆盖率,分支覆盖率(奢侈品),输入输出覆盖率,环境配置覆盖率(奢侈品),这些相对是真实的。如果你打算覆盖需求,你应该清楚你的目标是很高端的奢侈品。首先你要确认你有一份真正的需求说明书。这份需求说明书是谁制定的?开发部有多少人看过,或者了解这份需求说明书?它是由什么人维护的?都有什么人,在什么情况下可以对需求进行更改?

    我不是否定需求覆盖,而是想解释测试的处境。你可以设计一个针对需求的测试阶段,在此阶段,我们把测试范围缩小到只检验需求相关内容,这样可以提高需求的覆盖。正常情况,我们只做系统测试。在系统测试阶段除了覆盖需求,我们还需要覆盖环境,覆盖代码,覆盖功能。我个人理解,需求覆盖度是个概念而不是一个具体的值。在测试人员的角度,增强客户的意识,可以保证需求覆盖。测试环境尽量贴近实际环境可以需求覆盖。在设计用例时增加场景用例,引入B测试可以增加需求覆盖。

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号