20250522打卡——软件测试复习笔记

• 软件测试复习
  • 第一章 软件测试概述
  • 第二章 黑盒测试
    • 黑盒测试用例设计方法
    • 测试方法选择的综合策略
  • 第三章 白盒测试
    • 白盒测试用例设计方法
  • 第四章 单元测试
  • 第五章 集成测试
  • 第六章 系统测试
  • 附件

软件测试复习

第一章 软件测试概述

软件 = 程序 + 数据 + 文档

发生软件缺陷：

至少满足以下5个规则之一，才称为发生一个软件缺陷：

• 软件未实现产品说明书要求的功能--功能缺失
• 软件出现了产品说明书指明不应该出现的错误--错误、缺陷
• 软件实现了产品说明书未提到的功能--功能多余
• 软件未实现产品说明书虽未明确提及但应该实现的目标--对隐性需求的把握，同时发现需求遗漏
• 软件难以理解，不易使用，运行缓慢--用户体验角度

软件测试：

软件测试是为了发现错误而执行程序的过程。

软件测试只能证明软件存在错误，但不能证明软件没有错误。

测试用例：

测试用例是为某个特殊目标而编制的一组测试，输入、执行条件以及预期结果。

测试用例是执行测试的最小实体。

软件测试分类：

第二章 黑盒测试

黑盒测试定义：

在测试时，把被测程序视为一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下进行。

静态黑盒测试方法：文档测试，特别是产品需求文档、用户手册、帮助文件等的审查。
动态黑盒测试方法：通过数据输入并运行程序来检验输出结果，如功能测试、验收测试和一些性能测试等。

黑盒测试用例设计方法

等价类划分（计算题）：

（1）确定等价类，列出等价类表。

（2）确定测试用例。

边界值分析（简答题）：

边界值分析法是作为对等价类划分法的补充。

• 获取测试用例的方法：
• （1）每次保留程序中一个变量，让其余的变量取正常值，被保留的变量依次取min、min+、nom、max-和max。
• （2）对程序中的每个变量重复（1）。

对于一个含有n个变量的程序，采用边界值分析法测试程序会产生4n+1个测试用例。

健壮性测试是边界值分析的一个简单的扩充，它除了对变量的5个边界值分析取值外，还需要增加一个略大于最大值(max+)以及略小于最小值(min-)的取值，检查超过极限值时系统的情况。
因此，对于有n个变量的函数采用健壮性测试需要6n+1个测试用例。

决策表法（判定表驱动法，计算题）：

最为严格、最具有逻辑性的测试方法，能够设计出完整的测试用例集合。

不能表达重复执行的动作，例如循环结构。

• 判定表的组成：
• 条件桩、动作桩、条件项、动作项，规则

• 构造判定表的5个步骤：
• （1）确定规则的个数。
  • 有n个条件的判定表有2n个规则（每个条件取真、假值）
• （2）列出所有的条件桩和动作桩。
• （3）填入条件项。
• （4）填入动作项，得到初始判定表
• （5）简化决策表，合并相似规则
  • 若表中有两条以上规则具有相同的动作，并且在条件项之间存在极为相似的关系，便可以合并。
  • 合并后的条件项用符号“-”表示，说明执行的动作与该条件的取值无关，称为无关条件。

因果图（计算题）：

一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。

因果图法最终生成的还是判定表。
考虑了相互制约关系。
可以指出规格说明存在的不完整性和二义性。

测试用例数目可能会很大，不便于维护

• 采用因果图法设计测试用例的步骤：
• （1）分析软件规格说明中哪些是原因（即输入条件或输入条件的等价类），哪些是结果（即输出条件），并给每个原因和结果赋予一个标识符。
• （2）分析软件规格说明中的语义，找出原因与结果之间、原因与原因之间对应的关系， 根据这些关系画出因果图。
• （3）由于语法或环境的限制，有些原因与原因之间、原因与结果之间的组合情况不可能出现。为表明这些特殊情况，在因果图上用一些记号表明约束或限制条件。
• （4）把因果图转换为决策表。
• （5）根据决策表中的每一列设计测试用例。

