1、测试用例的概念和作用
1.1.1什么是测试用例
测试用例是执行测试的依据，把测试系统的操作步骤用文档的形式描述出来
（1）测试用例是为达到最佳的测试效果或高效的揭露隐藏的错误，而精心设计的少量测试数据，包括测试输入、执行条件和预期的结果，实际结果
（2）测试用例是执行的最小实体。
（3）测试用例是测试工作的指导，是软件测试的必须遵守的准则，更是软件测试质量稳定的根本保障
1.1.2、测试用例的特征：
1、有效性：测试用例的能够被使用，且被不同人员使用测试结果一致
2、可重复性：良好的测试用例具有重复使用的功能。(回归测试)
3、易组织性：好的测试用例会分门别类地提供给测试人员参考和使用(功能、性能、易用分类编号)
4、清晰、简洁：好的测试用例描述清晰，每一步都应有相应的作用，有很强的的针对性，不应出现一些无用的操作步骤。
5、可维护性：由于软件开发过程中需求变更等原因的影响，常常对测试用例进行修改、增加、删除等，以便测试用符合相应测试要求。
1.1.3、测试用例的作用：
在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率。
测试用例的使用令软件测试的实施重点突出、目的明确。
在软件版本更新后只需修正少部分的测试用例便可展开测试工作，降低工作强度、缩短项目周期。
检验软件是否满足客户需求、体现一个测试人员的工作量、展现测试用例的设计思路
1.14、测试用例的4个特性
代表性：能够代表并覆盖各种合理的和不合理、合法的和不合法的、边界的和越界的以及极限的输入数据、操作等。
针对性：对程序中的可能存在的错误有针对性地测试
可判定性：测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果
可重现性：对同样的测试用例，系统的执行结果应当是相同的。
1.1.5、测试用例示例
2、编写测试用例的基本方法
等价类划分法 边界值分析法 错误推测法 因果图法 正交表法 场景法
2.1、等价类划分法
应用场景：多用于输入框
2.2、边界值法
一般边界值分析是因为程序开发循环体时的取数可能会因为<,<=搞错
2.3、因果图法
因果图法比较适合输条件比较多的情况，测试所有的输入条件的排列组合。所谓的原因就是输入，所谓的结果就是输出。
基本图形符号：
恒等：若原因出现，则结果出现；若原因不出现，则结果不出现。
非（～）：若原因出现，则结果不出现；若原因不出现，则结果出现。
或（∨）：若几个原因中有一个出现，则结果出现；若几个原因都不出现，则结果不出现。
与（∧）：若几个原因都出现，结果才出现；若其中有一个原因不出现，则结果不出现。
因果图的约束符号：
E（互斥）：表示两个原因不会同时成立，两个中最多有一个可能成立
I（包含）：表示三个原因中至少有一个必须成立
O（惟一）：表示两个原因中必须有一个，且仅有一个成立
R（要求）：表示两个原因，a出现时，b也必须出现，a出现时，b不可能不出现
M（屏蔽）：两个结果，a为1时，b必须是0，当a为0时，b
2.4、场景法
现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。
用例场景是通过描述流经用例的路径来确定的过程，
这个流经过程要从用例开始到结束遍历其中所有基本流和备选流。
流程：
基本流和备选流的区别：
2.4.1 银行案例ATM
个人标识号 (PIN＝personal identification number )，用于保护智能卡免受误用的秘密标识代码。PIN 与密码类似，只有卡的所有者才知道该 PIN。只有拥有该智能卡并知道 PIN 的人才能使用该智能卡
第一次测试中，根据测试计划，我们需要核实提款用例已经正确地实施。此时尚未实施整个用例，只实施了下面的事件流：
基本流-提取预设金额（100 元、200元、500元、1000元）
备选流2 - ATM 内没有现金
备选流3 - ATM 内现金不足
备选流4 - PIN 有误
备选流5 - 帐户不存在/帐户类型有误
备选流6 - 帐面金额不足
2.5 错误推测法
错误猜测法是测试经验丰富的人喜欢使用的一种测试用例设计方法。
一般这种方法是基于经验和直觉推测程序中可能发送的各种错误，有针对性地设计。只能作为一种补充
2.6 正交表法
用于多个下拉框之间的组合，可以通过正交助手生成测试用例
3、测试用例的评审
包含：参与评审人员（需求人员，对应开发人员，对应的测试人员，项目经理）
4、测试计划
测试背景
测试目的
确定测试范围
制定测试策略（功能测试/业务测试……）
测试资源安排
测试时间安排
测试人员分配
风险评估
5、缺陷报告
所属产品，所属模块，当前指派（重要），bug类型,，操作系统，重现步骤（*）验证程度（*），优先级（*）附件等
6、测试报告
测试目标，测试的范围，测试环境，测试结果分析（多少轮测试，测试多少，失败多少，成功占比），遗留缺陷，测试结论（本次测试涉及xxx个功能点，发现xx个缺陷，其中，xx个已修复，xx个遗留)测试过程完整有效，系统测试通过
7、软件缺陷的种类划分
- 功能不正常：简单地说就是所应提供的功能，在使用上并不符合产品设计规格说明书中规定的要求，或是根本无法使用。
- 软件使用上感觉不方便：只要是不知如何使用或难以使用的软件，在产品设计上一定是出了问题
- 软件的结构未做良好规划：这里主要指软件是以自顶向下方式开发，还是以自底向上方式开发
- 提供的功能不充分：这个问题与功能不正常不同，这里指的是软件提供的功能在运作上正常，但对于使用者而言却不完整。
- 与软件操作者的互动不良：
一个好的软件必须与操作者之间可以实现正常互动
- 使用性不佳：
被测软件功能正常，但使用性能不佳
- 位做好错误处理：
软件除了避免出错之外，还要做好错误处理，许多软件之所以会产生错误，就是因为程序本身对于错误和异常处理的缺失
- 边界错误
缓冲区溢出问题在这几年已成为网络攻击的常用方式，而这个缺陷就属于边界错误的一种
- 计算错误：
只要是计算机程序，就必定包括数学计算。软件之所以会出现计算错误，大部分出错的原因是由于采用了错误的数学运算工时或未将累加器初始化为0.
- 使用一段时间所产生的错误
这类问题是程序开始运行正常，但运行一段时间后却出现了故障
- 控制流程的错误
控制流程的好坏，在于开发人员对软件开发的态度及程序设计是否严谨
- 在大数据量要下产生的错误
程序在处于大数据量状态下运行出现问题，就属于这类软件错误
- 在不同硬件环境下产生的错误
这类问题的产生与硬件环境的不同相关。如果软件与硬件设备有直接关系，这样的问题就是数量相当多
- 版本控制不良导致的错误
出现这样的问题属于项目管理的疏忽，当然测试人员未能尽忠职守也是原因之一
- 软件文档的错误
最后这类缺陷是软件文档错误
8、软件缺陷的严重程度
按照严重程度分为：系统崩溃，严重，一般，次要，建议
按优先级分：高，中，低
9、Bug定级示例
1级，系统崩溃
定义：严重阻碍测试和开发工作
对应优先级：最高
具体可分为：
1、功能完全没有实现
2、应用闪退/崩溃无法运行
3、应用必现安全模式，无法运行
4、其他导致功能无法测试的问题
2级，至关重要
定义：非阻碍用例执行的严重问题
对应优先级：高
具体可分为：
1.简单操作应用闪退/崩溃，卡死
2.数据丢失
3.严重影响系统，自身功能无法运行
4.严重数值计算错误
5.数据库损坏或无法保存配置
6.安全性问题（包括数据加密等）
3级、主要
定义：功能存在缺陷，但不影响应用和系统的稳定性
对应的优先级：中
具体可分为：
1.内存泄露（长时间不用的对象需要被回收，不被回收占内存）
2.功能实现逻辑覆盖不全面
3.非必现，但复现概率超过50%的闪退/崩溃和安全模式
4级、一般
定义：对应用熟悉度高才能感知到的问题，对应用基本功能实现无响应
对用的优先级：中
具体可分为：
1.轻微数值计算错误
2.功能实现有误，与产品文档不完全贴切
3.用户简单操作，即可明显感知的UI问题
5级、较小
定义：对于产品的意见或者建议
对应优先级：低
具体可分为：
1.操作界面错误（提示显示规则，刷新规则是否与文档一致）
2.边界条件显示错误
3.提示信息和界面效果展示错误（包括未给出信息、信息提示错误等）
4.复现率低于5%的闪退/崩溃和安全模式
5.插件兼容和性能未优化问题
6.非正常操作导致UI显示异常
6级、建议
定义：对于产品的意见或者建议
对应优先级：低
具体可分为：
1.对于产品设计方面的意见和建议
2.对于产品界面优化方面的意见和建议
3.对于产品需要优化增强用户体验方面的意见和建议
10、Bug的处理
11、测试用例执行和故障管理流程图
