关于软件测试的逻辑覆盖

首先这道白盒测试理论题，应选择，BA，错误，判定覆盖只是对各个判定节点的结果进行测试设计，不一定就能保证所有语句都覆盖的了。

例如：测试判断节点当a=5或！=5时，b=1或c=2，确认b,c结果后，我们就完成了判定节点的测试。

但是你的d=？你搞不清楚。

你还需要路径覆盖与语句覆盖funciton_test1(int a){int b=0;int c=0;int d=0;if(a==5)b=1;elsec=2;d=b+c;return d;}C，错误，条件覆盖的检错能力是否强过路径覆盖不好说。

但是可以清楚知道条件覆盖是逻辑点测试，路径覆盖是逻辑线测试，语句覆盖只是代码面覆盖测试了（注：语句覆盖可不是逻辑面测试，就有人会问了，那逻辑面怎么测试？其实穷尽所有逻辑线就是保证程序的逻辑面了，又有人会问，为什么所有逻辑点测试不能保证逻辑线，甚至是逻辑面呢？？这里我们要清楚程序可不是只由判定结构的语句组成的，它们还有顺序结构语句，循环结构语句。

上面的例子就说明了问题）。

D，错误，满足了路径覆盖不一定就满足条件组合覆盖，首先条件覆盖就时针对判定覆盖而言的。

条件覆盖是针对条件去覆盖，判定覆盖是针对判断结果去覆盖。

例如：这里调用function_test2我们输入a为1,3,6查看结果，此为条件覆盖. 使得结果a=1 或者a=2（两种结果都要走一遍）此为判定覆盖。

而一次输入a=1,a=6 此为路径覆盖（将两种结果情况路径覆盖掉）。

。

这样来看发现a=3的情况漏测试了（为什么要测试3参考等价类与边界值方法）。

多句嘴，路径覆盖其实就是已结果为导向的，多少个不同结果就是多少个不同路径，但各种条件的覆盖就容易漏掉，所以路径覆盖要保证条件的覆盖，这也就有了判定条件覆盖的概念function_test2(int a){if(a>=3) a=2;elsea=1;return a;}下面是某文章内容，供参考白盒测试是通过对程序内部结构的分析、检测来寻找问题。

白盒测试可以把程序看成装在一个透明的白盒子里，也就是清楚了解程序结构和处理过程，检查是否所有的结构及路径都是正确的，检查软件内部动作是否按照设计说明的规定正常进行。

白盒测试又称结构测试。

1 白盒测试基本技术： 词法分析与语法分析，静态错误分析，程序插桩技术。

2 白盒测试方法 2.1 代码检查法：代码检查方式（桌面检查，代码审查，走查），代码检查项目，编码规范，代码检查规则，缺陷检查表。

2.2 静态结构分析法。

2.3 静态质量试题法。

2.4 逻辑覆盖法语句覆盖：选择足够多的测试数据，使测试程序中每条语句至少执行一次。

判定覆盖（分支覆盖）：设计足够多的测试用例，使用得程序中的每个判定至少都获得一次“真值”或“假值”；或者说使用得程序中的每一个取“真”分支和取“假”分支至少经历一次。

条件覆盖：构造一组测试用例，使得每一判定语句中每个逻辑条件的可能值至少满足一次。

条件判定组合覆盖：设计足够的测试用例，使用得判定中每个条件的所有可能（真/假）至少出现一次，并且每个判定本身的判定结果（真/假）也至少出现一次。

多条件覆盖：设计足够的测试用例，使得每个判定中条件的各种可能组合都至少出现一次。

2.5 基本路径测试法程序的控制流图（学会通过看程序块画出控制流图）。

程序环路复杂性（即McCabe复杂性度量）环路复杂性V(G)=判断结点数+1.基本路径测试法步骤： 以详细设计或源代码作为基础，导出程序的控制流图；计算得到的控制流图G的环路复杂性V(G);确定线性无关的路径的基本集；生成测试用例，确保基本路径集中每条路径的执行.2.6 其他白盒测试方法：域测试，符号测试，Z路径覆盖，程序编译

软件测试中,测试用例要怎么分析才能全部覆盖而不遗漏？请分别对黑...

测试是无法全尽的，无法遍历的。

但是我们可以通过一定的测试方法，设计测试用例，用较少的测试用例覆盖最大的范围，发现最多的bug。

黑盒测试（等价类划分法，边界值分析法）和白盒测试 （语句覆盖，判定覆盖，条件覆盖 ，基本路径覆盖，等等）都是从不同的角度来思考如何用较少的测试用例覆盖最大的范围。

