- 在软件测试过程中需要 3 类信息：
- 软件配置：指需求说明书、设计说明书和源程序等；
- 测试配置：指测试方案、测试用例和测试驱动程序等；
- 测试工具：指计算机辅助测试的有关工具。
- 软件产品在交付使用之前一般要经过单元测试、集成测试、 确认测试和系统测试 4 个阶段的测试。
![[Pasted image 20230625205159.png]] - 单元测试：
- 对软件基本组成单元进行的测试；
- 所发现的是编码和详细设计中的错误；
- 单元测试集中检测软件设计的最小单元——模块。
- 模块应该是有明确的功能、性能定义、接口定义，而且可以清晰地与其他单位区分开。
- 在编写出源程序代码并通过编译程序的语法检查后，用详细设计说明书作指南，对重要的执行通路进行测试，以便发现模块内部的错误。
- 可以应用人工测试和计算机测试两种测试方法来进行单元测试。
- 通常，单元测试主要使用白盒测试技术，而且多个模块可以并行地进行测试。
- 测试内容：
- 模块接口：I/O 参数值的个数、类型 、次序、格式是否正确， I/O 文件属性、操作是否正确等。
- 首先应该对通过模块接口的数据流进行测试，如果数据不能正确地进出，所有其他测试都是不切实际的。
- 在对模块接口进行测试时主要检查下述几个方面：
- 参数的数目、次序、属性或单位系统与变元是否一致 ；
- 是否修改了只作输入用的变元；
- 全局变量的定义和用法在各个模块中是否一致
- 局部数据结构：数据说明是否正确、一 致，变量及其初值定义是否正确等。
- 局部数据结构是模块常见的错误来源。常见的错误如下 :
- 不正确或不一致的数据说明 ;
- 错误的初始化或没有赋处值 ;
- 变量名的拼写或缩写错误；
- 数据类型不相容；
- 上溢、下溢和地址异常
- 局部数据结构是模块常见的错误来源。常见的错误如下 :
- 重要的执行通路：重要路径通常是指完成模块功能的主要路径，一般是控制结构。
- 由于通常不可能进行穷尽测试，因此，在进行单元测试时 , 关键是选择最有代表性、最可能发现错误的执行通路。
- 应该设计测试方案用来发现由于错误的计算、不正确的比 较或不适当的控制流而造成的错误。
- 出错处理通路：检查“错误处理程序”本身的错误。
- 好的设计应该能预见出现错误的条件，并且设置适当的处 理错误的通路，以便在真的出现错误时执行相应的出错处理 通路或结束处理。
- 当评价出错处理通路时，应该着重测试下述一些可能发生 的错误：
- 对错误的描述是难以理解的；
- 记下的错误与实际遇到的错误不同；
- 在对错误进行处理之前，错误条件已经引起系统干 预；
- 对错误的处理不正确；
- 描述错误的信息难以确定造成错误的位置。
- 边界条件：边界条件常包括循环边界，最大最小值、控制流中等于、大于、小于的比较值等。
- 边界测试是单元测试中最后且最重要的一步。
- 软件常常在它的边界上失效，例如，处理 n 元数组的第 n 个元素时，或做到 i 次循环中的第 i 次重复时，往往会发生错误。使用刚好小于、刚好等于和刚好大于最大值或最小值的数据结构、控制量和数据值的测试方案，非常可能发现软件中的错误。
- 模块接口：I/O 参数值的个数、类型 、次序、格式是否正确， I/O 文件属性、操作是否正确等。
- 测试方法：
- 代码审查（静态分析）
- 代码审查也称为人工测试，既可以由编写者自己来完成也可由审查小组来完成。后者对单元测试很有效，可以查出 30% ～ 70% 的逻辑设计错误和编码错误。审查小组最好由下述 4 人组成：
- 组长
- 程序的设计者
- 程序的编写者
- 程序的测试者
- 代码审查也称为人工测试，既可以由编写者自己来完成也可由审查小组来完成。后者对单元测试很有效，可以查出 30% ～ 70% 的逻辑设计错误和编码错误。审查小组最好由下述 4 人组成：
- 计算机测试（动态测试）
- 每一个被测试的单元 ( 模块 ) 并不是一个独立的程序， 模块自己不能单独执行 , 必须依靠其他模块来驱动。所以要为被测试的模块设计一些辅助性的模块，我们把他们称为驱动模块和 ( 或 ) 存根模块。
- 驱动模块和存根模块需要编写程序，也就是说，使用计算机进行单元测试必须编写测试软件。
- 驱动模块：是一个“主程序”，用来模拟测试模块的调用模块，它接收测试数据，把这些数据传送给被测试的模块，最后输出测试模块产生数据。
- 存根模块：作用是模拟被测试的模块的下属模块。因此也可以称为“虚拟子程序”。
- ![[Pasted image 20230625211223.png]]
- 代码审查（静态分析）
- 集成测试：
- 将已分别通过测试的单元按设计要求组合起来再进行测试
- 发现的是软件设计中的错误
- 也可能发现需求中的错误
- 集成测试：在装配的过程中对组装的模块进行测试 , 主要目标是发现与接口有关的问题。它包括子系统测试和系统测试两个过程。测试的技术有两种：
- 非渐增式测试技术：先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序；
- 渐增式测试技术：把下一个要测试的模块同已经测试好的那些模块结合起来进行测试，测试完以后再把下一个应该测试的模块结合进来测试。这种每次增加一个模块的方法称为渐增式测试，这种方法实际上同时完成单元测试和集成测试。
- 两者的主要优缺点对比：
- 非渐增式测试一下子把所有模块放在一起，把庞大的程序作为一个整体来测试，测试时会遇到许许多多的错误，而且改正错误相当困难；
- 渐增式测试把程序划分成小段来构造和测试，在这个过程中比较容易定位和改正错误；对接口可以进行更彻底的测试；可以使用系统化的测试方法。
- 因此，目前在进行集成测试时普遍采用渐增式测试方法。渐增方式有两种集成方法：
- 自顶向下集成
- 从主控制模块开始，沿着程序的控制层次向下移动，逐渐把各个模块一一结合起来，从而构成目标系统。在把附属于主控制模块的那些模块组装到程序结构中去时，有两种策略：
- 深度优先的策略
- 深度优先的结合方 法，先把软件结构的一条主 控制通路上的所有模块都结 合组装起来。然后再结合组 装中央或右侧的控制路径， 直到所有模块都被结合进去 为止。其中选择一条主控制 通路取决于应用的特点，并 且有很大任意性。
- ![[Pasted image 20230625212019.png]]
- 广度优先的策略
- 宽度优先的结合策略是沿软件结构水平地移动，把处于同一个控制层次上的所有模块组装起来。然后再组 装下一个控制层次中所有模块，如此进行下去，直到所有模块都被结合进软件结构为止。
- ![[Pasted image 20230625212114.png]]
- 深度优先的策略
- 自顶向下集成过程：
- 第一步，用主控程序作为测试驱动模块，用存根程序代替所有下属于主控制模块的模块；
- 第二步，选择一种结合策略（深度优先或宽度优先），每次用一个实际模块代换一个存根程序；
- 第三步，每结合一个模块，就进行相应测试；
- 第四步，为了保证不引入新的错误，可以进行回归测试（全部或部分地重复以前做过的测试）；
- 从第二步开始不断地重复进行上述过程，直到构造起完整的软件结构为止。
- 从主控制模块开始，沿着程序的控制层次向下移动，逐渐把各个模块一一结合起来，从而构成目标系统。在把附属于主控制模块的那些模块组装到程序结构中去时，有两种策略：
- 自底向上集成
- 从软件结构最低层的模块开始进行组装和测试。它不需要存根程序，但需要驱动程序。
- 自底向上的结合过程为：
- 第一步，把低层模块组成模块族，以实现某个特定的软件子功能；
- 第二步，为每个族写一个驱动程序，作为测试控制，用来协调测试数据的输入和输出；
- 第三步，对由模块组成的子功能族进行测试；
- 第四步，去掉驱动程序，沿软件结构自下向上移动，把子功能族组合起来形成更大的子功能族；
- 上述第二步到第四步实质上构成了一个循环。
- ![[Pasted image 20230625212915.png]]
- 不同集成测试策略的比较
- 自顶向下集成测试方法：
- 优点：
- 不需要驱动程序；
- 能够在测试阶段的早期实现并验证系统的主要功能；
- 能在早期发现上层模块的接口错误。
- 缺点：
- 需要存根程序 , 可能遇到与此相联系的测试困难；
- 低层关键模块中的错误发现较晚；
- 在早期不能充分展开人力
- 而自底向上测试方法的优缺点与上述自顶向下测试方法的优 缺点刚好相反。
- 优点：
- 自底向上集成测试方法：
- 优点：
- 不需存根驱动；
- 测试用例的设计比自顶向下集成测试方法容易。
- 缺点：
- 需要程序驱动；
- 直到把最后一个模块结合进来之前，程序作为一 个整体始终不存在。
- 优点：
- 总结：
- 在测试实际的软件系统时，应该根据软件的特点以及工程进度安排，选用适当的测试策略。一般说来，纯粹自顶向下或纯粹自底向上的策略可能都不实用，人们在实践中创造出许多混合策略：- 改进的自顶向下测试方法。基本上使用自顶向下的测试方法，但是在早期使用自底向上的方法测试软件中的少数关键模块。优点能在测试的早期发现关键模块中的错误；但是缺点也比自顶向下方法多一条，即测试关键模块时需要驱动程序；
- 混合法。自顶向下方法和自底向上方法相结合。对软件结构中较上层使用的自顶向下方法 , 对软件结构中较下层使用的自底向上方法。这种方法兼有两种方法的优点和缺点，当被测试的软件中关键模块比较多时，这种混合法可能是最好的折衷方法。
- 自顶向下集成测试方法：
- 自顶向下集成
- 确认测试：
- 检查所开发的软件是否满足需求规格说明书中所确定的功能和性能的需求
- 发现的是需求分析阶段的错误
- 确认测试（validation testing），又称为有效性测试或验收测试。目标是验证软件的有效性。
- 其任务是验证系统的功能、性能等特性是否符合需求规格说明；文档资料是否正确、完整；系统的可移植性、兼容性、错误的恢复能力和易维护性是否满足。
- 确认测试步骤
- ![[Pasted image 20230625213718.png]]
- 有效性测试
- 确认测试对已测试过的纯技术性的问题不再测试，对用户特别感兴趣的功能和性能需要增加测试。按照用户的实际使用过程，使用实际数据进行测试。确认测试是以用户为主进行的，用户参与设计测试方案，参与实地测试，参与评价测试结果。确认测试属于黑盒测试。
- 确认测试有下述两种可能的结果：
- 功能和性能与用户要求一致，软件是可以接受的；
- 功能和性能与用户要求有差距。
- 软件配置报告
- 复查软件配置是确认测试的一个重要内容。复查的目的是保证软件配置的所有成分都齐全，质量符合要求，文档与程序完全一致，具有完成软件维护所必须的细节， 而且已经编好目录。
- 除了按合同规定的内容和要求，由人工审查软件配置之外，在确认测试过程中还应该严格遵循用户指南及其他操作程序，以便检验这些使用手册的完整性和正确性。 必须仔细记录发现的遗漏或错误，并且适当地补充和改正。
- 系统测试
- 系统测试是将经过单元测试、集成测试、确认测试以后的软件，作为计算机系统中的一个组成部分，需要与系统中的硬件、外部设备、支持软件、数据及操作人员结合起来，在实际运行环境下对计算机系统进行一系列的严格有效的测试来发现软件的潜在问题，以保证各组成部分不仅单独的正常运行，而且在系统各部分统一协调下也能正常运行。
- 系统测试不同于功能测试。功能测试主要是验证软件功能是否符合用户需求，并不考虑各种环境及非功能问题，如安全性、可靠性、性能等，而系统测试是在更大范围内进行的测试，着重对系统的性能、特性进行测试。
- Alpha 和 Beta 测试
- 如果一个软件是为许多客户开发的，那么，让每个客户都进行正式的验收测试是不现实的。在这种情况下，使用 Alpha 测试和 Beta 测试。
- Alpha 测试是在受控的环境中进行的。它由用户在开发者的场所进行，并且在开发者对用户的“指导”下进行测试。开发者负责记录发现的错误和使用中遇到的问题。
- Beta 测试是软件在开发者不能控制的环境中的“真实”应用。Beta 测试由软件的最终用户们在一个或多个客户场所进行。用户定期把在 Beta 测试过程中遇到的一切问题（真实的或想像的）记录下来，并且报告给开发者。开发者接收到在 Beta 测试期间报告的问题之后，对软件产品进行必要的修改，并准备向全体客户发布最终的软件产品。
- 如果一个软件是为许多客户开发的，那么，让每个客户都进行正式的验收测试是不现实的。在这种情况下，使用 Alpha 测试和 Beta 测试。
上一篇
7.4 软件测试用例的设计
2024-04-20
下一篇
7.3 软件测试方法及分类
2024-04-20