软件开发中的白盒测试

今天,我们来谈谈软件开发过程中的白盒测试。

一、白盒测试的概念

  白盒测试(White Box Testing),按照程序内部的结构、逻辑驱动测试程序,通过测试来检测产品内部动作是否按照设计说明书的规定正常进行,检验程序中的每条路径是否都能按预定要求正确工作。白盒测试的对象主要是源程序。是指用代码内部的分支、路径、条件,使程序设计的控制结构导出测试用例。白盒测试是一个与黑盒测试相对的概念,是指测试者针对可见代码进行的一种测试。白盒测试通常再划分为单元测试、集成测试两大类,但依据不同的流程,对白盒测试细分的标准也不尽一致,比如在IBM的IPD流程之下,白盒测试可能划分为如下几类:模块单元测试、模块集成测试、模块系统测试、渐增Build集成测试、系统集成测试等。而在XP实践中,单元测试与集成测试之间的界限并不明显,统称为渐增迭代测试。

二、白盒测试的特点

  白盒法特点:以程序的内部逻辑为基础设计测试用例,所以又称为逻辑覆盖法。应用白盒法时,手头必须有程序的规格说明以及程序清单。白盒法考虑的是测试用例对程序内部逻辑的覆盖程度。最彻底的白盒法是覆盖程序中的每一条路径,但是由于程序中一般含有循环,所以路径的数目极大,要执行每一条路径是不可能的,只能希望覆盖的程度尽可能高些。

三、白盒测试的目的
  1)保证一个模块中的所有独立路径至少被执行一次;
  2)对所有的逻辑值均需要测试真、假两个分支;
  3)在上下边界及可操作范围内运行所有循环;
  4)检查内部数据结构以确保其有效性。
  5)提高代码的质量达到软件产品中要求的可靠性、安全性

