这一部分是“术”的重点，要深切彻底地掌握住软件测试的“道”，然后再对“术”加以灵活应用。
咱们一个一个来看。
首先是直觉经验，听说女人的第六感很准，不知道女测试员对这个技巧的掌握是不是要更厉害一点，至于经验，这个就得靠多实战和总结了。 错误推断基于的思想是：某处发现了缺陷，很可能会隐藏更多的缺陷。
然后是输入域： 这里我简写了一下，应该是基于输入域的测试方法，先看看什么是基于输入域的测试方法，对这个头衔没头脑很容易把握不到精髓。
解释：通过对不同数据的输入，检查其输出的数据以判断测试是否通过的方法，都归为基于输入域的方法。
但是现实是实在有太多种可能的输入了，根本不可能穷举完，这时候我们就需要派代表了。
代表怎么划分呢？想想我们的平时的的班级代表、年级代表、学校代表就懂了，不同需求下，划分方式是不同的。
这也就是我们说的等价类划分——“用一组有限的数据去代表近似无限的数据”
分为：有效等价类和无效等价类
等价类划分一般经过两个过程： （1）分类 （2）抽象，即在各子类种抽象出相同特性并用实例来表征这个特性。
优点：以少盖多，减少重复 缺点：缺乏特殊用例的考虑，同时需要深入的系统知识才能选择有效数据。
例题：
保险公司人寿保险保费计算程序的等价类测试 某保险公司人寿保险的保费计算方式为： 保费 = 投保额 × 保险费率 其中，保险费率根据年龄、性别、婚姻状况和抚养人数的不同而有所不同，体现在不同年龄、性别、婚姻状况和抚养人数，点数设定不同。10点以上保险费率为0.6%，10点及10点以下保险费率为0.1%；而点数又是由投保人的年龄、性别、婚姻状况和抚养人数来决定的，具体规则如下所示： 假设投保额是1万元，找出保险公司人寿保险保费计算程序的等价类测试用例。
解: Step1.分析程序规格说明中给出的和隐含的对输入数据的要求.
可以得出： 1）年龄：一位或两位非零整数，取值的有效范围为1-99； 2）性别：一位英文字符，只能取“M”或“F”值； 3）婚姻：字符，只能取“已婚”或“未婚”； 4）抚养人数：空白或字符“无”或1-9之间的一位非零整数； 5）点数：一位或两位非零整数，取值范围为5-15。
这里的分析非常重要,会对用例的设计产生影响,不同的分析结果和约束会有不同的用例设计.
Step2. 对规格说明输入数据的取值分析.
可得出保险公司人寿保险保费计算程序的等价类如下： Step3. 设计用例,给出预期结果.
根据等价类，假设投保额为1万元，保险公司人寿保险保费计算程序的等价类测试用例如下 测试用例个数（至少）：有效等价类最多的数量（4个）+无效等价类的总数（7个）
注意: 如果你是要考试的同学,利用等价类划分的测试用例的设计个数就是你老师判断你掌握了等价类划分方法的关键!!
为了考虑一些特殊的用例，我们又需要用到边界值分析。
边界值分析法就是在某个输入输出变量范围的边界上,验证系统功能是否正常运行的测试方法.
边界值分析常被看作是等价类划分法的补充,两者通常结合起来用.
一般分为: (1)数值的边界值检验 (2)字符的边界值检验(ASCII码值) (3)其他边界值检验
例题:
加法器程序计算两个1~100之间的整数的和。综合考虑边界值方法，设计加法器边界值测试用例集合。
解: Step1. 选边界值,一般我们会选5个点和7个点,在这里选的是6个点,正常点:1,2,99,100,不正常点:0,101,小数,其他特殊字符
解释一下为什么这道题要选小数和其他字符,因为题目明确说了输入是1-100的整数,所以要考虑到不是整数的用例.
另外,该答案中给的是所选的边界正常点与非边界正常点相结合设计,边界不正常点与非边界正常点结合设计,更正规的做法应该还要设计一个非边界正常点与非边界正常点的组合情况.
当然有的小伙伴就说,为什么不把每种情况都组合一遍,比如边界不正常点与边界不正常点组合. 这当然可以,但这种笛卡尔积之后,需要作的测试用例就太多了,通常情况下,我们不会采用. 讲完了基于输入域的测试方法,接下来我们进入到组合优化方法.
等价类和边界值分析法都用于单因素,单变量的数据分析,而对于多变量多因素的输入情况就需要考虑得更多.
组合分析是一种基于每对参数组合的测试技术.
优点: 低成本,易自动化,易以少用例发现更多错误,易自定义 缺点: 需要专业知识,不能测试所有可能的组合,不能测试复杂的交互.
首先讲判定表: 判定表的制作步骤: Step1. 列出所有条件桩和动作桩 Step2. 填入条件项 Step3. 填入动作项,制定初始判定表 Step4.简化, 合并相似规则或相同动作
举例: 化简: 然后来到了因果图:
这个名字让我想到了一句话"百因必有果…"咳咳,所以看到这儿了,觉得还挺有用的朋友,不要吝啬你的赞哦~
因果图法是借助图形,着重分析输入条件的各种组合,每种组合是"因",其对应的输出就是"果".
因果图生成测试用例的方法步骤:
Step1. 分析输入输出条件找到其中的关系,并得出等价类 Step2. 将对应的输入输出关联起来,将不可能情况标注成约束或限制条件,画出因果图 Step3. 由因果图转成判定表 Step4. 由判定表设计测试用例
具体例子可以看我的另一篇测试博文.
Pair-wise方法和正交试验法相对来说用得没那么多,以后有空了再补上.
进入我们的基于逻辑覆盖的方法!!! 表扬一下自己, 居然不知不觉学到这儿来了.
好,我们继续!
进行单元测试时,会针对程序进行测试,常常会设定目标比如代码行的覆盖率要超过80%. 如何进行覆盖呢? 这也是有方法的,往下看. 语句覆盖 最简单,设计用例把代码中的每个语句都覆盖到就行. 但这个其实没有用到什么逻辑.
判定覆盖: 设计测试用例,使得程序中每个判断的取真和取假分支至少经历一次.
条件覆盖: 设计测试用例,使得每个判断中每个条件的可能取值至少满足一次.
判定-条件覆盖: 将判定和条件结合,即设计测试用例,使得判断条件中的所有条件可能取值至少执行一次,同时所有判断的可能结果至少执行一次.
但这种情况下,未考虑条件的组合情况.
尽管看上去所有条件的所有结果似乎都执行到了,但由于某些特定的条件会屏蔽掉其他的条件,通常并不能全部执行到.例如它并不一定能发现逻辑表达式中的错误(或\与)
条件组合覆盖: 设计测试用例,使得判断中每个条件的所有可能至少出现一次,且每个判断的判断结果也至少出现一次.
缺点:线性地增加了测试用例数量.
举例: 本例来自博主「萝卜地里的兔子」的原创文章. 原文链接：https://blog.csdn.net/u012613903/article/details/80446721 感谢原博主,侵删. 针对上图的一个判断条件，在这里将分别讨论判定覆盖、判定条件覆盖、条件组合覆盖的情况：
设T1=A>3,T2=B>3;为该判定节点的两个子条件。
(一）判定覆盖：
所谓的判定覆盖就是让判定的真分支和假分支各执行一次，只要列出的子条件能够满足真假分支各一次就可以了：
例如： A=4,B=3(T1=True,T2=False)走了真分支，A=3,B=3(T1=False,T2=False)走了假分支。
当然，能走真假分支都走的条件组合还有很多种，这里随便选一种就可以了。
（二）判定条件覆盖(条件覆盖)：
所谓判定条件覆盖就是给出的条件组合里面每个子条件的真、假都出现过，也就是T1(True，False），T2（True，False）都出现过。现在如果我们拿过问题（一）的条件组合，那么得到的就是：
A=4,B=3(T1=True,T2=False) A=3,B=3(T1=False,T2=False)发现T1(True,False)都有了，T2(__,False）只有False，没有出现True，所以随便补充一个T2=True的条件组合就可以了：
A=3,B=4(T1=False,T2=True)
这样就满足判定条件覆盖了，当然，如果不在问题（一）的基础上扩展的话，可以用判定条件覆盖的最暴力的方式给出答案：
A=4,B=4(T1=True,T2=True) A=3,B=3(T1=False,T2=False)这样就满足了判定条件覆盖。
（三）条件组合覆盖：
所谓的条件组合覆盖，就是一个判定的所有子条件的组合情况都出现一次。一般使用列表法，把子条件的所有组合情况都列出来，然后填表：
在表格中的A B组合就满足了条件组合覆盖，可见条件组合覆盖是包含着判定条件覆盖的，而判定条件覆盖不一定包含判定覆盖。
注：本例中给出的测试用例严格来讲都是错误的，因为一个完整的测试用例，还要给出结果，这里只是为了说明问题，程序是截块的，所以就只给了输入，没有给输出。
总结一下它们之间的关系: 继续继续!基本路径覆盖!
基本路径覆盖是设计测试用例,使得程序中所有可能的独立路径被覆盖. 区别一下基本路径覆盖和语句覆盖, 语句覆盖是只管执行语句有没有被覆盖而不关心选择的是哪条路径的.
先看DD路径测试:
这是三角形程序的程序图: 这是它的DD路径图: 其实DD路径图就是只保留了主题架构,压缩了顺序执行的部分. DD路径测试是要每条DD路径都被覆盖.
基路径测试: 同样的,我们要先明白基路径到底指什么,这里的"基"是指向量空间中的基. 基路径测试步骤: Step1. 依据代码绘制流程图(DD路径图) Step2. 确定流程图的圈复杂度 Step3. 确定线性独立路径的基本集合 Step4. 设计测试用例覆盖每条基本路径
截至这,我们关注的都是对控制流的测试,因此再补充一个:数据流测试.
两种主要形式的数据流测试方法: (1)定义/使用测试 (2)程序片测试
定义使用测试的一些基本概念
定义节点; 使用节点(分为谓词使用和计算使用); 定义使用路径(定义节点到使用节点之间的路径); 定义清除路径(定义使用路径上没有对变量进行多次定义的路径)
不是定义清楚的路径就是数据流上容易出错的地方.
注意这里的DD和程序图的else语句没有展现出来,是有点问题的. 标红的地方是有问题的地方,要么定义了从未被使用,要么没有定义就使用了.
基于缺陷模型和模型的测试以后有空再补充.
