单元测试策略--设计
1. 单元测试-计划 在day01里面学过
1) 确定要测试代码范围
2) 评估标准(确定被测代码的覆盖率)
2. 测试策略-设计
1) 拿到开发代码进行调整(可独立执行)方式
1. 自上向下
2. 自下向上
3. 孤立策略 自上向下
方式：从最上层函数往下开始逐层测试案例1
两个函数(求和、求减)，求和函数内调用求减函数；案例1分析
1. 编写求和函数
2. 编写求减函数
3. 在求和函数内调用求减函数
4. 调用求和函数案例1问题
1. 我们只想测试求和函数不测求减函数该如何做？打桩
概念：打桩就是模拟编写一个我们需要引用的函数
提示：一般我们只模拟写个函数名，直接返回相应的结果即可
示例：
def fun_1(self):
return true自上向下总结
1. 方式
2. 打桩(模拟调用的函数)
3. 缺点(成本高)策略 自下向上
方式：从最底层函数往上开始逐层测试自下向上-总结：
1. 方式
2. 缺点(周期长) 要等开发把最下层函数定义好测试策略--孤立策略(重点)
方式：选择需要进行测试的函数进行测试孤立策略-总结：
1. 方式
2. 【推荐使用】
3. 优点：选择重要的代码进行测试单元测试策略--实现
测试策略-实现
1) 根据调整好的代码-画流程图
2) 根据流程图画流图-确定复杂度、路径
3) 根据复杂度和路径确定测试用例(测试数据)什么是流图
概念：表达程序业务逻辑的复杂度一种示意图
构成：
1) 圈：判断条件、语句块(一条或多条语句)两者都圈
2) 线：箭头指向的线，用来连接圈和圈的指向 流图的目的
1) 确定单元的复杂度级别
2) 确定测试用例
备注: 路径的个数为复杂度的级别(一条路径为1个复杂度级别)案例
函数(test001)判断参数a,如果a>0，执行语句1；
流图其实就是程序所有可能执行的逻辑。
测试用例模板
根据流图可以写出测试用例，这样写出的测试用例完全覆盖了所有的可能。
注意：在根据流图写测试用例时，一定要把流图附在用例文件里，不然谁知道你路径怎么标的。
案例总结
1. 路径：2 (1-2-4,1-4) 路径个数就是复杂度个数
2. 复杂度：2
3. 用例个数：2
总结出结论：复杂度最少为条件个数，最多为条件个数加1案例2
函数(test002)判断参数a,b;如果a>0 and b<10 输入语句1；否则输入语句2；
代码:
流程图:
流图：
思考
如果把案例3的条件 a>0 and b<10 换成 条件1 or 条件2 那么复杂度是多少？
案例3
输入两个数，如果两个数同时为大于0小于10，那么就进行求和运算；否则判断两个数是否同时大于等于10小于20那么
就进行求减运算，否则输入错误；
代码：
流程图：
流图：
（可能判断条件里面的代码调下顺序结果就不一样）测试用例
案例4
使用while循环求1-10相加之和；
代码：
流程图：
流图：
案例5
提示输入三角形三条边,进行判断三角形类型(等边、等腰、普通)并进行提示，否则提示不是三角形；
提示：
三角形：两边之和大于第三边；
等腰三角形：两条边相等
等边三角形：三条边相等步骤分析
1. 代码：
1) 自定义函数
2) 判断是否为三角形
3) 判断是否为等边三角形 如果是等边肯定就是等腰了，没必要往下走，所以等边判断在等腰上面
4) 非等边三角形继续判断是否为等腰三角形
5) 如果不是等腰三角形，输出普通三角形
2. 流程图
3. 流图
4. 用例
测试用例
总结
1. 单元测试计划
2. 测试策略设计
3. 测试策略实现