软考中级—软件评测师 备考笔记:测试基础

目录

软件测试基础

基本概念

  • 需求分析和设计阶段产生的缺陷很隐蔽

  • 缺陷从产生到发现的间隔时间越短,修复的代价就越小

  • 保证软件质量的措施和手段有很多,测试是其中一种

  • 软件测试更多的表现为技术性活动,而软件质量保证保证则是管理性活动更明显

检验与确认

  • 验证是检验软件是否满足规格说明的需求
  • 确认是检验软件师傅有效,是否满足用户的预期用途和应用需求
  • 通过验证的软件不一定能够通过确认

软件测试的原则

  1. 溯源性原则(测试应当溯源到原始需求)
  2. 工程性原则(测试贯穿软件生产的各阶段,应尽早开展测试)
  3. 独立性原则(避免开发工程师测试自己的程序)
  4. 合理性原则(无法对软件开展穷举式的测试)
  5. 不完全性原则(测试都不能暴露全部的缺陷)
  6. 相关性原则(缺陷常常有聚集现象)
  7. 可接受性原则(已发现的缺陷不一定全部修复)
  8. 风险性原则(测试本身也是有风险的)

产品质量模型

特性"字" 特性 子特性"词" 子特性
八大特性 功效简易,全靠位置 功能性、性能效率、兼容性、易用性、信息安全性、 可靠性、维护性、可移植性
功能性 功能完备,正确适合 功能完备性、功能准确性、功能适合性、功能性的依从性
性能效率 时间、资源的容量 时间特性、资源利用率、容量、性能效率的依从性
兼容性 共存互操作 共存性、互操作性、兼容性的依从性
易用性 辨识学习易操作、以防界面出差错 可辨识性、易学性、易操作性、易访问性、 用户界面舒适性、用户差错防御性、易用性的依从性
信息安全性 保密完整抗抵赖,全为核查真实性 保密性、完整性、抗抵赖性、可核查性、真实性、 信息安全性的依从性
可靠性 恢复容错,成熟可用 易恢复性、容错性、成熟性、可用性、可靠性的依从性
维护性 为了测试各模块,分析修改可重用 易测试性、模块化、易分析性、易修改性、可重用性、维护性的依从性
可移植性 适应安装易替换 适应性、易安装性、易替换性、可移植性的依从性

完备性:完成需求情况

正确性:正确实现情况

适合性:完备且正确

兼容性:与其他软件是否兼容,是否支持其他软件共存、互相调用、交换信息等操作

易访问性:无障碍,跨语言能力

保密性:访问控制性(内容保密、最小权限原则)数据加密正确性(数据保密)

可移植性:在其他设备是否可以使用,跨平台使用

真实性:认证机制,唯一标识

可核查性:确定是谁做的,即:"谁"干了什么,实体的活动可以被唯一地追溯到该实体的程度

抗抵赖性:确定身份,不可否认。使用数字签名,确定发送和接收事实:对事务进行数字签名,可为数据原发者或接收者提供数据原发和接收证据

符合性:符合声明使用的标准、认证

依从性:执行相关法规、标准

使用质量模型

特性"字" 特性 子特性"词" 子特性
使用质量模型 效效满抗,周境覆盖 有效性、效率、满意度、抗风险、周境覆盖
有效性 有效性
效率 效率
满意度 用信舒愉 有用性、可信性、舒适性、愉悦性
抗风险 缓解经济及环境,依赖健康和安全 经济风险缓解性、环境风险缓解性、 健康和安全风险缓解性
周境覆盖 周境覆盖 周境完备还灵活 周境完备性、灵活性

测试用例

  • 输入、执行条件及预期结果
  • 避免测试的随意性和盲目性
  • 测试用例是软件企业的一类资产,是企业成熟度的一个表现

测试策略

  • 平衡测试时间、测试技术、测试人力、质量要求之间的平衡

软件测试的原则

1.溯源性原则

测试应当溯源到原始需求,而不仅仅只盯着眼前。

  1. 工程性原则

贯穿软件生产的各阶段。即全生命周期。

  1. 独立性原则

应当避免开发工程师测试自己的程序,对同一内容开发与测试角色要拆开,避免灯下黑。

  1. 合理性原则

对软件进行完全测试是不合理的。

  1. 不完全性原则

测试不能暴露全部缺陷。

  1. 相关性原则

缺陷常常有聚集现象。

  1. 可接受性原则

可以允许某些缺陷遗留在软件中。

  1. 风险性原则

测试本身也是有风险的。

测试过程相关模型

V模型

编码之后才开始测试活动

W模型

两个V的叠加,一个V描述开发过程,一个V描述测试过程

