目录
1、软件测试基础
1.1软件概述
1.1.1软件的生命周期
1.1.2 软件开发模型
1.1.3 软件质量概述
1.2 软件缺陷管理
1.2.1 软件缺陷产生的原因
1.2.2 软件缺陷的分类
1.2.3 软件缺陷的处理流程
1.3 软件测试概述
1.3.1 软件测试简介
1.3.2 软件测试的目的
1.3.3 软件测试的分类
1.4 软件测试与软件开发
1.4.1软件测试与软件开发的关系
1.4.2 常见的软件测试模型
1.5 软件测试的原则
1.6 软件测试的基本流程
2. 黑盒测试方法
2.1 等价类划分法
2.1.1 等价类划分法概述
2.1.2 三角形问题的等价类划分
2.2 边界值分析法
2.2.1 边界值分析法概述
2.2.2 三角形问题边界值分析
2.3 因果图与决策表法
2.3.1 因果图设计法
2.3.2 决策表（判定表）
2.3.3 三角形决策表
2.4 正交实验设计法
3. 白盒测试
3.1 逻辑覆盖法
3.1.1 语句覆盖
3.1.2 判定覆盖
3.1.3 条件覆盖
3.1.4 判定-条件覆盖
3.1.5 条件组合覆盖
3.2 程序插桩法
3.2.1 目标代码插桩
3.2.2 源代码插桩
4. 性能测试
4.1 性能测试
4.2 性能测试的指标
4.3 性能测试的种类
4.4 性能测试流程
4.5 性能测试工具
4.5.1 LoadRunner
4.5.2 JMeter
5. 自动化测试
5.1 自动化概述
5.1.1 什么是自动化概述
5.1.2 自动化测试的基本流程
5.1.3 自动化测试实施策略
5.1.4 自动化测试的优势和劣势
5.2 自动化测试常见技术
5.3 自动化测试常用工具
5.4 持续集成测试
5.4.1 持续集成的概念
5.4.2 持续集成测试框架设计
5.5 自动化测试脚本
5.5.1 页元素定位
5.5.2 具体定位操作
习题
习题1.
习题2.
习题3.
其他习题：
写在前面：要结课了整理了下笔记，祝逢考必过！
1、软件测试基础
1.1软件概述
1.1.1软件的生命周期
（1） 概念：软件从“出生”到“消亡”的过程，称为生命周期。
（2）阶段划分：
| 1 | 问题定义 | 主要确定软件的开发目的和可行性 |
| 2 | 需求分析 | 作用在整个软件的生命周期中，直接关系到后期的开发成功率。 |
| 3 | 软件设计 | 在需求分析结果的基础上，对整个软件系统进行设计 |
| 4 | 软件开发 | 选择语言开发，制定规范 |
| 5 | 软件测试 | 查找软件设计与软件开发过程中存在的问题并加以修正 |
| 6 | 软件维护 | 包括纠错性维护和改进型维护两方面，在软件生命周期中持续时间最长 |
1.1.2 软件开发模型
软件开发模型规定了软件开发遵循的步骤，是软件开发的导航图，能够清晰、直观地表达软件开发的全过程。
| 1 | 瀑布模型 |
（1）严格按照线性方式进行； （2）无法适应用户需求的变更，增加了开发风险； （3）要求每一个阶段必须有结果产出； |
| 2 | 快速原型模型 |
（1）根据用户需求快速搭建一个软件原型 （2）克服了需求不明带来的风险 （3）适用于不能预先确定需求的软件项目 （4）不利于开发人员对产品进行扩展 |
| 3 | 迭代模型 |
（1）以组件的形式交付给客户 （2）可以很好地适应用户需求的变更 （3）降低了软件开发成本与风险 （4）有集成失败的风险 （5）容易失去对软件开发过程的整体控制 |
| 4 | 螺旋模型 |
（1）引入了其他模型所忽略的风险分析 （2）有助于将软件质量作为特殊目标融入产品开发之中 （3）成本易控制，用户常参与，项目不偏离 |
| 5 | 敏捷模型 |
（1）以用户的需求进化为核心 （2）采用迭代、循序渐进的方法进行软件开发 （3）及时响应客户需求的变更，不断适应新趋势 （4）但人员较多，面对面的有效沟通困难 （5）适用于小型项目的开发 |
1.1.3 软件质量概述
1.软件质量的概念
软件质量是指软件产品满足基本需求及隐式需求的程度。可将软件质量分为三个层次：
（1）满足需求的规定
（2）满足用户需求
（3）满足用户隐式需求
2.软件质量模型
评价软件质量的国际标准ISO/IEC 9126:1991，由六个特性组成。分别为：功能性、可靠性、可使用性、效率、可维护性、可移植性。
3.影响软件质量的因素
（1）需求模糊
（2）软件开发缺乏规范性的指导
（3）软件开发人员问题
（4）缺乏软件质量控制管理
1.2 软件缺陷管理
1.2.1 软件缺陷产生的原因
1.从产品内部方面：缺陷是产品开发或维护过程中存在的错误、毛病等各种问题。
2.从产品外部方面：缺陷是系统运行过程中某种功能的失效或违背。
3.软件缺陷产生的原因主要有：
- 需求不明确
- 软件结构复杂
- 编码问题
- 项目期限短
- 使用新技术
1.2.2 软件缺陷的分类
1.2.3 软件缺陷的处理流程
1.3 软件测试概述
1.3.1 软件测试简介
软件测试定义：软件测试是使用人工或自动手段运行或测定某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清楚预期结果与实际结果之间的差异。
1.3.2 软件测试的目的
1.对软件开发来说：软件测试通过找到的问题缺陷帮助开发人员找到开发过程中存在的问题，预防下次缺陷的产生。
2.对于软件测试来说：使用最少的人力、物力、财力、时间找到软件中隐藏的缺陷，保证软件的质量，为以后软件测试积累经验。
3.对于客户需求来说：软件测试能够检测是否符合客户需求，对软件质量进行评估和度量，为客户评审软件提供有力的依据。
1.3.3 软件测试的分类
1.按照测试阶段分类
- 单元测试
- 冒烟测试
- 集成测试
- 系统测试
- 验收测试
2.按照测试技术分类
- 黑盒测试
- 白盒测试
3.按照软件质量特性分类
- 功能测试
- 性能测试
4.按照自动化程度分类
- 手工测试
- 自动化测试
5.按照测试类型分类
- 界面类测试
- 安全性测试
- 文档测试
1.4 软件测试与软件开发
1.4.1软件测试与软件开发的关系
1.软件测试在各个阶段的作用：
| 项目规划阶段 | 负责从单元测试到系统测试的整个测试阶段的监控 |
| 需求分析阶段 | 确定测试需求分析，同时制定系统测试计划 |
| 概要设计与详细设计阶段 | 制定单元测试计划和集成测试计划 |
| 编码阶段 | 开发相应的测试代码和测试脚本 |
| 测试阶段 | 实施测试并提交相应的测试 告 |
2.软件开发：自顶向下、逐步细化的过程。
3.软件测试：自底向上、逐步集成的过程。
1.4.2 常见的软件测试模型
1.V模型
描述了基本的开发过程与测试过程，主要反映了测试活动分析与设计之间的关系。
2.W模型
由V模型演变而来，强调测试应伴随整个软件生命周期，有利于尽早的发现问题。
3.H模型
测试级别不存在严格的次序关系，软件生命周期的各阶段的测试工作可以反复触发、迭代、，即不同的测试可以反复迭代的进行。
4.X模型
X模型的设计原理是将程序分成多个片段反复迭代测试，然后将多个片段集成再进行迭代测试。
1.5 软件测试的原则
- 测试应基于客户需求
- 测试要尽早进行
- 穷尽测试是不可能的
- 遵循GoodEnough原则（测试的投入与产出适当权衡）
- 测试缺陷要符合“二八”定理（缺陷不是平均分布的，80%缺陷会集中在20%的模块中）
- 避免缺陷免疫（定式思维所导致）
1.6 软件测试的基本流程
虽然不同软件的详细测试步骤不同，但它们所遵循的基本测试流程是一样的。
- 分析测试需求
- 制定测试计划
- 设计测试用例
- 执行测试
- 编写测试 告
2. 黑盒测试方法
2.1 等价类划分法
2.1.1 等价类划分法概述
一个程序可以有多个输入，等价类划分就是将这些输入数据按照输入需求进行分类，将他们划分为若干个子集，这些子集即为等价类。
1. 划分等价类
（1）有效等价类：有效值的集合，他们是符合程序的要求、合理且有意义的输入数据。
（2）无效等价类：无效值的集合，他们是不符合程序的要求，不合理或无意义的输入数据。
2.设计测试用例
基于等价类划分法的测试用例设计步骤如下：
- （1）确定测试对象，保证非测试对象的正确性；
- （2）为每个等价类规定一个唯一编 ；
- （3）设计有效等价类的测试用例，使其尽可能多的覆盖尚未覆盖的有效等价类；
- （4）设计无效等价类的测试用例，使其覆盖所有的无效等价类。
2.1.2 三角形问题的等价类划分
三角形输入等价类表
有效等价类的测试用例
无效等价类的测试用例
2.2 边界值分析法
2.2.1 边界值分析法概述
边界值分析法是对软件的输入或输出边界进行测试的一种方法，它通常作为等价类划分法的一种补充测试。
在等价类中选择边界值时，如果输入条件规定了取值范围的值或个数，则在选取边界值时可选取5个或7个测试值。若为5个测试值：最小值、略大于最小值、正常值、略小于最大值、最大值。若为7个：则是在5的基础上增加略小于最小值和略大于最大值。
边界值作为一种单独的软件测试方法，它只在边界取值上考虑测试的有效性，相对于其他等价类划分法来说，他的执行更加简单易行，但缺乏充分性，不能全面的测试软件，因此他只能作为等价类划分法的补充测试。
2.2.2 三角形问题边界值分析
三角形边界值分析测试用例
2.3 因果图与决策表法
描述多个输入之间的制约关系。
2.3.1 因果图设计法
因果图法是利用图解法分析各种组合情况的测试方法，它考虑了输入条件的各种组合及输出条件之间的相互制约关系，并考虑输出情况。
1.因果图
包含四种关系：恒等、非、或、与。
2.因果图法设计测试用例特点
（1）因果图法考虑了输入情况的各种组合以及各种输入情况之间的相互制约关系，可以帮助测试人员按照一定的步骤高效的开发测试用例。
（2）因果图是由自然语言规格说明转化成语言规格说明的一种严格方法，能够发现规格说明书中存在的不完整性和二义性，帮助开发人员完善产品的规格说明书。
2.3.2 决策表（判定表）
1.输入较多时，因果图比较复杂，因此往往使用决策表法替代因果图法。
2.它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确。利于决策表可以设计出完整的测试用例集合。
3.决策表通常由四部分组成：条件桩、条件项、动作桩、动作项。
2.3.3 三角形决策表
三角形决策表
三角形测试用例
2.4 正交实验设计法
正交实验设计法是指从大量的实验点中挑选出适量的、有代表性的点，依据Glois理论导出“正交表”，从而合理的安排实验的一种实验设计方法。
此法包含三个关键因素：
- 指标：判断实验优劣的标准；
- 因子：所有影响实验指标的条件；
- 因子的状态：指因子变量的取值；
3. 白盒测试
白盒测试又称为透明盒测试、结构测试，它基于程序内部结构进行测试，而不是测试应用程序的功能。
3.1 逻辑覆盖法
逻辑覆盖法是白盒测试最常用的测试方法，它包括语句覆盖、判定覆盖、条件覆盖、判定-条件覆盖5种。
3.1.1 语句覆盖
1.别称：行覆盖、段覆盖、基本块覆盖。
2.语句覆盖的目的是测试程序中的代码是否被执行，它只测试代码中的执行语句。
3.语句覆盖是弱覆盖方法。
3.1.2 判定覆盖
原则是设计足够多的测试用例，在测试的过程中保证每个判定至少有一次真值，有一次为假值。虽然判定语句覆盖比语句覆盖强，但仍然具有和语句覆盖一样的单一性。（弱覆盖）
3.1.3 条件覆盖
设计足够多的测试用例，使判定语句中的每个逻辑条件取真值与取假值至少出现一次。
3.1.4 判定-条件覆盖
要求设计足够多的测试用例，是的判定语句中所有条件的可能取值至少出现一次，同时，所有判定语句的可能结果也至少出现一次。
弥补了条件覆盖和判定覆盖的不足，但是由于判定-条件覆盖没有考虑判定语句与条件判断的组合情况，其覆盖范围并没有比条件覆盖更全面。仍存在遗漏的情况。
3.1.5 条件组合覆盖
设计足够多的测试用例，使判定语句中每个条件的所有可能至少出现一次，并且每个判定语句本身的判定结果也至少出现一次。
与判定-条件覆盖相比，条件组合覆盖包括了所有判定-条件覆盖，因此它的覆盖范围更广。但是当程序中条件比较多的时候，条件组合会呈指数级增长，这样反而测试效率会降低。
3.2 程序插桩法
程序插桩就是往被测程序中插入测试代码以达到测试目的的方法，插入的测试代码被称为探针。根据测试代码插入的时间可以将程序插桩法分为目标代码插桩和源代码插桩。
3.2.1 目标代码插桩
目标代码插桩是指向目标代码插入测试代码获取程序运行信息的测试方法，也称为动态程序分析方法。
相比于逻辑覆盖法，目标代码插桩在测试过程中不需要代码重新编译或链接程序，并且目标代码的格式和具体的编程语言无关，主要和操作系统相关，因此被广泛使用。
1.目标代码插桩的原理
原理：在程序运行平台和底层操作系统之间建立中间层，通过中间层检查执行程序、修改指令。
2.目标代码插桩法的执行模式
分为两种情况：
- （1）对未运行的目标代码插桩，从头到尾测试代码，然后执行程序。
- （2）向正在运行的程序插入测试代码，用来检测程序在特定时间的运行状态信息。
分为三种执行模式：
- （1）即时模式：原始的二进制或可执行文件没有被修改或执行，将修改部分的二进制代码生成文件副本存储在新的内存区域中，在测试时仅执行修改部分的目标代码。
- （2）解释模式：在解释模式中目标代码被视为数据，测试通过替代指令指令的执行信息就可以获取程序的运行信息。
- （3）探测模式：使用新指令覆盖旧指令进行测试。
3.由于目标程序是可执行的二进制文件，人工插入代码是无法实现的，因此目标代码插桩一般通过相应的插桩工具实现。
3.2.2 源代码插桩
1. 源代码插桩是指对源文件进行完整的词法、语法分析后，确定插桩的位置，植入探针代码。
2. 相比目标代码插桩：具有精确性和针对性。
3. 源代码插桩是在程序执行之前完成的，因此源代码插桩在程序运行过程中会产生探针代码的开销。
4.相比较目标代码插桩，源代码插桩实现复杂程度低，探针代码具有好的通用性（使用同一种语言编写的程序可以使用一个探针代码程序来完成测试）。
黑盒测试和白盒测试比较
| 测试种类 | 发现缺陷/适用情况 | 特点 |
| 黑盒测试 |
（1）外部逻辑功能缺陷 （2）兼容性错误 （3）性能问题 |
不用考虑内部逻辑结构，仅仅需要验证软件外部功能是否符合用户实际需求。 |
| 白盒测试 |
（1）源程序中含有多个分支 （2）内存泄漏检查迅速 |
可以设计用例尽可能覆盖程序中的分支语句，分析程序内部结构。 |
测试阶段
| 测试名称 | 测试对象 | 测试方法 |
| 单元测试 | 模块功能 | 白盒测试 |
| 集成测试 | 接口测试 | 黑盒测试和白盒测试 |
| 系统测试 | 系统测试 | 黑盒测试 |
| 验收测试 | 系统测试 | 黑盒测试 |
4. 性能测试
性能测试是度量软件质量的一种重要手段，他从响应速度、稳定性、兼容型、可移植性等方面检测软件是否满足用户需求。
4.1 性能测试
1.概述：使用性能测试工具模拟正常、峰值及异常负载状态，对系统的各项性能指标进行测试活动。
2.作用：验证软件是否达到了用户期望的性能需求，同时也可以发现系统中可能存在的瓶颈及缺陷，从而优化系统的性能。
3.目的：
（1）验证系统性能是否满足预期的性能需求；
（2）分析软件系统在各种负载水平下的运行转态，提高性能需求和效率；
（3）识别系统缺陷，寻找系统中可能存在的性能问题；
（4）系统调优，探测系统设计与资源之间的最佳平衡，改善并优化系统的性能。
4.2 性能测试的指标
性能测试常用的指标包括响应时间、吞吐量、并发用户数、TPS等。
1.响应时间
系统对用户请求做出响应所需要的时间。
2.吞吐量
单位时间内系统能完成的工作量，他衡量的是软件系统服务器的处理能力。
3.并发用户数
同一时间请求和访问的用户数量。
4.TPS
系统每秒钟能够处理的事务和交易的数量。
5.点击率
用户每秒向Web服务器提交的HTTP请求数，这个指标是Web应用特有的一个性能指标。
6.资源利用率
软件对系统系统资源的使用情况，是分析软件性能瓶颈的重要参数。
4.3 性能测试的种类
性能测试是一个统称，包含多种类型。主要有：
1.负载测试
逐步增加系统负载，测试系统性能的变化，并最终确定在满足系统性能指标的情况下，系统能够承受的最大负载量。
2.压力测试
逐步给系统增加压力，测试性能变化，使系统某些资源达到饱和或系统崩溃的边缘，从而测定系统所能承受的最大压力。
ps:负载测试与压力测试的区别
例如：软件系统正常的响应时间为2s,负载测试时确定访问量超过1万时响应时间变慢。
压力测试则继续增加用户的访问量，当用户增加到4万时，系统崩溃。
则可以确定，最大负载是1万人（开始影响性能），最大压力4万人（系统撑不住了）
3.并发测试
4.配置测试
5.可靠性测试
6.容量测试
4.4 性能测试流程
- 分析性能测试需求
- 制定性能测试计划
- 设计性能测试用例
- 编写性能测试脚本
- 测试执行及监控
- 运行结果分析
- 提交性能测试 告
4.5 性能测试工具
常用：LoadRunner和JMeter
4.5.1 LoadRunner
主要特点：
- 广泛支持业界标准协议
- 支持多平台开发的脚本
- 可创建真实的系统负载
- 具有强大的实时监控与数据采集功能
- 可以精确分析结果，定位软件问题
缺点：收费
组成部分：Virtual User Generator(简写VuGen)、Controller和Analysis。
作用：
1.VuGen
用于创建虚拟用户脚本的工具，因此也被称为虚拟用户脚本生成器。
2.Controller
用于创建和控制LoadRunner场景，场景负责定义每次测试中发生的事件。
3.Analysis
数据分析工具，可以收集测试中的各种数据，对其进行分析生成图表和 告供测试人员查看。
4.5.2 JMeter
优势：开源免费。
工作原理与LoadRunner类似，不同的是：JMeter通过线程创建虚拟用户。虚拟用户向服务器发送一个请求，JMeter称之为一次采样，这个操作由采样器完成。
JMter工具核心组件：
- 逻辑控制器
- 配置元件
- 前置处理器
- 定时器
- 采样器
- 后置处理器
- 断言
- 监听器
缺点： 表少、分析没有LoadRunner详细。
5. 自动化测试
5.1 自动化概述
5.1.1 什么是自动化概述
自动化测试，是把以人为驱动测试行为转化为机器执行的过程。实际上就是模拟手工测试过程。
实施自动化测试之前，需要对软件开发过程进行分析。需要满足的条件有：
- 项目需求变动不频繁
- 项目周期足够
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！