四、白盒测试的策略

  1)测试中,尽量先用自动化工具来进行静态结构分析;  

  2)auJ试中建议先从静态测试开始,如:静态结构分析、代码走查和静态质量度量后进行动态测试,如:覆盖率测试;

  3)利用静态分析的结果作为依据,再使用代码检查和动态测试的方式对静态分析结果进行进一步确认,提高测试效率及准确性;

  4)覆盖率测试是白盒测试中的重要手段,在测试报告中可以作为量化指标的依据,对于软件的重点模块,应使用多种覆盖率标准衡量代码的覆盖率;

  5)在不同的测试阶段,测试的侧重点是不同的。其中主要包含:

    (1)桌前检查(Desk Check)
    (2)单元测试(Unit Testing
    (3)代码评审(Code Review
    (4)同行评审(Peer Review
    (5)代码走查(Walkthrough
    (6)静态分析(Static Analysis

时间: 2024-10-14 06:04:30

软件开发中的白盒测试的相关文章

对软件开发中uml建模的理解和图形整理(一)

由于uml(统一建模语言)在开发中经常会用到,特别是在软件开发中的OOAD阶段,因此要理解和使用uml显得尤为重要.在uml开始之前,咱先回顾一个OOAD.OOP的主要特征. OOAD:根据面向对象的方法学来对软件系统进行分析和设计的过程.它包括OOA 分析阶段和OOD设计阶段.其中分析阶段主要解决"What to do?"的问题,而设计阶段主要解决"How to do?"的问题.具体来说就是:在OOA分析阶段咱要做的主要工作就是建立对业务问题域的视图(建立模型).

对于软件开发中开发人员与测试人员关系的理解

在软件开发中都会有开发人员(以下简称开发)和测试人员(以下简称测试),在一些小型公司可能并没有测试,仅仅是开发兼任测试.在这里我仅针对于有专业的测试和专业的开发的项目. 每个公司应该都有考核机制,对于开发和测试的考核实际上很难量化,通常来讲大的方向就是开发所负责模块的bug数,对于测试来讲就是测出来的bug数,但这真的有效吗?这也许对开发有约束力,理论上开发是能够自己控制bug数的,如果从产生的bug数来评判开发的绩效还算有效,这样开发自然就会把代码写得更加认真.但如果根据测试测出来的bug数来

软件开发中几个基本概念

软件开发中几个基本概念 Peixu.Zhu 自己真的深切理解那些经常挂在嘴边的概念么? 抽象 Abstract 抽象的特点是仅存在于思想和理论之中,而非物理或者具体的存在.(不是指C++中的抽象类) 抽象是永存的,不会随着时空而发生变化. 具体 Concrete 具体的特点是物化的或者是具备物理形态,是真实存在的. 具体不是永存的,是随着时空而发生变化的,仅存于具体的时空之中. 具体和抽象的最大区别是是否随着时空而发生变化,即是否存在于我们的四维空间. 实体 Entity 实体是单独的个体事物(

软件开发中,什么是模块化开发?

软件产品可以被看作是由一系列具有特定功能的组件组成,作为一个完整的系统也可以被分解成一系列功能模块,这些模块之间的相互作用就形成了系统的所有功能. 所谓模块是指可组成系统的.具有某种确定独立功能的半自律性的子系统,可以通过标准的界面和其他同样的子系统按照一定的规则相互联系而构成的更加复杂的系统.每个模块的研发和改进都独立于其他模块的研发和改进,每个模块所特有的信息处理过程都被包含在模块的内部,如同一个"黑箱",但是有一个或数个通用的标准界面与系统或其他模块相互连接. 在软件的模块化开发

软件开发中的自测及C代码示例

在软件开发中,程序自测是一个永远都绕不开的话题.很多开发人员以写出有难度的代码为荣,但却不重视对自己编写的代码进行测试,这导致了最终到达客户手中的产品质量不高,bug频发,损害了公司的形象.对于一个开发人员来说,我们应该将开发和自测置于同等重要的地位,我们花在自测上的时间要不比开发少.能否对自己编写的代码进行充分的自测也是检验一个开发人员水平高低的标准之一. 自测方法 根据所编写的程序的特点,自测方法大致有如下几种: 第一种,利用模拟工具进行自测.这种方法适用于需要其他模块(尚不具备)发过来的消

基于git的软件开发中并行工程管理以及版本控制系统概要

并行工程师什么,这里就不再解释(不懂请百度),实际上,在软件开发过程中,涉及到多人合作的以项目小组形式完成开发的软件(这里指广义上)或多或少都使用了并行工程的概念,在正式的项目开发中,项目小组成员总是分工合作每人完成一部分,然后再合并起来,而且,在实际应用中,尽管使用的是瀑布模型完成开发,但总是所有项目小组成员同时开始完成自己的部分,这,其实已经是并行工程了,我们可以自豪的宣布:我们在开发过程中使用了并行 工程这种高大上的玩意来提高开发速度,所以,老板你得给我们涨工资! 很简单吧,看起来好简单的

软件开发中的流程图

在软件开发中必须经历五个阶段,当然这仅是我个人的看法,我只是个初学者,步骤如下: 1.需求分析 2.算法设计极其分析 3.编写代码 4.测试代码 5.软件维护 对于初学者来说,第5步,可以暂时不用管,当然我们的需要任务就是学好第一步,需求分析,有时候一个软件的开发花费的大量时间并不在于编写代码上,而真正花费时间的是第一步,我们软件开发人员开发的软件并不是为了我们,而是为了客户,因此我们要想开发一个成功的软件,了解客户的需求是非常必须的,客户并不是真正的开发人员,他们的要求没有编程人员的想法严密,

软件开发中 常见英文文档 缩写(转)

软件开发中常见英文缩写和各类软件开发文档的英文缩写: 英文简写 文档名称 MRD market requirement document (市场需求文档) PRD product requirement document (产品需求文档) SOW 工作任务说明书 PHB Process Handbook (项目过程手册) EST Estimation Sheet (估计记录) PPL Project Plan (项目计划) CMP Software Management Plan( 配置管理计划

Atitit 软件开发中 瓦哈比派的核心含义以及修行方法以及对我们生活与工作中的指导意义

Atitit 软件开发中 瓦哈比派的核心含义以及修行方法以及对我们生活与工作中的指导意义 首先我们指明,任何一种行动以及教派修行方法都有他的多元化,只看到某一方面,就不能很好的评估利弊,适不适合自己使用,犹如盲人摸象,虽然都对,但是并不完整 1. 瓦哈比教派的核心思想1 1.1. 归一化,反对多神..反对邪教与不良的 修炼方式1 1.2. 规范化,标准化最佳实践 圣训立国,依法治国1 1.3. 主张整肃社会风尚,净化人们的"心灵1 1.4. 倡导团结,团队建设1 1.5. 回归传统,轻量化1 2