【软件评测】11软件测试理论

仅为学习记录~

软件测试基础

软件测试

软件测试

软件测试的定义

• 73年的第一个定义–程序能够按照预想的设计去运行而给出的信心（83年修订后为系统的特性和能力为目标的一种活动
• 79年给出了新的定义–为了发现错误而执行系统的目的，称为“证伪”
• 83年–使用人工或自动手段来运行和测试某个系统的过程，目的是是否满足了规定的需求，弄清预计结果和实际结果的差距，这个定义开始像质量方面靠拢
• 14年-发布了软件工程知识体系SWEBOK3.0，强调的是动态验证计算机程序对有限的测试用例集是否可产生期望的结果

软件测试的对象–程序、数据和文档

软件测试的目的–保证软件质量，保证软件和系统符合相关法律、技术标准、应用需求，降低软件产品的产品风险和应用风险

验证与确认

GB/T给出了验证与确认的描述，称为V&V
验证–对应的是需求，找相关的客观证据来证实规定的需求已经得到了满足
确认–通过提供客观证据来证明针对某一功能和特定应用需求得到了满足

软件缺陷

GB/T32422的定义，软件中出现了瑕疵或缺点，导致无法满足用户的需求或者规格说明书的要求，称为缺陷

软件缺陷主要产生在需求分析阶段和设计阶段，需求分析阶段40%，设计阶段30%，编码阶段30%

需求分析阶段（通过评审可以降低缺陷率）

• 客户描述不够清晰，造成需求不明确
• 需求频繁变更
• 用户和软件开发人员的沟通问题
• 获取需求查验的方式（调查问卷、当面沟通）有待提高

设计阶段–缺陷较隐蔽，通过评审可以降低缺陷率

编码阶段–缺陷较容易发现

缺陷越早发现，修复代价越低


优先级用于表达、评估、解决缺陷的优先程度

严重性指缺陷失效后最大的影响程度

测试质量与保证

软件质量

GB/T25000.1指在规定条件下软件产品满足明确或隐含要求的能力

质量保证

质量保证是以保证各项质量管理工作实际有效的进行和完成为目的的活动体系

质量保证是管理性活动

软件测试是技术性活动

软件测试是质量保证活动中的一个子项，是质量保证中一个很重要的技术手段

测试用例

测试用例–为某个特定目的而开发的输入、执行条件、预期结果的一个集合

要点

• 目的性强
• 需要有特定目的下的运行环境
• 要提供判定准则

作用

• 测试实施的依据
• 体现了测试的方案、方法、技术和策略
• 保证测试的规范性，提高测试效率
• 保证测试质量，避免随意性和盲目性
• 作为软件企业的一类资产
  

测试策略

测试策略是软件测试的原则、方法的集合

测试策略的方法

• 基于分析的策略
• 基于模型的策略
• 基于标准规范的策略
• 基于自动化的回归测试策略

软件策略的确定主要是测试的需求以及测试风险的评估结果来决定，基于测试需求、风险评估结果去定义测试的范围、要求，选择合适的测试方法，然后去制定测试启动、测试停止、测试完成的标准和条件

测试策略的输入

• 测试所需软硬件资源的详细说明
• 需要的人力资源的角色和职责
• 测试方法、测试标准和完成标准
• 目标系统的功能性和非功能性需求、技术指标

测试策略的输出

• 已批准或审核的测试策略文档、测试用例和测试计划
• 需要解决方案的测试项目

制定测试策略过程

1. 确定测试需求

测试需求必须是可观测、可测评的
软件需求与测试需求以及测试用例不是一对一关系
测试需求可能有许多来源

2. 评估风险并确定优先级
3. 确定测试策略

测试的原则

• 溯源性原则–追溯到原始需求，旧版本称为溯源
• 工程性原则–需尽早地不断地开展测试
• 独立性原则–避免开发人员自己测试自己的程序（在旧版本中，测试人员可以进行单元测试）
• 合理性原则–无法对软件进行穷举，无法进行彻底的测试，在质量的要求和测试强度之前找到合理的点，设置测测试的增值条件
• 不完全性原则–测试显示软件中缺陷的存在，但不能证明软件不存在缺陷。也就是说，软件测试可以降低软件中未发现的缺陷的可能性，但是即使没有发现缺陷，也不能证明其正确性
• 相关性原则–一个功能模块发现的缺陷越高，那存在的未被发现的缺陷也越高，故发现的缺陷与未发现的缺陷成正比，旧版称为群集性原则
• 可接受性原则–在利益相关方可接受的情况下，允许某些缺陷的存在
• 风险性原则–测试本身是有风险的

