软件测试复习
软件测试目的：发现软件中的缺陷和错误。
-
软件缺陷
至少满足以下5个规则之一，才称为发生一个软件缺陷：
1.软件未实现产品说明书要求的功能——功能缺失
2.软件出现了产品说明书指明不应该出现的错误——错误、缺陷
3.
软件产品规格说明书为什么是软件缺陷存在最多的地方？
-
原因：
-
软件产品还没有设计、开发、完全靠想象去描述系统的实现结果，所以有些特性还不够清晰
-
需求不断变换
-
对规格说明书不够重视
-
沟通不充分
-
软件测试根本目的：提高软件质量，降低软件风险
软件风险分为内部风险和外部风险。
内部风险：如在即将销售发现重大错误，延迟发布，失去市场机会
外部风险：产品上线后，用户发现问题，引起索赔、产生法律纠纷、客户拒绝支付费用、甚至失去客户的风险
软件测试关键：如何合理地设计测试用例
测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果
软件测试不等于程序测试
回归测试：黑盒、白盒
冒烟测试：单元、集成、系统、验收
随机测试：功能、性能
黑盒测试：完全不考虑程序内部结构和内部特性的情况下进行。只要进行一些输入，就能得到某种输出结果。
静态测试
-
特点：
-
不必运行程序
-
无需条件，易展开
-
-
方法：
-
代码审查（与设计的一致性、标准、可读性，表达式逻辑、结构合理性）
-
代码检查（与审查类似，但不如审查检查范围广）
-
桌面检查（阅读自己程序，效率低）
-
静态分析（借助于测试工具）
-
数据流、控制流、接口分析、表达式分析
-
动态测试
-
特点
-
要求在代码实现的前提下进行
-
运行被测试的程
-
要进行测试数据准备
-
-
方法
-
白盒测试
-
黑盒测试
-
灰盒测试
-
软件测试原则：
-
尽早和及时的测试
-
准备好测试数据和预期结果
-
输入数据包括合理输入条件和不合理输入条件
软件需求验证
需求验证
需求验证概述
-
需求验证是软件需求的最后一个环节。
-
目标：尽可能发现存在的错误。
-
主要手段：需求评审
-
需求验证是专指在需求规格说明完成之后，对需求规格说明文档进行的验证活动。
需求验证方法
需求验证的主要方法是评审。
黑盒测试
测试用例是为特定的目的而设计的一组测试输入、执行条件和预期的结果。测试用例是执行的最小实体。
测试用例设计要素：
-
用例ID
-
用例概述：对该用例设计的目的进行描述
-
用例优先级
-
前置条件（可选）：用例必须满足的前提条件
-
操作步骤
-
测试数据
-
预期结果
-
备注（可选）
-
BUG-ID
测试用例评审
-
目的：确保用例更全面、结构更清晰、提高用例质量
-
评审时间：用例初步设计之后、全部用例完成之后
黑盒测试目的
-
检查程序功能能否按需求规格说明书的规定正常使用，测试各个功能是否有遗漏，检测性能等特性要求是否满足。
-
检测人机交互是否错误，检测数据结构或外部数据库访问是否错误，程序是否能适当地接收输入数据而产生正确的输出结果，并保持外部信息（如数据库或文件）的完整
-
检测程序初始化和终止方面的错误。
优点：
-
有针对性地寻找问题，并且定位问题更准确。
-
黑盒测试可以证明产品是否达到用户要求的功能，符合用户的工作要求。
-
能重复执行相同的动作，测试工作中最枯燥的部分可交由机器完成。
缺点：
-
需要充分了解产品用到的技术，测试人员需要具有较多经验。
-
在测试过程中很多是手工测试操作。
-
测试人员要负责大量文档、报表的编制和整理工作。
静态黑盒测试：文档测试
动态黑盒测试：功能测试、验收测试、性能测试
黑盒测试方法：PPT03
-
等价类划分法
划分等价类：寻找输入条件、划分为多个等价类、形成互不相交子集
例：
边界值分析
边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界
边界值分析法利用输入变量的最小值、略大于最小值、输入值域内的任意值、略小于最大值和最大值来设计测试用例
例：
等价类划分：
边界值分析：
判定表测试
在所有的黑盒测试方法中，基于判定表的测试是最为严格、最具有逻辑性的测试方法。
判定表由4部分组成，即条件桩、动作桩、条件项、动作项，及规则。
-
条件桩：条件
-
动作桩：问题规定可能采取的操作
-
条件项：条件下的取值
-
动作项：条件下采取的操作
-
规则：判定表中贯穿条件项和动作项的一列就是一条规则。
有n个条件的判定表有2的n次方个规则
例：
因果图
定义：利用图解法分析输入的各种组合情况，从而设计测试用例的方法
因果图中的4种基本关系
在因果图的基本符号中，图中的左结点ci表示输入状态（或称原因），右结点ei表示输出状态（或称结果）。ci 与 ei 取值0或1，0表示某状态不出现，1则表示某状态出现。
-
恒等：若 c1 是1，则 e1 也为1，否则 e1 为0
-
非：若 c1 是1，则 e1 为0，否则e1为1
-
或：若 c1 或 c2 或 c3 是1，则 e1 为1，否则 e1 为0
-
与：若 c1 和 c2 都是1，则 e1 为1，否则 e1 为0
因果图中的约束
在实际问题中输入状态相互之间、输出状态相互之间可能存在某些依赖关系，称为“约束”。对于输入条件的约束有E、I、O、R四种约束，对于输出条件的约束只有M约束。
-
E约束(互斥)：原因a和原因b中最多有一个可能成立，即a和b不会同时成立。
-
I约束(包含)：a、b、c这三个原因中至少有一个必须成立。
-
O约束(唯一)：原因a和b有且仅有一个成立。
-
R约束(要求)：原因a出现时，原因b也必须出现。
-
M约束(强制)：若结果a为1，则结果b强制为0。当a为0，b的值不确定
案例：
错误推测法
定义：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据他们选择测试用例。
正交试验法
-
指标：通常把判断试验结果优劣的标准叫做试验的指标
-
因子：影响实验指标的条件称为因子
-
因子的状态：影响实验因子的条件
案例：
场景法
案例：
白盒测试
基本路径测试
根据程序的控制流图找出一个模块所需测试的基本路径，根据这些基本路径设计构造相应的测试用例。
设计步骤：
-
根据模块逻辑构造控制流图（如上图）
-
计算控制流图的环复杂度
-
列出包含起始节点和终止节点的基本路径
-
检查一下列出的基本路径数目是否超过控制流图的环复杂度
-
设计覆盖这些基本路径的测试用例
环复杂度：用V(G)表示，用来衡量一个模块判定结构的复杂程度，在数量上表现为独立的路径条数，是需要测试的基本路径数目的上限
-
计算公式：
-
V(G) =闭合区域的数目
-
V(G) =边的数目-节点的数目 + 2
-
案例：
采用白盒测试方法必须遵循以下几条原则，才能达到测试的目的：
-
保证一个模块中的所有独立路径至少被测试一次。
-
所有逻辑值均需测试真 (true) 和假 (false) 两种情况。
-
检查程序的内部数据结构，保证其结构的有效性。
-
在上下边界及可操作范围内运行所有循环。
白盒测试——覆盖测试
测试覆盖率
测试覆盖率：用于确定测试所执行到的覆盖项的百分比。其中的覆盖项是指作为测试基础的一个入口或属性，比如语句、分支、条件等。
覆盖率=至少被执行一次的item数/item的总数
$$
一个程序总代码为100行，使用测试用例运行一次，执行了75行代码，则代码覆盖率＝75％
测试覆盖率包括功能点覆盖率和结构覆盖率。
-
功能点覆盖率：用于表示软件已经实现的功能与软件需要实现的功能之间的比例关系。
-
结构覆盖率包括语句覆盖率、分支覆盖率、循环覆盖率、路径覆盖率等等。
逻辑覆盖法
根据覆盖目标的不同，逻辑覆盖又可分为语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、组合覆盖和路径覆盖。
-
语句覆盖：选择足够多的测试用例，使得程序中的每个可执行语句至少执行一次。
-
判定覆盖：通过执行足够的测试用例，使得程序中的每个判定至少都获得一次“真”值和“假”值， 也就是使程序中的每个取“真”分支和取“假”分支至少均经历一次，也称为“分支覆盖”。
-
条件覆盖：设计足够多的测试用例，使得程序中每个判定包含的每个条件的可能取值（真/假）都至少满足一次。
-
判定/条件覆盖：设计足够多的测试用例，使得程序中每个判定包含的每个条件的所有情况（真/假）至少出现一次，并且每个判定本身的判定结果（真/假）也至少出现一次。
满足判定/条件覆盖的测试用例一定同时满足判定覆盖和条件覆盖。
-
组合覆盖：通过执行足够的测试用例，使得程序中每个判定的所有可能的条件取值组合都至少出现一次。
满足组合覆盖的测试用例一定满足判定覆盖、条件覆盖和判定/条件覆盖。
-
路径覆盖：设计足够多的测试用例，要求覆盖程序中所有可能的路径。
语句覆盖
优点：直观、简单，易自动化
缺点：发现错误能力很弱
判定覆盖
优点：发现错误能力比语句覆盖强
缺点：对复合条件判断，只判定整个最终结果，而忽略每个条件的取值情况，必然会遗漏部分测试路径。
条件覆盖
优点：发现错误的能力比语句覆盖强
缺点：条件覆盖不能保证判定覆盖，对复合条件，条件覆盖只能保证每个条件至少有一次为真，而不考虑所有的判定结果。
判定条件覆盖
判定条件覆盖率=条件操作数值或判定结果至少被评价一次的数量/（条件操作数值总数+判定结果总数）
$$
组合覆盖
组合覆盖率=条件操作数值结果组合的数量/条件操作数值总组合数
$$
路径覆盖
根据路径覆盖的基本思想，在满足组合覆盖的测试用例中修改其中一个测试用例，则可以实现路径覆盖。
满足路径覆盖的测试用例并不一定满足组合覆盖
逻辑覆盖并不能真正做到无遗漏。
数据流测试
如果程序中某一语句i的执行能改变某程序变量V的值，则称V被语句i定义,可记作Def（V，i）。
如果某一语句j的执行引用了内存中变量V的值，则称变量V被语句j使用，可记作Use（V，j）。
案例：
给一个变量赋值时才算该变量被定义
最少测试用例数
小结
常用的白盒测试方法包括基本路径测试、分支-条件测试和循环测试。
覆盖准则可以作为测试停止或/和选取测试数据的标准。
基于控制流的覆盖准则是被工业界广泛采用的覆盖标准之一。按照覆盖率从低到高的顺序，基于控制流的覆盖准则包括语句覆盖、分支覆盖、条件覆盖、分支-条件覆盖和多条件覆盖。
单元测试
定义：是对软件基本组成单元进行的测试。是检验程序最小单位，即检查模块有无错误， 它是在编码完成后必须进行的测试工作。
目的：验证这段代码的行为是否与我们期望的一致。
步骤：编译运行程序（查看能否正确运行）→静态测试（检查代码是否符合规范）→动态测试（深入检查代码的正确性，容错性和边界值等）
单元测试通过准则
（1）功能与设计说明一致；
（2）性能达到软件设计指标；
（3）命名和编码符合规则；
（4）逻辑测试达到规定的覆盖率，若达不到规定指标，应在测试报告中给出合理解释；
（5）对发现的问题已进行修改并通过回归测试。
单元测试主要任务
单元测试针对每个程序的模块，主要测试如下5方面： 模块接口、局部数据结构、边界条件、路径测试和错误处理。
模块接口：
-
对模块接口进行测试，检查进出程序单元的数据流是否正确。须在其它测试之前进行。
主要关注单元中的输入和输出。
局部数据结构：
-
测试模块内部的数据能否保持完整性，包括内部数据的内容、形式及相互关系不发生错误。
路径测试：针对程序路径进行测试
边界条件：边界值分析法进行测试
出错处理：模块在工作中发生错误时，出错处理设施是否有效。
单元测试执行过程
-
驱动模块：模拟被测试模块的上一级模块，相当于被测模块的主程序。
-
桩模块：模拟被测模块工作过程中所调用的模块。它们一般只进行很少的数据处理。
-
驱动模块、桩模块——案例
集成测试
定义：集成测试又称组装测试，是在单元测试的基础上，将所有模块按照设计要求组装成 子系统或系统进行的测试活动。又称子系统测试、联合测试。
目的：确保各单元组合在一起后能够按既定意图协作运行，并确保增量的行为正确，所测试的内容包括单元间的接口以及集成后的功能。
集成测试需要考虑的问题：
-
在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；
-
各个子功能组合起来，能否达到预期要求的父功能；
-
一个模块的功能是否会对另一个模块的功能产生不利的影响；
-
全局数据结构是否有问题
-
单个模块的误差积累起来，是否会放大，从而达到不可接受的程度。
集成测试的层次：
-
模块内集成测试。
-
子系统内集成测试：先测试子系统内的功能模块，然后将各个功能模块组合起来确认子系统的功能是否达到预期要求。
-
子系统间集成测试：测试的单元是子系统之间的接口。子系统是可单独运行的程序或进程。
集成测试方法
-
静态测试技术——针对概要设计的测试
-
动态测试技术——灰盒测试
灰盒测试的优点：
-
能够进行基于需求的测试和基于路径的覆盖测试。
-
可深入被测对象的内部，便于错误的识别分析和解决。
-
能够保证设计的黑盒测试用例的完整性，防止功能或功能组合的遗漏。
-
能够减小需求或设计不详细或不完整性对测试有效性造成影响。
集成策略：
-
非增量式集成策略：一步到位（适合小系统）
-
优点：①方法简单 ②允许多测试人员同时并行工作，人力物力资源利用率较高。
-
缺点：①必须为每个模块准备相应的驱动模块和桩模块，测试成本较高 ②一旦集成后包含多种错误，难以纠正。
在非增量式集成测试时，应当确定关键模块，对这些关键模块及早进行测试。
-
-
增量式集成策略：逐步实现
分类：
自顶向下增量式测试
-
深度优先方式：首先集成在结构中的一个主控路径下的所有模块，主控路径的选择是任意的。
-
广度优先方式：首先沿着水平方向，把每一层中所有直接隶属于上一层的模块集成起来，直到底层。
-
优点：
-
较早地验证了主要控制和判断点；
-
功能较早证实；
-
只需一个驱动；
-
支持故障隔离；
-
-
缺点：
-
桩的开发量大；
-
底层验证被推迟；
-
底层组件测试不充分；
-
自底向上增量式测试
-
优点：
-
对底层组件行为较早验证；
-
工作最初可以并行集成；
-
减少了桩的工作量；
-
能较好锁定软件故障所在位置；
-
-
缺点：
-
驱动的开发工作量大；
-
对高层的验证被推迟，设计上的错误不能被及时发现；
-
三明治增量式测试（混合增量式测试）
-
优点：集合了自顶向下和自底向上两种策略的优点
-
缺点：中间层测试不充分
-
案例1：
-
-
案例2
-
案例3
集成策略框图
系统测试
测试方法：黑盒测试
目的：发现软件与系统定义不符合或与之矛盾的地方，测试用例应根据需求分析说明书来设计，并在实际使用环境下运行
对象：项目级→软件（也可能包含硬件） 产品级→软件+硬件
系统测试的层次：
-
用户层测试
-
用户支持测试
-
用户界面测试
-
安全性测试
-
可维护测试
-
-
应用层测试
-
系统性能
-
系统可靠性、稳定性
-
版本兼容性
-
系统安装升级
-
-
功能层测试
-
指标/协议层测试
功能测试
定义：功能测试是系统测试中最基本的测试。
分类：
-
逻辑功能测试
-
界面测试
-
易用性测试
-
安装测试
-
兼容性测试
性能测试
定义：保证系统发布后，产品的性能满足用户要求。
软件性能指标
-
响应时间
-
并发用户数
-
吞吐量
-
资源占用率
分类：
-
一般性能测试：被测系统在正常的软硬件环境下运行，不向其施加任何压力的性能测试。
-
稳定性能测测：连续运行被测系统，检查系统运行时的稳定程度
-
负载测试：让被测系统在其能忍受的压力的极限范围之内连续运行，来测试系统的稳定性。
-
压力测试：通常持续不断地给被测系统增加压力，直到被测系统压垮为止，来测试系统所能承受的最大压力。
验收测试
目的：确保软件系统可以正式投入运行。
α测试
-
目的：评价软件产品的FLURPS（功能、局域化、可使用性、可靠性、性能和支持）。