错误推测法：

基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法。

正交试验法（简答题）：

正交实验设计方法是依据Galois理论，从大量的数据中挑选适量的、有代表性的点，从而合理地安排实验的一种科学实验设计方法。

减少测试的工时与费用

• 正交试验法的步骤：

• （1）提取用例中的因子

• （2）分析因子的状态

• （3）查找合适的正交表

• （4）给出测试用例

• 正交表符号表示：

• 正交表通常表示为$L_n(m^k)$，其中：

  • $L$：正交表（Latin Square的缩写）
  • $n$：试验次数（行数），即需要进行的试验次数。
  • $m$：每个因素的水平数（所有因素的水平数相同）。
  • $k$：因素数（列数），即最多能安排的因子数量。
  • $n=k(m-1)+1$

• 示例：

• $L_9(3^4)$表示：

  • 9次试验
  • 每个因素有3个水平
  • 最多可安排4个因子

• 选择合适的正交表：

• 确定因素和水平：明确试验的因素数和各因素的水平数。

• 选择合适正交表：

  • 因素数 ≤ 正交表的列数$k$。
  • 水平数匹配（等水平或混合水平）。
  • 试验次数$n$尽可能少（如优先选$L_9(3^{4)$而非$L_{27}(3})$）。

• 安排因素和交互作用：避免交互作用的因素放在交互作用列。

场景法：

现在的软件都是用事件来触发流程的，事件触发时的情景并成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。

用例场景用来描述流经用例的路径，从用例开始到结束，遍历这条路径上所有基本流和备选流。
基本流用直黑线表示，备选流用不同的彩色表示。

测试方法选择的综合策略

（1）首先进行等价类划分，包括输入条件和输出条件的等价划分，将无限测试变成有限测试，这是减少工作量和提高测试效率最有效的方法。
（2）在任何情况下，都必须使用边界值分析法，经验表明，用这种方法设计出的用例，发现程序错误的能力最强。
（3）可以用错误推测法追加一些用例，这需要依靠测试工程师的经验。
（4）对照程序逻辑，检查出已设计出的测试用例的逻辑覆盖程度，如果没有足够覆盖，应当再补充足够的测试用例。
（5）如果程序说明中有输入条件的组合情况，则一开始就可以选用因果图或判定表驱动法设计测试用例。
（6）对于参数配置类型的软件，要用正交试验法选择较少的组合方式，达到最佳效果。
（7）对于业务流清晰的系统，可利用场景法贯穿整个测试案例过程，在案例中综合使用各种设计方法。

第三章 白盒测试

白盒测试定义：

基于系统或者组件的内部实现结构和逻辑寻找缺陷的测试技术。

在使用白盒测试方法之前进行代码评审是一个非常好的工程实践。

白盒测试用例设计方法

基本路径法（计算题）：

根据程序的控制流图找出一个模块所需测试的基本路径，根据这些基本路径设计构造相应的测试用例。

• 设计步骤：

• （1）根据模块逻辑构造控制流图。

• （2）计算控制流图的环复杂度。
  • 用V(G)表示，用来衡量一个模块判定结构的复杂程度，在数量上表现为独立的路径条数，是需要测试的基本路径数目的上限。
  • 计算公式：
  • V(G) = 闭合区域的数目
  • V(G) = 二值判定节点个数 + 1
  • V(G) = 边的数目-节点的数目 + 2

• （3）列出包含起始节点和终止节点的基本路径。
  • 是一条从起始节点到终止节点的路径
  • 至少包含一条其它基本路径没有包含的边

  对于循环而言，基本路径应包含不执行循环和执行一次循环体

• （4）检查一下列出的基本路径数目是否超过控制流图的环复杂度。
• （5）设计覆盖这些基本路径的测试用例。

逻辑覆盖法（计算题）：

