软件评测师:第一篇 测试原理

文章介绍了软件测试的起源、目的和重要性,以及测试与软件项目的关系。测试是为了发现错误,提高软件质量,降低项目风险。文中探讨了测试的不同阶段,如单元测试、集成测试、系统测试和验收测试,并提到了测试工作前移和外包趋势。此外,还讲解了软件质量的ISO9126模型,包括可靠性、可移植性、可维护性、易用性和效率等方面。最后,文章提到了自动化测试的优势和局限性,以及软件质量的评估标准。
摘要由CSDN通过智能技术生成

第1章 软件测试概述

1.1 概述

软件工程出现的原因:

软件危机的爆发

软件测试的定义

测试是为了发现错误而执行的一个程序或系统的过程——《软件测试艺术》

测试是以评价一个程序后者系统属性为目标的任何一种活动,是对软件质量的度量——《软件测试完全指南》

测试是为了度量和提高被测软件的质量,贯穿软件的整个生命周期——《系统的软件测试》

1.2 软件测试和软件项目的关系

软件测试的根本目的:提高软件质量,降低软件项目的风险

目的:将交付/发布的软件的错误控制在一个合理的范围内

软件测试只能证明软件存在错误,而不能证明软件没有错误

1.3 测试发展趋势

  • 测试工作前移

  • 与其他人员协调:架构师、开发、QA,矛盾统一

  • 专业化:独立部门、第三方机构外包

第2章 软件测试基础

2.1 软件测试相关概念

软件测试

对软件的文档、数据、程序进行测试,发现其中的错误,对软件质量进行评估,贯穿软件的整个生命周期。

软件质量

ISO 9126定义:软件满足规定或潜在的用户需求的能力,从内部质量、外部质量和使用中的表现来衡量

  • QA:着眼软件开发的过程、步骤和产物,不直接对软件本身的问题进行测试

  • 软件测试:不关心开发过程,只关心过程中的产物和软件本体,是保证软件质量的一环

验证与确认(V &V)

验证(Verification):验证软件是否满足需求说明书,实现需求说明书规定的所有特性

确认(Vaildation):验证软件是否有效,是否满足用户的预期用途和应用

软件缺陷(Bug)

软件失效的机理:软件错误→软件缺陷→软件故障→软件失效

  • 软件错误error:强调是软件存在人为错误,导致软件缺陷的产生

  • 软件缺陷defect:存在于软件(文档、数据、程序)的偏差,满足缺陷出现的一定条件时,缺陷被激活

  • 软件故障fault:软件运行过程中出现的不希望或不可接受的内部状态

  • 软件失效failure:软件运行时产生的不希望或不可接受的外部行为结果

软件缺陷的定义:

①软件未达到产品说明书中标明的功能

②软件出现了产品说明书中指明的不会出现的错误

③软件功能超出了产品说明书指明的范围

④软件未达到说明书虽未指出但应达到的目标

⑤测试人员认为软件难以理解、不易使用、运行速度慢,或用户认为不好使用的

Bug的生命周期

  • 新信息(New)/发现:

  • 打开(Open)

  • 修正(Fixed):若验证不通过则Reopen

  • 拒绝(Declined)

  • 延期(Deferred)

  • 关闭(Closed):Bug已被修复

2.2 软件测试的目的

目的

  • 测试的目的是发现错误

  • 好的测试用例在于能发现至今没发现的错误

  • 成功的测试是发现了至今没发现的错误

2.3 软件测试的原则

  • 溯源性原则:测试可追溯至客户需求

  • 工程性原则:软件测试应尽早介入、不断进行

  • 合理性原则:完全测试是不可能的,测试需要中止

  • 不完全性原则:测试不能证明缺陷不存在,无法显示潜在缺陷

  • 相关性原则:注意测试中缺陷的群集现象(二八原则)

  • 独立性原则:程序员应避免检查自己的程序

  • 可接受性原则:已发现的缺陷经过各方确认,可以不修复

  • 风险性原则:构造测试用例时避免影响软件工作,开展风险评估

2.4 软件测试的对象

  • 设计文档:需求规格说明、概要设计、详细设计

  • 源程序:单元测试、集成测试、系统测试、确认测试

  • 数据

2.5 软件测试的分类

2.5.1 按开发阶段

定义目的
单元测试(模块测试)对软件设计的最小单位——程序进行的测试验证详细设计中说明的功能
集成测试在单元测试的基础上,对程序模块进行有序、递增的测试验证单元或部件的接口关系
确认测试确认软件是否满足预期用途的需求检测软件是够满足软件说明书规定的要求
系统测试确认系统是否达到原始目标,对集成的软硬件进行测试检查软件能否和系统正确配置、连接,并满足用户需求
验收测试按照项目任务或合同、约定等验收依据文档测试并评审系统是否达到验收标准决定是否接收或拒收系统

2.5.2 按测试实施单位

  • 开发方测试(α测试):开发方在测试环境执行的测试,可与系统测试一起进行

  • 用户测试(β测试):应用环境下,用户的使用性测试(一般未达到验收测试级别,仅体验性使用)

  • 第三方测试:由技术、管理和财务上与开发方和用户方相对独立的组织进行、模拟用户真实应用环境下的软件确认测试。

2.5.3 按照测试技术划分