软件测试模型

V模型

V模型是对瀑布模型的优化，强调了测试的重要性，从本质上还是没有改变瀑布模型的特点
左边部分表示开发阶段，右边部分表示测试阶段

W模型

体现了测试工作应尽早和不断地开始的原则（工程性原则）
第一个V表示开发过程，第二个V表示测试过程
W模型仍然没有把软件测试独立出来，还是依赖于开发过程

H模型

H模型把测试流程从开发过程中独立了出来，不需依赖于开发过程
在软件开发过程中，任何一个时间点上，只要具备了测试的条件，就开展测试工作，兼顾了测试的效率和联合性，适用于各种规模的软件测试

敏捷测试模型

以应付需求为核心，进行持续、有意义的沟通和迭代，强调的是各方人员之间的相互协作
敏捷测试模型对测试人员要求较高，要求测试人员沟通高效、理解需求能力足够

软件测试分类

回归测试

软件有变动的情况需要进行回归测试

• 对缺陷修复–首先验证缺陷是否正确修复、然后测试缺陷修复可能影响到的功能是否正确
• 对新增功能–验证新功能的正确性、测试可能受到影响的其他功能
• 对删减功能–检测是否影响到保留的功能

按照关联代码划分

• 白盒测试–也称为结构测试、逻辑驱动测试、基于结构代码的测试。基于程序内部结构来设计测试用例
• 黑盒测试–把软件看成一个不透明的盒子，只关注软件的功能、规格说明书和特性，不关注内部结构

按实施主体划分

• 开发方测试–开发方在开发环境下测试，比如说α测试
• 用户测试–用户在用户的应用环境下测试，比如说β测试
• 第三方测试–以第三方为主体的测试（技术、财务、管理独立于开发方、用户方的组织）

按工程阶段划分

• 单元测试–单元为软件中最小的单位，可以表现为一个函数、一个过程、一个类，主要依据为模块的详细设计文档，测试价值为尽早地发现问题，降低成本，也称为模块测试。单元测试可由测试人员和开发人员共同完成。单元测试的测试内容包括模块接口、出错处理、局部数据、独立路径、模块、边界条件
• 集成测试–去发现单元、接口之间可能存在的问题，涉及的输入文档为概要设计说明书、详细设计说明书。一次性组装为big bang，还有增值组装

组装时需要考虑的问题
1.在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失
2.一个模块的功能是否回对另一个模块的功能产生不利的影响
3.各个子功能组合起来，能否达到预期要求的父功能
4.全局数据结构是否有问题
5.单个模块的误差累积起来，是否会放大，以致达到不能接受的程度

模块组装方式
一次性组装方式：节省人力，如果没有问题的话成立，在测试过程中发现问题时，很难定位问题出现在哪里，反而浪费工时
增量式组装方式：
1.自顶向下的增量方式
2.自底向上的增量方式
桩模块/驱动模块–是一个底层的驱动模块

• 系统测试–将软件整个结合在一起，以需求规格说明书的要求逐一地去验证系统的质量
• 确认测试–也叫做有效性测试，一般由开发方组织，去验证软件的有效性，以需求规格说明书来确认和验证的有效性，还需要做软件配置的复查工作
• 验收测试–以用户为主的测试，一般使用生产中的实际数据进行测试，决定是否接受或拒收系统

按执行代码划分

• 动态测试–黑盒测试、白盒测试、灰盒测试
• 静态测试–代码审查、代码走查

按质量特性划分

• 功能测试
• 性能效率测试
• 兼容性测试
• 易用性测试
• 可靠性测试
• 信息安全性测试
• 维护性测试
• 可移植性测试

按符合性情况划分

• 符合性测试–按照相关的标准、合同来进行符合性的检查

软件评测标准

标准化概述

标准–为了在一定范围内获得最佳秩序经协商一致，并由公认机构批准共同使用和重复使用的一种规范性文档，是标准化活动的核心产物

标准化–为了获得在一定范围内的最佳秩序，对现实的问题和潜在问题，制定共同使用和重复使用的条款的一种活动

