【软件评测师】基础理论篇:2 软件测试基础 ①

短命女 2022-09-17 01:57 270阅读 0赞

目录

watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6aG-5LiJ5q6H_size_20_color_FFFFFF_t_70_g_se_x_16



一、什么是软件测试

(1)粗浅说明:针对软件产品的检测,称为软件测试。

(2)各个历史时期代表性的软件测试定义:

① 1973 年(第 1 个定义新建):软件测试就是为了程序能够按预期设想运行而建立足够的信心。(“证真”:强调证实程序按预期运行)[ Bill Hetzel ]

② 1979 年:测试是为了发现错误而执行一个程序或者系统的过程。(“证伪”:强调测试目的是发现错误)[ Glenford J. Myers ]

③ 1983 年:使用人工或自动手段来运行或测定某个系统的过程,其目的在于检验它是否满足规定的需求或是弄预期结果与实际结果的差异。(强调识别实际结果与预期结果的差异)[ IEEE ]

④ 1983 年(第 1 个定义修订):测试是以评价一个程序或者系统的特性或能力为目标的一种活动。(强调对软件质量的度量)[ Bill Hetzel ]

⑤ 2014 年(最新的定义):是动态验证程序针对有限的测试用例集是否可产生期望的结果。(强调测试用例集的有限性特征和对程序是否满足期望结果的验证)(狭义定义:只定义了广义软件测试概念中的动态验证,没有包含静态验证及各类评审)[ IEEE ]

—— 任何时期的定义,软件测试的目的都是一致的,那就是 “保证软件质量”

(3)对于测试的组织者和实施者,想要获得恰当环境下的真实测试结果,需:

① 第一:需要明确测试对象的边界

② 第二:必须认识到环境对测试的影响



二、验证与确认 (V&V)

(1) 相关术语






























序号 术语 英文全称 英文简写 名词解释 备注
1 验证 Verification V 通过提供客观证据来证实规定需求已经得到满足 ① V&V:验证与确认
②“正确地做事”
③ 判断生产者是否正确地构造了软件
④ 依据:产品要求(需求规格)
⑤ 是生产者的内部要求
2 确认 Validation V 通过提供客观证据来证实针对某一特定预期用途或应用需求已经得到满足 ① V&V:验证与确认
②“做了正确的事”
③ 判断生产者是否构造了正确的软件
④ 依据:用户的应用要求(或许没有再需求规格走了得到完全真实体现)
⑤ 是生产者的外部要求


三、软件缺陷

(1)相关术语




































































序号 术语 英文全称 英文简写 名词解释 备注
1 缺陷 Defect Bug 软件的问题、错误以及因软件而引起的异常、故障、失效、偏差均称为软件缺陷。 ① 从产品内部看,缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题;虫产品外部看,缺陷是系统所需要实现的某种功能的失效或违背。 [IEEE 729-1983 定义]
② 工作产品中所出现的瑕疵或缺点,导致软件产品无法满足用户需求或者规格说明,需要修复或者替换。[国家标准 GB/T 32422-2015 定义]
2 错误 是软件缺陷的静态表现,是存在于软件中的一种缺陷
3 故障 是软件缺陷的动态表现,是因为软件的缺陷造成软件工作时出现的问题
4 失效 软件因为缺陷而导致的后果
5 异常 从文档或软件操作观察到偏离以前验证过的软件产品或引用的文档的任何事件 ① 异常是软件的表现不符合已经通过验证的(被认为是正确的)情况
② 异常会给软件的使用带来问题
6 缺陷的优先级 用于表达评估、解决和关闭缺陷的优先程度
7 缺陷的严重性 指缺陷引起失效的最大影响程度

(2)缺陷的属性分类






















































































































术语 属性 属性值 描述 备注
缺陷 状态
优先级 紧急 需要立即处理 解决后需立即发紧急修复版迭代
应在下一个可运行版本中解决 解决后无需立即发修复版迭代,可等集中修复后再发版迭代
应在第一个交付版本中解决 需要在上线前解决
期望第一个交付版本中解决 未能解决的,在第一个交付版本后升级到优先级“中”
无需在第一个交付版本中解决 可任意时间延期解决
严重性 阻塞 在纠正或发现合适的方法之前,测试无法进行
严重 主要操作被打乱,导致安全性受到影响
一般 主要操作受到影响但软件产品仍能继续运行
轻微 非主要操作受到影响
可忽略 操作未受影响
发生概率
影响质量特性的范围
引入的阶段
原因分析
解决方案
处置结果
处理风险
……(等20余项)

(3)其他说明

软件工程各阶段引入缺陷的比例为:

  • 需求分析阶段:40% 以上
  • 设计阶段:30% 以上
  • 编码阶段:30% 以上

