软件工程第7章

合集下载

第7章软件测试标准

第7章软件测试标准

和隐含需要的能力和特性总和” 和隐含需要的能力和特性总和”
Байду номын сангаас
• 从软件质量的定义可以看出以下4个含义:
• 具有能满足给定需要的所有特性 • 具有所希望的各种属性的组合的程度 • 顾客或用户认为能满足其综合期望的程度 • 软件的组合特性,它确定软件在使用过程中将满足顾客预期要求的程度。
5
7.1.1 软件质量与度量
19
3.1.3软件质量评价
1. 开发人员的评价过程 2. 顾客的评价过程 3. 评价者的评价过程
20
1.开发人员的评价过程
• 指开发人员对软件产品的质量进行评价的 过程
– 首先要明确评价的概念,包括软件质量指示器 – 规定了对评价过程的要求,包括对组织的要求 (数据收集的反馈方式和途径)、项目的要求 (如确定质量要求、确定内部和外部质量度量 等),以及对质量分析、质量控制和质量评价 的要求。
• GB/T 18905-2002系列标准等同于ISO/IEC 14598标准是为软件产品 质量的测量、评估和评价提供了方法。 • 软件质量评价的基本部分包括:质量模型、评价方法、软件的测量和 支持工具。 • GB/T 18905-2002系列由6部分组成:
– – – – – – GB/T 18905.1-2002,概述软件产品评价的产品,提供评价需求和指南 GB/T 18905.2-2002,策划和管理 GB/T 18905.3-2002,开发者用的过程 GB/T 18905.4-2002,需求方用的过程 GB/T 18905.5-2002,评价者用的过程 GB/T 18905.6-2002,评价模块的文档编制
17
3.ISO 9126质量模型
18
3.ISO 9126质量模型

软件工程(pankaj jalote版)第7章编码(上)

软件工程(pankaj jalote版)第7章编码(上)

代码规模
重构技术
2
2
复杂度量
第7章 编码和单元测试
第7章 编码和单元测试 编码重点是易于阅读和理解。
维 维 护 护
易读
易读
易读
测 试
易读
易读
易读
编码
设计
第7章 编码和单元测试 为什么代码易于理解很重要?表中有答案。
排名 工作量 语句 工作 量少 语句 最少 内存 最小 1 2.5 5 4 1 2 可理解 内存 清晰度平均分 性 4 2 1 5 3 4 5 5 4 3.8 2.7 3.2 方差 2.16 1.76 2.16 标准差 1.47 1.33 1.47
不编程,你就废了
——第7章编码和单元测试
藏宝图
数据隐藏 1 编码原则
1
过程测试
2
3
实践经验
7.1
原则 指南
4 1
编码标准
7.4 第七章
单元 测试
2
测类单元
一个例子
1
计划
测试优先
7.2
增量 开发
2
结队编程
编码
单元 测试
7.5
检查 代码
代码自查
2
小组会议
3
3
版本控制
1
7.3
代码 演化
7.6
度量 代码
1
单出口单入口 的模块
含义
作用
含义
作用
含义
作用
7.1.1结构化编程(3)
单出口单入口让程序很容易读
入口
1 1 1 1 1 1 1
1
1
1
1
1
1
1
1
1
1
1

精品文档-软件工程经济学(赵玮)-第7章

精品文档-软件工程经济学(赵玮)-第7章