软件测试标准化的作用

• 建立了软件测试最佳秩序的一个工具
• 促进了软件测试技术的创新和应用的途径
• 扩大推广了软件测试的技术

标准分类

• 国际标准–任何的国际组织公布的标准
• 国家标准–作用于国家行政管理范围内
• 行业标准–国家相关行业的行政主管编写和公布的
• 地方标准–各个区域的地方政府制定的
• 团体标准–相关团体自行制定的，自愿采用
• 企业标准–由企业指定的人员发布的，作用标准在企业内

软件测试相关的主要标准

• 软件质量标准–主要用于解决产品质量如何来进行评价、怎么评价的问题
• 软件测试文档和技术标准–支撑软件质量中各个质量特性，以及策动取值和评价，并给出了相关测试的过程、测试文档、测试技术
• 软件测试工作量及成本估算标准–控制成本和成本管理的决策的一种量化方法

软件质量模型与评价标准

软件质量标准的发展

软件质量模型的发展

1. 第一阶段：ISO/IEC9126:1991《软件工程 产品质量》对软件产品提出了6个方面的质量特性（功能性、可靠性、易用性、效率、维护性、可移植性）
2. 第二阶段–ISO/IEC9126:2001《软件工程 产品质量第1部分：软件模型》和3个质量度量标准。将软件质量分为内部质量、外部质量和使用质量（有效性、生产率、安全性、满意度）
3. 第三阶段–ISO/IEC 25000系列标准，将软件内部和外部质量更改为软件产品质量，产品的特性由原来的8个改为8个（多了兼容性和信息安全性），使用质量更改为有效性、效率、满意度、抗风险、周境覆盖，增加了IT服务质量（适宜性、可用性、安全性、可靠性、有形性、响应性、适应性、可维护性）和数据质量（准确性、完备性、一致性、确实性、现时性、可访问性、依从性、保密性、效率、精度、可跟踪性、可理解性、可用性、可移植性、可恢复性）的模型

使用质量

使用质量–从用户角度来看待软件的质量
有效性–用户实现确定目标的准确性和完备性
效率–用户实现目标准确性和完备性过程中所消耗的资源的情况
满意度–产品在指定的使用周境中用户要求满足的程度
抗风险性–产品或系统在经济状况、人的生命健康、环境潜在的风险因素
周境覆盖–在指定的周境中，能够被使用的程度

产品质量：系统/软件产品质量

• 功能性–在指定的条件下使用，产品或系统提供满足用户明确或隐含功能的程度，功能的特性：完备性、正确性、适合性、依从性
  测试方法：等价类、边界值法、因果图法、判定表法、场景法

  用例：正常用例、异常用例

完备性–功能集对指定用户的覆盖程度，X=1-A/B
正确性–提供所需的精度,X=1-A/B
适合性–功能与指定任务之间的实现程度，X=1-A/B
依从性–对相关标准、约定的遵循程度

• 性能效率–在指定的使用条件下，使用资源量的有关情况，性能效率的特性：时间特性、资源利用率、容量、性能效率的依从性

时间特性–响应时间、处理时间、吞吐率是否满足需求
资源利用率–所使用的资源数量、资源类型满足需求的程度
容量–参数最大需求的程度，对象处理大量的数据，确定是否达到了将使软件发生故障的极限；给定时间内，能够持续处理的最大负载或工作量

测试类型：基准测试、并发测试、压力测试、负载测试、稳定性测试、极限测试、场景测试、吞吐量测试

• 兼容性–共享相同的硬件和软件环境的条件下，产品系统或组件能够与其他产品能够执行信息的交换以及执行所需功能的程度，兼容性的特性：共存性、互操作性、兼容性的依从性

共存性–在与其他产品共享通用的环境，或者共享资源的环境下，产品能够有效执行所需的功能，且不会对其他产品功能造成影响的程度
互操作性–各组件之间能够进行数据的交换

• 易用性–在特性的使用周境中，产品系统在有效性、效率、满意度等方面为了指定目标可为用户去使用的程度，易用性的特性：可辨识性、易学性、易操作性、用户差错防御性、用户界面舒适性、易访问性、易用性的依从性

