测试流程
- 分析：需求评审、测试需求分析，得到测试点
- 计划：测试计划和方案文档编写
- 设计：测试用例设计
- 实现：编写测试用例、测试脚本等
- 执行：执行测试脚本、缺陷报告
按照以上步骤，一步一步实现。
需求来源
合同型项目（外包、甲方乙方）
用户业务需求——>产品需求
产品型项目（没有明确的用户）
协议/标准/规范
继承性需求（来自于老版本）
竞争分析
需求评审
1.需求从哪来，没有需求怎么办（依据相似产品的使用设计测试用例）
2.需求评审怎么评？
测试需求分析
在做任何系统的测试之前，我们都需要思考以下问题
- 你知道要测试的系统是干什么的吗？
- 你了解系统有哪些特点吗？
- 你知道系统有哪些功能吗？
- 你知道系统的业务流程是什么吗？
- 系统在这个版本上，哪些需要测试，哪些不需要测试？（迭代）
- 系统对性能、安全性上有没有什么要求？
测试需求分析流程
- 根据产品需求提取系统的测试点
- 编写需求跟踪矩阵
- 更具测试点利用适当的测试用例设计方法设计测试用例
测试设计和用例的编写
测试设计的概念
将测试点转化为测试用例的过程，就叫测试设计
测试用例的概念
测试用例就是一种用来具体说明如何进行测试操作并验证结果的文档
测试用例的模板
用例编号：TC：test case；
用例标题：用一句话表述用例是测试哪个测试点的；
优先级：区分用例重要性（时间不够时优先执行重要的）；
预置条件：在执行该用例时系统必须拥有的条件（有就写没有就不写）；
创建人；
创建时间；
所属模块；
测试步骤：描述执行测试用例时需要执行哪些步骤；
预期结果：来自于需求，要求我们达到的结果；
实际结果：实际操作后的结果（和预期结果进行对比）；
测试结果：pass/fail/NA（pass预期结果实际结果相同，fail预期结果实际结果不相同，NA当前用例不适用（没开发完成））
测试用例设计方法
世界上最好的测试方法？（不考虑测试的成本）
穷举法：每一种可能都去进行测试
等价类法（测试基石）：
定义：某个输入域（所有用户可以输入内容的区域叫做输入域）的集合，在这个集合中每个输入条件都是等效的，如果其中一个输入不会导致问题，则集合中其他输入条件进行测试也不可能发现问题
有效等价类：有效等价类即对程序有意义、正确的输入数据
无效等价类：无效等价类即对程序无意义、不正确的输入数据
等价类的划分原则：
- 如果输入条件规定了取值范围或值的个数，则可以确定一个有效等价类和两个无效等价类
- 输入条件规定了输入值的集合，或是规定了必须如何的条件，则可以确定一个有效等价类和一个无效等价类
- 在输入条件是一个布尔值的情况下，可以确定一个有效等价类和一个无效等价类
- 如果我们确知，已经划分的等价类中各个元素在程序中的处理方式不同，则应该将此等价类进一步划分
- 在规定了输入数据必须遵守的规则的情况下，可确定一个有效等价类（遵守规则）和若干个无效等价类（从不同的角度违反规则）
?
编写等价类表为每个输入划分等价类得到等价类表为每一个等价类规定唯一编号
设计一个测试用例使其尽可能多的覆盖所有尚未覆盖的有效等价类。重复这一步骤，使得有效等价类均被测试用例所覆盖
设计一个测试用例使其只覆盖一个无效等价类重复这一步骤使得所有无效等价类均被覆盖
?
边界值（和等价类法配合使用）：
- 对程序的输入和输出边界进行测试的一种黑盒用例设计方法，常与等价类设计发结合使用，此时它的用例来自于等价类的边界
- 边界值分析法的理论基础是假定大多数的错误是发生在各个输入条件的边界上，如果在边界附近的取值不会导致程序出现错误，那么其他的取值导致错误的可能性也很小
- 边界值使用条件（重点：可度量）
- 输入条件明确了一个值的取值范围，或是规定了值得取值个数
- 输入条件明确了一个有序集合
边界值法相关概念
上点：边界上的点（范围中看到的两个点一定是上点）
离点：离边界最近的点（开内闭外）（不可能既是上点又是离点）
内点：取值域内任意一点
边界值法分析原则
如果输入（输出）条件规定了取值范围，则应该以该范围的边界内的及边界附近的值作为测试用例
如果输入（输出）条件规定了值的个数，则用最大个数、最小个数，比最小个数少1，比最大个数多1的数作为测试用例
如果程序规格说明中提到的输入或输出是一个有序的集合，应该注意选取有序集合的第一个和最后一个元素作为测试用例
如果程序中使用 了一个内部数据结构，则因该选择这个内部数据结构的边界上的值作为测试用例
边界值法设计用例的步骤
分析输入参数的类型：从测试规格中分析得到输入参数的类型
等价类划分（可选）：对于输入的等价类划分方法进行等价类的划分确定边界：运用域测试分析方法确定域范围的边界（上点、离点与点内）
形成测试项：选择这些上点、离点与内点或者这些点的组合形成测试项
?
上面这个例子只有取60岁才能测试出问题（边界值法）
等价类和边界值使用于把输入条件分成多个不同的子条件，条件与条件之间相互独立，没有制约关系
判定表法：
判定表是分析和表达多种输入条件下系统执行不同动作的工具，它可以把复杂的逻辑关系和多种条件组合的情况表达的即具体又明确
?
确定规则的个数。如这里有3个条件，每个条件有两个取值，固有2*2*2=8种规则
列出所有的条件桩和动作桩
填入条件项
填入动作桩和动作项
化简，合并相似规则
将每条规则转化为用例
?
化简工作是以合并相似规则为目标的。如果表中有两条或多条规则具有相同的动作，并且其条件项之间存在极为相似的关系，我们便可以将其合并。
判定表法最后获取的是规则，获取规则后我们需要再利用等价类法和边界值法将其转换成测试数据
流程分析法（场景分析法）：
流程分析法（又名场景设计法）是将软件系统的某个流程看成路径，用路径分析的方法来设计测试用例根据流程的顺序一次进行组合，使得流程的各个分支都能走到。这是从白盒测试中路径覆盖分析法中推广到黑盒测试中来的测试分析方法
?
基本流：指所有操作都正确的主流程
备选流：指部分操作不正确的流程分支
流程分析法用例设计步骤：
画出业务流程图
设置功能路径优先级
确定测试路径
选取测试数据
构造测试用例
场景法最终得到的也是规则需要利用等价类划分法和边界值法进行划分
错误猜测法（探索性测试）：
错误猜测法就是根据经验猜想可能有什么问题并依此设计测试用例
错误猜测法只能作为测试设计的补充而不能单独用来设计测试用例，否则可能会造成测试的不充分
错误猜测不是瞎猜，不是没有根据和目的的猜测。他需要依据对系统薄弱的了解和对开发人员盲点的了解
业务熟悉程度、编程经验的丰富程度
测试用例设计总结
- 测试用例设计方法很多，我们不仅要知道每种方法怎么用，更要清楚每种方法的使用场景
- 等价类和边界值是任何其他测试设计方法的基石，必须首先考虑使用等价类和边界值进行用例设计
- 当输入域与输入域之间有约束关系，必须使用判定表来进行组合
- 在考虑了所有测试用例设计方法后，最后还要使用错误猜测法进行补充，以免遗漏。
- 在测试某一个字段时应保证其他字段的取值是一个正常值
?