第7章 软件测试的资源分配、进度管理与最优发行 NIS软件的测试过程通常包括拟定测试计划和编制测试大 纲,设计和生成测试用例,按序完成单元测试、集成测试、系 统测试和运行测试,生成相应的测试报告等基本活动,其测试 流程见图7.1。需要说明的是,系统测试是需在相关硬件(计 算机硬件与网络设备)配置好的情况下所进行的软/硬件系统联 试,经系统测试通过后即可交付用户运行,而运行测试则是在 用户的作用下为提高软件可靠性所做的相关测试。此外,为使 软件测试能省时高效,应采用测试与开发同步进行和逐步推进 的渐近策略,并将测试贯穿于软件的整个生命周期的始终。
第7章 软件测试的资源分配、进度管理与最优发行
集成测试包括功能集成测试、操作剖面建立和有效性测试 三部分,其中功能测试通常采用非增量式集成方法或增量式集 成方法。非增量式集成方法是首先分别测试各个模块,然后再 把这些已被测试并确认为功能与性能符合设计要求的模块组合 起来进行整体测试;增量式集成测试方法则是采用测试一个模 块组装一个模块,然后再测试再组装,直到所有模块均被组装 完毕,并被整体测试合格为止的一种逐步组装的方式。显然, 非增量式集成测试可以对所有模块并行进行单元测试,能充分 利用人力,加快工程进度;但这种一步到位的方法容易形成混 乱,出现错误后不容易查找和定位,故一般适用于规模较小的 软件。增量式集成测 试虽然采用逐步到位的方法,要多费人力和工时,但由于每个 已被测试过的模块还可以在以后组装过程中的每一步骤(组装 一个新模块)进行新的测试,从而使得程序测试更为彻底。因 而从测试有效性角度来看,增量式集成测试将比非增量式集成
第7章 软件测试的资源分配、进度管理与最优发行 集成测试的第三个重要部分是有效性测试。由于软件经组 装测试并排错后,接口方面的问题已经解决,故以后集成测试 的主要问题是解决软件的有效性问题,所谓软件的有效性问题, 是指软件的功能、性能、可靠性、安全性及保障性等方面软件 的实际水平是否达到用户的需求。有效性测试是在开发方地点 在模拟用户运行环境的条件下所进行的一种用户需求测试,一 般采用黑盒测试来检验所开发并经单元测验、组装集成测试及 排错后的软件是否与描述用户需求的需求分析说明书相一致。 测试人员一般由开发方的测试人员及软件设计人员组成。以下 简述各类测试的基本内涵。

《软件工程实用教程》第7_章_软件测试技术

《软件工程实用教程》第7_章_软件测试技术

第7 章 軟體測試技術
7.2.3 白盒測試方法 白盒測試也稱結構測試或邏輯驅動測試。在使 用白盒測試方案時,測試者必須檢查程式的 內部結構,從檢查程式的邏輯著手,對所有 邏輯路徑進行測試,得出測試數據。 開始 1 .邏輯覆蓋法:以程式內部的邏輯結構為基礎 的測試用例設計技術。 X=x/a a>1andb= 0 (1)語句覆蓋 X=x+1 A = 2 o r (2)判定覆蓋 x>1 (3)條件覆蓋 輸出a,b,x
第7 章 軟體測試技術
3.錯誤推測法
錯誤推測法是基於經驗和直覺推測程式中所 有可能存在的各種錯誤,從而有針對性的 設計測試用例的方法。
第7 章 軟體測試技術
4.因果圖方法 (1) 分析軟體規格說明描述中,哪些是原因(即輸入條件 或輸入條件的等價類 ),哪些是結果 (即輸出條件 ) , 並給每個原因和結果賦予一個識別字。 (2) 分析軟體規格說明描述中的語義,找出原因與結果之 間、原因與原因之間對應的關係,根據這些關係,畫 出因果圖。 (3) 由於語法或環境限制,有些原因與原因之間,原因與 結果之間的組合情況不可能出現。為表明這些特殊情 況,在因果圖上用一些記號表明約束或限制條件。 (4) 把因果圖轉換為判定表。 (5) 把判定表的每一列拿出來作為依據,設計測試用例
第7 章 軟體測試技術
7.1.2 軟體測試原則 1. 應早並不斷地進行測試 2. 程式員應盡可能避免檢查自己的程式 3. 測試用例應當包括合理的輸入條件和 不合理的輸入條件 4. 測試用例應包括輸入數據和預期的輸 出結果兩部分 5. 全面檢查每個測試結果 6. 嚴格按照測試計畫來測試 7. 充分注意測試中的集群現象 8. 注意遵守“經濟性”的原則
第7 章 軟體測試技術
3)根據規格說明的每個輸出條件,使用前面的原則 1)。 4)根據規格說明的每個輸出條件,應用前面的原則 2)。 5)如果程式的規格說明給出的輸入域或輸出域是有序集 合,則應選取集合的第一個元素和最後一個元素作 為測試用例。 6)如果程式中使用了一個內部數據結構,則應當選擇這 個內部數據結構的邊界上的值作為測試用例。 7)分析規格說明,找出其他可能的邊界條件。

