软件测试的分类
1、按测试阶段划分：单元、集成、系统、验收（Alpha、Beta、正式）
2、按测试技术划分：黑盒：看不到程序的逻辑与走向，在测试过程中只关注输入输出，也叫数据驱动测试
白盒：基于软件内部设计和程序实现的测试方法。不仅关注输入输出的结果，还关注程序是如何处理的。
灰盒：介于白盒和黑盒之间的一种测试，例如接口测试。
3、按被测试对象是否运行划分：静态、动态
4、按不同的测试手段划分：手动、自动
5、按测试包含的内容划分：
功能测试：测试软件功能是否符合需求。
界面测试：UI测试，测试系统用户界面是否合理，整体风格是否一致，界面文字是否正确，图片美观等等。
性能测试：为获取或验证系统性能指标而进行的测试，会在不同负载情况下进行。
安全性测试：测试该系统防止非法入侵的能力。
负载测试：通过改变系统负载方式、增加负载等来发现系统中存在的性能问题。体现一种方法和一种技术。
兼容性测试：测试该系统与其他软硬件兼容能力（app，c/s架构软件、b/s架构软件）。
压力测试（强度测试）：主要为了确定系统稳定性
1、高负载下长时间 的稳定性压力测试；
2、极限负载情况下导致系统崩溃的破坏性压力测试。
恢复测试：检查系统的容错能力。
易用测试：软件测试是否易用，主观性较强。
6、其他测试：
冒烟测试：对象是每一个新编译的需要正式测试的软件版本，确认基本功能正常，可继续后续正式测试工作。
回归测试：指错误被修正后或软件功能、环境发生变化后进行的重新测试，确认修改部分不会对其他功能造成影响。
探索性测试
软件质量
软件质量包括正确性，可靠性，可读性，可移植性和健壮性，主要含义是软件的可靠性软件可靠性
特定环境下，在给定时间内，无障碍运行的概率度量
软件中初始故障的数量
软件经过测试后，通过查错，改错，在软件中剩余故障的数量
平均无故障时间
故障间隔的时间长度
故障发生率
经过预测下次故障的发生时间软件故障
定义
从内部看，软件故障是软件产品开发或维护过程中存在的错误，毛病等各种问题
从外部看，软件故障是系统所需要实现的某种功能的失效或违背
计算机系统或程序存在任何一种破坏正常运行能力的问题，错误，或者隐藏的功能缺陷等
软件故障导致软件产品在某种程度上不能满足用户的需求
硬件故障
物理性能恶化
软件故障
设计阶段人为因素造成的
操作故障
操作人员和维护人员的错误
环境故障
电源，外界干扰，地震，火灾，病毒等各种外界因素引起的故障
错误
人是会犯错的。过失是人犯下的，是人做一件错事或认为产生的一个不正确的结果
故障
故障时错误的结果
失效
故障引起的结果
软件测试与软件可靠性
软件中都会有故障存在
可以减少故障的引入，但是不可能完全杜绝软件中的故障软件测试
软件需求分析，设计说明和编码的最终复审
是软件质量保证的关键步骤 是为了发现故障而执行程序的过程
定义：
- 是否满足规定的需求
- 是否有差别
测试是为了发现故障而执行程序的过程
谁来执行
测试什么
什么时候测试
怎样进行测试
测试停止的标准
成功采用了具体的测试用例设计方法
每一类覆盖的覆盖率
故障检测率
检测出故障的具体数量或消耗的具体时间软件生存周期
制定计划
需求分析
设计
程序编码
测试
运行维护
测试原则
黑盒测试与白盒测试
黑盒测试
等价类划分
边界值分析
决策表驱动
白盒测试
逻辑覆盖
数据流测试
域测试
符号测试
路径分析
程序变异
程序插装技术
软件测试过程
软件开发是自顶向下，软件测试自底向上
单元测试
又称模块测试，针对程序模块来进行正确性检验的测试工作
模块接口测试
局部数据结构测试
路径测试
错误处理测试
边界测试
静态测试与动态测试
静态测试
不利用计算机运行被测试的程序，通过其他手段达到检测的目的
动态测试
通过运行和使用被测程序，发现软件故障，达到检测目的
回归测试
对程序进行测试已确定是否因修复故障而引入了新的故障
α\alphaα测试
由一个用户在开发环境下进行的测试
目的是平价产品的功能，可使用性，可靠性，性能和支持
β\betaβ测试
软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场
α\alphaα测试达到一定的可靠程度时才能进行β\betaβ测试，它处在整个测试的最后阶段
测试与调试
调试不属于测试
成功的测试发现错误从而引起调试的进行
测试生命周期
测试计划
测试设计
测试开发
测试执行
测试评估
测试工具
测试评估
测试覆盖测试
软件故障评估
测试有效性评估
软件质量评估
检查和评价当前软件开发过程,并设法达到防止软件故障出现
软件过程成熟度
- 初始度
- 可重复级
- 定义明确
- 定量管理级
- 优化级
结构性测试
特点
基于被测试程序的源代码,而不是软件规格说明
更容易发现软件测试故障,常用于单元测试
结构性测试
白盒测试又称结构测试或者基于程序的测试.
该方法将被测对象看做一个打开的盒子,允许内部人员检查其内部结构.测试人员根据程序内部结构特性,设计,选择测试用例,检查程序的每条路径是否都按照预定的要求正确执行.
常见的白盒测试方法有:
逻辑覆盖
数据流测试
域测试
符号测试
路径分析
程序变异
程序插装
逻辑覆盖
使用最广泛
要求对被测试程序逻辑结构有清楚的了解,要能掌握程序的所有细节
要求对被测试程序的结构做到一定程度的覆盖
分为:
语义覆盖
是比较弱的测试覆盖准则
判定覆盖
又称之为分支覆盖,使得每个判断的取真分支和取假分支至少执行一次,即判断的真假值均要被检测
条件覆盖
每个判断的每个条件的可能取值至少被执行一次
判定-条件覆盖
判断中的每个条件的所有可能取值至少执行一次,同时每个判断的所有可能判断结果也至少被执行一次
路径覆盖
程序控制图
重要性
明确地描述测试用例和测试用例所执行的程序部分之间的关系.
McCabe的基本路径法
测试观点
强连通图的圈数就是图中线性独立环路的数目
- 选择一条基线路径,一般选择有较多判断结点的路径
- 回溯基线路径
符号测试
基本思想
允许程序的输入不仅可以是具体的数值数据,而且还可以包括符号值.
执行过程中以符号计算代替了普通执行中的数值计算,所得到的结果自然是符号公式或符号谓词
普通测试执行的事算数运算,符号测试执行的是代数计算程序插装
借助于往被测试程序中插入操作来实现测试目的的方法
考虑的方面
探测哪些信息
在程序的什么部位设置探测点
需要设置多少个探测点用途
- 覆盖分析
- 监控和断言
- 查找数据流异常
指导方针
基本原则
具有高圈复杂度的程序需要更充分的测试
一般选择V(G)=10
如果单元具有更高的复杂度,可以简化单元或计划更充分的测试
简化单元的最好方法是解决非结构化的问题覆盖指标
- 作为一种强制执行的标准
- 作为一种机制,指导要求更严格部分的代码有选择地进行测试
数据流测试
数据流是指关注定义点和使用(或引用)点的一种结构测试方法,它和数据流图没有什么联系.
实际上很多数据流测试支持者和研究人员将这种测试方法看作是一种路径测试.
通过分析变量的定义和使用,以查找如引用未定义变量等程序错误,也可以用来查找对以前未曾使用的变量的再次赋值等数据流异常的情况
早期数据流分析常常集中于现在叫定义/引用异常的缺陷:
变量被定义但是从来没有被使用
所使用的变量没有被定义
变量在使用之前被定义了两次
这些异常可以通过程序的索引表发现,可以通过所谓的静态分析发现
将程序中的变量出现分为定义和引用
语句K执行时改变了程序变量V的值,则称K定义了变量V
若语句k执行时引用了变量V的值,则称K引用了变量V定义/使用测试
假设V是程序P中的变量的集合,程序P控制流程图用G(P)表示,其中结点代表语句或语句片段,边代表结点序列.G(P)有一个单入口节点和一个单出口节点,并且不允许有某个结点到自身的边
变量V的定义结点,记作DEF(v,n)
结点n∈\in∈ G(P)是变量v∈\in∈V定义的结点,当且仅当变量V的值由对应结点n的语句或语句片段所定义.
变量v的使用结点n记作USE(v,n)
结点n∈\in∈ G(P)是变量v∈\in∈V的使用结点,当且仅当变量v的值在对应结点n的语句或语句片段中被引用.
谓词使用,记作P-use
USE(v,n)是一个谓词使用,当且仅当n是谓词语句,否则,USE(v,n)是计算使用,记作C-use.
定义/使用路径,记作du-path
如果对某个变量v∈\in∈V,存在一个定义,使用结点对,即DEF(v,m)和USE(v,n),使得变量v在结点m处被定义,在结点n处被使用,则称为一条定义/使用路径,结点m称为该定义使用路径的开始结点,而结点n则称为该定义/使用路径的结束结点.
定义清晰路径(defination-clear path),记作dc-path
如果一个变量v∈\in∈V,存在一个定义,使用结点对,即DEF(v,m)和USE(v,n),使得变量v在结点m处被定义,在结点n处被使用,并且从m到n的结点序列中没有其他结点对对变量v进行过定义,则从m到n的结点序列称为一条定义清晰路径,结点m称为该定义/使用路径的开始结点,而结点n则称为该定义/使用路径的结束结点.
定义/使用路径和定义清晰路径描述了变量从被定义到被引用点数据流向.
不是定义清晰的定义/使用路径,很可能是潜在问题的所在.所以应该特别关注定义/使用路径定义/使用路径覆盖测试
数据流覆盖测试指标
P是被测程序,G(P)是其控制流图,T是G(P)的路径集合,并假设定义/使用路径都是可执行路径
所有定义/使用路径覆盖准则
集合T满足程序P的所有定义/使用路径覆盖准则,当且仅当对所有的变量v∈\in∈V,T包含了从v的每个定义结点到v所有使用结点的定义清晰路径.
所有定义覆盖准则
集合T满足程序P所有定义覆盖准则,当且仅当对所有的变量v∈\in∈V,T包含了从变量v的每个定义结点到v的一个使用结点的定义清晰路径.
所有使用覆盖准则
集合T满足程序P的所有使用覆盖准则,当且仅当对所有的变量v∈\in∈V,T包含了从v的每个定义结点到v的所有使用结点的定义清晰路径
所有谓词使用/部分计算使用覆盖准则
集合T满足程序P的所有谓词使用/部分计算使用覆盖准则,当且仅当对所有的变量v∈\in∈V,T包含了从v的每个定义结点到v的所有谓词使用结点的定义清晰路径,并且如果v的一个定义没有谓词使用结点,则定义清晰路径至少包含一个计算使用
所有计算使用/部分谓词使用覆盖准则
集合T满足程序P的所有计算使用/部分谓词使用覆盖准则,当且仅当对所有的变量v∈\in∈V,T包含了从每个定义结点v的所有计算使用结点的定义清晰路径,并且如果v的一个定义没有使用计算节点,则定义清晰路径至少包含一个谓词使用.
测试和质量的关系
修复软件缺陷的代价：
假设在需求分析阶段修复软件缺陷的代价为“单位1”。
设计阶段：3～6倍。
编程阶段：10倍。
内部测试阶段：20～40倍。
外部测试阶段：30～70倍。
产品发布后：40～1000倍。
修正错误的代价不是随时间线性增长，而几乎是呈指数增长的。
软件测试结束的标准：
用例全部测试；
覆盖率达到标准；
缺陷率达到标准；
其他指标达到标准。
软件测试的工作范围
1、软件测试工作的组织与管理：制定测试策略、测试计划，确认所采用的测试方法与规范，控制测试进度，管理测试资源。
2、测试工作的实施：编制符合标准的测试文档，搭建测试环境，开发测试脚本、与开发组织协作实现各阶段的测试活动。
软件质量与软件缺陷
软件质量：
软件产品满足使用要求的程度。
白盒测试黑盒测试
白盒测试也称结构测试或逻辑驱动测试，它是按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作。
黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。
测试用例
测试用例：
为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。
设计测试用例的原因：
测试用例构成了设计和制定测试过程的基础。
测试的“深度”与测试用例的数量成比例。由于每个测试用例反映不同的场景、条件或经由产品的事件流，因而，随着测试用例数量的增加，对产品质量和测试流程也就越有信心。判断测试是否完全的一个主要评测方法是基于需求的覆盖，而这又是以确定、实施和/或执行的测试用例的数量为依据的。
测试工作量与测试用例的数量成比例。根据全面且细化的测试用例，可以更准确地估计测试周期各连续阶段的时间安排。
测试设计和开发的类型以及所需的资源主要都受控于测试用例。
测试用例通常根据它们所关联关系的测试类型或测试需求来分类，而且将随类型和需求进行相应地改变。最佳方案是为每个测试需求至少编制两个测试用例：一个测试用例用于证明该需求已经满足，通常称作正面测试用例；另一个测试用例反映某个无法接受、反常或意外的条件或数据，用于论证只有在所需条件下才能够满足该需求，这个测试用例称作负面测试用例。
测试用例是软件测试的核心。
4.1 W模型
4.2 五大流派
1、分析学派：
分析学派认为软件测试是严格的技术性的，这一派在学术界有很多支持者。
2、标准学派：
标准学派认为软件测试是用于衡量进度的一种方式，强调成本度量和可重复的标准。
3、质量学派：
质量学派强调过程，软件测试人员像警察一样审判开发人员，又像守门员一样保证质量。
4、上下文驱动学派：
上下文驱动学派强调软件测试人的作用，寻找利益相关的BUG。
5、敏捷学派：
敏捷学派使用软件测试来验证开发是否完成，强调自动化。
单元测试
单元测试是对软件基本组成单元（如函数、类的方法等）进行的测试。
单元测试是对软件基本组成单元进行的测试。
单元测试的时机：
一般在代码完成后由开发人员完成，QA（质量保证）人员辅助。
单元测试相关概念：模块, 组件, 单元。
单元测试的测试人员：程序人员和开发人员。
单元测试的测试依据：详细设计说明书、概要设计说明书。
单元测试测试的不仅仅是代码，还有：接口测试、局部数据结构测试、独立路径测试、独立路径测试、边界条件测试、错误处理测试、功能测试、性能测试、内存使用测试等。
单元测试的主要目标：
测试单元模块是否被正确编码，具体表现为：
1、信息能否正确地流入和流出单元；
2、在单元工作过程中，其内部数据能否保持其完整性，包括内部数据的形式、内容及相互关系不发生错误，也包括全局变量在单元中的处理和影响。
3、在为限制数据加工而设置的边界处，能否正确工作。
4、单元的运行能否做到满足特定的逻辑覆盖。
5、单元中发生了错误，其中的出错处理措施是否有效。
驱动程序和桩程序
驱动程序：
对底层或子层模块进行测试所编写的，调用这些模块的程序。
桩程序：
对顶层或上层模块进行测试时所编写的，替代下层模块的程序。
集成测试
集成测试是将软件集成起来，对模块之间的接口进行测试。 集成测试又叫子系统测试、组装测试、部件测试等。
1、模块内的集成，主要是测试模块内各个接口间的交互集成关系；
2、子系统内的集成，测试子系统内各个模块间的交互关系；
3、系统内的集成，测试系统内各个子系统和模块间的集成关系。
集成测试的测试人员：有经验的测试人员和开发者共同进行测试。
非渐增式测试模式：
先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序，如大棒模式。
渐增式测试模式：
把下一个要测试的模块同已经测试好的模块结合进来进行测试，测试完后再把下一个应该测试的模块结合起来测试。
渐增式测试又可以根据每次添加模块的路线分为自顶向下测试、自底向上测试和混合测试（三明治集成方法）等方式。
系统测试
系统测试（特征测试）：
检验系统所有元素之间协作是否合适，整个系统的性能和功能是否达到要求。
系统测试的测试内容：功能测试，非功能测试与回归测试。
非功能性测试（特征测试）包含的内容：
性能测试，压力测试，容量测试，安全性测试，可靠性测试，容错性测试。
系统测试的测试依据：
需求说明书，概要设计说明书，详细设计说明书，最重要的是需求说明书。
性能测试
性能测试（performance test）就是为了发现系统性能问题或获取系统性能相关指标而进行的测试。一般在真实环境、特定负载条件下，通过工具模拟实际软件系统的运行及其操作，同时监控性能各项指标，最后对测试结果进行分析来确定系统的性能状况。
验收测试：
检查软件是否符合合同要求，包括需求规格说明、设计规格说明和用户手册等。
验收测试的测试人员：用户和测试部门共同完成。
验收测试的测试依据 ：
国家规范，行业标准，合同条款，用户确认的SRS。
α，β测试
α测试是指软件开发公司组织内部人员模拟各类用户行对即将面市软件产品（称为α版本）进行测试，试图发现错误并修正。
经过α测试调整的软件产品称为β版本。紧随其后的β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况、提出批评意见。然后软件开发公司再对β版本进行改错和完善。
自动化测试
自动化测试是相对手工测试而存在的一个概念，由手工逐个地运行测试用例的操作过程被测试工具自动执行的过程所代替。