开发过程 测试过程 关注重点
需求分析 测试目标
概要设计 测试计划
详细设计 用例设计
编码 单元测试 仅专注于当前的单元代码,单元测试时很少关心功能设计的内容和需求的内容。寻找代码缺陷:如笔误,或代码级别的逻辑错误。常见的误区之一是将所有的软件缺陷都归结为代码错误。编码笔误、变量、逻辑错误。 最大的单元是模块,最小的单元是函数。
缺陷修复 集成测试 识别功能设计或架构设计的错误造成的风险。设计错误。 对于复杂度较低的系统,不安排集成测试也非常常见。
缺陷修复 系统测试 发现软件需求的错误。
缺陷修复 验收测试

W模型实际是两个V的叠加,将开发&测试的混合V模型,拆分成一个V描述需求设计和开发一个V描述测试阶段,合二为一成为W。

H模型

H模型将开发流程和测试流程都独立出来,只要测试条件(环境满足)即开展测试。

敏捷测试模型

  • 主张简单、拥抱变化、递增和快速反馈
  • 需要与开发流程良好融合

软件测试的分类

按工程阶段划分

  1. 单元测试
  • 模块接口测试
  • 局部数据结构测试
  • 路径测试
  • 错误处理测试
  • 边界测试

也称模块测试,测试一个模块,具有数据输入、处理及输出的基本特征

各个模块可以并行进行,可能需要构造驱动模块或桩模块来支持单元测试
#mermaid-svg-L2P1j76hKaffOuQF{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-L2P1j76hKaffOuQF .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-L2P1j76hKaffOuQF .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-L2P1j76hKaffOuQF .error-icon{fill:#552222;}#mermaid-svg-L2P1j76hKaffOuQF .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-L2P1j76hKaffOuQF .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-L2P1j76hKaffOuQF .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-L2P1j76hKaffOuQF .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-L2P1j76hKaffOuQF .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-L2P1j76hKaffOuQF .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-L2P1j76hKaffOuQF .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-L2P1j76hKaffOuQF .marker{fill:#333333;stroke:#333333;}#mermaid-svg-L2P1j76hKaffOuQF .marker.cross{stroke:#333333;}#mermaid-svg-L2P1j76hKaffOuQF svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-L2P1j76hKaffOuQF p{margin:0;}#mermaid-svg-L2P1j76hKaffOuQF .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-L2P1j76hKaffOuQF .cluster-label text{fill:#333;}#mermaid-svg-L2P1j76hKaffOuQF .cluster-label span{color:#333;}#mermaid-svg-L2P1j76hKaffOuQF .cluster-label span p{background-color:transparent;}#mermaid-svg-L2P1j76hKaffOuQF .label text,#mermaid-svg-L2P1j76hKaffOuQF span{fill:#333;color:#333;}#mermaid-svg-L2P1j76hKaffOuQF .node rect,#mermaid-svg-L2P1j76hKaffOuQF .node circle,#mermaid-svg-L2P1j76hKaffOuQF .node ellipse,#mermaid-svg-L2P1j76hKaffOuQF .node polygon,#mermaid-svg-L2P1j76hKaffOuQF .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-L2P1j76hKaffOuQF .rough-node .label text,#mermaid-svg-L2P1j76hKaffOuQF .node .label text,#mermaid-svg-L2P1j76hKaffOuQF .image-shape .label,#mermaid-svg-L2P1j76hKaffOuQF .icon-shape .label{text-anchor:middle;}#mermaid-svg-L2P1j76hKaffOuQF .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-L2P1j76hKaffOuQF .rough-node .label,#mermaid-svg-L2P1j76hKaffOuQF .node .label,#mermaid-svg-L2P1j76hKaffOuQF .image-shape .label,#mermaid-svg-L2P1j76hKaffOuQF .icon-shape .label{text-align:center;}#mermaid-svg-L2P1j76hKaffOuQF .node.clickable{cursor:pointer;}#mermaid-svg-L2P1j76hKaffOuQF .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-L2P1j76hKaffOuQF .arrowheadPath{fill:#333333;}#mermaid-svg-L2P1j76hKaffOuQF .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-L2P1j76hKaffOuQF .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-L2P1j76hKaffOuQF .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-L2P1j76hKaffOuQF .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-L2P1j76hKaffOuQF .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-L2P1j76hKaffOuQF .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-L2P1j76hKaffOuQF .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-L2P1j76hKaffOuQF .cluster text{fill:#333;}#mermaid-svg-L2P1j76hKaffOuQF .cluster span{color:#333;}#mermaid-svg-L2P1j76hKaffOuQF div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-L2P1j76hKaffOuQF .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-L2P1j76hKaffOuQF rect.text{fill:none;stroke-width:0;}#mermaid-svg-L2P1j76hKaffOuQF .icon-shape,#mermaid-svg-L2P1j76hKaffOuQF .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-L2P1j76hKaffOuQF .icon-shape p,#mermaid-svg-L2P1j76hKaffOuQF .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-L2P1j76hKaffOuQF .icon-shape .label rect,#mermaid-svg-L2P1j76hKaffOuQF .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-L2P1j76hKaffOuQF .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-L2P1j76hKaffOuQF .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-L2P1j76hKaffOuQF :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 调用
触发
驱动模块
待测模块
桩模块(log也是一种插桩)

  1. 集成测试
  • 一次性组装方式
  • 增殖式组装方式