第7章语义建模

第7章语义建模
Principle of the database and application
数据库原理与应用
信息学院软件工程系
1
第7章 语义建模
关系数据理论(即“模式设计理论”)主要
研究的问题是如何构造合理的关系,使之 能准确地反应现实世界,有利于应用和具 体的操作。
优秀的数据库设计是应用成功的基石
2
7.1 概述 理解数据含义是永远不会停止的任务 “语义建模”:是对试图表示语义的所有 行为的一个恰当描述
3.设计一组正规的常用的完整性规则
4.设计一组用来操作这些正规对象的操作符
对象、规则和操作符组成一个扩展的数据模型
4
7.2 ER模型
7.2.1 概念模型
7.2.2 E/R图
数据的三种范畴
5
7.2.1 概念模型(Conceptual Model)
概念模型的用途


用于信息世界的建模
器件只能存放在一个仓库,仓库与器件--1:1
如果规定一个仓库可以存放多种器件,但是一种 器件只能存放在一个仓库,仓库与器件--1:n 如果规定一个仓库可以存放多种器件,同时一种 器件可以存放在多个仓库,仓库与器件--m:n
19
多个实体型间的联系
多个实体之间可以有不同的联系
例如:零件、供应商、仓库三个实体
多个实体型间的多对多联系
24
多个实体型的1:n联系
同一实体集内各实体间的联系
一对多联系---实例

职工实体集内部具有领导与被领
导的联系:某一职工(干部)“ 领导”若干名职工,一个职工仅 被另外一个职工直接领导 这是一对多的联系
同一实体型内 部的1:n联系 1 领导 职工 n

软件工程7-史济民

软件工程7-史济民
2. 系统元素设计
• 系统元素包括组成系统的类、子系统与接口、包等。系统 元素设计是对每个设计元素进行详细设计。主要的设计内 容是:
• 类/对象设计; • 子系统设计; • 包设计。
模式的应用
• 提倡在OOD中充分应用设计模式。 • 模式的定义
• 模式是解决某一类问题的方法论,也是对通用问题 的通用解决方案。
① 确定任务的特征。 ② 定义一个协调者任务和与之关联的对象。 ③ 集成其他任务和协调者。
• 任务管理部件的设计一般遵循如下的步骤 与策略:
① 识别由事件驱动和时间驱动的任务。
② 识别关键性任务、任务优先级以及任务管理 类。任务管理类是为了实现而引入的专门用 于管理和协调其他任务的任务。
③ 定义任务。说明任务的名称、功能、优先级 任务与其他任务的通信方式。
属性、操作、协作 者
类/对象 模型
用例 模型
对象关系模型
对象-行为模型
责任设计
消息设计 类及对象设计 系统架构设计
面向对象设计的任务
• OOD的软件设计可划分为两个层次,即系统架构 设计和系统元素设计。设计过程是循环渐进的。
1. 系统架构设计
• 软件系统架构是指系统主要组成元素的组织或结构,以及 其他全局性决策,组成元素之间通过接口进行交互。系统 架构包含关于软件系统组织的许多重要决定。
<<Interface>>
ICourseCatalogSystem
0..*
1 (from External System Interfaces)
4、分布式实现机制
• 为实现分布式结构,需完成以下工作。 1. 确定网络拓扑配置 2. 将设计元素分配到网络节点
• 节点容量(指内存量和处理能力) • 通信介质带宽(总线、LAN、WAN) • 硬件与通信链路的可用性、重选路由 • 对冗余与容错能力的要求 • 响应时间要求 • 吞吐量要求

计算机科学与技术专业课课件_软件工程SE_Chapter7

计算机科学与技术专业课课件_软件工程SE_Chapter7

