有多个输入，输入的不同，输出也不同，输入的组合导致输出的结果的不同。

2.         缺点：

如果有 n 个输入，转换成判断表有 2ⁿ 项，所以如果输入很多的话，比较复杂。

3.         基本符号：

目前对要求和强制约束不理解

4.         一般步骤：

1．  列出输入和输出，用符号表示

2．  生成因果图

3．  转换成判定表

4．  根据判定表生产测试用例

5.         个人体会：

在输入条件大于 4 的时候，因果图法比较复杂，特别是转换成判断表。下一个学习的目标是功能图法。

6.     补充一下

         3） 因果图基本图形符号
通常在因果图中，用Ci 表示原因，Ei表示结果，各结点表示状态，可取值0（状态不出现） 或1（某状态出现）
l 恒等：若原因出现，则结果出现；若原因不出现，则结果不出现
l 非（～）：若原因出现，则结果不出现；若原因不出现，则结果出现
l 或（V）：若几个原因中有一个出现，则结果出现；若几个原因都不出现，则结果不出现；
l 与（∧）：若几个原因都出现，结果才出现；若其中有一个原因不出现，则结果不出现
（4） 因果图的约束符号
从输入（原因）考虑四种约束
l E（互斥）：表示两个原因不会同时成立，两个中最多有一个可能成立
l I（包含）：表示三个原因中至少有一个必须成立
l O（惟一）：表示两个原因中必须有一个，且仅有一个成立
l R（要求）：表示两个原因，a出现时，b也必须出现，a出现时，b不可能不出现
从输出（结果）考虑一种约束
l M（屏蔽）：两个结果，a为1时，b必须是0，当a为0时，b值不定

以前在三级目录调整的时候，那是我第一个测试项目，测试用例不知道怎么写，当时测的时候觉得很头疼，头绪太多，现在觉得测试用例是很有必要的，再测之前把所有的测试点和测试方法都写好了，那么测试就根据测试用例走了，很有条理，不会看到要测的东西，就晕了，要测的点太多，不知从何下手，下面的测试测试用例要好好写了，确实有用的 J 目前所掌握的测试用例的写法、 bug 提交、也总结了一些测试方法如等价类法，边界值发，表格列举组合法，需要继续学习的有测试计划、测试报告。

做项目测试的流程：第一遍分模块，每个测试人员负责一块，测试所有级别的测试用例；第二遍测试人员交换测试模块，只测试优先级别较高的测试用例子；第三遍只测试优先级别更高的用例，最后一遍测试人员交换测试模块，在测试所有级别的测试用例，保证测试人员所测的模块不会重复。对开发人员和测试人员的工作都有一个考核，千万不要在一遍测试没结束，就交换测试模块，这样有的测试人员就会出现不积极的情况。

思考的问题：

1.         怎样考核测试人员的工作成绩？

2.         怎样激发开发和测试人员的积极性？

测试语录：

1.         大家都是为了产品的质量 , 多多沟通 , 既然目标一致就没有原则性的冲突了 .

2.         不是我们死扣， 我就是干这个的，就混这个饭吃的，你的东西要是做的好，就算我怎么死扣，也扣不出什么来啊

3.         测试不只是一种形式

4.         有时侯优秀就是差这么一点用心 , 就差这么点细心 , 就是差这么点专业角度看问题

5.         马云说的：在中国最贵的是服务！个人认为软件就是一种服务，属于第三产业。我们测试是让这种服务更好更贴心！

6.         做的东西足够牛，才有资格牛

测试的初级阶段，一般能做的就是找 bug 。到一定阶段后，就应该考虑怎样高效、有效的找 bug 。在到一定阶段后，就要学会写测试报告，分析错误数据