可辨识性–用户能够辨识产品是否能够完成其目标的程度。描述的完整率、演示覆盖率、产品标识可辨识、入口点的自描述性
易学性–学习使用产品的程度。帮助系统和文档的完整性、自动填充默认输入字段、差错信息易理解性、用户界面的自解释性
易操作性–操作和控制的难易程度。操作一致性、消息的明确性、功能的易定制性
用户差错防御性–预防用户犯错的程度。抵御误操作、用户输入差错纠正
用户界面舒适性–让用户感到舒服的程度
易访问性–广泛特征为个体使用的程度。特殊群体的易访问性、支持的语种的充分性

• 可靠性–在指定环境下指定时间内完成指定功能的程度，可靠性的特性：成熟性、可用性、容错性、易恢复性、可靠性的依从性

成熟性–在正常运行下，满足可靠性要求的程度。故障密度、故障修复率、平均失效间隔时间（MTBF）、周期失效率
可用性–在需要使用时，能够进行数据操作。系统可用性、平均宕机时间
容错性–硬件发生错误时，软件是否能正常运行。避免失效率、组件的冗余度
易恢复性–软件失效时，是否能恢复受影响的数据，以及重建的程度。平均恢复时间、数据备份完整性、数据恢复能力

• 信息安全性–产品或者系统保护信息和数据的程度，使其他用户按照授予的权限访问软件系统，信息安全的特性：保密性、完整性、抗抵赖性、可核查性、真实性、信息安全的依从性

保密性–只有被授权的用户才可以访问。访问控制性、数据加密正确性
完整性–防止非授权的访问和篡改计算机的程度
抗抵赖性–活动发生后能够正视且不否认的程度
可核查性–实体活动可以进行追溯的程度。用户审计跟踪的完整性、系统日志存储
真实性–对身份、标识进行核实符合其声明的程度。鉴别机制的充分性、鉴别规则的符合性

• 可维护性–能够被预期的维护人员进行有效的修改和效率的程度，维护性的特性：模块化、可重用性、易分析性、易修改性、易测试性、维护性的依从性

模块化–组件发生变更后，对其他组件影响的程度
可重用性–资产能够被重复利用于多个系统或用于其他资产建设的程度。资产的可重用性、编码规则符合ing
易分析性–评估变更的难易程度。日志完整性、诊断功能有效性
易修改性–被有效修改而不会引入新的缺陷。扩充系统应用、软件版本更新方式、软件版本更新时的数据操作、系统参数配置、用户权限配置
易测试性–是否满足有效性和效率的程度

• 可移植性–系统和软件产品从一个环境下迁移到另一个环境的下的有效性和效率程度，可移植性的特性：适应性、易安装性、易替换性、可移植性的依从性

适应性–在软件环境变更下，能够有效率的去使用的程度
易安装性–安装卸载的有效性和效率
易替换性–产品能够替换另一个同样用途产品的程度

软件质量、模型、测度、测量函数之间的关系

• 确定评价需求–确定评价目的、评价的产品质量需求、标识待测产品相关的部件、待测产品规定的严格程度
• 规定评价–测量的测度、测度判断的准则、评价判断的准则
• 设计评价–策划评价相关的活动
• 执行评价–实时测量工作、应用选定的测试标准进行验证
• 结束评价–评审评价结果、编制评价报告、评审质量反馈

就绪可用产品（RUSP）

RUSP–直接就可以使用的产品

RUSP要求–产品说明要求、用户文档集要求、软件质量要求

测试文档集要求–规定了对产品进行测试时，需要整理编写的测试文档的集合

符合性评价细则–适用于产品的说明、交互的软件

软件测试标准

38534修改采用了国际标准29119，主要适用于企业和评测机构，去规范测试过程，建立自己的软件测试流程，提高测试人员的能力

测试过程标准

组织级测试过程

定义了开发和管理组织级测试规格说明书的过程，包括组织级测试方针、策略、规程、资产的维护

组织级测试过程的输入

• 主要利益相关方的观点
• 组织内当前测试实践和知识体系
• 组织使用宣言
• IT仿真，及IT项目管理方针
• 质量方针
• 组织级测试方针
• 组织级测试策略
• 对测试规格说明的反馈
• 组织机构的典型测试计划
• 产业和政府标准

活动和任务

• 家里组织级测试规格说明
• 监测和控制组织级测试规格说明的使用
• 更新组织级测试规格说明

结果

• 确定组织级测试规格说明