“条件测试”( ISTQB教学大纲所定义的)究竟有什么好处？

Question

我目前正在检查ISTQB“技术测试分析员”认证的教学大纲。该教学大纲(此后称为"TTA教学大纲“)包含一个专门讨论”条件测试“的章节(显然这也被称为”条件覆盖“或”条件覆盖测试“)。

在TTA教学大纲中定义的条件测试给我的印象是一件非常奇怪的事情，而且可能是一件过时的事情，它更多地与奶奶的火腿故事有关，而不是软件测试。让我解释一下..。

根据TTA教学大纲什么是“状态测试”？

关于“高级课程大纲-技术测试分析员，2012年版”，现有的这里，“条件测试”在第12页的定义如下：

与将整个决策作为一个整体并在单独的测试用例中评估真假结果的决策(分支)测试相比，条件测试考虑决策是如何作出的。每个决策谓词由一个或多个简单的“原子”条件组成，每个条件的计算结果都是一个离散的布尔值。这些因素在逻辑上结合在一起，以确定决定的最终结果。必须通过测试用例对每个原子条件进行双向评估，以实现这一覆盖级别。由于下面提到的困难，适用性条件测试可能只是在抽象中感兴趣。然而，了解这一点对于在此基础上实现更大的覆盖面是必要的。

，所以让我们澄清一下

这个词

假设我们有一些正在测试的软件，我们希望对其进行白盒测试(即我们有源代码)。代码自然包含了许多我们都知道和喜爱的决策谓词，这些谓词出现在字符串(如if、while、until等)之后。

决策谓词的一个例子可能是：

((x>y+z) AND (y<-3)) OR ((z²+x²<4) AND (z≤y))

这个判定谓词接受整数值的三重(x，y，z)，并输出布尔值b_out。

将(x，y，z)映射到{TRUE，FALSE}的第一级函数在TTA教学大纲中称为条件(也是原子条件)。

条件测试覆盖

一个通过运行测试用例达到“条件测试覆盖”，直到决策中找到的所有条件至少产生一次为真和至少一次为假。

因此，可以通过运行以下五个测试用例来实现条件测试覆盖(例如)：

每个b0、b1、b2、b3至少出现一次以true表示，至少一次以false出现。在一些测试用例中，我们不关心给定的值，因为它对我们希望得到正确输出的条件没有影响。

增编:决策覆盖率

顺便提一句，真值表还显示，该决定已经达到“决策覆盖率”，因为b_out至少显示一次为true，至少一次为false，因此任何代码的两个分支都将被覆盖。

和现在的问题

上面定义的“条件测试”实际上对什么有好处？

它根本不会帮助您确定决策谓词的正确性。

这最好通过代码检查来完成，让第二个团队编写相同的表达式，比较输出或在“边界值”运行测试用例(例如，在这里，y= -4，-3，-2)。

检查单个条件会让我更多地了解如何测试CPU的ALU，或者可能测试编译器的输出。它当然适合于检查手工编写的汇编程序代码或验证手动组装逻辑。

这让我认为，“状态测试”很可能是一个遗留下来的日子，当时的条件实际上是连接在面板上(例如在ENIAC中)，因此可能会受到布线错误的影响。现在，这个条件是用高级代码编写的，在概念上正是你想要的。虽然回顾可能是有用的，但是对条件的测试只是浪费时间。

还是我漏掉了什么？

增编:文献检索

通过搜索库中的“状态测试”，只能得到两篇与软件相关的论文(所有其他文件似乎都只与硬件相关)，这两篇论文都是由北卡罗来纳州立大学计算机科学系的K.C.TAI撰写的。

基于条件的软件测试策略对其中的一种情况进行了检验，发现作者在决策意义上使用了条件一词，即在本文中“条件测试”实际上是“决策测试”。TTA教学大纲中使用的条件称为简单条件。TTA教学大纲的定义似乎没有被广泛使用。

从摘要来看：

计算机程序由包含条件的语句(如IF和WHILE语句)组成，这些条件是布尔表达式和关系表达式的组合。一种测试方法，称为条件测试，是通过集中测试程序中的条件来测试程序。虽然已经提出了许多状态测试策略，但是它们不能有效地检测复杂条件下的误差。本文定义了两种条件测试策略，一种是在条件下检测布尔型和关系型即表格E1的表达式opE2，其中E1和E2是算术表达式，op是六种可能的关系运算符之一：< <=，=，!=，>，>=错误。对于这两种条件测试策略，我们展示了它们的一些理论性质，并解释了它们为什么对包含复杂条件的测试程序是实用和有效的。

Answer 1

我能找到的最好的答案(也适用于语句覆盖测试和其他类型的覆盖测试)是由atollic.com “为什么要进行代码覆盖分析？”提供的。

更严格地说，代码覆盖率分析会发现程序中没有包含在测试用例中的区域，从而使您能够创建额外的测试，以覆盖程序中未经测试的部分。因此，理解代码覆盖率有助于您理解测试过程的质量，而不是代码本身的质量，这一点非常重要。

这似乎与此相当相关。如果您有一个测试用例集，它设法将任何决定的个别条件设置为TRUE或FALSE，那么您很可能使用一组相当详尽的输入值调用所测试的代码！

良好的条件覆盖率并不能告诉您关于所测试的代码的多少信息(除非代码崩溃或生成可检测的错误)，但它会给您对测试用例集的信心。

增编：

这是正确的解释。在程序结构和模型结构对MC/DC测试充分性覆盖的影响 (Ajitha和Mats Heimdahl，明尼苏达大学，ICSE，2008年)一篇关于相关的“修改条件/决策覆盖”(MC/DC)的论文中，有这样一篇文章：

测试套件的充分性目前是使用MC/DC度量来度量源代码(或基于模型的开发中的模型).在程序结构上定义的测试充分性度量，例如语句覆盖、分支覆盖和决策覆盖，几十年来一直用于评估测试套件的充分性。在评估测试工作时，这些标准可能是有用的工具。

本文还认为，MC/DC覆盖对SUT的结构具有很高的敏感性。单纯的句法重排可以极大地改变MC/DC的覆盖范围。当然，这是因为MC/DC只是在语法上工作，而不是在数据流上工作，因此在任何情况下都是一个相当可疑的度量。但这完全是另一个问题。