白盒测试

语句覆盖 是指选择足够的测试用例，使得运行这些测试用例时，被测程序的每一个语句至少执行一次，其覆盖标准无法发现判定中逻辑运算的错误； 判定覆盖<又叫分支覆盖率> 是指选择足够的测试用例，使得运行这些测试用例时，每个判定的所有可能结果至少出现一次，但若程序中的判定是有几个条件联合构成时，它未必能发现每个条件的错误； 条件覆盖 是指选择足够的测试用例，使得运行这些测试用例时，判定中每个条件的所有可能结果至少出现一次，但未必能覆盖全部分支； 判定 / 条件覆盖 是使判定中每个条件的所有可能结果至少出现一次，并且每个判定本身的所有可能结果也至少出现一次； 修正条件判定覆盖 满足条件与判定覆盖，并且需要确定每个条件能够影响到包含的判定的结果。 条件组合覆盖 是使每个判定中条件结果的所有可能组合至少出现一次，因此判定本身的所有可能解说也至少出现一次，同时也是每个条件的所有可能结果至少出现一次； 路径覆盖 是每条可能执行到的路径至少执行一次； 其中 语句覆盖是一种最弱的覆盖 ，判定覆盖和条件覆盖比语句覆盖强， 满足判定 / 条件覆盖标准的测试用例一定也满足判定覆盖、条件覆盖和语句覆盖 ，条件组合覆盖是除路径覆盖外最强的， 路径覆盖也是一种比较强的覆盖，但未必考虑判定条件结果的组合，并不能代替条件覆盖和条件组合覆盖 。 不论那种覆盖方法，都不能保证程序的正确性 。 白盒测试中的六种覆盖方法

圈复杂度 圈复杂度(Cyclomatic Complexity)是一种代码复杂度的衡量标准。它可以用来衡量一个模块判定结构的复杂程度，数量上表现为独立现行路径条数，也可理解为覆盖所有的可能情况最少使用的测试用例数。圈复杂度大说明程序代码的判断逻辑复杂，可能质量低且难于测试和维护。程序的可能错误和高的圈复杂度有着很大关系。 下面这个实例中，单元测试的覆盖率可以达到100%，但是很容易发现这其中已经漏掉了一个NPE的测试用例。case1方法的圈复杂度为2，因此至少需要2个用例才能完全覆盖到其所有的可能情况。 //程序原代码，圈复杂度为 2 public String case1( int num) { String string = null ; if (num == 1) { string = "String"; } return string.substring(0); } //上面代码的单元测试代码 public void testCase1(){ String test1 = case1 (1); } 圈复杂度主要与分支语句（if、else、，switch 等）的个数成正相关。可以在图1中看到常用到的几种语句的控制流图（表示程序执行流程的有向图）。当一段代码中含有较多的分支语句，其逻辑复杂程度就会增加。在计算圈复杂度时，可以通过程序控制流图方便的计算出来。通常使用的计算公式是V

基本路径方法设计测试用例步骤 1、画出控制流程图 2、计算圈复杂度（环路复杂度） 3、整理基本路径集合 4、导出测试用例 一、常见结构的控制流图 控制流图是退化了的流程图，将流程图中执行语句、判定语句、开始、结束等退化成节点，将流程线退化成一个节点到另一个节点的带箭头的弧线 红色标出的是判定节点、蓝色标出的是区域 流图只有两种图形符号： - 每一个圆称为流图的 节点 ，代码一条或多条语句 - 箭头称为 边或连接 ，代表控制流 - 包含条件的节点称为 判定节点 （也叫谓词节点），由判定节点发出的边必须终止于摸一个节点（判断是否为判定节点：该节点会有多个流出的边） - 由边和节点限定的范围称为区域（图形外也算一个区域） 多个逻辑运算符的情况 如果判断中的条件表达式是由一个或多个逻辑运算符（OR,AND,NAND,NOR）连接的复合条件表达式，则需要改为一系列只有但条件的嵌套的判断 在程序流图中一系列的顺序执行语句可以合成为一个节点，但是对于多分支的判断则需要分界为独立的分枝，每个分支一个节点 二、计算圈复杂度（环路复杂度） 圈复杂度是一种为程序逻辑复杂性提供定量测试的软件度量，该度量用于计算程序的基本的独立路径数，为确保所有语句至少执行一次的测试数量的上界。独立路径必须包含一条在定义之前不曾用到的边 有以下三种方法计算圈复杂度： 流图中区域的数量对应于环形的复杂度