在实际测试当中，通常为了提高覆盖，我们需要组合使用这些测试方法，并不一定只采用一个。

边界值分析法：? 如果输入了条件规定了值的范围，则应取刚达到这个范围的边界值，以及刚刚超越这个边界范围的值作为测试输入数据；? 如果输入条件规定了值的个数，则用最大个数、最小个数、比最大多1、比最小小1的数作为测试输入数据；? 根据规格说明的每个输出条件，使用前面的原则；? 如果程序的规格说明给出的输入输出域是有序集合，则应选取集合的每一个元素和最后一个元素作为测试用列；? 如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试案例；? 分析规格说明，找出其他可能的边界条件。

边界条件是指软件计划的操作界限所在的边缘条件。

等价类划分法：? 如果输入条件决定了取值范围，或值的个数，则可以确立一个有效等价类和两个无效等价类。

? 如果输入条件规定了输入值的集合，或者规定了“必须如何”的条件，此时可确立一个有效等价类和一个无效等价类；? 如果输入条件是一个布尔量，则可以确定一个有效等价类和一个无效等价类；? 如果规定了输入数据的一组值，而且程序对每个输入值分别进行处理，此时可为每一个输入值确立一个有效等价类，此外，针对这组值确立一个无效等价类，它是所有不允许输入值的集合；? 如果规定了输入数据必须遵守的规则，则可以确立一个有效等价类（符合规则）和若干个无效等价类（从不同的角度违反规则）。

? 如果确知，已划分的等价类中各元素在程序中的处理方式不同，则应将此等价类进一步划分成更小的等价类。

基本路径覆盖：在程序控制流图的基础上，通过分析程序控制流图的环路复杂性，导出基本可执行路径的集合，然后据此设计测试用例。

设计出的测试用例要保证在测试中程序的每一条可执行语句至少执行一次。

条件判定组合覆盖：设计足够多的测试用例，使得判定中的每个条件的所有可能（真/假）至少出现一次，并且每个判定本身的判定结果也至少出现一次。

一组测试用例是条件覆盖,则一定是语句覆盖吗？为什么

软件测试覆盖率覆盖率=（至少被执行一次的item数）/item的总数语句覆盖率=（至少被执行一次的语句数量）/（可执行的语句总数）判定覆盖率=（判定结果被评价的次数）/（判定结果总数）条件覆盖率=（条件操作数值至少被评价一次的数量）/（条件操作数值的总数）判定条件覆盖率=（条件操作数值或判定结果至少被评价一次的数量）/（条件操作数值总数+判定结果总数）路径覆盖率=（至少被执行一次的路径数）/（总的路径数）需求覆盖率=（被验证到的需求数量）/（总的需求数量）继承上下文判定覆盖率=（累加每个上下文内执行到的判定分支数）/（上下文数*上下文内的判定分支总数）基于状态的上下文入口覆盖率=（累加每个状态内执行到的方法数）/（状态数*类内方法总数）函数覆盖率=（至少被执行一次的函数数量）/（系统中函数的总数）指令块覆盖率=（至少被执行的一次指令块的数量）/（系统中指令块总数）DDP覆盖率=（至少被执行的一次的判定路径数量）/（ 系统中判定路径总数）分支条件组合覆盖率=（被评测到的分支条件组合数）/（分支条件组合数）PPP覆盖率=（至少被执行的一次的PPP数量）/（ 系统中PPP总数）

软件测试

写好一个软件的测试用例的建议有：1、测试用例名称，也叫测试用例标题，一定要写得简洁、明了，需要用概括的语言描述该用例的出发点和关注点，使得测试人员第一眼看到测试用例名称就能够明白测试用例的目的。

用例名称中一般要求不能存在假设性的语句，并且原则上每个用例的名称不能重复。

2、预置条件要明确，包括测试环境、测试数据、测试场景。

因为许多BUG只有在特定的环境、特定的场景下才可以重现。

没有正确的前提条件，就无法进行后面的测试步骤或无法得到预期的结果。

3、测试步骤描述要简单、清晰，并且要清楚每一个步骤的描述，比如：第一步，输入用户姓名；第二步，输入登录密码；第三步，用户点击登录。

步骤写的明确时就利于提高用例的可操作性。

4、用例的预期结果要完整而且清晰，并且要将各个输出的结果写出来，包括：返回值的内容、数据库相关字段的记录、界面的响应结果、输出结果的规则符合度、日志的检查和对其它业务影响的检查。

5、测试用例级别要划分清楚，这样在测试执行时有主次之分。

6、测试用例的划分也要单一，一个测试用例只检查功能点的一种情况。

一个用例检查的情况太多，会导致用例的目的不明确。