语句覆盖：使得程序中的每个可执行语句至少执行一次。
判定覆盖：使得程序中的每个判定至少都获得一次“真”值和“假”值。
条件覆盖：使得程序中每个判定包含的每个条件的可能取值（真/假）都至少满足一次。
判定/条件覆盖：使得程序中每个判定包含的每个条件的所有情况（真/假）至少出现一次，并且每个判定本身的判定结果（真/假）也至少出现一次。
组合覆盖：使得程序中每个判定的所有可能的条件取值组合都至少出现一次。
路径覆盖：要求覆盖程序中所有可能的路径。

循环测试：

对循环变量运用类似于边界值测试的方法以验证循环体结构的正确性。

• 四种循环结构：
• 简单循环

• 嵌套循环

• 连接循环

• 非结构循环

数据流测试（简答题）：

根据被测模块中变量的定义和使用路径，发现代码中如引用未定义变量、对以前未曾使用的变量再次赋值等数据流异常情况。

导致这些异常情况原因是由于代码存在名字拼错、名字混淆或是语句遗漏等缺陷。

变量的定义节点：
如果程序中某一语句i的执行能改变某程序变量V的值，则称V被语句i定义,可记作Def（V，i）。

变量的使用节点：
如果某一语句j的执行引用了内存中变量V的值，则称变量V被语句j使用，可记作Use（V, j）。

程序插桩：

“插桩”：通过在源代码中加入记录信息语句，以便进行运行信息的追踪和调试，统计有关的运行资源状况。

程序插桩方法：借助往被测程序中插入操作，来实现测试目的的方法，即向源程序中添加一些语句，实现对程序语句的执行、变量的变化等情况进行检查。

如print语句（最简单的插桩）。
插桩技术是实现各种覆盖测试的必要手段。

最少测试用例数计算（简答题）：

N-S图

第四章 单元测试

定义：

是对软件基本组成单元进行的测试。是检验程序最小单位，即检查模块有无错误，它是在编码完成后必须进行的测试工作。

一般步骤：

编译运行程序 → 静态测试 → 动态测试

静态分析（简答题）：

（1）控制流程分析：通过软件测试工具，将程序的控制语句转化成相应的可视化控制图形，通过图形识别并检出程序中的缺陷和错误。
（2）数据流分析：通过软件测试工具，自动分析、识别并检出发生异常的数据。
（3）表达式分析：通过软件测试工具，自动分析被测软件的表达式，确定表达式是否满足其技术要求。

主要任务（测试以下5个方面）：

模块接口、局部数据结构、边界条件、独立的路径和错误处理

执行过程（辅助测试模块，简答题）：

驱动模块：
用来模拟被测试模块的上一级模块，相当于被测模块的主程序。

桩模块：
用来模拟被测模块工作过程中所调用的模块。

第五章 集成测试

概念：：

集成测试又称组装测试，是在单元测试的基础上，将所有模块按照设计要求组装成子系统或系统进行的测试活动。又称子系统测试、联合测试。

目的：：

确保各单元组合在一起后能够按既定意图协作运行，并确保增量的行为正确，所测试的内容包括单元间的接口以及集成后的功能。

层次：

（1）模块内集成测试。
（2）子系统内集成测试：先测试子系统内的功能模块，然后将各个功能模块组合起来确认子系统的功能是否达到预期要求。
（3）子系统间集成测试：测试的单元是子系统之间的接口。子系统是可单独运行的程序或进程。

集成测试方法：

静态测试技术--针对概要设计的测试
动态测试技术--灰盒测试

集成测试策略（简答题）：：

增量式测试要比非增量式测试具有一定的优越性。

参与集成测试的人员：
系统设计人员，软件测试部，开发人员

• 非增量式集成策略--一步到位：
• 适用于一个维护型或被测试系统较小的项目

优点：
方法简单。
允许多测试人员同时并行工作，人力物力资源利用率较高。

缺点：
必须为每个模块准备相应的驱动模块和桩模块，测试成本较高。
一旦集成后包含多种错误，难以纠正。

• 增量式集成策略--逐步实现：