软件测试 黑盒白盒的区别不用说了，这里介绍黑盒白盒测试所用的方法，都是关于测试样例的设计 白盒测试 语句覆盖 每条语句至少执行一次 判定覆盖 每一判定的每个分支至少执行一次 条件覆盖 每一判定中的每个条件，分别按“真”、“假”至少各执行一次 判定/条件覆盖 同时满足判定复盖和条件复盖的要求 条件组合覆盖 求出判定中所有条件的各种可能组合值，每一可能的条件组合至少执行一次 黑盒测试 等价分类法：划分输入数据的等价类，可分为有效类和无效类 边界值分析法：考虑边界情况使被测程序在边界值附近运行，通常和等价分类法联合使用 来源： CSDN 作者： wenkun97 链接： https://blog.csdn.net/hello_my_coder/article/details/80058476

问题背景 网上有许多介绍如何使用一种白盒测试工具的教程，但是很少有教人自己开发一个白盒测试工具的教程。因此我做了一次这样的实验，根据Python语言的特性，开发一个Python代码的白盒测试工具，实现以下功能：记录程序执行路径、获取函数调用关系、计算代码覆盖率、语句覆盖率、分支覆盖率（判定覆盖率）、字节码覆盖率。其中字节码覆盖率是我自己造的一个词，本想用于实现计算条件覆盖率的，奈何没有成功。 实验环境 编程语言：Python 编程环境：Linux16.04 + Anaconda2 + Python2.7 完整代码可以到我的GitHub上查看： https://github.com/Jancy1072/pycoverage 原理 1、Python是基于虚拟机的语言，首先是通过编译器编译成字节码文件，然后在运行时通过解释器解释成机器文件。Python是一种先编译后解释的语言。 我们在硬盘上看到的.pyc文件就是字节码文件，它来源于：当python程序运行时，编译的结果保存在位于内存中的PyCodeObject中，当Python程序运行结束时，Python解释器则将PyCodeObject写回到.pyc文件中。当python程序第二次运行时，程序首先会在硬盘中寻找.pyc文件，如果找到，则直接载入，否则就重复上面的过程。在载入之前还会先检查一下.py文件和.pyc文件保存的最后修改日期

第一次听说灰盒测试，是在金蝶上班的时候，那时候老大让我们研究灰盒测试，当时一头雾水。来阿里工作一年多自己感觉现在做的工作有点像灰盒测试，于是总结了一下，拿出来给大家分享。 在测试领域众所周知存在黑盒测试和白盒测试，黑盒测试更多是在集成测试阶段进行只关注应用是否符合需求，而不关心代码设计的结构，方式，方法。而白盒测试是针对黑盒测试提出的，前提是知道软件产品内部工作过程。通过测试来检测 软件产品内部动作 是否按照规格说明书的规定正常进行，通常是在单元测试阶段进行。那么做了这两种测试是否覆盖了软件测试的全部内容，即是否就能保证产品的质量呢。其实是不一定的，或者说如果靠这两种方法来覆盖，投入的代价是比较大的。譬如目前很火的 OPEN API 的测试，譬如对具备软件平台性质产品的测试。因为通过黑盒手工测试是很难完成的，而白盒测试是在单元测试进行的，显然对产品的测试带来很大的局限性，它也无法测试到产品在集成过程中带来的问题。那么灰盒测试就有它出现的必然性，这就是所谓存在就是合理的。 灰盒测试的特性： 1. 灰盒测试通常是在集成测试前期进行的。灰盒测试通常在程序员做完白盒测试之后（有些书上认为白盒测试是由测试人员进行的，我觉得纯属理想主义），在功能测试人员进行大规模集成测试之前进行的。 2. 灰盒测试是需要了解代码工程的实现的 3. 灰盒测试是通过类似白盒测试的方法进行的

第六章 编码与测试 1.程序设计语言分为两大类： 面向机器语言： 面向机器语言包括机器语言和汇编语言； 高级语言： 高级语言分为专用语言和通用语言； 2.程序设计语言的选择 理想标准、实用标准、系统用户的要求、工程的规模、软件的运行环境、可以得到的软件开发工具、 软件开发人员的知识、软件的可移植性要求。 3.软件测试 软件测试是使用人工或自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的 需求或是弄清预期结果与实际结果之间的差别。 4.测试用例设计的核心： a.要测试的内容； b.输入信息和对应的预期结果； 5.软件测试的重要性 a.寻找软件错误，以便进行修正； b.证明软件符合要求，是可用的； c.验证软件是否符合用户要求； d.指导软件的开发过程； e.提供软件的相关特征； 6.软件测试的分类 按照是否需要查看代码分类： a.黑盒测试： 黑盒测试是将被测软件看出一个黑盒子，只考虑系统的输入和输出，完全不考虑程序内部的逻辑结构和处理过程。 黑盒测试的依据是开发各阶段的需求规格说明。 b.白盒测试： 白盒测试是将黑盒子打开，研究源代码和程序内部的逻辑结构； 按照是否需要执行被测软件分类： a.静态测试： 又称为静态分析，是不实际运行被测软件，而是直接分析软件的形式和结构，查找缺陷。 主要包括对源代码、程序界面和各类文档及中间产品所做的测试。 b.动态测试：

