大家好，我是十一。
前情回顾
上面一篇我们讲了判定表法，我们先来回顾下：
判定表法
判定表驱动法是分析和表达多逻辑条件下执行不同操作的工具。由条件桩、动作桩、条件项、动作项、规则5大元素组成。
建立判定表的五大步骤：列出所有的条件桩和动作桩；确定规则；填入条件项；填入动作项；简化。
判定表转化成测试用例：判定表中的每一列就是一条测试用例。
今天，我们讲一个相对容易理解的设计方法：错误推测法
错误推测法
错误推测法是依赖对被测软件系统设计的理解、过往经验、直觉和简单的判断，来推测程序中可能存在的各种缺陷，从而有针对性地设计测试用例的方法。
该方法强调的是对被测试软件的需求理解以及设计实现的细节把握，当然还有个人的能力。那么显而易见地，这个方法的缺点就是太过依赖个人能力，难以系统化。因此，这个方法一般是作为测试用例设计的补充，而不是单独用来设计测试用例。
错误推测法的基本思想是：列举程序中所有可能出现的错误和容易出现错误的地方，作为推测的依据来选择和设计测试用例。
常见错误大概有几大类，如下：
1.页面规范相关部分（跟公司甚至项目需求有关系）
a.命名、注释、字体、颜色、缩进等
b.文本框长度/范围限制
c.支持的浏览器、操作系统、jdk等做兼容性测试
d....等等
2.常识性问题
a.密码用密文
b.手机号码是11位，且是135、151、153、171等开头
c.文本框自动忽略前后空格
d.支持模糊查询
e....等等
3.常见的异常测试情况
a.输入框不输入任何内容（为空）或者输入空格的情况
b.输入框输入非法字符
c.用户注销后，是否仍然能操作；再登录是否能成功
d.断电重连后是否能继续使用且信息未丢失
e....等等
4.功能相关的常见异常问题
a.C++软件的内存泄漏、内存分配
b.web程序的session失效问题
c.JavaScript字符转义
d...等等与需求/业务相关的常见问题
综上所述：
在错误推测法中，通常依据下列因素来进行判断和设计测试用例。
a.客观因素：产品先前版本的问题
b.已知因素：语言、操作系统、浏览器的限制可能带来的兼容性等问题
c.经验：利用不同测试阶段的经验和对测试软件的需求理解以及设计实现的细节来整理归纳的测试点
在软件企业的具体实践中，为了降低对个人能力的依赖，就需要做下列事情：
a.建立常见缺陷知识库或者常见问题集，在测试设计的过程中，会使用缺陷知识库作为检查点列表（checklist），去帮助优化补充测试用例的设计。
b.建立页面规范，用页面规范指导我们做页面测试
c.建立常识性测试用例集，测试需要时候直接提取或者复制即可
做到上述3点，我们的测试工作就可以事半功倍了！
上节课作业解析：
需求：
某软件规格说明书包含这样的要求：
第一列字符必须是A或B，第二列字符必须是数字，这种情况下进行文件的修改；如果第一列字符不正确，则给出信息E；如果第二列字符不是数字，则给出信息M。
上节课我们最终得到的判定表如下：
由判定表最终生成4条测试用例如下：
这里的测试项是指测试用例标题，那我们在实际测试中，可以直接写名称，比如第一列是用户名，第二列是密码，我们可以把第一个测试用例标题改为：输入合法用户名、非法密码登录。
好了，今天到此结束。如有任何问题请留言及时与我沟通，我会尽快回复大家！谢谢大家~我们下次再见！
让我们共同相伴，开启软件知识之旅。