◆ 软件测试准则
● ● ● ● ● ● 所有测试都应该能追溯到用户需求。 测试开始之前就制定出测试计划。 Pareto原理:80%的错误很可能是20%的模块造成的 从“小规模”测试逐步到“大规模”测试。 穷举测试是不可能的。 为了达到最佳的测试效果,应该由独立的第三方从事测试工作。
2013-8-31
1) 2) 3) 4) 5) 6) 7) 系统用户的要求 可以使用的编译程序 可以得到的软件工具 工程规模 程序员的知识 软件可移植性要求 软件的应用领域
2013-8-31
上海大学计算机学院
3
编码风格
◆ 编码风格的作用就是使代码容易读; ◆ 风格良好的代码更容易阅读和理解,错误更少; ◆ KIS(Keep it Simple)。
集成测试
●系统测试
经过测试的子系统装配成一个完整的系统来测试 发现的往往是软件设计中的错误,也可能发现需求说明中的错误
●验收测试(确认测试)
它的目标是验证软件的有效性(如果软件的功能和性能如同用户所 合理期待的那样,软件就是有效的) 用户积极参与,可能主要使用实际数据进行测试 发现的往往是系统需求说明书中的错误
第7章 实现
◆编码 ◆软件测试基础 ◆单元测试 ◆集成测试
◆确认测试
◆白盒测试技术
◆黑盒测试技术
◆调试 ◆软件可靠性
2013-8-31 上海大学计算机学院 1
主要任务
◆编码和测试统称为实现 ◆编码
● 把软件设计结果翻译成程序。 ● 程序的质量主要取决于软件设计的质量。 ● 程序设计语言的特点及编码风格。
● 对一段程序注释,而不是每一个语句
◆ 输入输出
● 对所有输入数据都进行检验 ● 检查输入项重要组合的合法性 ● 保持输入格式一致 ● 应允许缺省值 ● 保持输入格式简单 ● 使用数据结束标记(EOF、BOF),不要指定数据的数目

软件工程导论(第7章)

软件工程导论(第7章)

测试的正确定义:“为了发现程序中的错 误而执行程序的过程。”
7.2.2 软件测试准则
1)所有测试都应该能追溯到用户需求;
2)应该远在测试前就制定出测试计划;
3)把Pareto原理应用到软件测试中;Pareto原理 说明测试发现的错误中的80%很可能是由程序 中20%的模块造成的。
4)应该从“小规模”测试开始,并逐步进行“大 规模”测试;
USER32.DLL; GDI32.DLL; KERNEL32.DLL。
Windows消息机制:
1)基于消息的事件驱动 消息可以是由硬件发来的(存于系统队列),
也可以由Windows系统和应用程序发来(存于 程序队列中);
每一个Windows程序在不停的捕捉各种消息, 并进行处理;
每个窗口都必须有一个窗口函数,来负责消息 的判断与处理。
3)重要的执行路径 由于不可能进行穷尽测试,因此选择测试
路径是非常关键的。 4)出错处理通路 5)边界条件
7.3.2 代码审查
审查小组: 1)组长; 2)程序的设计者; 3)程序的编写者; 4)程序的测试者。
7.3.3 计算机测试
由于软件模块不是一个独立的系统,不能独 立运行,要依靠其他模块调用,或需要调用其 他模块。
1.模块测试 模块测试又称单元测试,它把每个模块作为
单独的实体来测试。 2.子系统测试
子系统测试是把经过单元测试的模块放在一 起形成一个子系统来测试。
3.系统测试 系统测试是把经过测试的子系统装配成一个完
整的系统来测试。 4.验收测试
验收测试把软件系统作为单一的实体进行测试 (利用用户的实际数据测试)。 5.平行运行
如PL/1、PASCAL、C、ADA等 3)专用语言 如APL、BLISS、FORTH、LISP、PROLOG等
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
北华大学计算机学院
8.1.2 抽象与逐步求精
软件工程
抽象 过程抽象 数据抽象
把完成一个特定功能的动作序列抽象为 抽出事务的本质特性而暂时不考虑它们 把一个数据对象的定义(或描述)抽象 一个过程名和参数表 的细节。是控制复杂性的基本策略。 为一个数据类型名
定义 软件系统 被描述为 基于计算 机的大系 统的一个 组成部分
计算水费和电费 计算水量和电费
住户详情 本月用水量 住户详情
本月用电量 电费 电费
计算水费 计算水费
水费 水费
计算电费 计算电费
住户详情数据结构中包括: “本月用水量”、“本月用电量”。 “特征耦合”图可改进“数据耦合”图
北华大学计算机学院
4.控制耦合----5.外部耦合
软件工程
4.当模块A向模块B所传递的信息控制了B的内部 逻辑。 获得库存记录
2. 模块规模适中: 过大不易理解;太小则接口开销过大。 注意分解后不应降低模块的独立性。
北华大学计算机学院
3. 选择适当的深度、宽度、扇出和扇入
软件工程
深度 = 分层的层数。过大表示分工过细。 宽度 = 同一层上模块数的最大值。过大表示系统复杂 度大。 北华大学计算机学院
软件工程