集成测试的主要任务是发现单元之间的接口(验证数据协议是否一致)可能存在的问题

即验证模块之间的通信协议是否一致

  1. 系统测试

系统测试的目标是确认软件的应用系统能否如预期工作并满足应用的需求

系统测试不能由开发团队实施(但一般仍由开发方实施)

相当于团队内部验收

  1. 确认测试

焦点由系统正常运行改为与交付相关的验证和确认上,与系统测试相似

确认测试又称有效性测试

由软件开发方组织

  1. 验收测试

焦点由系统正常运行改为与交付相关的验证和确认上,与系统测试相似

由用户方组织

按是否执行代码划分

  • 动态测试

通过运行软件来发现错误或验证程序是否符合预期要求

  • 静态测试

静态测试不运行代码

测试对象包括需求文档、设计文档、产品规格说明书以及代码,即各类文件文档及代码源码

可以及时发现更多的错误,减少动态测试的压力,降低错误修改的成本,更好的保证软件质量
静态评审包括内部评审和外部评审

  • 内部评审:对程序逻辑,偏重技术层面。
  • 外部评审:对需求分析,不关心实现,外部评审需要用户代表参加,也可以邀请领域专家参加

按测试实施主体划分

  • 开发方(供方)测试

开发方测试注重开发过程中测试

涵盖软件生产及交付的各个阶段

强调对软件"证真"

能够高效与开发团队沟通

容易遗漏对软件缺陷的暴露,或者忽视用户的需求

  • 用户方(需方)测试

只能进行黑盒测试

用户方测试只能验收测试

缺乏专业人员

更好地确认软件是否符合自身的需求

  • 第三方(独立评价方)测试

只能进行黑盒测试

第三方测试以专业素养对已完成系统进行测试

公平公正的地位

高度专业化的团队,丰富的测试经验,完备的测试工具

主要开展确认测试(开发方委托)、验收测试(用户方委托)、符合性测试

也可接受其他用途的委托测试

按是否关联代码划分

  • 白盒测试

也称结构化测试、逻辑驱动测试、基于代码的测试

能看见内部实现

对程序完全覆盖是不可能的

  • 黑盒测试

又称功能测试、基于规格说明的测试

无法看到内部实现

只关心程序的输入和输出

依据需求规格说明

用户方测试和第三方测试只能进行黑盒测试
速记:白盒看代码,黑盒看需求

  • 灰盒测试

较多运用于集成测试中

软件质量特性划分

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

按符合性评价要求划分

判定软件是否符合事先已经明确的文件性要求和约束,即文件符合性

最好由具备资质的第三方测试机构开展

更类似于系统测试、确认测试、验收测试,需要具备系统完备性才可进行测试。

接受需方的验收测试,也是一种符合性测试

合同符合性测试:依据招投标文件或合同相关约定
要有准确的描述,不能模棱两可,需要详细到可以在不同时期进行验证,例如运行环境等等条件约束。

回归测试

只要软件发生了变化,都应该进行回归测试,原来正确的功能可能受到影响

由改动点扩散到周边进行测试

每一次回归测试可能需要设计一些新的测试用例,同时也会复用已经建立的许多测试用例

软件测试相关标准

公共标准与私有标准

  • 公共标准: 国际标准,国家标准,行业标准,地方标准等公共标准的宗旨是维护公共秩序

  • 私有标准:行业标准、企业标准属于私有标准,提高竞争力,获取实施标准带来的收益(获取收益是私有标准)

  • 国际标准-->国家标准-->行业标准-->地方标准-->团体标准-->企业标准

工作量及成本评估标准

  • 对软件系统进行穷尽测试是一项不可能完成的任务
  • 软件测试成本包含直接成本和间接成本

直接成本

  • 测试人力成本:产品说明评审、用户文档集评审、软件测试三部分
  • 测试环境成本:测试执行过程中所需的软硬件环境、测试设计和实现过程中所需的软硬件环境,测试环境成本指的是人力成本,即搭建环境所需的人力开销,而不是软硬件设备本身的成本
  • 测试工具成本是测试过程中所使用到的软硬件工具的成本
    间接成本:办公成本和管理成本

软件测试过程和管理

  • 组织级测试过程

组织级测试过程是一个通用过程,不面向具体项目,而是适用于整个组织的测试

  • 单个测试覆盖项可以实现多个测试条件
  • 在一个测试用例中组合多个测试覆盖项的覆盖范围,这可以减少测试执行时间。