如何保证黑盒测试的覆盖率(转)

1、  首先测试需求分析要全面

测试需求分析分两步:

  1,测试需求的获取

  需求的来源:

  显式需求:

    (1)原始需求说明书

    (2)产品规格书

    (3)软件需求文档

    (4)有无继承性文档

    (5)经验库

    (6)通用的协议规范

  隐式需求:用户的主观感受,市场的主流观点,专业人士的评价分析

2,需求的分析
,产生测试需求文档

将不同的需求来源划分成一个个需求点,针对每一点进行测试分析:

    (1)界定测试范围

    (2)利用各种测试设计的方法产生测试点

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

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

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

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

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

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

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

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

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

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

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

2、  当测试需求分析完成,并且形成文档后,要进行测试需求评审,保证需求的准确性以及完整性。

3、  测试需求完成以后,可以根据测试需求设计测试用例。

要保证测试用例能够全面覆盖测试需求,要包含所有的情况。

测试用例设计上划分为单功能测试用例和测试场景设计,单功能测试覆盖的需求中的功能点,测试场景覆盖需求中的业务逻辑。

在设计测试用例的时候,可以使用多种测试用例设计方法。

  l  首先进行等价类划分,包括输入条件和输出条件的等价类划分,合理设置有效等价类和无效等价类,这是减少工作量和提高测试效率最有效的方法。

  l  必须使用边界值分析,经验表明,这种方法设计出的用例能发现很多程序错误。

  l  可以使用错误推测法追加一些测试用例,这需要依靠您的智慧和经验。

  l  对照程序逻辑检查已设计出的测试用例的逻辑覆盖度,如果没有达到覆盖标准应当再补充足够的测试用例。

  l  如果程序的功能说明中含有输入条件的组合情况,一开始就可选因果图和判定表驱动法。

  l  对于参数配置类的软件,要用正交试验法选择较少的组合方式达到最佳效果。

  l  对于业务流清晰的系统,可以利用场景法贯穿整个测试方案过程,在案例中综合使用各种测试方法。

当测试用例设计完成后,要组织测试用例的评审,这样可以吸取别人的意见,减少遗漏,补全测试用例。

4、  测试用例编写完成后,就是测试执行,

  l  测试用例执行100%覆盖。

  l  在测试执行过程中,要继续对测试用例补充完善,确保提高测试覆盖率。

5、  在整个测试过程中,需求都是不可能不变的,所以要及时的更新测试需求、测试用例。

6、  要将测试需求、测试用例以及发现的bug关联起来,便于管理和跟踪,同时也便于查看覆盖率。

时间: 2024-08-03 18:39:31

如何保证黑盒测试的覆盖率(转)的相关文章

如何保证测试的覆盖率

如何保证测试的覆盖率 一.首先测试需求分析要全面. 测试需求分析分两步: 1.测试需求的获取 需求的来源: 显式需求: (1)原始需求说明书 (2)产品规格书 (3)软件需求文档 (4)有无继承性文档 (5)经验库 (6)通用的协议规范 隐式需求:用户的主观感受,市场的主流观点,专业人士的评价分析 2,需求的分析 ,产生测试需求文档 将不同的需求来源划分成一个个需求点,针对每一点进行测试分析: (1)界定测试范围 (2)利用各种测试设计的方法产生测试点 在测试方法方面,可做如下注意: 其一,分析

利用EMMA监测测试覆盖率

http://www.ibm.com/developerworks/cn/opensource/os-cn-emma/index.html 引言 EMMA 是一个开源.面向 Java 程序测试覆盖率收集和报告工具.它通过对编译后的 Java 字节码文件进行插装,在测试执行过程中收集覆盖率信息,并通过支持多种报表格式对覆盖率结果进行展示. EMMA 所使用的字节码插装不仅保证 EMMA 不会给源代码带来“脏代码”,还确保 EMMA 摆脱了源代码的束缚,这一特点使 EMMA 应用于功能测试成为了可能

用户需求驱动式的开发方法