一、什么是白盒测试 　　白盒测试是一种测试策略，这种策略允许我们检查程序的内部结构，对程序的逻辑结构进行检查，从中获取测试数据。白盒测试的对象基本是源程序，所以它又称为结构测试或逻辑驱动测试，白盒测试方法一般分为静态测试和动态测试。 二、如何去做白盒测试 　　网上很多介绍白盒测试的文章会提到白盒测试的方法有：代码检查法、静态结构分析法、静态质量度量法、逻辑覆盖法、基本路径测试法、路径覆盖等等。实际工作中的白盒测试并不是一上来就进行代码分析，我个人理解白盒测试应该从以下几个步骤来一步一步执行： 1、使用静态代码分析工具：Findbugs先找出一些简单的 bug 操作空对象； 数组访问越界； 线程安全； 字符串拼接； 资源关闭； 2、diff评估影响范围，找边界和影响范围 往上找，找它的调用链，找测试范围的边界； 往下找，找它对下游的影响，找影响范围； 3、做单测，从上往下串 不只是对改动方法做单测； 还要找到它影响的点，从上到下往下串； 4、单独拉分支，梳理代码逻辑 checkpoint：根据checkpoint画出流程图/时序图，后面做接口测试的测试点/检查点； bug：梳理代码时能够确定的问题； 5、接口测试 基于第四步代码梳理的checkpoint来做接口测试； 只做白盒测试不做接口测试，无法将代码的整个逻辑理顺； 6、debug再做一遍 远程debug，将整个流程走一遍；

软件生命周期 软件测试要经过一个什么样的过程呢，这就要从软件的生命周期开始说起了。 软件生命周期又称为软件生存周期或系统开发生命周期，是软件的产生直到报废的生命周期。 整个生命周期包括问题定义与规划、需求分析、系统设计、软件编程、软件测试、软件运维等阶段。 在周期内，无论是开发还是测试都依赖于某个模型进行作为依据，有效地提高开发、测试效率。 软件开发模型 在软件开发的实践中，总结了很多软件的开发模型来描述和表示一个复杂的开发过程，如果瀑布模型、快速原型模型、螺旋模型等。 软件测试与软件开发模式有着紧密的关系，作为一名测试人员，应该充分理解软件的开发模式，尽快的找准自己的位置，从而尽快的发挥自己的价值。 瀑布模型 瀑布模型是线性模型的一种，在所有的模型中占有重要的地位，是所有其他模型的一个基础。 瀑布模型如同工地里的建造盖房流程，使用里程碑的方式，严格定义了各开发阶段的输入和输出。如果达不到要求的输出，下一阶段的工作就不展开。 测试的切入点，开发完成后，必须留给测试足够的时间给测试人员，否则可能会导致测试不充分，导致很多问题到项目的后期才体现出来。 优点 明确划分了软件生命周期的各个环节。 强调早期软件计划，需求分析比较重要。 清晰的工作流程，便于分工协作。 适合需求稳定的产品开发。 每个阶段都有一个检查点。 缺点 线性的开发流程，存在巨大的风险。 依赖于早期的需求调查

概述 整理一下我对 代码覆盖率 的认识 背景 理解了 白盒测试 用例设计 设计完了, 总需要一个 标准, 来评估用例的某些方面 这个可能, 是 覆盖率 提出的意义吧 至于这个是谁最先提出, 又是出于 什么目的, 现已无从考证 主要是我 懒得考证... 1. 回顾: 白盒测试用例设计思路 概述 回顾一下白盒测试用例的设计思路 思路 代码覆盖 分支覆盖 条件覆盖 分支条件覆盖 多重条件覆盖 ref 后面会有 2. 覆盖率 概述 简单介绍 覆盖率 覆盖率 作用 度量 测试用例 对 代码 测试程度 意义 找出那些地方没有测 重视没有覆盖的部分 重点是解释这些问题 为什么没有覆盖 能否覆盖 对于 测试质量, 没有任何的表述 是的, 覆盖率高, 未必就是 测试得好 计算方式 代码覆盖率 覆盖率 = 被测代码行数 / 代码总行数 当然还有其他的 覆盖率 那些怎么算的, 我目前还不清楚 3. 常见的 覆盖率 指标 概述 以 jacoco 的指标为例, 简单说明一下 jacoco 执行结果 概述 简单描述下 jacoco 执行结果 列 Element 被测的包 Missed Instructions & Cov 指令覆盖 Missed Branhes & Cov 分支覆盖 Missed & Cxty 圈复杂度 Missed & Lines 代码覆盖 Missed & Method 方法覆盖