黑白灰

  • 白盒测试(结构性测试、静态测试)

  • 黑盒测试:在程序界面进行检查,仅检查程序是否按照规格说明书中的规定正确进行

  • 灰盒测试:及关注输出对于输入的合理性,又关注内部表现。

动静

  • 静态测试:走查、符号执行、需求确认

  • 动态测试:人工或使用工具执行测试

2.6 软件测试模型

2.6.1 V模型

单元测试、集成测试:验证程序执行是否满足设计要求

系统测试:功能、性能是否达到系统指标

验收测试、确认测试:追溯需求说明书,软件实现是否满足需求

局限性

将测试过程视作开发过程的后一阶段,容易忽略文档设计阶段隐藏的问题

2.6.2 W模型

基于“尽早地和不断地进行软件测试”原则,针对V模型的补充和完善,强调测试伴随整个软件开发周期,测试对象除程序还包括需求、功能、设计。

局限性

仍然依赖开发,具有串行的特点

2.6.3 H模型

体现测试独立的流程

软件测试过程模型的种类之--H模型_测试管理_领测软件测试网

2.6.4 敏捷测试模型

与敏捷开发对应,强调迭代,循序渐进

2.7 软件测试策略

输入

  • 测试软硬件资源的详细说明

  • 针对测试和进度的限制,人力资源

  • 测试方法、测试标准和完成标准

  • 系统的功能性和非功能性需求指标、技术指标

  • 系统局限(系统不能实现的功能)

输出

  • 已经批准的测试策略、测试计划、测试用例文档

  • 确定测试的额需求

  • 评估测试风险和测试优先级

  • 确定测试策略

2.8 自动化测试

优点

  • 提高软件质量:软件迭代中用于测试重复的内容,避免人为因素影响

  • 提高测试效率

  • 提高测试覆盖率

  • 执行手工测试无法完成的测试:压力测试、负载测试、大数据量测试

  • 便于重现缺陷

局限性

  • 定制型项目

  • 短周期项目

  • 业务规则复杂的项目:投入自动化的人力较多

  • 人体观感与易用性

  • 不稳定的软件

  • 涉及物理交互

第3章 软件评测标准

3.1 质量的定义

实体特性的总和,满足明确的和隐含要求的能力

3.2 软件质量模型

ISO 9126

  • 可靠性(RELIABILITY)

    成熟性、容错性、易恢复性

  • 可移植性(PROTABILITY)

    适应性、易安装性、一致性、易替换性

  • 可维护性(MAINTAINABILITY)

    易分析性、易更改性、稳定性、易测试性

  • 易用性(USABILITY)

    易理解性、易学习性、易操作性、用户差错防御性

  • 功能性(FUNCTIONALITY):

    适合性、准确性、功能依从性、安全性、(互操作性)

  • 效率(EFFICIENCY)

    时间特性、资源特性、容量

GB/T 25000,增加下面两个方面

  • 兼容性

    共存性、互操作性、兼容依从性

  • 信息安全性

    保密性、完整性、抗抵赖性、真实性、可核查性

3.3 使用质量的质量模型

(1)有效性:实现指定目标的准确性和完备性

(2)效率/生产率:实现有效性的资源消耗

(3)满意度:用户要求被满足的程度,用户的心理状态

(4)抗风险:包括经济风险、(人的)健康风险、安全风险

(5)周境覆盖:在特定环境下,有效性、效率、满意度、抗风险的实现能否达到使用要求

3.4 成本估算

UW=TW+SR+DR

UW:未调整的软件测试人工工作量

TW:软件测试工作量

SR:产品说明评审工作量,SR=TW×10%

DR:用户文档集评审工作量,SR=TW×20%

目前感觉不是很重要,略,后面遇到再补充吧

4.1 测试过程模型

4.2 组织级测试过程

组织级测试规格说明

特点:适用于整个组织的测试,不面向具体项目

  • 组织级测试方针:执行级文档,描述测试目的、目标、总体范围

  • 组织级测试策略:技术性通用文档,指导如何在组织内执行测试

4.3 测试管理过程

环节输入结果输出
测试策划过程组织级测试策略、组织级测试方针;项目测试计划、项目管理计划确定测试范围、测试风险、测试策略、测试环境、测试工具、人员配置等测试计划
测试设计和实现过程测试计划、测试策略、测试技术设计导出测试条件、测试用例、测试集测试用例、测试规格说明、测试数据需求、测试环境需求
测试环境构建和维护过程测试计划、测试环境需求测试环境就绪测试环境准备报告、测试数据、测试环境
测试执行过程测试计划、测试项、(测试环境准备报告)记录测试结果、比较实测和预期结果、确定测试结果实测结果、测试结果、测试执行日志
测试事件报告过程测试结果、测试用例、测试项、(测试执行日志)分析测试结果、创建或更新事件报告事件报告
测试监测和控制过程测试计划、产品文档、组织级测试策略和方针、控制指令、测度监测测试计划进度、控制风险、批准停止测试决定测试状态报告、测试计划变更、控制指令、产品和项目风险信息
测试完成过程测试计划、事件报告、测试状态报告验证测试要求、编写批准测试完成报告测试完成报告

4.4 静态测试过程

代码走查:由编写代码的程序员来组织讨论
,非正式

代码审查:由高级管理人员来领导评审
,正式评审活动


评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值