引言:开发者应该如何处理研发中的需求?在快速迭代的开发过程应该分为哪几个阶段?在一个快节奏的开发过程中,如何建立一个质量保障体系?七牛CEO许式伟在MDCC上的讲座<用户需求驱动式的开发方法>分享了他在开发过程中的一些心得. 许式伟:大家好,先自我介绍一下,我叫许式伟,刚才主持人大概也介绍了一下,最早在金山做WPS Office ,2007年在金山实验室主要做存储相关的技术研究,2008年底加入了百度做网页搜索,2009年.2011年在盛大做存储相关的,2007年到现在在七牛,这是整个的经历.

ThreadingTest(穿线测试)引领白盒测试进入工业界

ThreadingTest(穿线测试)引领白盒测试进入工业界 测试一直都有黑,白之分.由于白盒测试一般情况下需要有比较高的技术要求及比一般开发人员还要高的项目经验和缜密的逻辑思维能力,且测试时间较长,多用于单元测试,工具昂贵,所以一般国内的企业会忽略白盒测试,这也是为什么白盒测试诞生至今,在国内没有正式推广的原因.对于一个健康的测试团队来讲,必须要有一个或多个熟悉白盒测试的人员.让我们先分析下,一般情况下,要实施覆盖率测试,有几种完全不同的策略. 1 黑盒测试(功能测试) 黑盒测试是面向功能的测

精准测试白皮书-2019最新版

精准测试白皮书 精准测试诞生的背景 现代社会是建立在各种以计算机为基石的软件技术基础之上的.随着日新月异的需求变化,软件系统越来越复杂.很多人觉得软件开发才是重要环节,但实际上,无法对大型软件进行有效的质量把控,就无法真正构建与维护大型软件.--系统中任何一个错误都可能导致整个系统的崩溃,造成无法弥补的损失,系统的任何一个微小的修改都可能引入新的缺陷导致维护困难重重. 然而,如何从极端庞大复杂的系统中迅速及时地找到故障所在,却是行业的一大难点.目前国内软件测试基本处于两种状态:一是绝大多数企业采

初级软件测试总结

1.测试用例编写 1.1 设计测试用例的依据 根据需求文档,项目设计文档,接口文档,系统使用手册等来设计测试用例. 重点是要理清项目的流程,核心模块,实现的主要功能. 还应该在开发过程与测试过程之间建立起一对一的联系. 一般的软件测试生命周期: 需求分析-用例设计-脚本开发-测试执行-结果分析 但在实际测试过程中,会根据项目的周期来调整测试的时间. 1.2最常接触的基础测试类别 1.2.1模块测试 - 模块测试的目的是发现程序模块与其接口规格说明之间的不一. 1.2.2功能测试 功能测试的目的是

如何提高短平快项目的测试效率?

                         如何提高短平快项目的测试效率?                                                    研发资深顾问  杨学明   最近几年,笔者在全国各地包括深圳,北京,上海,杭州,武汉,济南等大中城市开设了近百场测试公开课程,也帮助许多创新型企业进行了产品测试或软件测试管理的内训,大的企业有中航工业.中科院.中国电力研究院.华立仪表.深圳迈瑞等等,也有一些中小型的企业,总体来说,目前中国国内的各公司的测试体系还不

appscan 对api的手工检测

AppScan 在 API 安全测试中的实例介绍 在本项目中,API 遵循标准的的 REST 架构和背端服务器进行通信.针对 API 的功能测试由两部分组成:一部分是用一个 Web 的测试页面直接实现的,另一部分,由于 Web 页面的局限性(比如不能任意修改 HTTP header),所以是通过 Shell 脚本调用 curl 实现的. 并且这个 API 的测试环境没有固定的域名和 IP 地址.针对 Web 应用的安全测试采用 AppScan Standard.项目实施过程中面临这样几个问题:

手工测试 测试框架?如何提高测试效率?

百度了一下“测试框架”,搜索结果大部分都是“自动化测试框架”.“单元测试框架”,没有手工测试框架.但是所谓框架不就是把“共性部分形成的体系”提高效率和质量吗? 做测试3年,现在想的更多的是如何提高测试效率和保证测试用例的覆盖率.目前所在的是公司是互联网公司(之前一直在传统软件公司工作),节奏很快,测试周期很短.产品需求文档的完善程度也是参差不齐,然后测试时间又比较紧急,除了个别庞大的项目外,领导不会专门预留编写测试用例的时间. 事件一,2015/12/8,领导安排我和另外一个同事测试一个新增节点