软件工程PPT
合集下载
《软件工程》PPT课件
第四课时
第一章第四课时
喷泉模型 软件工程的任务与研究范围 软件开发的原则与开发方法
返回
喷泉模型
瀑布模型要求在软件开发的初期就完全确定软件的需求,这在很多 情况下往往是做不到的.螺旋模型试图克服瀑布模型的这一不足.SM 把软件开发过程安排为逐步细化的螺旋周期序列,每经历一个周期, 系统就细化和完善一些.SM每—螺旋周期由六个步骤组成: <1> 确定任务目标: 根据初始需求分析项目计划,确定任务目标、可选 方案和限制.<2>选择对象:对各种软硬件设备、开发方法、技术、 开发工具、人员、开发管理等对象进行选择:并决定软件是进行研 制、购买还是利用现有的.<3>分析约束条件:软件开发的时间、经 费等限制条件.<4>风险分析:评估目标、对象、约束条件三者之间 的联系,列出可能出.现的问题及问题的严重程度等,把最重要的问 题作为尚未解决的关键问题的风险.<5>制定消除风险的方法:应有 详尽的说明和周密的计划,并估计可能产生的后果.依此来开发软件, 为制订下一周期的计划打下基础.<6>制定下一周期的工作计划:在 第一个螺旋周期,确定目标、选择对象、分析约束,通过风险分析制 订消除风险的方法,初步开发原型1,制定系统生存周期计划.
软件工程的任务与研究范围
•软件产品的特点 •软件工程的研究内容与方法 •软件工具与软件支撑环境 •软件管理
软件开发的原则与方法
•软件开发的原则 • 自顶向下与模块结构 •软件开发的方法 •1.非自动形式的系统开发方法 •〔1〕系统流程图〔2〕结构分析法〔3〕结构化设计法 •〔4〕数据结构法〔5〕层次输入——处理——输出方法<HIPO法> • 2.半自动形式的系统开发方法 •〔1〕软件需求工程法〔2〕问题说明语言与分析法 • 3. 自动形式的系统开发方法 〔HOS方法〕:由计算机自动确定规 范、自动分析、自动编程、自动执行与模拟,以规范语言AXES、资 源分配工具RTA为工具.能自动进行分析、设计,工作量少、设计规范, 也能自动进行修改和维护.该方法适用于系统分析和设计.
第一章第四课时
喷泉模型 软件工程的任务与研究范围 软件开发的原则与开发方法
返回
喷泉模型
瀑布模型要求在软件开发的初期就完全确定软件的需求,这在很多 情况下往往是做不到的.螺旋模型试图克服瀑布模型的这一不足.SM 把软件开发过程安排为逐步细化的螺旋周期序列,每经历一个周期, 系统就细化和完善一些.SM每—螺旋周期由六个步骤组成: <1> 确定任务目标: 根据初始需求分析项目计划,确定任务目标、可选 方案和限制.<2>选择对象:对各种软硬件设备、开发方法、技术、 开发工具、人员、开发管理等对象进行选择:并决定软件是进行研 制、购买还是利用现有的.<3>分析约束条件:软件开发的时间、经 费等限制条件.<4>风险分析:评估目标、对象、约束条件三者之间 的联系,列出可能出.现的问题及问题的严重程度等,把最重要的问 题作为尚未解决的关键问题的风险.<5>制定消除风险的方法:应有 详尽的说明和周密的计划,并估计可能产生的后果.依此来开发软件, 为制订下一周期的计划打下基础.<6>制定下一周期的工作计划:在 第一个螺旋周期,确定目标、选择对象、分析约束,通过风险分析制 订消除风险的方法,初步开发原型1,制定系统生存周期计划.
软件工程的任务与研究范围
•软件产品的特点 •软件工程的研究内容与方法 •软件工具与软件支撑环境 •软件管理
软件开发的原则与方法
•软件开发的原则 • 自顶向下与模块结构 •软件开发的方法 •1.非自动形式的系统开发方法 •〔1〕系统流程图〔2〕结构分析法〔3〕结构化设计法 •〔4〕数据结构法〔5〕层次输入——处理——输出方法<HIPO法> • 2.半自动形式的系统开发方法 •〔1〕软件需求工程法〔2〕问题说明语言与分析法 • 3. 自动形式的系统开发方法 〔HOS方法〕:由计算机自动确定规 范、自动分析、自动编程、自动执行与模拟,以规范语言AXES、资 源分配工具RTA为工具.能自动进行分析、设计,工作量少、设计规范, 也能自动进行修改和维护.该方法适用于系统分析和设计.
软件工程导论(共65张PPT)可编辑全文
–期刊管理系统之借阅子系统
– 学生选课系统 软件
Microsoft Visio; Rational Rose
高级程序语言 作业递交方式:
来信标题注明 :班级 、学号、姓名、章节
第1章 软件工程学概述
1.1 软件危机
软件危机的出现:60年代中期到70年代中期, 许多软件最终成为不可维护的,这就是软件危 机.
不能用象硬件替换部件的方式修复软件的故障 使用增量模型的困难是,在把每个新的增量构件集成到现有软件体系结构中时,必须不破坏原来已经开发出的产品。
出现了“软件作坊”,软件作为一种产品被广泛使用;
使用个体化开发方式;
软件的发展史_2
随着软件数量的增加及软件需求的日趋复杂, 维护难度与来越大,开发成本高,质量低 导致“软件危机”
➢相同点:都将软件开发划分为分析、设计、编码、 测试等阶段 ➢不同点:思想不同,方法不同。另外,传统软件 工程更关注功能模块,面向对象软件工程更关注对 象的抽取和设计
➢ 两类软件工程方法学没有绝对的替代关系
1.3软件生命周期
生命周期方法学
从时间角度对软件开发和维护的复杂问题进行分解,把软件生命 的漫长周期依次划分为若干个阶段,每个阶段有相对独立的任务, 然后逐步完成每个阶段的任务。
关注大型程序的构造 中心问题是控制复杂性 软件经常变化 开发效率非常重要 和谐地合作是开发软件的关键 有效地支持它的用户 具有一种文化背景的人替另一种文化背景的人
创造产品
用分阶段的生命周期计划严格管理 坚持进行阶段评审 实行严格的产品控制 采用现代程序设计技术 结果应能清楚地审查 开发小组成员应少而精 承认不断改进软件工程实践地必要性
软件工作涉及到很多社会因素。 由于对象概念的引入,表达分析、设计及实现等活动只用对象类和关系,从而可以较容易地实现活动的迭代和无间隙
– 学生选课系统 软件
Microsoft Visio; Rational Rose
高级程序语言 作业递交方式:
来信标题注明 :班级 、学号、姓名、章节
第1章 软件工程学概述
1.1 软件危机
软件危机的出现:60年代中期到70年代中期, 许多软件最终成为不可维护的,这就是软件危 机.
不能用象硬件替换部件的方式修复软件的故障 使用增量模型的困难是,在把每个新的增量构件集成到现有软件体系结构中时,必须不破坏原来已经开发出的产品。
出现了“软件作坊”,软件作为一种产品被广泛使用;
使用个体化开发方式;
软件的发展史_2
随着软件数量的增加及软件需求的日趋复杂, 维护难度与来越大,开发成本高,质量低 导致“软件危机”
➢相同点:都将软件开发划分为分析、设计、编码、 测试等阶段 ➢不同点:思想不同,方法不同。另外,传统软件 工程更关注功能模块,面向对象软件工程更关注对 象的抽取和设计
➢ 两类软件工程方法学没有绝对的替代关系
1.3软件生命周期
生命周期方法学
从时间角度对软件开发和维护的复杂问题进行分解,把软件生命 的漫长周期依次划分为若干个阶段,每个阶段有相对独立的任务, 然后逐步完成每个阶段的任务。
关注大型程序的构造 中心问题是控制复杂性 软件经常变化 开发效率非常重要 和谐地合作是开发软件的关键 有效地支持它的用户 具有一种文化背景的人替另一种文化背景的人
创造产品
用分阶段的生命周期计划严格管理 坚持进行阶段评审 实行严格的产品控制 采用现代程序设计技术 结果应能清楚地审查 开发小组成员应少而精 承认不断改进软件工程实践地必要性
软件工作涉及到很多社会因素。 由于对象概念的引入,表达分析、设计及实现等活动只用对象类和关系,从而可以较容易地实现活动的迭代和无间隙
软件工程课件(全)
03
识别项目中的关键路径,确保项目按计划进 行
04
及时调整项目计划,应对项目变更和不确定 性
风险管理策略制定
识别项目中的潜在风险, 包括技术风险、市场风险、 资源风险等
制定相应的风险应对策略 和措施,如风险规避、减 轻、转移和接受等
评估风险的概率和影响程 度,制定风险优先级列表
监控风险状态,及时调整 风险管理计划
质量改进
根据质量评估结果,制定相应的改进措施, 如优化性能、增强安全性等。
经验教训总结
对测试过程中遇到的问题进行总结,形成经 验教训,为后续项目提供参考。
06
项目管理与团队协作
项目计划制定与监控
01 制定详细的项目计划,包括项目目标、范围 、时间表、资源需求、成本估算等
02 设立项目里程碑,对项目进度进行阶段性监 控
开发方向。
持续集成和测试
03
迭代增量模型强调持续集成和测试的重要性,以确保每个迭代
周期都能交付高质量的软件产品。
03
需求分析与管理
需求获取与整理
确定需求来源
与客户、利益相关者、业务领 域专家等进行沟通,收集原始
需求。
需求分类
将收集到的需求按照功能、性 能、安全、易用性等方面进行 分类。
需求筛选
去除重复、模糊、不切实际的 需求,确保需求的准确性和可 行性。
处理变更请求
根据实际情况,决定是否接受变更请求,并 制定相应的实施计划。
跟踪和验证变更
对实施的变更进行跟踪和验证,确保变更的 正确性和完整性。
04
系统设计与实现
系统架构设计
分层架构
将系统划分为表示层、业务逻辑层和数据访问层,实现高内聚、 低耦合的设计。
软件工程ppt课件完整版
缺陷跟踪
使用缺陷管理工具对缺陷进行 跟踪,确保每个缺陷都得到处 理。
缺陷修复
开发人员对缺陷进行分析并修 复,然后提交给测试人员进行 验证。
回归测试
对修复后的缺陷进行回归测试 ,确保修复没有引入新的缺陷
。
质量评估与改进
质量评估
定期对软件产品的质量进行评估,包括功能 、性能、安全等方面。
过程改进
对软件开发过程进行持续改进,提高开发效 率和软件质量。
,提高代码的可读性和可维护性。
模块化开发
02
采用模块化开发方式,将系统划分为不同的模块进行开发,提
高开发效率和质量。
错误处理
03
对可能出现的错误进行充分的考虑和处理,包括异常捕获、日
志记录和错误提示等,确保系统的稳定性和可靠性。
05 测试与质量保证
测试类型及方法
功能测试对软件产品的各项功 进行验证,确保符 合需求和设计。
同时引入了风险管理机制。
螺旋模型的主要阶段包括:制 定计划、风险分析、工程实施
和客户评估。
螺旋模型的优点在于其强调风 险分析和迭代开发,能够及时 发现并解决问题,降低项目风 险。
螺旋模型的缺点在于其需要较 高的项目管理能力和技术水平 ,且可能因为过度关注风险而 忽略其他重要因素。
敏捷开发模型
敏捷开发的主要实践包括:短周期迭代开发、 持续集成、持续交付和自动化测试等。
水平。
04
迭代增量模型的优点在于其能够逐步增加系统功能和 性能,降低项目风险,同时也能够及时发现并解决问 题。
03 需求分析与管理
需求获取与整理
确定需求来源
与客户、利益相关者、业务领域 专家等进行沟通,明确需求背景
和范围。
使用缺陷管理工具对缺陷进行 跟踪,确保每个缺陷都得到处 理。
缺陷修复
开发人员对缺陷进行分析并修 复,然后提交给测试人员进行 验证。
回归测试
对修复后的缺陷进行回归测试 ,确保修复没有引入新的缺陷
。
质量评估与改进
质量评估
定期对软件产品的质量进行评估,包括功能 、性能、安全等方面。
过程改进
对软件开发过程进行持续改进,提高开发效 率和软件质量。
,提高代码的可读性和可维护性。
模块化开发
02
采用模块化开发方式,将系统划分为不同的模块进行开发,提
高开发效率和质量。
错误处理
03
对可能出现的错误进行充分的考虑和处理,包括异常捕获、日
志记录和错误提示等,确保系统的稳定性和可靠性。
05 测试与质量保证
测试类型及方法
功能测试对软件产品的各项功 进行验证,确保符 合需求和设计。
同时引入了风险管理机制。
螺旋模型的主要阶段包括:制 定计划、风险分析、工程实施
和客户评估。
螺旋模型的优点在于其强调风 险分析和迭代开发,能够及时 发现并解决问题,降低项目风 险。
螺旋模型的缺点在于其需要较 高的项目管理能力和技术水平 ,且可能因为过度关注风险而 忽略其他重要因素。
敏捷开发模型
敏捷开发的主要实践包括:短周期迭代开发、 持续集成、持续交付和自动化测试等。
水平。
04
迭代增量模型的优点在于其能够逐步增加系统功能和 性能,降低项目风险,同时也能够及时发现并解决问 题。
03 需求分析与管理
需求获取与整理
确定需求来源
与客户、利益相关者、业务领域 专家等进行沟通,明确需求背景
和范围。
软件工程培训课件(PPT)
编码效率技巧:在保证代 码质量的前提下,应该尽 可能提高编码效率,减少 不必要的重复工作。
单元测试的方法与工具
测试用例设 计
执行测试流 程
测试工具选 择
测试结果分 析和报告
集成测试的方法与工具
测试方法:自 下而上、自上
而下
测试工具: JUnit、
Te s t N G 、 Selenium等
测试目的:检 测模块之间的 接口是否正确
方法:采用版本控制、变更 控制、状态报告等手段进行
管理
感谢观看
汇报人:
软件风险管理的方法与策略
风险识别:识别潜在的风险和 问题
风险评估:评估风险的大小和 影响
风险应对:制定应对策略和措 施
风险监控:持续监控风险的变 化和进展
软件配置管理的基本概念与方法
目的:确保软件产品的完整 性、一致性和可追溯性
范围:包括文档、程序、数 据等所有软件工程产品
定义:软件配置管理是一种 标识、组织和控制修改的技 术
质量控制:通过测试、统计等方 法,对软件开发过程中的质量进 行监控和评估,及时发现和解决 问题。
添加标题
添加标题
添加标题
添加标题
质量保证:通过一系列的质量保 证活动,如代码审查、测试、文 档编写等,确保软件质量的稳定 性和可靠性。
工具和技术:使用一些工具和技 术来辅助软件质量管理,如代码 审查工具、测试工具、项目管理 工具等。
编写要求:清晰明了,易于理解,方便查阅,及时更新
编写目的:方便用户和系统管理员使用和维护系统
06
软件工程管理
软件项目计划与进度安排
定义项目目标和范围 确定关键路径和里程碑 分配资源和工作任务 监控和控制项目进度
软件工程课件(全)ppt
第1章 1.2软件工程
1.2.1 软件工程的定义和目标
为了克服软件危机,1968年10月在北大西洋公约组织(NATO)召开的计 算机科学会议上,Fritz Bauer首次提出“软件工程”的概念。
按工程化的原则和方法组织软件开发工作是有效的,是摆脱软件危机的一 条主要出路。
软件工程的主要思想是强调软件开发过程中应用工程化原则的重要性。软 件工程的目标是实现软件的优质高产。软件工程的目的是在经费的预算范围内, 按期交付出用户满意的、质量合格的软件产品。
第1章 1.1软件与软件危机
1.1.3 软件危机
2. 软件危机产生的原因
(1)忽视软件开发前期的调研和需求分析工作。 (2)缺乏软件开发的经验和有关软件开发数据的积累,使得开发计划很难制定。 (3)开发过程缺乏统一的、规范化的方法论指导。 (4)忽视与用户、开发组成员间的及时有效的沟通。 (5)文档资料不规范或不准确。导致开发者失去工作的基础,管理者失去管理的依据。 (6)没有完善的质量保证体系。
第1章 1.1软件与软件危机
1.1.1 软件的定义及其特点
2.软件具有下列特点:
比硬件发展慢
是逻辑产品
软件
生产与硬件不同 不会磨损和老化
成本高、风险高
手工开发为主
依赖硬件
第1章 1.1软件与软件危机
1.1.2 软件的发展及其分类
1.软件技术的发展
程序设计
程序系统
软件工程
第1章 1.1软件与软件危机
第1章 1.1软件与软件危机
1.1.3 软件危机
3. 软件危机解决途径
要解决软件危机问题,需要采取以下措施: (1)使用好的软件开发技术和方法。 (2)使用好的软件开发工具,提高软件生产率。 (3)有良好的组织、严密的管理,各方面人员相互配合共同完成任务。 为了解决软件危机,既要有技术措施(好的方法和工具),也要有组织管理措施。软件工 程正是从技术和管理两方面来研究如何更好地开发和维护计算机软件的。
软件工程完整PPT课件
2021/3/9
10
④局部化。要求在一个物理模块内集中逻辑上相互关联 的计算资源,保证模块间具有松散的耦合关系,模块 内部有较强的内聚性,这有助于控制解的复杂性。
⑤确定性。软件开发过程中所有概念的表达应是确定的、 无歧义且规范的。
⑥一致性。包括程序、数据和文档的整个软件系统的各 模块应使用已知的概念,内外部接口应保持一致,系 统规格说明与系统行为应保持一致。
2021/3/9
14
2. 需求分析方法 常见的需求分析方法有:
①结构化分析方法。 ②面向对象的分析方法。
2021/3/9
15
2.2结构化分析方法
(1)关于结构化分析方法 结构化分析方法的实质是着眼于数据流,自顶向下,逐层分解,
建立系统的处理流程,以数据流图和数据字典为主要工具,建 立系统的逻辑模型。 结构化分析的步骤如下:
3. 信息隐蔽 信息隐蔽使得一个模块内包含的信息(过程和数据)
对于不需要这些信息的模块来说,是不能访问 的。
2021/3/9
24
4. 模块独立性 每个模块完成一个相对独立的特定子功能,并且 和其他模块之间的接口很简单。
模块的独立程度可以由两个定性标准来衡量,这 两个标准分别称为耦合性和内聚性。藕合衡量不 同模块彼此间互相依赖(连接)的紧密程度;内 聚衡量一个模块内部各个元素彼此间结合的紧密 程度。
⑦完备性。软件系统不丢失任何重要成分,完全实现系 统所需的功能。
⑧可验证性。开发大型软件系统需要对系统自顶向下, 逐层分解。系统分解应遵循容易检查、测评、评审的 原则,以确保系统的正确性。
2021/3/9
11
1.5软件开发工具与软件开发环境
1. 软件开发工具 软件开发工具是指可以用来帮助开发,测试、分 析、维护其他计算机程序及其文档资料,实现软 件生产过程自动化的一类程序。 软件工具主要包括需求分析工具、设计工具、编 码工具、确认工具、维护工具等。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
基本路径测试
第一步:画出控制流图 流程图用来描述程序控制结构。可将流程图映 射到一个相应的流图(假设流程图的菱形决定框 中不包含复合条件)。在流图中,每一个圆,称 为流图的结点,代表一个或多个语句。一个处理 方框序列和一个菱形决测框可被映射为一个结点, 流图中的箭头,称为边或连接,代表控制流,类 似于流程图中的箭头。一条边必须终止于一个结 点,即使该结点并不代表任何语句。由边和结点 限定的范围称为区域。计算区域时应包括图外部 的范围。
2.2白盒测试
源程序
分析
测试用例
被测程序 覆盖情况分析
执行路径
图2-7 白盒测试过程示意图
白盒测试主要对程序进行的检查点:
(1)保证一个模块中的所有独立执行路径 至少测试一次; (2)对所有逻辑判定取值“true”和“fal se”的两种情况都至少测试一次; (3)在循环边界和运行界限内执行循环体; (4)测试内部数据结构的有效性。
2.2.2白盒测试的用例设计 白盒测试用例设计技术就是研究如何用 最少的测试用例最大限度地发现软件中的错 误,目前主要有基本路径测试、等价类划分 /边界值分析测试、覆盖测试、循环测试、 数据流测试、程序插桩测试、变异测试等等 方法。
2.2.2白盒测试的用例设计
一、基本路径测试 概念:基本路径测试就是在程序控制流 图的基础上,通过分析控制构造的环形复杂 性,导出基本可执行路径集合,从而设计测 试用例的方法。 设计出的测试用例要保证在测试中,程 序的每一个可执行语句至少执行一次。
集合的划分: 划分的含义就是将一个整体分成小块,使 得所有事物都在某个小块中,不会遗漏。 划分的定义: 给定集合B,以及B的一组子集A1,A2,A3, ‥‥,An,这些子集是B的一个划分, 当且仅当A1∪A2∪ ‥‥ ∪ An=B, 且 i≠j=>Ai∩Aj=Ф
划分的概念对于测试人员非常重要,在 测试中往往一方面要保证B的所有元素都在 某个子集中,另一方面要保证任意一个元 素都不会同时出现在两个子集中。 有效的划分可以保证功能测试时的完备 性与无冗余性。防止有些内容没有被测试, 而另一些内容被测试多遍的情况。 功能性测试的主要困难之一,就是难以 找到合适的划分。
2.1用于测试的离散数学和图论基础
一般而言,在功能性测试中,通常要 用到离散数学知识,而在结构性测试领域中, 则要用到一些关于图论的知识。
2.1.1集合论
集合论可分为:自然和不言自明两种。 自然的集合论把集合看作是基本术语,我们 把集合看作一个单位,或一个整体引用多个 事物。
集合的表示法有以下两种: 1、将集合所有元素一一列出的表示法叫 做“枚举法”,但有时也可以只列出一部 分元素。 M1={1月,2月,3月,4月‥‥‥} 2、用一个集合所具有的共同性质来刻画 这个集合。 N={t:t是等边三角形}
1、程序图 程序图定义:节点要么是整个语句,要 么是语句的一部分,边表示控制流(从节 点i到节点j有一条边,当且仅当对应节点j的 语句或语句的一部分,可以立即在节点i对 应的语句或语句的一部分之后执行)。 程序的有向图公式化能够非常准确地描 述基本结构化程序设计的构造,例如:串 行、选择和循环等可以用有向图表示。
独立路径
独立路径:至少沿一条新的边移动的路径
1 2,3 6 4,5
路径1:1-11 路径2:1-2-3-4-5-10-1-11 路径3:1-2-3-6-8-9-10-1-11
7
9
8
路径4:1-2-3-6-7-9-10-1-11 对以上路径的遍历,就是至 少一次地执行了程序中的所 有语句。
10 11
有限状态机与流程图的转换
针对这两大类的程序,通常描述它们的 方法也不太一样,对于前者,我们通常用控 制流程图或是数据流程图来描述,对于后者 则常用有限状态机或状态图来描述。 流程图中最重要的部份是 “处理过 程" 单元,程序由几个主要的处理单元组合 而成,有限状态机中最主要的是程序目前的 状态,每一个状态总结记录程序由开始到目 前所有接到的输入。
3、从执行的过程来看,测试是一个发 现错误、改正错误、重新测试的过程;而 调试是一个推理过程。
4、从准备工作来看,测试从已知的条 件开始,使用预先定义的程序;调试一般 是以不可知的内部条件开始,做统一性调 试。
5、从执行的计划性来看,测试是有计 划的并要进行测试设计;而调试则不受时 间约束。 6、从执行的人员来看,测试经常是由 独立的测试组在不了解软件设计的条件下 完成的,而调试必须由程序员来完成。 7、从所使用的工具来看,大多数白盒 测试的执行和设计可有工具支持,而调试 程序员能利用的工具主要机事件发生的可能性的数量指
标。 在独立随机事件中,如果某一事件在全 部事件中出现的频率,在更大的范围内比较 明显的稳定在某一固定常数附近。就可以认 为这个事件发生的概率为这个常数。对于任 何事件的概率值一定介于 0和 1之间。
2.1.6用于测试的图
图(又叫做线性图)是一种由两种集合定 义的抽象数据结构,即一个节点集合和一 个构成节点之间连接的集合。 图中节点的度是以该节点作为端点的边的 条数。 在本节中将介绍的两种图: 程序图 有限状态机
• 任何过程设计都要被翻译成控制流图。
控制流图
• 在将程序流程图简化成控制流图时,应注 意: –在选择或多分支结构中,分支的汇聚处 应有一个汇聚结点。 –边和结点圈定的区域叫做区域,当对区 域计数时,图形外的区域也应记为一个 区域。
控制流图
待测试程序
1 2 6
节点
用流图表示的待测试程序
1 2,3 4,5
空闲 非法卡显示屏幕 S1;退卡 合法卡 显示屏幕S2 不正确的PIN 显示屏幕S3 等待第一次 PIN输入尝试 等待第二次 PIN输入尝试 正确PIN显示屏幕S5 等待事务选择
不正确的PIN 显示屏幕S4
不正确的PIN 显示屏幕S3
正确PIN 显示屏幕S5
等待第三次 PIN输入尝试
图2-2 用于PIN尝试的有限状态机
有限状态机与流程图的转换
有限状态机与流程图的转换
有限状态机与流程图的转换 状态图明显在架构上比流程图要简 单,包容的模型也比较丰富,需做的 假设比较少。另外,状态图比较重视 事件/动作的完成,比较不在意是哪一 个程序完成的。流程图则很在意动作 是如何完成的。
2.2白盒测试
白盒测试是一种可视的测试软件的方法, 即它把测试对象看作一个透明的盒子,测试 人员要了解程序结构和处理过程,按照程序 内部逻辑测试程序,检查程序中的每条通路 是否按照预定要求正确工作。白盒测试的过 程如图2-7所示:
基本路径测试
• 前提条件 测试进入的前提条件是在测试人员已经 对被测试对象有了一定的了解,基本上明确了 被测试软件的逻辑结构。
• 测试过程
过程是通过针对程序逻辑结构设计和加 载测试用例,驱动程序执行,以对程序路径进 行测试。测试结果是分析实际的测试结果与预 期的结果是否一致。
基本路径测试
• 包括以下4个步骤: 1. 程序的控制流图:描述程序控制流的一种图 示方法。 2. 程序圈复杂度:从程序的环路复杂性可导出 程序基本路径集合中的独立路径条数,这是 确定程序中每个可执行语句至少执行一次所 必须的测试用例数目的上界。 3. 导出测试用例:根据圈复杂度和程序结构设 计用例数据输入和预期结果。 4. 准备测试用例:确保基本路径集中的每一条 路径的执行。
车库门有限状态机
• 假设由两个按钮来控制门:一个称为开钮而另一个 称为关钮。当门是在关闭状态,按住开钮会使得门 进入上升状态,于此期间在马达控制之下,门将逐 渐的开启。 在门完全打开之后,即进入打开状态。再按住关钮 会使门进入下降状态,于此期间门将逐渐的关闭。 从状态途中可以清楚的看出门不能立即地从打开状 态至关闭状态,反过来亦如此。 而且,也可能轮流的按开钮与关扭,使门在上升与 下降状态之间转变,使得门的动作像玩偶一样。最 后,此模型说明当门是在关闭状态时按关钮或者门 是在打开状态时按开钮,将不会引起任何状态的改 变,所以什么事情都不会发生。
串行
If-Then-Else
If-Then
条件
前测试环路
后测试环路
图2-1 结构化程序设计构造的有向图
2、有限状态机 有限状态机是需求规格说明的一种标准的表 示方法。有限状态机是一种有向图,其中状态是 节点,转移是边。 图2-2是一个简单的自动柜员机(SATM)系统。 该图描述了用于个人标识编号PIN尝试部分的有限 状态机。这种机器包含5 个状态(空闲、等待第 一次PIN尝试等等)和8个用边表示的转移。转移 上的标签所遵循的规则是,“分子”是引起转移 的事件,“分母”是与该转移关联的行为。
第二章 软件测试基础
[本章要点] • 白盒测试和黑盒测试的定义; • 常见的白盒和黑盒测试设计技术; • 白盒测试与黑盒测试的区别; • 测试计划和测试报告的编制; • 测试用例的定义和编制方法。
[本章目标] 理解并掌握白盒测试和黑盒测试,以 及二者的优缺点和各自的应用范围; 能够熟练使用几种常见测试用例设计 技术; 了解测试计划和测试文档的作用,以 及应该包含的内容和制定方法; 了解测试报告的基本内容,以及测试 用例的基本内容和编制方法。
在软件测试领域,白盒测试可以用在 三种测试类型中:
1、单元测试 2、集成测试 3、回归测试
2.2.1白盒测试与调试的异同
1、从承担的任务来看,白盒测试同其 他类型测试一样,它的任务是发现所开发的 项目中的缺陷;但是,调试不属于测试,其 任务是纠正软件中的缺陷。 2、从最终的结果来看,白盒测试有预 知的结果,不可预知的只是程序是否通过测 试,并且成功测试的结果是发现错误的症状, 从而引起调试的进行;而调试的结果是消除 项目中的错误。
边
3 7
6
8
9 10 11
4
5
7
9
8
10
区域
11