11测试评审方法
2021-04-25 10:36:03 1 举报AI智能生成
系统架构师考试时整理的测试评审方法部分内容
作者其他创作
大纲/内容
11.1 测试方法
软件测试的目的就是在软件投入生产性运行之前，尽可能多地发现软件产品（主要是指程序）中的错误（缺陷）
11.1.1 软件测试阶段
1．单元测试
单元测试（unit testing），也称模块测试，通常可放在编程阶段，由程序员对自己编写的模块自行测试，检查模块是否实现了详细设计说明书中规定的功能和算法。单元测试主要发现编程和详细设计中产生的错误，单元测试计划应该在详细设计阶段制定
单元测试期间着重从以下几个方面对模块进行测试：模块接口、局部数据结构、重要的执行通路、出错处理通路和边界条件等
2．集成测试
集成测试（integration testing），也称组装测试，它是对由各模块组装而成的程序进行测试，主要目标是发现模块间的接口和通信问题
集成的方式可分为非渐增式和渐增式
非渐增式集成是先测试所有的模块，然后一下子把所有这些模块集成到一起，并把庞大的程序作为一个整体来测试
渐增式集成是将单元测试和集成测试合并到一起，它根据模块结构图，按某种次序选一个尚未测试的模块，把它同已经测试好的模块组合在一起进行测试，每次增加一个模块，直到所有模块被集成在程序中。这种测试方法比较容易定位和改正错误，目前在进行集成测试时已普遍采用渐增式集成
3.系统测试
系统测试是软件测试中的最后的、最完整的测试，它是在单元测试和集成测试的基础上进行的，它从全局来考察软件系统的功能和性能要求。系统测试计划应该在需求分析阶段制订
系统测试包括确认测试和验收测试
确认测试，主要依据软件需求说明书检查软件的功能、性能及其他特征是否与用户的需求一致
由于软件系统的复杂性，在实际工作中，验收测试可能会持续到用户实际使用该软件之后的相当长的一段时间
11.1.2 白盒测试和黑盒测试
1．白盒测试
白盒测试，又称结构测试，主要用于单元测试阶段
白盒测试根据软件的内部逻辑设计测试用例，常用的技术是逻辑覆盖，即考察用测试数据运行被测程序时对程序逻辑的覆盖程度。主要的覆盖标准有 6 种：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、组合条件覆盖和路径覆盖
白盒测试根据软件的内部逻辑设计测试用例，常用的技术是逻辑覆盖，即考察用测试数据运行被测程序时对程序逻辑的覆盖程度。主要的覆盖标准有 6 种：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、组合条件覆盖和路径覆盖
（2）判定覆盖。判定覆盖又称分支覆盖，它的含义是，不仅每个语句至少执行一次，而且每个判定的每种可能的结果（分支）都至少执行一次
（3）条件覆盖。条件覆盖的含义是，不仅每个语句至少执行一次，而且使判定表达式中的每个条件都取得各种可能的结果
（4）判定/条件覆盖。同时满足判定覆盖和条件覆盖的逻辑覆盖称为判定/条件覆盖。它的含义是，选取足够的测试用例，使得判定表达式中每个条件的所有可能结果至少出现一次，而且每个判定本身的所有可能结果也至少出现一次
（5）条件组合覆盖。条件组合覆盖的含义是，选取足够的测试用例，使得每个判定表达式中条件结果的所有可能组合至少出现一次
（6）路径覆盖。路径覆盖的含义是，选取足够的测试用例，使得程序的每条可能执行到的路径都至少经过一次（如果程序中有环路，则要求每条环路路径至少经过一次）
2．黑盒测试
黑盒测试，又称功能测试，主要用于集成测试和确认测试阶段。它把软件看作一个不透明的黑箱子，完全不考虑（或不了解）软件的内部结构和处理算法，它只检查软件功能是否能按照软件需求说明书的要求正常使用，软件是否能适当地接收输入数据并产生正确的输出信息，软件运行过程中能否保持外部信息（例如文件和数据库）的完整性等
黑盒测试根据软件需求说明书所规定的功能来设计测试用例，它不考虑软件的内部结构和处理算法
常用的黑盒测试技术包括等价类划分、边值分析、错误推测和因果图
（1）等价类划分
等价类就是某个输入域的集合，对于一个等价类中的输入值来说，它们揭示程序中错误的作用是等效的
步骤
① 根据软件的功能说明，对每一个输入条件确定若干个有效等价类和若干个无效等价类，并为每个有效等价类和无效等价类编号
② 设计一个测试用例，使其覆盖尽可能多的尚未被覆盖的有效等价类。重复这一步，直至所有的有效等价类均被覆盖
③ 设计一个测试用例，使其覆盖一个尚未被覆盖的无效等价类。重复这一步，直至所有的无效等价类均被覆盖
（2）边值分析
软件在处理边界情况时最容易出错。设计一些测试用例，使软件恰好运行在边界附近，暴露出软件错误的可能性会更大一些
（3）错误推测
错误推测法主要依靠测试人员的经验和直觉，从各种可能的测试方案中选出一些最可能引起程序出错的方案
（4）因果图
因果图法是根据输入条件与输出结果之间的因果关系来设计测试用例的，它首先检查输入条件的各种组合情况，并找出输出结果对输入条件的依赖关系，然后为每种输出条件的组合设计测试用例
11.1.3 缺陷的分类和级别
分类
（1）输入/输出错误。包括不接收正确的输入、接收不正确的输入、描述有错或遗漏、参数有错或遗漏、输出结果有误、输出格式有误、输出时间有误、结果不一致、遗漏结果、不合逻辑的结果、拼写/语法错误、修饰词错误
（2）逻辑错误。包括遗漏情况、重复情况、极端条件出错、解释有误、遗漏条件、外部条件有错、错误变量的测试、不正确的循环迭代、错误的操作符
（3）计算错误。包括不正确的算法、遗漏计算、不正确的操作数、不正确的操作、括号错误、精度不够错误的内置函数
（4）接口错误。包括不正确的中断处理、I/O 时序有错、调用了错误的过程、调用了不存在的过程、参数不匹配、不兼容的类型、过量的包含
（5）数据错误。包括不正确的初始化、不正确的存储/访问、错误的标识/索引值、不正确的打包/拆包、使用了错误的变量、错误的数据引用、缩放数据范围或单位错误、不正确的数据维数、不正确的下标、不正确的类型、不正确的数据范围、数据超出限制、数据溢出、不一致的数据
10 级
（1）轻微（例如，界面文字有个别的错别字，但不影响理解）。
（2）中等（例如，界面文字错误可能误导操作者）。
（3）使人不悦（例如，数字串被断开）。
（4）影响使用（例如，有些交易没有处理）。
（5）严重（例如，丢失交易）。
（6）非常严重（例如，不正确的交易处理）。
（7）极为严重（例如，经常出现不正确的交易处理）。
（8）无法容忍（例如，数据库遭到破坏）。
（9）灾难性（例如，系统无法工作）。
（10）传染性（例如，可导致其他系统无法工作）
11.1.4 调试
调试又称为排错，调试与成功的测试形影相随。测试成功的标志是发现了错误。根据错误迹象确定错误的原因和准确位置并加以改正，主要依靠排错技术
隐藏在程序中的错误具有下列特殊的性质
（1）错误的外部征兆远离引起错误的内部原因，对于高度耦合的程序结构此类现象更为严重
（2）纠正一个错误造成了另一错误现象（暂时）的消失。
（3）某些错误征兆只是假象。
（4）因操作人员一时疏忽造成的某些错误征兆不易追踪。
（5）错误是由于分时而不是程序引起的。
（6）输入条件难以精确地再构造（例如，某些实时应用的输入次序不确定）。
（7）错误征兆时有时无，此现象对嵌入式系统尤其普遍。
（8）错误是由于把任务分布在若干台不同处理机上运行而造成的
排错策略分为三类
（1）原始类：主要思想是“通过计算机找错”。例如输出存储器、寄存器的内容，在程序安排若干输出语句等，凭借大量的现场信息，从中找到出错误的线索
（2）回溯类：回溯法能成功地用于程序的排错。方法是从出现错误征兆处开始，人工地沿控制流程往回追踪，直至发现出错的根源
（3）排除类。排除法基于归纳和演绎原理，采用“分治”的概念，首先分析与错误出现有关的所有数据，假想一个错误原因，用这些数据证明或反驳它；或者一次列出所有可能的原因，通过测试一一排除
11.2 评审方法
软件评审包括
（1）软件需求评审。在软件需求分析结束后必须进行软件需求评审（ software
requirements review），以确保在软件需求说明书中所规定的各项需求的合适性
（2）概要设计评审。在软件概要设计结束后必须进行概要设计评审（preliminary designreview），以评价软件设计说明书中所描述的软件概要设计在总体结构、外部接口、主要部件功能分配、全局数据结构以各主要部件之间的接口等方面的合适性
（3）详细设计评审。在软件详细设计结束后必须进行详细设计评审（detailed designreview），以评价软件设计说明书中所描述的软件详细设计在每一个基本部件的功能、算法和过程描述等方面的合适性
（4）软件验证和确认评审。在软件验证与确认计划完成后必须进行软件验证与确认评审（software verification and validation review），以评价软件验证与确认计划中所规定的验证与确认方法的合适性与完整性
（5）功能检查。在软件释放前，要对软件进行功能检查（functional audit），以验证所开发的软件已经满足在软件需求说明书中规定的所有需求
（6）物理检查。在软件验收前，要对软件进行物理检查（physical audit），以验证程序和文档已经一致并已做好了交付的准备
（7）综合检查。在软件验收时，要允许用户或用户所委托的专家对所要验收的软件进行设计抽样的综合检查（comprehensive audit），以验证代码和设计文档的一致性、接口规格说明的一致性（硬件和软件）、设计实现和功能需求的一致性、功能需求和测试描述的一致性
（8）管理评审。要对计划的执行情况定期（或按阶段）进行管理评审（managementreviews），这些评审必须由独立于被评审单位的机构或授权的第三方主持进行
几点值得注意
（1）不应以测试代替评审
（2）评审人员应关注产品而不应评论开发人员
（3）评审人员应关注于实质性问题
（4）评审会议不应变为问题解决方案讨论会
（5）评审应被安排进入项目计划
（6）评审参与者应了解整个评审过程
（7）评审人员事先应对评审材料充分了解
（8）应重视评审的组织工作
11.3 验证与确认
1.验证
（1）合同验证。应根据下列准则验证合同：
供方具有满足需求的能力。
需求是一致的并覆盖了用户的需要。
为处理需求变更和升级问题规定了适当的规程。
规定了各方之间的接口及其合作规程与范围，包括所有权、许可权、版权和保密要求。
按照需求规定了验收准则和规程
（2）过程验证。应根据下列准则验证过程：
项目是适当的、及时的。
为项目选择的过程是适当的并满足合同要求的。
用于项目过程的标准、规程和环境是适当的。
根据合同要求为项目配备了经过培训的人员
（3）需求验证。应根据下列准则验证需求：
需求是明确的、一致的、无歧义的。
需求是可行的。
需求是可测试的
（4）设计验证。应根据下列准则验证设计：
设计是正确的，是可以实现需求的。
可以从需求导出设计，可以从设计追踪需求
（5）编码验证。应根据下列准则验证编码：
编码是正确的，可以实现设计和需求。
可以从设计导出编码，可以从编码追踪设计
（6）集成验证。应根据下列准则验证集成：
每一个软件项的软件部件和软件单元已完整、正确地集成到软件项中。
系统的硬件项、软件项和人工操作已完整、正确地集成到系统中
（7）文档验证。应根据下列准则验证文档：
文档是充分的、完备的、一致的。
文档制订是及时的。
文档配置管理遵循了规定的规程
2．确认
（1）编写测试需求、测试用例和测试规程。
（2）确保这些测试需求、测试用例和测试规程可以反映软件产品的预期用途。
（3）执行测试。
（4）确认软件产品满足其预期用途
11.5 面向对象的测试
传统的软件测试策略是从“小型测试”开始，逐步走向“大型测试”。即从单元测试开始，然后进入集成测试，最后是系统测试
1.面向对象测试模型
面向对象的开发模型突破了传统的瀑布模型，将开发分为 OOA、OOD 和 OOP 三个阶段。针对这种开发模型，结合传统的测试步骤的划分，可以把面向对象的软件测试分为：面向对象分析的测试、面向对象设计的测试、面向对象编程的测试、面向对象的单元测试、面向对象的集成测试和面向对象的系统测试
2.面向对象分析的测试
（1）对认定的对象的测试。
（2）对认定的结构的测试。
（3）对认定的主题的测试。
（4）对定义的属性和实例关联的测试。
（5）对定义的服务和消息关联的测试
3．面向对象设计的测试
（1）对认定的类的测试。
（2）对构造的类层次结构的测试。
（3）对类库的支持的测试
4．面向对象编程的测试
（1）数据成员是否满足数据封装的要求。
（2）类是否实现了要求的功能
5．面向对象的单元测试
面向对象的软件，单元的概念发生了变化。每个类和类的实例（对象）封装了属性
（数据）和操纵这些数据的操作，而不是个体的模块，最小的可测试单位变成了封装的类或对象
6．面向对象的集成测试
第一种称为基于线程的测试，集成系统的一个输入或事件所需的一组类，每个线程被集成并分别测试，并使用回归测试以保证没有产生副作用
第二种称为基于使用的测试，首先测试那些几乎不使用其他类的类（称为独立类）并开始构造系统，在独立类测试完成后，下一层的使用独立类的类（称为依赖类）被测试。这个依赖类层次的测试序列一直持续到构造完整个系统
7．面向对象的系统测试
系统测试时，应该参考 OOA 分析的结果，对应描述的对象、属性和各种服务，检测软件是否能够完全“再现”问题空间。系统测试不仅是检测软件的整体行为表现，从另一个侧面看，也是对软件开发设计的再确认
11.4 测试自动化
适于考虑进行自动化的测试工作
（1）测试用例的生成（包括测试输入、标准输出、测试操作指令等）
（2）测试的执行控制（包括单机与网络多机分布运行、夜间及假日运行、测试用例调用控制、测试对象、范围、版本控制等）
（3）测试结果与标准输出的对比。
（4）不吻合的测试结果的分析、记录、分类和通报
（5）总测试状况的统计，报表的产生。测试自动化与软件配置管理是密不可分的，与测试有关的资源都应在配置管理中统一考虑
0 条评论
下一页
