了解软件的范在特性、可靠性问题以及缺陷、错误、故障和失效 ;了解软件测试基本概念;
1.软件的泛在特性
软件是人脑智力的一种具体形式的体现。软件是信息与数据处理系统的 ‘血与肉’,是现代信息技术的‘灵魂’。 软件在现实世界里,具有‘无孔不入、无处不在、超强控制’的泛在特 性
2.软件的可靠性问题;
IEEE组织定义的软件可靠性:系统在特定环境下,在给定的时间内无故障 运行的概率。
3。软件的缺陷、错误、故障与失效
软件中存在 缺陷或错误几乎无可避免
软件缺陷或故障(在运行时发生),可依据其可能造成的危害及风险程 度,分为极其严重、严重、一般、轻微等不同级别
1)软件缺陷、错误与故障、失效的定义
缺陷: 组件或系统中导致组件或系统无法执行其必须功能的瑕 疵。例如:错误的语句或变量定义,如果在组件或系统运行中遇到缺陷,可能 会导致失效;
错误:人为因素产生不正确结果的行为(
故障: 指软件的缺陷或错误,将会造成软件使用上的各种障碍
失效:(软件)组件/系统与预期的交付、服务或结果存在的偏差
2)软件缺陷或错误的特征
第一,软件系统的逻辑性与复杂性等特殊性质决定了其缺陷、错误不易直 接被肉眼观察到,***即缺陷“难以看到”。***
第二,即使在软件运行与使用当中发现了缺陷、错误或发生了故障,仍不 容易找到该问题产生的原因,***即故障、失效“看到但难以抓到”。***
3)软件缺陷、错误产生的原因
1)软件需求解释有错误或不明确。
2)用户需求的定义中存在错误。
3)软件需求中记录了错误。
4)软件设计说明中有错误。
5)软件编码说明中有错误。
6)软件程序代码存在错误。
7)数据输入有错误。
8)软件测试过程有错误。
9)软件问题修改不正确或不彻底。
10)有时,错误结果是因其他的软件缺陷或错误而引起或产生的。
3.了解软件测试的基本概念
“测试是为了度量和提高被测软件的质量,是对被测软件进行工程设计、实施和维护的整个生命周期过程
了解软件测试的产生与发展以及软件测试目的、原则、基本原理、测试特性准则
1.
软件测试的发展:定义起源、内含演进、软件质量度量、软件测试技术规范、内涵的进一步丰富
软件测试的发展趋势是:
软件测试领域的动态变化 ;
基于模型的软件测试技术将成为新的技术或主流
基于模型的测试技术的优势:
① 工具自动化程度高,测试效率高,测试过程所需时间较短;
② 基于模型的测试技术往往能发现其他测试方法难以发现的故障。
基于模型的测试技术目前存在的不足:
① 存在误报问题。通常基于模型的测试技术属于静态分析,而某些软件故障的确定需要动态执行的信息,因此对于基于静态分析的工具来说,误报问题则不可避免;
② 存在漏报问题。该问题主要是由模型定义和模型检测的算法而引起,因 为,目前软件模式还无规范、统一与形式化的定义;
③ 模型呈多样性。由于软件模型的多种多样,很难用一种或几种策略方法适应多种模型。
软件测试的描述性定义:
定义1:软件测试是为了发现错误而执行程序的过程。
定义2::软件测试是根据软件开发各阶段的规格说明和程序的内部结构 而精心设计的一批测试用例(即输入数据及其预期的输出结果),并利用这些测试用例运行程序以及发现错误的过程,即执行测试步骤。
2.软件测试的目的
软件测试是以发现软件的存在的缺陷、错误为第一目的,并藉此对软件的质量进行度量评价
软件测试的原则:
尽早和及时的进行测试。测试活动应从软件产品开发初始阶段就开始;
测试需根据软件需求和分析得来的风险,测试活动可由专业测试者进行 或程序开发者自行测试完成;
测试需要严格执行测试计划,排除测试工作的随意性;
充分注意测试中的集群效应
应对测试结果作核查,存档测试计划、测试用例、缺陷统计和分析报告 等文档,为软件运行时的维护工作提供足够的资料及测试条件
软件测试的基本测试原理:
测试原理1:测试可以证明缺陷存在,但不能证明缺陷不存在
测试原理2:穷尽测试是不可能的
测试原理3:测试活动应尽早开始
测试原理4:缺陷的集群性
测试原理5:‘杀虫剂’悖论
测试原理6:测试依赖于测试内容
测试原理7:没有失效就是有用的系统是一种谬论
软件测试特性准则:
对任何软件(产品)系统都**存在有限的充分测试集合**
若一个软件系统在一个测试数据(测试用例)集合上的测试是充分的, 那么再测试执行一些测试用例也是充分的,这一特性称作***测试的单调性***
即使对软件所有的组成成分都进行了充分测试,也并不能表明整体软件 系统的测试已经充分,这一特性称作***测试的非复合性。***
即使对软件系统整体的测试是充分的,也并不能证明软件系统中各组成 成分都已得到了充分测试,这个特性称作***测试的非分解性。***
软件测试的充分性应与软件需求及软件实现相关。***测试充分性和软件需 求、实现相关联。***
软件越复杂,测试数据需用就越多,这一特性称为***测试的复杂性。***
测试越多,进一步测试所获充分性增长就越少,这一特性称作***测试回报 递减率。***
掌握软件测试策略与模式;
测试的基本策略是在其生命周期的 每个阶段中确定测试目标、确认测试对象、建立测试生命周期、制定和实施测试 策略、选择测试类型,以及运用测试方法六项
1.明确测试目标
根据软件生命周期划分的几个阶段,以及软件质量包含的各项属性特征,测 试需要对每一阶段和每个部分的目标进行确定。
2.确认测试对象
软件测试是对程序的测试,并贯穿于软件生命周期整个过程。因此,软件 开发过程中产生的文档,说明书及源程序都是软件测试的对象
3.建立测试生命周期
软件测试生命周期包含在软件生命周期中,主 要横跨了两个历程。分为软件生产阶段的测试历程与软件运行维护阶段的测试活 动
4.制定和实施测试策略
制定和实施一项软件测试的策略包含了四项内容:
(1) 确定测试由谁执行
(2) 确定测试什么
(3) 何时进行测试
(4) 确定怎样进行测试
5.明确测试类型
(1) 功能测试
(2) 非功能性的测试
(3) 恢复测试
(4) 确认测试
(5)验收测试
(6)回归测试
学习软件测试模型优缺点;
1.瀑布模型
瀑布模式优点:易于理解、开发具有阶段性、强调早期的计划及需求分析、 基本可确定何时交付产品及进行测试。
式缺点:需求调查分析只在最初进行,不能适应需求的新变化;顺序 开发流程使开发经验教训不便进行前向反馈;不能反映出开发过程的反复性与迭 代特性,无任何类型的风险评估,出现或隐藏的问题直到开发后期才会显露,失 去了及早纠正错误或缺陷机会
2.螺旋模型、
由于引入严格风险识别、风险分析和风险控制,因此对管理水平提出较高要 求,需管理者专注及具备管理经验,并需较多人员、资金与时间的投入
主要思想是在开 发初始阶段不必详细定义软件细节,而从小规模开始定义重要功能,并尽量实现 ,然后评测其风险,制定风险控制计划,接受客户的反馈,确定进入下一阶段的 开发并重复上述的过程,进行下一个螺旋与反复,再确定下一步项目是否继续, 或中止或调整,直到获得最终产品
3. RUP 流程(模式)
4. IPD
5. 敏捷模式
了解软件测试生命周期和通用流程,掌握组件测试、集成测试、系统测试、确认测试、验收测试和更新测试,主题讨论:软件生命周期及测试层级的理解和认识;
1.,主要由测试规划、测试需求、测试用例设计、产品 集成、集成测试、确认测试(系统测试和发布测试)和验收测试 7 个部分组成。
2.组件测试
1)组件测试的类别及模式
组件测试是整个软件产品的质量基础。
(1)组件测试对象
(2)组件测试类别
(3)组件测试模式
测试驱动模式和代码先行模式
2)组件测试的任务:
(1)组件内部模块接口检测
(2) 局部数据结构检测
(3)路径检测
(4)边界条件检测
(5)出错处理检测
3)组件测试过程
在通常情况下,组件测试常与代码编写工作同时进行,在完成了程序编写与 语法的正确性检查(通常由编译过程完成)后,就应进行组件(单元)测试的测 试用例设计
在对每个组件模块进行测试时,不能完全忽视它们和周围其他模块的相互作 用及关系。为模拟这一联系,在测试时,需要设置一些辅助测试模块。
辅助测试模块两种:驱动模块;桩模块
4)组件测试管理
,需注意组件测试与程序调试的不同。
测试时从已知条件开始,可 预知测试的结果;测试过程可设计预期,并可控 ;。测试能在无详细设计的情况下 进行
调试是从未知条件开始,预期过程与结果不可预计。调试难以预期过程及时 间。调试需要经验与思考,为一个程序逻辑推理的修正过程。调试无详细设计(或 代码)则无法进行
3.集成测试
1)集成测试概念
集成测试(Integrated Testing)阶段是指每个模块完成组件测试后,需按 照设计时确定的软件结构图,将它们连接起来,进行集成测试
2)集成测试策略
非增量式测试
非增量式测试采用一步到位的方法构造测试。在对所有模块进行测试后, 按照程序结构图将各模块连接起来,把连接后的模块当成一个整体进行测试。 集
增量式测试
增量式测试与非增量式测试不同,集成是逐步实现的,测试也是逐步完成的, 因此,可认为是将组件测试与集成测试结合进行,。增量式集成测试可按照不同次 序实施,由此产生了两种不同的方法,即自顶向下结合的方法和自底向上结合的 方法。
自顶向下结合的方法
集成测试整个过程由以下3个步骤完成: (1)主控模块作为测试驱动器。 (2)根据集成的方式(深度或广度),下层的桩模块一次一次地被替换为真 正的模块。 (3)在每个模块被集成时,都必须进行单元测试。 重复第(2)步,直至整个系统被测试完成。
自底向上的增量式测试
自底向上的增量式测试表示逐步集成和逐步测试是按结构图自下而上进行 的,由于从底层开始集成,所以不再需要使用桩模块进行辅助测试。 图
4.系统测试
1)系统测试的概念、对象、环境与目标
系统测试主要从系统的角度来检验和寻找缺陷。这部分测试主要包含功能测 试、性能测试、安全测试、可靠性测试、恢复性测试与兼容性测试等。
(2)系统测试的对象与环境
。系统测试应尽可能在与目标运行环境一致的情况下进行
(3)系统测试需要独立的测试环境
(4)系统测试的目标
确认整个系统是否满足了软件规格说明中的功能性和非 功能性的各项需求,以及满足的程度。系统测试应能够发现和找出因需求不正确、 不完整或实现与需求之间的不一致而引起的失效,并识别在没有文档化时或被遗 失的那些需求。
(5)系统测试实践中的问题
在不明确的系统需求情况下,软件所有的系统行为都是正确的。这时所进行的 系统测试,则无法对软件系统的各项功能进行正确地评估。此时,针对系统测试 只能采用探测性测试。另外,错误的测试分析和决策也将导致系统测试的失败, 并由此造成项目(系统或研发)失败。
2。系统的功能性测试
功能性测试包括验证系统输入/输出行为的各种测试。功能性测试的基础是 功能需求,功能需求详细地描述了系统行为,定义了系统必须完成的功能。
功能测试可细分为逻辑功能测试、界面测试、易用性测试、安装测试等,而
其中最重要的是逻辑功能测试
3.系统测试的非功能性测试
非功能的需求不 描述功能,而描述功能行为的属性或系统的属性,即系统执行其功能有“多好”,或质量程度如何。
4.安全性测试
为源码分析(白盒测试方法)与推断测试(黑盒测 试方法)
5.其他测试
(1)恢复性测试
(2)兼容性与数据转换测试
(3)文档检查
(4)可维护性测试(检查)
5.确认测试
确认测试可检验所开发的软件产品能否按用户(合同)提出的各项要求来进 行
1.确定测试的准则
采用黑盒测试技术来完成。
。经过确认测 试,可为已开发完成的软件产品做出是否合格的结论与其质量评价
2. 程序修改后的确认测试
(1)回归测试
(2)变更测试
3.配置与审查
其目的在于 确保已开发软件(产品)的所有文件资料均已编写齐全,这里包括已发布的软件 版本(或称它为软件资产)等并得到分类编目,足以支持运行以后的软件维护工 作
(1)用户手册
(2)操作手册
(3)设计资料
(4)已发布的软件资产(程序)版本
4,。 关于更详尽的回归测试阐述
(1)回归测试
回归测试是指修改了旧代码后,重新进行测试以确认修改没有引入新的错误 或导致其他代码产生错误
(2)回归测试的策略
(3)测试用例库的维护
6.验收测试
1.验收测试的含义
验收测试是检验软件产品质量的最后一个过程。验收测试通常更突出客户的 主导作用 验收测试范围取决于软件的风险评估。
2. 验收测试的任务及内容
任务:
明确验收项目,规定验收测试通过的标准。
决定验收测试组织机构、利用的资源。
3验收测试关于软件文档的测试(检查
(1)检查产品说明书的属性
(2)检查文档的内容是否完整
(3)检查文档描述是否准确
(4)检查文档描述是否精确
(5)检查文档描述是否一
(6)检查文档描述是否贴切
(7) 检查代码的无关性
7.更新测试
了解经典软件测试技术、静态软件测试、静态测试评审;
1. 静态测试
静态测试存在于软件生命周期的各级测试。
静态测试中的评审(或审查)的基本思想和目标是对软件缺陷或错误的
一种预防措施。因而软件技术文档的审查是静态测试的主要任务之一。
2. 静态测试内容及过程
静态测试的内容包含:测试需求分析、测试概要分析、测试详细设计、测试
执行与测试结果分析
过程:进行测试需求分析、进行测试概要设计:进行测试详细设计,测试执行与结果分析
3. 静态测试的实施与执行
(1) 静态测试的实施
静态测试通常采用两种策略:人工静态分析和借用工具静态分析。
(2) 静态分析的过程有别于编译过程
(3) 代码检查
4.静态测试的结构分析方法
(1)以图形方式表现程序内部结构
(2) 以程序的控制流图显示程序函数的逻辑结构
(3)检查项
(4) 代码的质量度量
(5)检查与规范、标准的一致性
2.静态测试–评审
1.评审的作用和意义
评审是保证 质量的方法:通过检查文档来实现。
评审的积极作用:及早发现潜在缺陷与错误,消除或减少缺陷的存在,
降低运行故障率,降低开发成本,缩短开发周期,改进软件开发过程,对检查的
问题达成共识。促进团队内部知识共享,提高团队整体水平
2。评审的过程
(1) 评审计划及其准
(2) 评审会议
3 评审角色及职责
(1) 测试经理 (2) 评审主持(3)评审文档作者(4)评审人员(5)记录员
4 评审的类型
(1) 走查 (2)审查 (3)技术评审 (4)非正式评审
5 评审成功的关键因素
依被评审文档类型、级别、人员选择评审类型 ;
对发现的问题作中性客观的记录,降低人的心理作用对评审影响
用检查表(checklist)的方式来提高发现问题的效率
为评审提供必要的资源
6 代码检查法
代码评审是指在软件开发中对源代码的系统性检查。其目的是查找系统
的缺陷或错误,保证软件总体质量和提高开发者的水平。
讨论
- 怎样理解软件生命周期,请举例说明。
一个软件从定义,开发,运行维护,直到最终要经历一个时期的过程
2 软件生命周期的通用测试模型是什么,怎样正确理解?
V模型
V 模型除了确认测试,还要求进行验证测试
V模型定义了测试级别的抽象过程
思想::软件开发和测试是相互对等的活动,并同等重要。 其左侧部分代表了开发过程,右侧部分代表了集成和测试的过程。 “V”模型的两 个分支形象地表达了这一点。
3。组件测试(即通常所说的单元测试),其主要的测试工作和任务有哪些?
工作“”(1)组件测试对象
(2)组件测试类别
(3)组件测试模式
任务:(1)组件内部模块接口检测
(2) 局部数据结构检测
(3)路径检测
(4)边界条件检测
(5)出错处理检测
4。集成测试的工作任务有哪些?
检查多个组件是否按照系统技术设计描述的方向协同工作
每个模块完成组件测试后,需按 照设计时确定的软件结构图,将它们连接起来,进行集成测试
5系统测试的工作任务有哪些?
系统测试主要从系统的角度来检验和寻找缺陷
,确认整个系统是否满足了软件规格说明中的功能性和非 功能性的各项需求,以及满足的程度。系统测试应能够发现和找出因需求不正确、 不完整或实现与需求之间的不一致而引起的失效,并识别在没有文档化时或被遗 失的那些需求。
6.怎样正确理解确认测试和验收测试,其差异在哪里?
确认测试可检验所开发的软件产品能否按用户(合同)提出的各项要求来进 行。
验收测试是检验软件产品质量的最后一个过程。验收测试通常更突出客户的 主导作用
确认测试和验收测试都是用来检验软件产品质量是否符合标准,
7. 在V模型当中,测试如何与开发做到相对应?
V模型的右边定义了相应的测试级别。