北京理工大学 计算机 软件测试 笔记
1 软件测试基础
1.1 软件测试
- 定义 ：在特定条件下运行系统或构件、观察或记录结果，对系统某个方面做出评价。分析某个软件项以发现现存和要求的条件之差别并评价此软件项的特性
1.2 软件缺陷 Bug
定义：缺陷是对软件产品预期属性的偏离现象。与产品说明书不符
分类
- 功能、特点没实现/部分实现
- 实际与预期不一致
- 运行出错：运行中断、系统崩溃、界面混乱
- 用户不能接受的其他问题：存取时间过长、界面不美观
缺陷修复成本
1.3 软件测试模型瀑布测试模型
- 修复代价高
1.2 V模型
- 把测试和设计开发分开
- 测试分阶段
- 测试阶段之内可以并行
1.3 RUP迭代V模型
1.4 软件测试分类
- 静态测试：看文档
- 动态测试：运行软件
1.5 测试用例
- 定义：确定软件或某功能与预期一致的一系列条件的集合
- 作用：
- 输入
- 判定
- 复用（测试脚本）
- 形式 步骤列表等
1.6 软件测试流程
- 测试过程
软件配置、测试配置
1.7 软件测试验证和确认的关系
- 软件测试：设计符合需求，代码符合设计
- 软件确认：黑盒确认测试（用户来判断）
- 测试=验证+确认
1.8 软件测试原则
- 尽早并不断进行软件测试
- 早期bug占多数
- 早期修复成本低
- 程序员应该避免检查自己的程序
- 自己不会否认自己的算法
- 穷举测试不可能
- 输入情况不可能遍历
- 不可能证明一个程序的正确性
- 软件测试有风险
- 应当输入合理和不合理的条件
- 测试中的群集效应（28效应）：有缺陷的地方往往有更多缺陷
- 严格执行测试计划、排除随意性
- 应当对每一个测试结果做全面检查
1.9 软件测试中的误区
- 调试和测试是相同的
- 软件测试对象仅限于程序
- 软件测试仅需要测试人员，不需要开发人员
- 单元测试是开发人员进行的
- 好的软件质量是通过测试得到的
- 把不合格的开发人员安排做测试
- 关注于测试的执行而忽略设计
- 测试自动化是万能的
- 测试是为了证明软件的正确性
- 无法证明正确性
2 单元测试
2.1基本概念
- 单元测试又称模块测试，是针对软件设计的最小单位-程序模块，进行正确性检验的测试工作
- 单元测试特点
- 单元测试主要需要测试者非常清楚代码内部结构，单元测试是软件开发人员的职责，==测试人员一般不参与单元测试==
- 既可以静态测试也可以动态测试
- 单元选择的依据
- 单元必须是可测试的
- 有明确规约（ground truth）作为测试依据
- 单元的行为或输出是可观测的
- 有一个明确的可定义的边界或接口
- 单元必须是可测试的
- 单元：能够实现需求规格的最小组件
- 函数、过程、类（面对对象语言单元测试均是以类为基准）、页面
- 单元测试的组织：谁写谁测
- 分级 的单元测试–产业
- 每个类对应一个testing-class
- 每个method对应一个或多个testing-method
- 单元测试的主要目的
- 合格代码的要求：正确性、清晰性、规范性、一致性、高效性
2.2单元测试方法
- 静态 白盒
- 动态 黑盒
2.4 静态测试
静态测试目标和内容
- 详细设计文档
- 代码风格和规则
- 程序设计和结构的检查
方法
同行评审：由软件工作产品创建者的同行们检查该工作产品，识别产品的缺陷，改进产品的不足
- 产品：最终产品的组成部分，源代码、设计文档
- 同行：项目成员和具有同等开发专业技能的并==熟知工件==的人员。也称为评省人员或评省组成员
- 公司内项目组成员
- 公司内其他项目组成员
- 公司外的专家
- 形式
- 走读（最自由）
- 评价软件代码（code review）
- 小组评省（做决策）
- 参与者主要是公司技术领导或权威及公司外部专家
- ==需求规范和概要设计==的评审
- 目标：提出意见和建议
- 确认某个制品是否符合要求，能否进入下个阶段
- 如何提高制品的质量，如何使之符合要求
- 审查
- 组织：公司内部设计开发测试质量等部门中工作性质相关的员工（QA部门）
- 形式：它遵循一个严格的过程，人员经过培训，检查过程有标准
- 适用范围与目的
- 代码、详细设计、概要设计
- 形成缺陷列表，缺陷总结
- 走读（最自由）
- 流程：计划—评省实施（会议形式）—评省情况统计（形成文档）—问题追踪/修改
数据流测试（少见，程序员自己进行，不提倡）
2.4.1 静态测试-详细设计
测试依据：概要设计（总体设计）
主要形式：审查和走读
检查要求：清晰性、完整性、规范性、一致性、正确性、数据、可靠性(catch e)、可追溯性、==接口==
数据：数据都已经被描述
可追溯性：每个详细设计单元都可以追溯到概要设计
接口
2.4.2 代码静态测试
代码静态测试是开发者自己执行的数据流测试或同行执行的代码走读
代码走读测试
代码风格和规则检查
程序设计和结构的检查
- 模块接口的正确性检查
- 输入参数有没有做正确性检查
- 调用其他方法接口的正确性
- 出错处理是否能挣挣表示错误是什么
- 保证表达式、SQL语句的正确性
- 检查常量或全局变量的正确性
- 数字是否使用表示符
- 检查代码是否可以优化、算法效率是否最高
业务逻辑的检查
2.5 黑盒测试
2.5.1 边界值测试
- 针对各种边界情况设计测试用例
最大值
最小值
略大于最大值
略小于最小值
中间值
- 变异：
- 主动植入错误，查看测试用例通过的数量
- 覆盖率
2.5.2 等价类划分测试
等价类：软件的行为对于一组值来说是相同的，那么这组值就叫做等价类
feajofj
测试用例选择
尽可能多地覆盖尚未覆盖的有效等价类，重复直到覆盖所有有效等价类
尽可能少地覆盖尚未被覆盖的无效等价类，重复直到所有无效等价类都被覆盖为止
有效等价类：
1、年龄20～39
2、年龄40～59
3、年龄：60岁以上20岁以下
4、性别：Female（F）
5、性别：Male（M）
6、 婚姻：Married
7、婚姻：Unmarried
9、抚养人数：0
10、抚养人数：1～6
11、抚养人数：6人以上
Order Age Gender Marriage 抚养人数 保险费率 testcase1（覆盖等价类1 4 7 9） 25 Female Unmarried 0 0.6% testcase2（覆盖等价类2 5 6 10） 50 Male Married 3 0.6% testcase3（覆盖等价类3 4 6 11） 70 Female Married 7 1% testcase4（年龄无效） 0 Male Unmarried 4 null testcase5（性别无效） 35 Unknown Married 0 null testcase6（婚姻无效） 28 Male Unknown 3 null testcase7（抚养人数无效） 29 Male Married -1 null 年月日 2019年12月5日
有效等价类
- 年
- 2017年之前
- 2017年-2019年
- 2019年之后
- 月
- 1 3 5 7 8 10 12月
- 2月
- 4 6 9 11月
- 日
- 1～28
- 29
- 30
- 31
Order 年 月 日 结果 testcase1（覆盖等价类1.1 2.1 3.1） 2016 1 1 超出范围 testcase2（覆盖等价类1.2 2.2 3.2） 2018 2 29 不存在这一天 testcase3（覆盖等价类1.3 2.3 3.3） 2020 4 30 超出查询范围 testcase4（覆盖等价类1.2 2.3 3.4） 2017 6 31 不存在这一天 testcase5（年份无效） 0 6 1 输入违法 testcase6（月份无效） 2018 13 5 输入违法 testcase7（日期无效） 2018 3 0 输入违法 - 年
2.5.3 输入组合法测试（不考）
研究统计表明：很多程序的错误都是由少数几个参数及参数之间的相互作用而导致
基本思想：统计学的角度对测试实验进行设计
求解配对测试用例的方法：正交表
- 选的点都不在一个线上（共同的坐标值超过1个）
- 任意两个平面必须有共同点（交点）
不同取值个数的处理方法
- 补齐
2.5.4 因果图法（必考）
是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，适合于检查程序输入条件的各种组合情况
- 首先从程序规格说明书的描述中，找出因（输入条件）和果（输出结果或程序状态的改变）
- 将因果图转换为判定表，判定表每一列设计一个测试用例
通常Ci表示原因，Ei表示结果，各节点表示状态，可取值0，1。0表示状态不出现，1表示状态出现
恒等：原因结果同时出现
若c1是1，则e1也是1；否则e1为0.
非~：原因出现，结果不出现；原因不出现，结果出现
若c1是1，则e1是0；否则e1 是1；
或V：原因只有一个出现，结果就出现；原因都不出现，结果就不出现。
若c1或c2或c3是1，则e1是1；否则e1为0。“或”可有任意个输入
且/与^：原因都出现，结果才出现。
若c1和c2都是1，则e1为1；否则e1为0。可有任意个输入
约束条件
从输入考虑
- E exclusive 互斥：表示a，b两原因不会同时成立，最多一个能成立
- I inclusive disjunction ：a、b、c三个原因中至少有一个必须成立
- O（唯一）：a、b当中必须有一个，且仅有一个成立
- R（要求）：当a出现时，b必须也出现，不可能a出现b不出现；
从输出考虑M（强制或屏蔽）
1）结果a是1时，结果b必须是0；
2）结果a是0时，结果b的值不定；
2.6 ==白盒测试==
知道源码，根据源码设计测试用例
- 黑盒：只能根据输入输出关系设计测试用例 基于数据的分类
- 白盒：根据内部结构优化测试用例的设计
测试的根源：不可能遍历所有的输入情况
2.6.1 覆盖率测试
语句覆盖
- 选取足够多的测试数据，使被测试程序中每个语句至少执行一次
- 控制流图，标号
判定覆盖（分支覆盖）
- 选取足够多的测试数据，使被测试程序中不仅每个语句至少执行一次，而且每个判定的每种可能的结果都至少执行一次
- 判定：程序分支节点上控制
条件覆盖：判定表达式中的每个条件都取到各种可能的结果（T&&F）
判定/条件覆盖：
- 选取足够多的测试数据，是被测试程序中每个判定表达式中的每个条件都取到各种可能的结果
- A = 2, B = 1, X = 2 X = 2 1假2假3真4真
- A = 1, B = 0, X = 0 X = 0 1真2真3假4假
==（白盒的测试用例一般是自动生成的）==
条件组合覆盖
- 选取足够多的测试数据，使得判定表达式中条件的各种可能组合都至少出现一次
- 不需要跨条件组合
路径覆盖
- 选取足够多的测试数据，使得程序的每条可能路径都至少执行一次
- 路径：开始语句到结束语句之间执行的语句序列
- 满足条件组合不一定满足路径，满足路径不一定满足条件组合
2.6.2 循环测试
- 简单循环测试：
- 整个跳过循环
- 只有一次通过循环
- 两次通过循环
- 最大次数次通过循环
- 嵌套循环的测试集
- 把外循环设置为最小值并执行内循环的所有可能情况
- 把外循环设置为最大值并执行内循环的所有可能情况
- 把内循环设置为最小值并执行外循环的所有可能情况
- 把内循环设置为最大值并执行外循环的所有可能情况
2.6.4 程序切片测试
- 找出可能影响变量的语句的集合（应该包含语句本身）
2.6.6 基本路径测试
- 基本路径：程序中的循环体只执行零次和一次的路径就是基本路径
- 测试方法：只覆盖所有基本路径的测试方法
2.6.7 错误定位
- 可疑变量查看
- 可疑语句查看
- 函数调用语句
- 判定转移/循环语句
- SQL语句
- 复杂算法段
- 插装：在软件特定的位置插入一些语句，用来获取软件的运行信息并反馈给测试者
2.7 灰盒测试
2.8 白盒测试与黑盒测试的比较
- 白盒测试的优缺点
- 优点
- 揭示隐藏在代码中的错误
- 对代码的测试比较彻底
- 优化代码
- 缺点：昂贵
- 优点
- 黑盒测试的优缺点
- 优点
- 对于较大的代码单元，效率高
- 测试人员不需要了解实现的细节
- 测试人员和编码人员相对独立
- 从用户的视角进行测试，容易被理解
- 有助于暴露任何规格不一致或有歧义的问题
- 测试用例可以在规格完成之后马上进行
- 缺点
- 只有一小部分可能的输入被测试到
- 如果没有清晰和简明的规格，测试用例难以设计
- 优点
2.9 类测试
2.10 单元测试流程
2.11 单元测试角色和职责
3 集成测试
3.1 基本定义
- 集成测试又称组装测试，是在单元测试的基础上，将所有模块按照设计要求
3.1.1 集成测试和单元测试的区别
- 对象不同：集成测试组装的对象比单元测试的对象级别药膏
- 关注点区别：集成测试关注的是模块间的接口，接口间的数据传递关系，单元组合后是否实现预计的功能
