写在前面的碎碎念：
近日，看了好多文章，也思考了很多。有些东西，总要实践一下嘛。
想锻炼文字，不一定上来就要从自己想写的东西开始，比如写写读书笔记，读后感啊，都可以进行很好的锻炼和积累。
很感谢古典老师的拆墙文。因古典老师，又结缘了很多大咖（说的好像人家认识我似的 ≧≦），从大咖们的经历中也收获良多。十一期间，本就打算要再好好想想一些东西，也基本想好接下来要怎样做了。目前在看《软件测试的艺术》这本书，若只是看一遍，恐怕很快就会忘却。记笔记还是很OK的方式的，不过又不太想用一般的写在本上的方式。诶，不如写个读书笔记吧，看过之后，经过自己的理解并进行总结，再落实到文字上，既巩固了学习内容，又能锻炼文字能力，一举两得啊。虽然开始会很弱，但不要怕，高手也是一步一步练就出来的。
嘛，就从这篇开始吧。
写于2016.10.4
--------碎碎念好长啊，我是吐槽的分界线-------
第4章 测试用例的设计
这一部分的总体思想，就是教你如何设计出高效的测试用例。
总体方法：用黑盒的方法来设计用例，用白盒的方法进行补充（视情况而定），尽可能多的运用黑盒和白盒下的各种方法，以达成优势互补，从而设计出严谨的测试。
1.白盒测试
1）语句覆盖
2）判定覆盖 or 分支覆盖
3）条件覆盖
4）判定/条件覆盖
5）多重条件覆盖
白盒测试即逻辑覆盖测试，有以上5种准则，覆盖程度按罗列顺序由弱到强。关于5种准则的关系画了个简图，如下：
对每种准则做个简要说明。借助书上的图画了个简要流程图：
这5个准则就是要依据各自的方式，从入口走到出口。当然，可以走多次，但要满足各自的条件。
语句覆盖，就是保证每条语句都走到；
判定覆盖，就是要把每个判断语句为Y和N的情况都走到（即每个判断语句的分支都要走到）；
条件覆盖，就是保证判断语句中的每个条件满足、不满足的情况都覆盖到；
判定/条件覆盖，即判定覆盖和条件覆盖的条件都要满足；
多重条件覆盖，则要将判断语句中的每个条件满足、不满足的情况进行组合，保证每种组合都覆盖到。
假设第1个判断语句为 if(x>3 && y>4 && z>5)，这条语句中有3个条件，多重条件覆盖就是要保证2^3=8种情况都被覆盖到。
注意：不是说有多少种组合情况，就一定有多少个用例，有时有的用例能同时覆盖多种组合情况，即用例数≤组合数。
这5个准则的定义如下，供参考：
1）语句覆盖：程序中的每条语句至少执行一次。
2）判定覆盖：每个判断的所有可能的结果至少执行一次，每个入口点（包括ON单元）都至少调用一次。
3）条件覆盖：每个判断中的每个条件的所有可能的结果至少执行一次，每个入口点都至少调用一次。
4）判定/条件覆盖：每个判断中的每个条件的所有可能的结果至少执行一次，每个判断的所有可能的结果至少执行一次，每个入口点都至少调用一次。
5）多重条件覆盖：将每个判断中的所有可能的条件结果的组合，以及所有的入口点都至少调用一次。
2.黑盒测试
1）等价类划分
2）边界值分析
3）因果图分析
4）错误猜测
PS：书中的范例很好，值得一看。
1）等价类划分
① 确定等价类：根据规格说明，选取每一个输入条件（通常是句子或短语），并将其按“有效等价类”和“无效等价类”进行划分。这两类下可能会有多个等价类。
② 生成最小测试用例集：编写新用例，每个用例尽可能覆盖多个有效等价类；编写新用例，每个用例只覆盖一个无效等价类。
2）边界值分析
需要考虑：
① 恰好处于边界上的值
② 刚在边界之外的值
③ 不仅要对输入条件考虑边界值，对输出结果也要考虑边界值
注意：边界条件可能非常微妙，边界值分析往往比想象中要费脑筋。
3）因果图分析
因果图是一种形式语言，它可以对输入条件的组合进行系统的分析，有助于我们选择出高效的测试用例集。此外，它还可以指出规格说明的不完整性和不明确之处。
把输入看做“因”，把输出视为“果”，将语义转换为连接因果关系的布尔图，同时将因或果之间的限制用符号进行标注，所得到的就是因果图。
基本的因果图符号：
Identity；NOT；OR；AND
输入条件间的约束符号：
E（不能同时为1）
I（不能同时为0）
O（有且仅有一个必须为1）
R（require. 如果条件a为1，b也必须为1）
输出结果间的约束符号：
M（如果a为0，则b强制为0）
图略。
灵活设置中间节点，有利于因果图的生成。
用因果图生成用例的过程：
① 将规格说明分解为可执行的片段
② 转换为因果图
③ 转换为判定表
④ 转换为测试用例
直接由因果图生成测试用例是比较困难的，在这个过程中需要借助于一个二维表，即判定表。
因果图转换为判定表有一定的方法和规则，只要遵循这一方法和规则，就可达到这样一个作用：减少组合关系，排除低效测试用例。即得到一个可接受、高质量的测试用例集。
具体方法就不详述了。
判定表的每一列即代表一个测试用例。
因果图转换为判定表是最难的部分。这个过程是有算法的。可使用相关软件进行转化。
* * * * * * * * * * * * * * * * * * * * * * * * * * * *
自己平常测试时，使用的就是个简单的二维表，方法自然不似这般系统，当然也无这个必要。条件间的关系也并不复杂，所以可直接转化为二维表。
结合实际工作又想了想，大多数时候，我是将有交的关系的条件直接当做判定表的每一行，有或的关系的则不拆开，直接当做一个条件，打勾划叉时再做具体考虑。
本来对书中生成判定表的过程这一块看的很绕，很费劲才想明白，等再看时又会绕半天。突然开窍将此对应于实际工作中用的方法，再一思考，也就明白多了，其实在工作中自己就是那么考虑的。同时也发现了自己平时忽略的一些情况。结合实践思考，能让自己更好的理解一些方法、原理，并意识到自己的不足。
虽然自己平时并不需要用这样复杂的二维表，但看了判定表这部分内容后，我知道了二维表系统化后的样子，以及它可能的复杂性。也意识到自己在测试的道路上，路漫漫其修远兮。
* * * * * * * * * * * * * * * * * * * * * * * * * * * *
仅仅使用因果图的方法通常不能生成全部应该被确定的有效测试用例。
一个比较好的策略是：因果图+边界值分析
在用因果图生成测试用例时，可将边界值分析一并考虑进去，从而减少用例数的增长。
3.错误猜测
探索性测试的思想。
依赖于测试经验，磨炼出的对测试情况的敏锐，跳出常规思维方式等。
4.测试策略
例如：
因果图+边界值 为主
等价类，错误猜测 进行补充
逻辑覆盖 检查、补充
以上即是我关于第4章的读书笔记。
虽然还有很多不足，但也是个很大的进步。
从开始写到现在，拖了好久了呀~
