【系统架构设计】测试评审方法

本文主要是介绍【系统架构设计】测试评审方法，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

测试方法

需要明确 错误（erro）和缺陷（fault） 的概念，根据IEEE定义，错误主要针对软件开发过程，而缺陷针对软件产品。软件开发人员在开发过程中所出现的错误是导致软件产品缺陷的原因。因此，缺陷是错误的结果和表现形式。

从测试阶段上分

从测试阶段上分，软件测试通常可分为单元测试、集成测试、系统测试。

单元测试

也称模块测试，目的是检查模块是否实现了详细说明书中规定的功能和算法，应该在详细设计阶段制定。

测试一个模块需要为该模块编写一个驱动模块 和 若干个桩（stub）模块。

• 驱动模块用来调用被测模块，它接收测试者提供的测试数据，并把这些数据传送给被测模块，然后从被测模块接收测试结果，并以某种可见的方式将测试结果返回给测试者；
• 桩模块用来模拟被测模块所调用的子模块，它接收被测模块的调用，检验调用参数，并以尽可能简单的操作模拟被调用的子程序模块功能，把结果返回被测模块。

顶层模块测试时不需要驱动模块，底层模块测试时不需要桩模块。

集成测试

也称组装测试,目的是发现模块间的接口和通信问题，应该在概要设计阶段制定。

集成的方式可分为非渐增式和渐增式。

• 非渐增式集成是先测试所有的模块，然后一下子把所有这些模块集成到一起，并把庞大的程序作为一个整体来测试。这种测试方法的出发点是可以“一步到位”，但测试者面对众多的错误现象，往往难以分清哪些是“真正的”错误，哪些是由其他错误引起的“假性错误”，诊断定位和改正错误也十分困难。非渐增式集成只适合一些非常小的软件。

• 渐增式集成是将单元测试和集成测试合并到一起，它根据模块结构图，按某种次序选一个尚未测试的模块，把它同已经测试好的模块组合在一起进行测试，每次增加一个模块，直到所有模块被集成在程序中。这种测试方法比较容易定位和改正错误，目前在进行集成测试时已普遍采用渐增式集成

ps ：平时常用的就是渐增式集成方法，把要测试的和已知没问题的一起测试，如果出现问题，那就是要测试的有问题，然后再通过打印的方式去定位原因。

系统测试

是软件测试中的最后的、最完整的测试，目的是从全局来考察软件系统的功能和性能要求，应该在需求分析阶段制定。

通常包括 确认测试 和验收测试。

• 确认测试，主要依据软件需求说明书检查软件的功能、性能及其他特征是否与用户的需求一致。
• 验收测试 通常采用 (Alpha)测试和 (Beta)测试 的过程，来发现那些看起来只有最终用户才能发现的错误。

1. a 测试由用户在开发者的场所进行，并且在开发者的指导下进行测试。开发者负责记录发现的错误和使用中遇到的问题。也就是说， 测试是在“受控的”环境中进行的。
2. b 测试是在一个或多个用户的现场由该软件的最终用户实施的，开发者通常不在现场，用户负责记录发现的错误和使用中遇到的问题并把这些问题报告给开发者。也就是说，测试是在“不受控的”环境中进行的。

ps ：app 在发布前，会将测试版本发给用户使用，让他们在现场进行实操，如果有问题在进行解决，当时就是(Beta)测试；然后测试版本在做汇报时，给客户演示，以及让客户体验测试，当时就是(Alpha)测试。

从测试方法上分

从测试方法上分，软件测试通常可分为白盒测试、黑盒测试。

白盒测试

又称结构测试，主要用于单元测试阶段。它的前提是可以把程序看成装在一个透明的白箱子里，测试者完全知道程序的结构和处理算法。这种方法按照程序内部逻辑设计测试用例，检测程序中的主要执行通路是否都能按预定要求正常工作。

白盒测试根据软件的内部逻辑设计测试用例，常用的技术是逻辑覆盖，即考察用测试数据运行被测程序时对程序逻辑的覆盖程度。主要的覆盖标准有 6 种：

• 语句覆盖。语句覆盖是指选择足够多的测试用例，使得运行这些测试用例时，被测程序的每个语句至少执行一次。很显然，语句覆盖是一种很弱的覆盖标准。