而且这样组织用例，有利于需求覆盖率的统计。

一个功能点我们测试了哪些情况，以及哪些功能点我们在重点测试，一目了然。

如何编写单元测试用例

展开全部 1，语句覆盖：语句覆盖就是设计若干个测试用例，运行被测试程序，使得每一条可执行语句至少执行一次。

2，判定覆盖（也叫分支覆盖）：设计若干个测试用例，运行所测程序，使程序中每个判断的取真分支和取假分支至少执行一次。

3，条件覆盖：设计足够的测试用例，运行所测程序，使程序中每个判断的每个条件的每个可能取值至少执行一次。

4，判定——条件覆盖：设计足够的测试用例，运行所测程序，使程序中每个判断的每个条件的每个可能取值至少执行一次，并且每个可能的判断结果也至少执行一次。

5，条件组合测试：设计足够的测试用例，运行所测程序，使程序中每个判断的所有条件取值组合至少执行一次。

...

测试覆盖率中如何提高测试覆盖率

这篇文章中，主要讨论的是如何提高测试覆盖率的相关问题。

其实，提高测试覆盖率最基本，甚至是唯一的办法就是增加测试用例，但是怎样通过增加测试用例而帮助我们“迅速”提高我们的测试覆盖率呢？ 代码走查 对于代码的不熟悉造成了我们的代码覆盖率迟迟上不去，我们需要了解到代码里面究竟有多少条件分支，多少怎样的循环，分支和循环向来是导致我们代码覆盖率比较低的原因，另外，是不是存在一些过时的代码，没有运行过代码监测工具的代码中很可能存在一些没有被引用的死代码，而代码走查，尤其是对于覆盖率低的模块的代码走查将有助于你增加相关的用例而提高代码覆盖率。

工具 这里倒不是说有些工具可以帮助你直接提高代码覆盖率，这样的工具至少我还没有就见过。

这里提到的工具主要包括两种，一是代码分析工具另外一种就是上篇文章中提到的代码覆盖率工具。

代码分析工具可以帮助我们分析代码中的冗余部分，这样可以帮助我们干掉那些总是不可能覆盖到的死函数，有的编译器已经提供了类似的功能。

使用代码覆盖率工具则可以帮助我们快速监测代码覆盖率低的地方，这样我们可以快速定位我们测试的薄弱环节，通过代码走查或其他方式可以快速增加用例。

一般来讲，某一模块的代码覆盖率从30%提高到50%所需的时间遥远小于从60%提高到80%的时间。

规则 这里所指的规则其实是指一些基本测试方法，如等价类划分，边界值分析。

我们有时候需要通过这些手段来逐一检查我们那些方面的测试用例没有考虑到，从而帮助我们增加相关的测试用例。

经验 这个看起来有点像废话，因为一般都知道测试经验丰富有助于测试用例的设计，写出别人没有想到的测试用例。

我在这里把这句话提出来的主要意图是告诉大家注意平时的积累，某些时候的灵光一现可能成为日后的一个重要用例。

以前的失败教训也可以帮助我们从中学到经验，毕竟“经验是人为其错误而找的代名词”。

注意 有一点我想有必要再次提醒大家：单方面的提高测试覆盖率并不能有效的帮助测试质量的提升，尤其是在代码质量低劣的情况下。

就拿一个经典的三角形测试用例来讲，开发人员的代码可能仅仅判断了“两边之和大于第三边”然后就返回“这是三角形”。

在测试用例中，我们可能考虑了很多的问题，考虑了输入数据的类型，合法性等等的问题，但是这并无助于增加测试覆盖率。

运行这些测试结果是万里江山一片红，记住在你的测试用例没有运行通过的时候考虑测试覆盖率是没有意义的，我目前想到了两条理由：一是这些测试用例可能在代码的中间部分就已经出了问题，所以用例本该覆盖到语句没有覆盖到，这降低了代码覆盖率数据；第二个理由测试用例没有通过可能就如刚才提到的三角形问题中一样，开发人员压根就没有那么多语句给你去覆盖，这时候的代码覆盖率数据显然是没有多大作用的。

这也印证了前面文章中提到的“高代码覆盖率比低代码覆盖率更加‘没用’”。

写到这里，我的观点已经表达完毕了。

这一系列文章也差不多可以做个了结了。

当然我们还留了一些重要的＂尾巴＂——测试覆盖率工具。

在昨天的文章中提到，笔者将实际学习使用一些工具，并将整理相关的资料，当然我是不会爽约的，不过这些内容恐怕要等一段时间才能开始了。

转载请注明出处51数据库 » 软件测试用例语句覆盖