—— 对需求和设计的评审,有助于降低缺陷的发生率

缺陷从产生到发现的间隔时间越短,修复的代价就越小,当缺陷从一个工程阶段跨入后一个工程阶段时,修复的代价将以指数级增长。

例如,需求阶段产生的一个缺陷,在需求阶段被发现并修复的代价假设为 1 ,那么:

  • 等到设计阶段再发现并修复的代价可能为 3~6 ;
  • 等到编码阶段再发现并修复的代价可能为 10 ;
  • 等到系统测试及交互测试阶段再发现并修复的代价可能为 20~70 ;
  • 等到产品已经发布阶段再发现并修复的代价可能为 100 。


四、测试与质量保证

(1)常见术语




























序号 术语 英文全称 英文简写 名词解释 备注
1 质量保证 Quality Assurance QA ① 为了提供足够的信任表明实体能够满足质量要求,而在质量管理体系中实施并根据需要进行证实的全部有计划和有系统的活动。
② QA 是以保证各项质量管理工作实际地、有效地进行与完成为目的的活动体系。
① 质量保证是系统性的活动或活动体系,涵盖的范围十分广泛,是企业级的系统性行为。
② 软件质量保证包含软件测试:保证软件质量的措施和手段有很多,测试是其中一种不可缺少的最为重要的手段。
③ 软件测试:技术性活动
④ 软件质量保证:管理性活动
2 软件质量 在规定条件下使用时,软件产品满足明确的或隐含的要求的能力


五、测试用例

(1)相关术语




































序号 术语 英文全称 英文简写 名词解释 备注
1 测试用例 Test Case 为某个特定目标而开发的输入、执行条件以及预期结果的集合 ① 测试用例是测试人员针对具体目标设计或开发出来的,有非常强的目的性
② 测试用例将体现软件的某一个具体运行实例或场景,包括输入的测试数据、执行条件、逻辑过程以及预期结果等
③ 测试用例须提供准确的判定准则,即按照该用例实施测试获得实际结果时如何判定
2 测试用例的设计 应当通过确定前置条件,选择输入值以及必要时执行所选测试覆盖项的操作,以及确定相应的预期结果来导出
3 测试脚本 Test Script 指一个特定测试的可以被自动化工具执行的一系列指令,脚本可以在工具中通过录制测试操作生成,也可以使用脚本语言直接编写 ① 被看成是测试工具执行的测试用例
② 但并没有测试用例多包涵的那么丰富的信息

(2)测试用例模板
















































































用例名称 属性 属性值 描述 备注
测试追踪 用例标识
用例说明
用例的初始化 硬件配置
软件配置
测试配置
参数配置
操作过程
序号 输入及操作说明 期望的测试结果 评价标准 备注
前提和约束
过程终止条件
结果评价标准
设计人员 设计日期


六、测试策略

(1)相关术语




















序号 术语 英文全称 英文简写 名词解释 备注
1 测试策略 是在一定的软件测试标准、测试规范的指导下,依据测试项目的特定环境而规定的软件测试的原则、方法的集合 ① 广义上说,测试策略是一套方法论,可以平衡测试时间、测试技术、测试人力、质量要求之间的关系,达到最佳测试效果,从而实现最大化的测试投入产出比
② 测试前期规划时,测试策略是计划中的重点内容,是测试最终成功的关键因素之一

(2)软件测试策略的划分






































术语 属性 属性值 描述 备注
测试策略 基于分析的策略 如风险分析、需求规格分析
基于模型的策略 如业务模型、软件质量模型、系统性能演化模型
基于标准规范的策略 如 GB/T 25000.51 标准、软件验收标准
基于自动化的回归的策略

(3)测试策略的属性分类








































































术语 属性 属性值 描述 备注
测试策略 输入 测试所需软硬件资源的详细说明
针对测试和进度约束,需要的人力资源的角色和职责
测试方法、测试标准和完成标准
目标系统的功能性和非功能性需求
系统局限 即系统不能满足的需求
……
输出 已批准或审核的测试策略文档、测试用例、测试计划
需要解决方案的测试项目
过程 确定测试的需求 ① 测试需求必须是可观测、可测评的
② 软件需求与测试需求以及测试用例不是一对一关系
③ 测试需求可能有很多来源
评估风险并确定测试优先级
确定测试策略 一个好的测试策略应该包括:实施的测试类型和测试目标、实施测试的阶段、技术、评估测试结果和测试是否完成的标准、对测试工作存在影响的特殊事项等。

发表评论

表情:
评论列表 (有 0 条评论,270人围观)

还没有评论,来说两句吧...

相关阅读