自顶向下与自底向上增量式测试的比较：
自顶向下增量式测试：
主要优点在于它可以自然的做到逐步求精，一开始就能让测试者看到系统的框架。
主要缺点是需要提供桩模块，并且在输入/输出模块接入系统以前，在桩模块中表示测试数据有一定困难。
自底向上增量式测试：
优点在于，由于驱动模块模拟了所有调用参数，即使数据流并未构成有向的非环状图，生成测试数据也无困难。
主要缺点在于，直到最后一个模块被加进去之后才能看到整个程序（系统）的框架。

• 自顶向下增量式测试：
• • 深度优先

• • 广度优先

• 步骤：
• （1）主控模块作为测试驱动器。
• （2）根据集成的方式（深度或广度），下层的桩模块一次一次地被替换为真正的模块。
• （3）在每个模块被集成时，都必须进行单元测试。重复第2步，直到整个系统被测试完成

优点：
较早地验证了主要控制和判断点；
按深度优先可以首先实现和验证一个完整的软件功能；
功能较早证实，带来信心；
只需一个驱动，减少驱动器开发的费用；
支持故障隔离。

缺点：
桩的开发量大；
底层验证被推迟；
底层组件测试不充分。

适用范围：
产品控制结构比较清晰和稳定；
高层接口变化较小；
底层接口未定义或经常可能被修改；
产口控制组件具有较大的技术风险，需要尽早被验证；
希望尽早能看到产品的系统功能行为。

• 自底向上增量式测试：

• 步骤：

• （1）起始于模块依赖关系树的底层叶子模块，也可以把两个或多个叶子模块合并到一起进行测试。

• （2）使用驱动模块对步骤１选定的模块（或模块组）进行测试。

• （3）用实际模块代替驱动模块，与它已测试的直属子模块组装成一个更大的模块进行测试。

• （4）重复上面的行为，直到系统最顶层模块被加入到已测系统中。

优点：
​对底层组件行为较早验证；
​工作最初可以并行集成，比自顶向下效率高；
​减少了桩的工作量；
​能较好锁定软件故障所在位置。

​缺点：
驱动的开发工作量大；
对高层的验证被推迟，设计上的错误不能被及时发现。

​适用范围：
适应于底层接口比较稳定；
高层接口变化比较频繁；
底层组件较早被完成。

• 三明治增量式测试（混合增量式测试）：

• 步骤：

• （1）首先对目标层之上一层使用自顶向下集成，因此测试A，使用桩代替B，C，D。

• （2）其次对目标层之下一层使用自底向上集成，因此测试E，F，使用驱动代替B，D。

• （3）其三，把目标层下面一层与目标层集成，因此测试（B，E），（D，F），使用驱动代替A。

• （4）最后，把三层集成到一起，因此测试（A，B，C，D，E，F）。

优点：
​集合了自顶向下和自底向上两种策略的优点。

​缺点：
​中间层测试不充分。

​适用范围：
​适应于大部分软件开发项目。

• 改进后的三明治集成方法：
• 不仅自两头向中间集成，而且保证每个模块得到单独的测试，使测试进行得比较彻底。

第六章 系统测试

概念：

是将已经集成好的软件系统，作为整个计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行环境下，对计算机系统进行系列的测试活动。

目的：

通过与系统的需求定义做比较，发现软件与系统定义不符合或与之矛盾的地方。

层次：

• 用户层测试
  • 用户支持测试
  • 用户界面测试
  • 安全性测试
  • 可维护(自检有效性、远程维护、软件升级)测试
• 应用层测试
  • 系统性能
  • 系统可靠性、稳定性
  • 版本兼容性
  • 系统安装升级
• 功能层测试
• 指标/协议层测试

系统测试策略：

功能测试：
逻辑功能测试。
界面测试。
易用性测试。
安装测试。
兼容性测试。

性能测试：
一般性能测试。
稳定性测试。
负载测试。
压力测试。

验收测试：
α测试：由用户在开发环境下进行的测试。
β测试：由软件的多个用户在一个或多个用户的实际使用环境下进行的测试。

附件