扇出 = 一个模块直接 调用\控制的模块数。
是程序设计技术,它采用自顶向下逐步求精 流程图 结构化 的设计方法和单入口单出口的控制构件。 结程序设计 构 化 盒图 设 计 判定树 图 形 表 示 判定表 法
北华大学计算机学院
7.2.2 图形表示法
软件工程
1.流程图(也称为程序框图)是最常用的一种 表示法, “顺序”、“分支”和“循环”三个 基本控制构件用流程图表达的形式如图8-2-1所 示。 F
北华大学计算机学院
表7-1 判定表
软件工程


1 T F T F √
2 T F F T √
3 F T T F √
4 F T F T
5 F F
条件
固定价格方式 浮动价格方式 耗电<100kW.h 耗电≥100kW.h 收取最低标准费 按价格表A收费 按价格表B收费 其他处理
动作


北华大学计算机学院
else 部分
if-then-else结构 图8-2-3 盒图的构件
循环结构
北华大学计算机学院
7.2.3 判定表与判定树
软件工程
用于:条件复杂,根据这些条件的组合选择动作 判定表由四部分组成:
左上部
左下部 右上部 右下部
列出所有条件
列出所有可能的动作 所有可能的条件组合(矩阵) 条件组合与动作之间的对应关系
软件 结构组成
系统中所有 过程性部件 (即模块) 构成的 层次结构 (即程序结构)
对应于 程序结构的 输入输出 数据结构
目标:模块化的程序结构、明确各模块之间的控制 关系、说明程序的输入输出数据流、进一步协调程 序结构和数据结构。 北华大学计算机学院
结构设计原则
软件工程
1. 提高模块独立性
争取低耦合、高内聚(增加内聚 > 减少耦合)
Great deal dependence of
单价
Independent 开发货单
2.数据耦合
Highly coupled
数量 Loosely coupled
金额 Uncoupled
两个模块间通过参数交换信 息, 而信息仅限于数据
计算金额

