第一章
软件测试概述
缺陷
- 软件缺陷是指计算机系统或者程序中存在任何一种破坏正常运行能力的问题、错误或者隐藏的功能缺陷、瑕疵。
按阶段分类
- 单元测试、集成测试、确认测试、系统测试、验收测试、回归测试
第二章
软件测试方法
静态测试
- 被测程序不被真正运行。
- 静态测试中在做会议审查时通常会用到一张表，叫做缺陷审查表，这张表把程序设计中可能发生的各种缺陷进行分类，每一类尽可能多地列举典型缺陷。
动态测试
- 通过运行和使用被测程序，发现软件故障，已达到检测目的的测试方法
黑盒测试
- 黑盒测试无法看见源码，源代码与黑盒测试无关
- 黑盒测试是根据程序的功能来设计测试用例的，也称为功能性测试
- 黑盒测试优先选择等价类划分
- 等价类划分法：原则包括完备性和无冗余性
- 划分等价类（有效与无效）
- 为每个等价类确定一个唯一的编号
- 设计一个新的测试用例，尽可能多的覆盖有效等价类，重复这个过程直到所有的有效等价类均被测试用例覆盖
- 设计一个新的测试用例，使其仅覆盖一个无效等价类，重复这个过程直到所有的无效等价类均被测试用例覆盖
- 边界值法：n个变量的程序产生4n+1个测试用例，采用强健边界值分析法会产生6n+1个测试用例
- 确定边界情况
- 选取刚好等于、刚好大于、刚好小于边界值的值作为测试数据
- 因果图法：根据输出对输入的依赖关系来设计测试用例
- 决策表法
白盒测试
- 白盒测试是基于被测程序的源代码，而不是软件规格说明的测试活动
- 白盒测试是根据程序的内部逻辑来设计测试用例的，也称为结构测试
- 逻辑覆盖测试
- 语句覆盖：时的每条可执行语句至少被执行一次
- 判断覆盖：每个判断条件的真值分支和假值分支至少被执行一遍
- 条件覆盖：每个判断条件的每个判断式的真值和假值至少被执行一次
- 判断/条件覆盖：每个判断条件的真值分支和假值分支至少被执行一遍，并且每个判断条件的内部判断式的真假值也要被执行一遍
- 条件组合覆盖：每个判断式的内部判断式的各种真假值组合可能都至少被执行一遍
- 路径覆盖：使程序中所有可能的路径都能被覆盖到
- 路径分析测试：一个程序中所含有的路径数与程序的复杂度有着直接的关系。
- 控制流图：唯一入口节点，唯一出口节点
- 程序环路复杂度：V(G)
V(G) = 边数 - 节点数 + 2
V(G) = 判断节点 + 1
V(G) = 区域数目 - 独立路径集：先找一条起点到终点的路径，然后按分支节点拆分
- 按路径设置测试样例
- 控制流图：唯一入口节点，唯一出口节点
- z路径覆盖测试
代码评审
- 代码评审也称代码复查，是指通过阅读代码来检查源代码与编码标准的符合性以及代码质量的活动。
- 代码审查是对可靠性要求很高的软件，例如操作系统，由第三者对源码进行逐行检查
- 显然是白盒测试
第三章
软件测试过程
测试计划
- 测试过程中，测试计划描述用于描述测试的整体方案，缺陷报告描述依据测试用例找出的问题。
- 描述所要完成的测试工作，包括被测试项目的背景、目标、范围、方式、资源、进度安排、测试组织，以及测试有关的风险等方面
测试用例
- 测试用例是一组输入（运行提前条件）和为某特定的目标而生成的预期结果及与之相关的测试规程的一个特定集合。
- 测试用例是一个详细说明测试的输、期望输出和为一组测试项所准备的一组执行条件
V模型
- V模型：描述了软件基本的开发过程和测试行为，描述了不同测试阶段与开发过程各阶 段的对应关系。
- 优化V模型采用W模型
单元测试
- 单元测试是软件开发过程中最低级别的测试活动，以白盒测试为主
- 单元测试包括模块接口测试、模块局部数据结构测试、错误处理检测、路径测试、模块边界测试
- 单元测试能发现约80%的软件缺陷。
- 驱动模块：相当于被测模块的主程序
- 桩模块：相当于被测模块调用的子模块，用以模拟被测模块的下级模块
- Junit是一个用java开发的进行单元测试的半自动化测试工具，测试类继承TestCase，可以用Assert类中的相关方法来验证某个条件是否成立
集成测试
- 持续集成
- 非增式集成测试法：先测试单元，再按模式图连接起来测试整体
- 增式集成测试发：自底向上（编写驱动模块）、自顶向下（编写桩模块）
- 主要为了发现概要设计阶段的错误
确认测试
- 是对照软件需求规格说明，对软件产品进行评估以确定其是否满足软件需求的过程
系统测试
- 性能测试（使用LoadRunner）：性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。
- 功能测试：QTP
- 恢复测试
- 安全测试
- 强度测试
- 兼容测试
验收测试
- 验收测试是由最终用户和测试人员共同来实施的。
- α测试：软件开发公司组织内部人员模拟各类用户行为对即将面世的软件产品进行测试，试图发现错误并修正（可控）
- β测试：软件开发公司组织各方面的典型用户在日常生活实际使用β版本（不可控）
- tps = (24小时的PV值 * 80%) / (24 * 3600 *20%)
回归测试
- 指软件系统被修改或扩充后重新进行的测试，是为了保证对软件进行的修改没有引入新的错误而重复进行的测试
第四章
bug跟踪管理
测试管理
- 测试计划、缺陷状态、测试缺陷管理
- 测试需求主要是基于需求规格说明书进行定义，它包括定义功能测试需求和非功能测试需求。
- 测试是为了寻找软件的错误与缺陷，评估与提高软件的质量，则软件测试的原则包括：
- 问题的互相确认
- 所有的软件测试都应该追溯到用户需求
- 完全测试是不可能的，测试需要终止
- 充分注意测试中的群集现象
- 尽量避免测试的随意性
- 软件测试者应该坚持“尽早地和不断地进行软件测试”
- 程序员应避免检查自己的程序
- 为了使软件测试更加高效，应遵循的测试原则包括：
- 所有的软件测试都应道溯到用户需求、充分注意缺陷群集现象
- 尽早地和不断地进行软件测试回归测试
- 应由不同的测试人员对测试所发现的缺陷进行确认
- 增量测试，由小到大
测试计划
- 下列各项中测试策略不是一个测试计划所应包含的内容。
- 修复软件缺陷费用最高的是发布阶段。
- 程序流程图不属于测试文档
bug严重等级
- 危急的、重大的、严重的、阻碍的、重要的、常规的、轻微的、微不足道的
bug处理的优先等级
- 立即修复、马上修复、尽快修复、正常修复、考虑修复
缺陷生命周期
- 缺陷状态：bug初始状态、bug分配状态、bug重新分配状态、bug修复状态、bug验证状态、bug重新打开状态、bug关闭状态
第五章
软件自动化测试基本理论
优点
- 更方便回归测试
- 提高测试质量
- 提高测试效率，缩短测试时间
- 提高测试覆盖率
- 易于执行手工测试困难或不能完成的测试任务
- 更好的利用资源
- 更好的重现软件缺陷
- 提高软件测试的准确度和精确度，增加软件信任度
- 增进测试人员和开发人员之间的合作伙伴关系
- 运行更多更繁琐的测试
缺点
- 不能取代手工测试
- 发现故障的数量不及手工测试
- 不能提高测试的有效性
- 不具有想象力
- 可能会制约软件开发
动态的自动化测试
- 动态的自动化测试技术实现的原理是：通过特定的程序模拟测试人员对系统的操作过 程，将其转化为测试工具可以执行的脚本，然后对之进行优化和修改，加入检测点（或验证点），运行后将实际结果和预期结果进行自动对比分析，确定是否存在差异。
附：名词解释
容错性测试
- 容错性测试是主要检查系统的容错能力，检查软件在异常条件下自身是否具有防护性的措施或者某种灾难性恢复的手段。
容量测试
- 容量测试的目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），系统在其极限状态下没有出现任何软件故障或还能保持主要功能正常运行
压力测试
- 压力测试：通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。通俗地讲，压力测试是为了发现在什么条件下用户的应用程 序的性能会变得不可接受。（压力测试（强度测试）：压力测试是在强负载（大数据量、大量并发用户等）下的测试，查看应用系统在峰值使用情况下操作行为，从而有效地发现系统的某项功能隐患、系统是否具有良好的容错能力和可恢复能力。）
性能测试
- 性能测试，性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。
并发用户数
- “并发用户数”指的是同时向服务器端发出请求的客户数，体现的是服务端承受的最大并发访问数。
在线用户
- 在线用户，通过网络从客户端登录进服务器端建立连接过程的客户数。（可以不发生请求）
虚拟用户
- 虚拟用户，同一台物理机器（同一客户端）启动一个或多个在线用户去访问服务器