• 判定覆盖。判定覆盖又称分支覆盖，它的含义是，不仅每个语句至少执行一次，而且每个判定的每种可能的结果（分支）都至少执行一次。判定覆盖比语句覆盖强，但对程序逻辑的覆盖程度仍然不高。

• 条件覆盖。条件覆盖的含义是，不仅每个语句至少执行一次，而且使判定表达式中的每个条件都取得各种可能的结果。

ps :一定要注意条件覆盖不一定包含判定覆盖，判定覆盖也不一定包含条件覆盖。如A || B > 1 ，对条件覆盖还要考虑A || B，但对判断覆盖就是 一次 假，所以，判断覆盖是整体上的，条件覆盖是细节上的。

• 判定/条件覆盖。同时满足判定覆盖和条件覆盖的逻辑覆盖称为判定/条件覆盖。它的含义是，选取足够的测试用例，使得判定表达式中每个条件的所有可能结果至少出现一次，而且每个判定本身的所有可能结果也至少出现一次。

• 条件组合覆盖。条件组合覆盖的含义是，选取足够的测试用例，使得每个判定表达式中条件结果的所有可能组合至少出现一次。

ps : 满足条件组合覆盖的测试用例，也一定满足判定/条件覆盖。因此，条件组合覆盖是上述 5 种覆盖标准中最强的一种。然而，条件组合覆盖还不能保证程序中所有可能的路径都至少经过一次。

• 路径覆盖。路径覆盖的含义是，选取足够的测试用例，使得程序的每条可能执行到的路径都至少经过一次（如果程序中有环路，则要求每条环路路径至少经过一次）。

ps:路径覆盖实际上考虑了程序中各种判定结果的所有可能组合，因此是一种较强的覆盖标准。但路径覆盖并未考虑判定中的条件结果的组合，并不能代替条件覆盖和条件组合覆盖。

黑盒测试

又称功能测试，主要用于集成测试、确认测试阶段。根据软件需求说明书所规定的功能来设计测试用例，它不考虑软件的内部结构和处理算法。

评审方法

评审过程中，以下几点需要注意：

• 不应以测试代替评审
• 评审人员应关注产品而不应评论开发人员
• 评审人员应关注于实质性问题，而非一些非实质性的问题，例如，文档的格式、措词
• 评审会议不应变为问题解决方案讨论会
• 评审应被安排进入项目计划
• 评审参与者应了解整个评审过程
• 评审人员事先应对评审材料充分了解
• 应重视评审的组织工作

面向对象的测试

传统的软件测试策略是从小型测试开始，逐步走向大型测试。即从单元测试开始，然后进入集成测试，最后是系统测试。

面向对象程序的结构不再是传统的功能模块结构，作为一个整体，原有集成测试所要求的逐步地将开发的模块搭建在一起进行测试的方法已成为不可能。而且，面向对象软件抛弃了传统的开发模式，对每个开发阶段都有不同以往的要求和结果，已经不可能用功能细化的观点来检测面向对象分析和设计的结果。因此，传统的测试模型对面向对象软件已经不再适用。

面向对象的开发模型突破了传统的瀑布模型，将开发分为 OOA、OOD 和 OOP 三个阶段：

• OOA：Object Oriented Analysis 面向对象分析方法
• OOD：Object Oriented Design 面向对象设计
• OOP：Object Oriented Programming 面向对象的程序设计

结合传统的测试步骤的划分，可以把面向对象的软件测试分为：面向对象分析的测试、面向对象设计的测试、面向对象编程的测试、面向对象的单元测试、面向对象的集成测试、面向对象的系统测试。

ps ：面向对象测试的整体目标是以最小的工作量发现最多的错误，与传统软件测试的目标是一致的，但 OO 测试的策略与传统测试有很大不同。这种不同主要体现在两个方面，第一，测试的焦点从过程构件（模块）移向了类；第二，测试的视角扩大到了分析和设计模型。所以在理解过程中，要结合起来看，只不过传统的以模块去理解，面向对象的以类为单位去理解。

这篇关于【系统架构设计】测试评审方法的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---