北华大学计算机学院
3.特征耦合
软件工程
如果两个模块都与同一个数据结构有关,则为特征耦合。
软件工程
软件工程
第 7 章
软 件 设 计 基 础
概 念
基本概念
设计 过程
设计 工具
说明 与评审
北华大学计算机学院
8.1.1 软件设计过程
软件工程
概要设计 详细设计
管 技 理与术 角 角 度 度
结构设计 数据设计
Text Text
过程设计
将 “概设” 结果进一步精化 把信息描述转换为实现软件所 概要设计 根据需求确定软件和数据的总体 结构设计 确定程序各主要部件之间的关系 详细设计 完成每一部件的过程化描述 数据设计 过程设计 框架 成算法表示和数据结构 要求的数据结构
北华大学计算机学院
对连锁反 耦合方式 可修改性 应的影响 非直接 弱 好 数据 弱 好 特征 弱 中 控制 中 不好 外部 中 不好 公共 强 不好 内容 最强 最坏
耦合、内聚与模块独立性的关系
软件工程
北华大学计算机学院
7.1.4 软件总体结构设计(software architecture)
软件工程
3 fan-out 9
A A的扇出
扇入
= 直接调用该模块 的模块数
A的扇入 A
在不破坏独立性的前提 下,fan-in 大的比较好。
北华大学计算机学院
4、作用域在控制域内
软件工程
控制域
B
M A C
M的控制域为 {M,A,B,C}
作用域:M中的一个判定所影响的模块。
例如: A:
………… if …… then goto B1 ………… …………
北华大复杂可能表 明模块的独立性差。
6、单出单入,避免内容耦合。
7、模块功能可预测 —— 相同输入必产生相 同输出。反例:模块中使用全局变量或静 态变量,则可能导致不可预测。
北华大学计算机学院
7.2 软件过程设计技术和工具
软件工程
7.2.1 结构化程序设计
B: ………… ………… B1: ………… …………
A: ………… if …… then goto M1 ………… …………
M: ………… ………… M1: goto C1 ………… …………
作用域在控制域内
作用域超出了控制域
上例中A的作用超出了控制域。改进方法之一,可以 把A中的 if 移到M中;方法之二,可以把C移到A下面。
软件工程
PDL应具有下述特点: 1.关键字采用固定语法并支持结构化构件、 数据说明机制和模块化; 2.处理部分采用自然语言描述; 3.允许说明简单(标量、数组等)和复杂 (链表、树等)的数据结构; 4.子程序的定义与调用规则不受具体接口方 式的影响。
北华大学计算机学院
7.2.4 过程设计语言(PDL)
判定表的每一列可解释为一条处理规则 北华大学计算机学院
7.2.3 判定表与判定树
软件工程
【例7.2】问题处理描述:耗电记费系统可以 采用固定价格收费、浮动价格收费和其他方 式收费三种方式。若采用固定价格方式收费, 对每月耗电100kW•h以下的用户只征收最低 标准费,超过100kW•h的用户按价格表A收 费;若采用浮动价格方式收费,则每月耗电 100kW•h以下的用户按价格A收费,超过 100kW•h的用户按价格B收费。
需求 软件用问 题域约定 的习惯用 语表达
设计 概要设计 过渡到详 细设计时, 抽象级再 一次降低
实现
编码完成 后达到了 抽象的最 低级
北华大学计算机学院
逐步求精
软件工程
逐步求精
为了能集中精力解决主要问题而 尽量推迟对问题细节的考虑
抽 象
求 精
北华大学计算机学院
信息隐藏
软件工程
模块内所含信息对那些不需要这些信息的模块不可
软件工程
【例7.2】判定树
耗电<100kW· — 收取最低标准费 h
固定方式
耗电≥100kW· — 按价格表A收费 h 耗电<100kW· — 按价格表A收费 h
耗电收费
浮动方式
耗电≥100kW· — 按价格表B收费 h 其他方式— 其他处理
图8-2-5 用判定树表示计算耗电收费的算法
北华大学计算机学院
软件工程
PDL(Procedure Design Language)也称 为结构英语或伪码,是所有正文形式的 过程设计工具的统称。
PDL经常表现为一种“混杂”的形式,允 许自然语言(如英语)的词汇与某种结 构化程序设计语言(如Pascal、C、Ada 等)的语法结构交织在一起
北华大学计算机学院
7.2.4 过程设计语言(PDL)
最坏
不好 中 中 好
不好
中 中 中 好
不完全黑
不完全黑 半透明 半透明 透明

中 不好 不好 最坏



透明
最坏
北华大学计算机学院
模块间的耦合 1.非直接耦合 --— 2.数据耦合
软件工程
1.非直接耦合: 耦合:表示一个软件结构内各个模块之间的互连程 两个模块中任一个,都不依赖于对方能独立工作 度,尽量选用松散耦合的系统
软件工程
考察一个PDL的原型,它可以建立在任意一个通用 的结构化程序设计语言之上。基本成分包括:子 程序定义、界面描述、数据说明、块结构、分支 结构、循环结构和I/O结构。 数据说明的形式为: TYPE <变量名> IS <限定词1> <限定词2> 其中: < 变量名 >——局部变量或全局变量; <限定词1>——某个特定关键字(例如,SCALAR, ARRAY,LIST,STRING,STRUTURE等); <限定词2>——说明此处定义的变量在该过程或整 个程序中应如何使用。
7.一个模块和另一个模块的内部属性有关 (运行程序和内部数据) 。
如:一个模块使用另一个模块内部的数据或控制信息; 北华大学计算机学院 一个模块直接转移到另一个模块。
软件工程
七种“耦合模块”的性能比 较
可读性 好 好 中 不好 不好 最坏 最坏 通用性 好 好 中 不好 不好 最坏 最坏
设计模块时,应以数据耦合为主,辅以特征耦合与控制耦合, 消除公共耦合和内容耦合。
相关文档
最新文档