《软件工程》(第2版)第7章
软件测试教程2版-第7章软件项目单元测试(简版)
2）设计测试类模块 一个模块或一个方法并不是一个独立的程序，在考虑测试时要同时考虑它与外界的联 系， 用些辅助模块去模拟与所测模块相联系的其他模块。 辅助模块分两种： 驱动模块 （driver） ， 相当于所测模块的主程序，接收测试数据，把这些数据传送给所测模块，最后再输出实际测 试结果；桩模块（stub） ，用于代替所测模块调用的子模块，可做少量数据操作，不需要把子 模块所有功能都带进来，但不容许不做任何事情。
《软件测试教程（第 2 版） 》
第 7 章 软件项目的单元测试（简版）
贺 平 编著
电子工业出版社
所测模块与它相关驱动模块及桩模块共同构成了“测试环境” 。因为在软件交付时不作 为产品的一部分一同交付，且其编写需一定工作量，特别是桩模块，不能只简单地给出“曾 经进入”的信息。为正确测试，桩模块需要模拟实际子模块功能。 编写桩模块较困难、费时，一种方法是只须在项目进度管理时将实际桩模块的代码编写 工作安排在被测模块之前编写即可， 这样可提高测试工作效率， 提高实际桩模块的测试频率， 有效保证软件质量。但为保证能向上一层级提供稳定可靠实际桩模块，为后续模块测试打下 良好基础，驱动模块必不可少。 3）跟踪调试 跟踪调试不仅是深入测试代码的最佳方法，也是程序调试发现错误根源的有力工具。 代码开发工具（如 JBuilder ）一般都集成排错工具，其一般由执行控制程序、执行状态 查询程序、跟踪程序组成。执行控制程序包括断点定义、断点撤销、单步执行、断点执行、 条件执行等功能。 执行状态查询程序包括寄存器、堆栈状态、变量、代码等与程序相关的各种状态信息的 查询。跟踪程序用以跟踪程序执行过程中所经历的事件序列（如分支、子程序调用等） 。可通 过对程序执行过程中各种状态的判别进行程序错误的识别、定位及改正。 对于模块单元跟踪调试，最好能做到对被测模块的每次修改都用测试用例进行跟踪执行 一遍，以排除所有可能出现或引进的错误。必须调用驱动模块对所有测试用例执行一次，并 对出现错误或异常的测试用例跟踪执行一次，以发现问题根源。 几种排错时应采用的方法策略： （1）断点设置。通常断点的设置除了根据经验与错误信息来设置外，还应重点考虑： ① 函数调用语句。 ② 判定转移/循环语句。 ③ SQL 语句。 （2）复杂算法段。出错的概率常与算法复杂度成正比，越复杂算法越需重点跟踪，如递 归、回溯等算法。 （3）可疑变量查看。当程序停止在某条语句时，可查看变量当前值和对象当前属性，通 过对比这些变量当前值与预期值可轻松定位程序的问题根源。 3．单元测试的设计方案 主要定义单元测试环境、静态测试和动态测试执行三个方面需做工作和完成任务。 1）单元测试环境配置的测试 （1）网络连接是否正常。 （2）网络流量负担是否过重。 （3）软件测试平台是否可选，是否在不同的软件测试平台进行软件测试。 （4）所选软件测试平台的版本（包括 Service Pack）是否正确。 5 / 60
第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质量模型
《软件工程实用教程》第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章 面向对象技术总论
在程序设计语言中，类是一个完整的、独立的、可重用 的，具有低耦合、高内聚特性的程序模块。类相当于一种自 定义数据类型，它类似于C语言中的结构体类型(C++本身就 可以使用strut关键字来定义类)，不仅包含数据结构也包含 操作结构。数据类型作为程序语言中进行变量内存分配、类 型匹配、操作检查的基础，为程序的一致性和安全性提供了 重要的保证。因此，类概念的引入从类型角度进一步提高了 程序的安全性。
第7章 面向对象技术总论
7.2.2 对象及对象实例 现实世界中的具体事物就是对象或者对象实例，类则是
对象实例的结构抽象。 每个对象实例一般具有三方面的特性(亦称对象“三要
素”)： (1) 确定的标识，能够被唯一地确认。 (2) 具有一定的属性，表示其性质或状态。 (3) 具有一定的行为能力或者操作能力，可给外界提供
第7章 面向对象技术总论
例如，客户如果想从ATM机中取钱，通常会按下取钱 按键，这实际上就是向ATM机发送了取钱消息，也是向 ATM机发送了取钱请求，ATM机会显示一个取钱界面，让 用户输入取款数额，这是通过ATM机的一个方法或者操作 实现的。用户输入取款金额后按下确定键，相当于又向 ATM机发送新的消息，导致ATM机的另一个方法的调用， 通常在该方法中又会向其他对象发送消息，例如该客户的账 户Account对象，通过调用该账户对象的draw()操作实现账 户上资金的更新。用户通过和ATM机一系列的请求/响应的 交互活动完成了执行系统的某个功能，如取钱。客户对象、 ATM对象、Account对象之间的消息交互见图7.6。
第7章 面向对象技术总论
如上所述，新一代的程序设计语言技术并不是简单地否 定上一代语言，而是在上一代语言的基础上增加新的程序结 构元素(函数、类)，从而实现更复杂的程序结构。这种新的 程序元素更直观、更真实、更自然、更完整地抽象了现实世 界中的数据和处理(或者事物与概念)，更好地抽象了程序中 的变量和代码，也进一步增强了程序的易读性、安全性、稳 定性和重用性，同时改变了系统的分析和设计方法。归根结 底，程序设计语言的发展就是程序结构以及建立在其基础上 的分析、设计方法的发展。
软件工程7-史济民
• 系统元素包括组成系统的类、子系统与接口、包等。系统 元素设计是对每个设计元素进行详细设计。主要的设计内 容是：
• 类/对象设计； • 子系统设计； • 包设计。
模式的应用
• 提倡在OOD中充分应用设计模式。 • 模式的定义
• 模式是解决某一类问题的方法论，也是对通用问题 的通用解决方案。
① 确定任务的特征。 ② 定义一个协调者任务和与之关联的对象。 ③ 集成其他任务和协调者。
• 任务管理部件的设计一般遵循如下的步骤 与策略：
① 识别由事件驱动和时间驱动的任务。
② 识别关键性任务、任务优先级以及任务管理 类。任务管理类是为了实现而引入的专门用 于管理和协调其他任务的任务。
③ 定义任务。说明任务的名称、功能、优先级 任务与其他任务的通信方式。
属性、操作、协作 者
类/对象 模型
用例 模型
对象关系模型
对象-行为模型
责任设计
消息设计 类及对象设计 系统架构设计
面向对象设计的任务
• OOD的软件设计可划分为两个层次，即系统架构 设计和系统元素设计。设计过程是循环渐进的。
1. 系统架构设计
• 软件系统架构是指系统主要组成元素的组织或结构，以及 其他全局性决策，组成元素之间通过接口进行交互。系统 架构包含关于软件系统组织的许多重要决定。
<<Interface>>
ICourseCatalogSystem
0..*
1 (from External System Interfaces)
4、分布式实现机制
• 为实现分布式结构，需完成以下工作。 1. 确定网络拓扑配置 2. 将设计元素分配到网络节点
• 节点容量（指内存量和处理能力） • 通信介质带宽（总线、LAN、WAN） • 硬件与通信链路的可用性、重选路由 • 对冗余与容错能力的要求 • 响应时间要求 • 吞吐量要求
《软件工程》课程教学大纲
《软件工程》课程教学大纲一、课程基本信息课程名称：软件工程英文名称：SoftwareEngineering课程编码：U223C课程类别：专业主干课总学时：48学时（含实验IO学时）总学分：3适用专业：计算机科学与技术/网络工程方向先修课程：高级语言程序设计，数据库设计原理，数据结构开课系部:计算机科学与技术系二、课程的性质和任务《软件工程》是计算机科学与技术专业本科生的一门专业主干课程。
它是一门指导计算机软件系统开发和维护的工程学科，也是计算机科学与技术领域的一个重要学科。
软件工程学是用以指导软件人员进行软件的开发、维护和管理的科学，通过本课程的学习，使学生掌握软件工程的基本概念、基本原理、实用的开发方法和技术，了解软件工程各领域的发展动向；开发软件项目的工程化的方法及在开发过程中应遵循的流程、准则、标准和规范等。
使学生掌握开发高质量软件的方法，以及有效地策划和管理软件开发活动，为今后从事软件开发和应用打下良好的基础。
通过本课程的学习，培养学生对软件开发能力和项目管理能力。
三、课程教学基本要求（一）理论教学内容和基本要求第1章软件工程概述了解软件工程的产生和发展、软件危机的原因，知道如何消除软件危机。
明白软件工程的基本概念，知道软件工程中包含的领域范围重点：软件危机的产生和消除方法第2章软件过程软件与软件生命周期任务，软件开发过程中的基本开发模型，软件开发工具与软件开发环境。
掌握软件生存期模型，软件开发模型方法介绍。
重点：软件与软件生存期，软件开发过程模型难点：软件开发过程模型第3章结构化分析掌握软件需求获取的方法、软件需求工程的任务、软件需求的原则、主要的需求分析方法；需求工程的基本活动、需求的有效性验证、需求变动管理、需求规格说明；建立结构化分析的三种模型；三种模型对应的描述方法：E-R图，数据流图，状态图。
掌握分层数据流图、数据词典和加工逻辑说明的基本构造方法。
重点：软件需求获取方法、结构化分析方法、分析建模方法难点：结构化分析建模方法第4章结构化设计理解软件结构化分析与结构化设计的映射关系，软件设计的基本原理。
软件工程学课后习题答案
2020/10/27
2020/10/27
2020/10/27
2020/10/27
•作业及解答（第3章）
电话号码=[校内电话号码|校外电话号码] 校内电话号码=非零数字+ 3 位数字 //后面继续定义 校外电话号码=[本市号码|外地号码] 本市号码=数字零+8位数字 外地号码=数字零+3位数字+8位数字 非零数字=[1|2|3|4|5|6|7|8|9] 数字零＝0 3位数字＝3{数字}3 //3至3个数字 8位数字=非零数字+7位数字 7位数字=7{数字}7 数字＝[0|1|2|3|4|5|6|7|8|9]
2020/10/27
•作业及解答（第3章）
2020/10/27
•作业及解答（第3章）
从问题陈述可知，本系统数据源点是“病人”和“护士”，他 们分别提供生理信号和要求病情报告的信息。进一步分析 问题陈述，从系统应该“定时记录病人情况以形成患者日 志”这项要求可以想到，还应该有一个提供日期和时间信 息的“时钟”作为数据源点。
软件工程学课后习题答案
2020/10/27
•作业及解答（第3章）
2-4 医院对患者2监护系统的基本要求是随时接收每个病人 的生理信号(脉搏、体温、血压、心电图等)，定时记录病 人情况以形成患者日志，当某个病人的生理信号超出医生 规定的安全范围时向值班护士发出警告信息，此外，护士 在需要时还可以要求系统印出某个指定病人的病情报告。
2020/10/27
1 2 3 4 5 6 7 8 9 10 11 12
人数≤40
TTTT
40＜人数≤60
TTTT
人数＞60
TT T T
助教
T
T
T
软件工程导论(第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等
软件工程考核知识点-第7章-软件测试
软件工程考核知识点-第7章-软件测试7.1 软件测试的目的及原则7.1.1 软件测试的目的(1)软件测试是为了发现错误而执行程序的过程。
(2)一个好的测试用例能够发现至今尚未发现的错误。
(3)一个成功的测试是发现了至今尚未发现的错误的测试。
因此,测试阶段的基本任务应该是根据软件开发各阶段的文档资料和程序的内部结构,精心设计一组“高产”的测试用例,利用这些实例执行程序,找出软件中潜在的各种错误和缺陷。
7.1.2软件测试的原则在软件测试中,应注意以下原则:(1)测试用例应由输入数据和预期的输出数据两部分组成。
这样便于对照检查,做到"有的放矢"。
(2)测试用例不仅选用合理的输入数据,还要选择不合理的输入数据。
这样能更多地发现错误,提高程序地可靠性。
对于不合理地输入数据,程序应拒绝接受,并给出相应提示。
(3)除了检查程序是否做了它应该做的事,还应该检查程序是否做了它不应该做的事。
例如程序正确打印出用户所需信息的同时还打印出用户并不需要的多余的信息。
(4)应制定测试计划并严格执行,排除随意性。
(5)长期保留测试用例。
测试用例的设计耗费很大的工作量,必须作为文档保存。
因为修改后的程序可能有新的错误,需要进行回归测试。
同时,为以后的维护提供方便。
(6)对发现错误较多的程序段,应进行更深入的测试。
有统计数字表明,一段程序中所发现的错误数越多,其中存在的错误概率也越大。
因为发现错误数多的程序段,其质量较差。
同时在修改错误过程中又容易引入新的错误。
(7)程序员避免测试自己的程序。
测试是一种"挑剔性"的行为,心理状态是测试自己程序的障碍。
另外,对需求规格说明的理解而引入的错误则更难发现。
因此应由别的人或另外的机构来测试程序员编写的程序会更客观,更有效。
7.2 测试方法软件测试方法一般分为两大类:动态测试方法与静态测试方法,而动态测试方法中又根据测试用例的设计方法不同,分为黑盒测试与白盒测试两类。
软件工程：理论与实践(第2版)
读书笔记
如果是初学者，不建议阅读此书，干巴巴得容易让人丧失兴趣，建议阅读《构建之法》。
目录分析
第1章软件与软 件工程
第2章软件过程
1.1软件 1.2软件危机 1.3软件工程 1.4软件开发方法 1.5软件工程工具 1.6 “小型网上书店系统”案例介绍 习题
2.1软件过程概述 2.2软件生命周期 2.3软件开发模型 2.4软件开发模型实例 习题
软件工程：理论与实践（第2 版）
读书笔记模板
01 思维导图
03 读书笔记 05 作者介绍
目录
02 内容摘要 04 目录分析 06 精彩摘录
思维导图
本书关键字分析思维导图
第版
内容
第章
面向对象
过程
实例
面向对象
软件
软件
工程 软件
案例
理论
习题
过程
系统
实验
ห้องสมุดไป่ตู้
书店
工程
内容摘要
本书按照典型的软件开发过程来组织内容，旨在培养读者具备软件工程思想及实际软件开发的能力。本书共 分为12章，内容涉及软件与软件工程、软件过程、可行性研究与项目开发计划、结构化分析、结构化设计、面向 对象方法与UML、面向对象分析、软件体系结构与设计模式、面向对象设计、软件实现、软件测试、软件维护与 软件工程管理。本书理论与实践相结合，内容翔实，可操作性强。本书是高等院校计算机科学、软件工程及相关 专业“软件工程”课程的理想教材。
第6部分软件维护与软件工程管 理
12.1软件维护 12.2软件估算 12.3软件开发进度计划 12.4软件开发人员组织 12.5软件开发风险管理 12.6软件质量保证 12.7软件配置管理概述 12.8软件工程标准与软件文档 12.9软件过程能力成熟度模型
软件工程课后习题答案2-12章
D3生理信息 定时的生理信号
F2生理信号 P1 接收信号 F2生理信号 定时的 生理信号
F6日志 E3 时钟 F3日前、时间 P4 定时取样 生理信号 F6日志 E1 护士 F1要求报告 P6 产生病情报告 D1患者日志
范
信
理
生
患者生理信 号获取
生理信号
定
时
生
理
生
号
理
信
信
围
号
号
患者监护系 统
危 日志 机信息
安排航班
预 定 信 息
机票 信息
交款
打印取票单 据
打印及发放 机票
有
航班
通 效 知
设置航班
录入预定信 息
录入取票凭 证
核对取票凭 证
P2 分析信号 E2 病人 F2生理信号
危及病人信息 F2生理信号 D2患者安全范围 P7制定安 全范围 P5 更新日志
P3 产生警告信息 F4警告信息 E1 护士
F5安全范围
监护处理
志 日 定时生理信号
号 生理信
监护信息输 出
息
生
理
制定生理信 号安全范围
接收信号
定时取样 生理信号
时间
分析信号
更新日志
报警
危机信
信
号
范
围
信息 危机
生
信 理 生 时 定 号 信 理
日 志
取得时间
号
病情报告
• P104:4 • 美国某大学有200名教师，校方与教师工会刚刚签订一项协议。 按照协议，所有年工资超过$26000（含$26000 ）的教师工 资将保持不变，年工资少于$26000的教师将增加工资，所增 加工资数额按下述方法计算：给每位教师所赡养的人（包括 教师本人）每年补助$100，此外，教师有一年工龄每年再多 补助￥50，但是，增加后的年工资总额不能多于$26000。 • 教师工资档案存储在行政办公室的磁带上，档案中有目前的 年工资、赡养的人数、雇佣日期等信息。需要写一个程序计 算并印出每名教师的原工资和调整后的新工资。 • 要求：（1）画出此系统的数据流图；（2）写出需求说明； • （3）设计上述的工资调整程序(要求用HIPO图描绘设计结果)， 设计时分别采用两种算法，并比较两种算法的优缺点： – （a）搜索工资档案数据，找出年工资少于$26000的人， 计算新工资，校核是否超过$26000，存储新工资，印出新 旧工资对照表； – （b）把工资档案数据按工资从最低到最高的次序排序，当 工资数额超过$26000时即停止排序，计算新工资，校核是 否超过限额，存储新工资，印出结果。 • （4）你所画出的数据流图适应用那种算法？
软件工程课后习题答案2-12章
书状态为S2&终端 输入“H=”加书名 管理员设置状 态 管理员删除 管理员添加
预约
书出库（删除） 书入库
图4.4.2
(三)图书馆终端用户模式的有穷状态机描述 • 状态机J：{读者查询状态，查询结果} • 输入集K：{终端输入用户查询命令，书的各种 状态（S1，S2，S3）} • 转换函数T：如图4.4.3所示 • 初始态S：{读者查询状态} • 终态集F：{查询结果}
取票通知 账单 机票 账单
P3.1 核对取票凭证 顾客 取票通知 P3.2 交款 机票 P3.3 打印机票
机票预定系 统
信 息 通 知 单 机 票
账
单
信息
机票
通
预定信息处 理
信息
知
账
通
单
有
单
取票凭证处 理
通知 账单 单
账单
信 息 定 预 航班信
息
机票预定子 系统
单 知
机票发放子 系统
效 通 知
机
票
取款单
P3.1输入取款 信息
取款信息 E1储 户 密码 P3.2 密码校验
P4 计算利息
利息 利息 P5 打印利息 清单
密码正确信息
E2业 务员
利率
P6设置利 率
利率
不能是两个分开的子系统，是相同的前台单个处理
银行储蓄系 统
存 款 单 款
率 利
利 存单 息清单
密 码
业务单据录 入
利 率
存款单
取
单
储蓄业务处理
（一）图书状态的有穷状态机描述 • 状态机J：{书在图书馆S1，书被借出S2， 书被预约S3} • 输入集K：{书上条形码，借阅卡条形码， 终端输入各种命令} • 转换函数T：如图4.4.1所示 • 初始态S：{书在图书馆S1，书被借出S2} • 终态集F：{书被借出S2，书被预约S3}
软件工程(第二版)PPT
依赖。 软件系统的安全层级、措施与防范机制。 软件系统与其它相关系统之间的协作关系。 软件系统与用户组织及其工作任务的协调性与
适应性。
3. 项目可行性分析
以少量的时间及人力成本，对项目是否可着手 实施作出有依据的判断，以避免因项目实施条 件不具备而造成的大量的人力、物力与时间的 浪费。可从技术、经济、应用等几个方面进行 可行性分析，分析结论则需要撰写成可行性分 析报告，并提交有关部门确认。
10. 建立需求模型
需求建模是用户需求问题图解，一些常用模型 有：业务树图、用例图、活动图。其中，业务 树是结构化需求建模，用例图是系统业务举例， 活动图则反映系统工作流程。
11. 进行需求验证
需求验证是指对需求分析成果的检查与确认。 主要的需求验证内容有：有效性验证、一致性 验证、完整性验证、现实性验证、可检验性验 证。
概要设计以需求规格定义为依据，首先要确定 的是系统构架，然后以系统构架为基础，确定 系统全局数据结构、程序结构，考虑系统安全 防范、故障处理措施。
2. 系统构架
系统构架是软件系统的基础框架，需要考虑问 题有：系统支持环境、系统体系结构。
系统支持环境是构建软件大厦的地基，涉及硬 件环境、软件环境、网络环境。
增量模式在整体上具有瀑布模式的里程碑特点， 可适应大型项目。但系统的局部构建上，则体 现为基于增量构件的原型进化，可适应用户的 需求变更。
5. 螺旋模式
螺旋模式是一种可较好规避开发风险的过程模 式。螺旋模式的特点是项目基于任务域螺旋式 递进，每一个任务域都需要进行风险评估，并 需要根据评估结论制定有效的风险规避措施。
自学考试软件工程第7章自测题及参考答案
第7章自测题及参考答案一、名词解释1. 软件测试2.黑盒法3.白盒法4.渐增式测试5.非渐增式测试6.调试二、填空题1.软件测试是为了_____而执行程序的过程。
2.运行被测程序的方法称为_______测试。
3.动态测试中，主要测试软件功能的方法称为______法。
4.选择测试用例，使得被测程序中每个判定的每个分支至少执行一次，这种逻辑覆盖标准称为_______。
5.要覆盖含有循环结构的所有路径是不可能的，一般通过限制_____来测试。
6.用等价类划分法设计测试用例时，如果被测程序的某个输入条件规定了取值范围，则可确定一个合理的等价类和_______。
7.凭经验或直觉推测程序中可能存在的错误而设计测试用例的方法是_______。
8.集成测试中的具体方法是______。
9.确认测试阶段的两项工作是______。
10.在单元测试中，测试一个模块时，需要设计_______。
三、选择题1.测试的关键问题是( )。
A.如何组织软件评审B.如何选择测试用例C.如何验证程序的正确性D.如何采用综合策略2.软件测试用例主要由输入数据和( )两部分组成。
A.测试计划B.测试规则C.预期输出结果D.以往测试记录分析3.成功的测试是指运行测试用例后( )。
A.未发现程序错误B.发现了程序错误C.证明程序正确D.改正了程序错误4.下列几种逻辑覆盖标准中，查错能力最强的是( )。
A.语句覆盖B.判定覆盖C.条件覆盖D.条件组合覆盖5.在黑盒测试中，着重检查输入条件组合的方法是( )。
A.等价类划分法B.边界值分析法C.错误推测法D.因果图法6.单元测试主要针对模块的几个基本特征进行测试，该阶段不能完成的测试是( )。
A.系统功能B.局部数据结构C.重要的执行路径D.错误处理7.软件测试过程中的集成测试主要是为了发现( )阶段的错误。
A.需求分析B.概要分析C.详细设计D.编码8.不属于白盒测试的技术是( )。
A.路径覆盖B.判定覆盖C.循环覆盖D.边界值分析9.集成测试时，能较早发现高层模块接口错误的测试方法为( )。
软件工程第7章习题
5. 软件测试用例主要由输入数据和( 成 A 测试计划 C 预期输出结果 B 测试规则
)两部分组
D 以往测试记录分析 答案: C )
6. 成功的测试是指运行测试用例后( A 未发现程序错误 C 证明程序正确
B 发现了程序错误 D 改正了程序错误 答案: B
7. 下列几种逻辑覆盖标准中, 查错能力最强的是( 答案: D
8. 在黑盒测试中, 着重检查输入条件组合的方法是 ( ) A 等价类划分法 C 错误推测法 B 边界值分析法 D 因果图法 )
)
A 语句覆盖 B 判定覆盖 C 条件覆盖 D 条件组合覆盖
答案: D 9. 软件测试过程中的集成测试主要是为了发现( 阶段的错误 A 需求分析 B 概要设计 C 详细设计 D 编码 答案: B
4. 在单元测试时, 需要为被测试模块设计( 答案: 驱动模块与桩模块 5. 在集成测试时有两种测试方法, 它们是( 答案: 渐增式和非渐增式 6. 软件测试是为了( )而执行程序的过程 )
)
答案: 发现错误 7. 运行被测试程序的方法称为( 答案: 动态 )测试
8. 动态测试中, 主要测试软件功能的方法称为( 答案: 黑盒
12. 集成测试中的具体方法是(
)
答案: 渐增式和非渐增式测试方法 二. 选择题 1. 软件测试中, 白盒法是通过分析程序的( 设计测试用例的 A 应用范围 B 内部逻辑 C 功能 答案: B 2 . 黑盒法是根据程序的( A 应用范围 B 内部逻辑 ) 来设计测试用例的 C 功能 D 输入数据 )来
D 输入数据
答案: C
3. 为了提高软件测试的效率, 应该(
A 随机地选取测试数据 B 取一切可能的输入数据作为测试数据 C 在完成编码以后制定软件的测试计划
实用软件工程( 第2版)7、8章
完整、正确的脚本为建立动态模型奠定了必要的基础。但是，用自 然语言书写的脚本往往不够简明，而且有时在阅读时会有二义性。为了 有助于建立动态模型，通常在画状态图之前先画出事件跟踪图。UML顺 序图（也称为事件跟踪图）中， 一条竖线代表应用领域中的一个类，每 个事件用一条水平的箭头线表示，箭头方向从事件的发送对象指向接受 对象，时间从上向下递增。
7.1 面向对象分析方法
明确了对象、类和类之间的层次关系之后，需要进一步 识别出对象之间的动态交互行为，即系统响应外部事件或操 作的工作过程。一般采用顺序图将用例和分析的对象联系在 一起，描述用例的行为是如何在对象之间分布的。也可以采 用协作图、状态图或活动图。
最后，需要将需求分析的结果用多种模型图表示出来， 并对其进行评审。由于分析的过程是一个循序渐进的过程， 合理的分析模型需要多次迭代才能得到。
7.1 面向对象分析方法
边界类示意图 控制类示意图 实体类示意图
目标系统的类可以划分为边界类、控制类和实体类。
➢ 边界类代表了系统及其操参与者的边界，描述参与者与 系统之间的交互。它更加关注系统的职责，而不是实现 职责的具体细节。通常，界面控制类、系统和设备接口 类都属于边界类。
➢ 控制类代表了系统的逻辑控制，描述一个用例所具有的 事件流的控制行为，实现对用例行为的封装。通常，可 以为每个用例定义一个控制类。
主机联接有问题，则执行异常事件流e。
a1． 提示用户输入无效密码，请求再次输入；
（5）ATM提供以下选项：存钱、取钱、查询。
a2．如果三次输入无效密码，系统自动关闭，退出客户银行卡。
（6）用户选择取钱选项。
（7）ATM提示输入所取金额。
子事件流b：
软件工程 第7章--面向对象设计
§1. OOD准则
5、Cohesion：模块内各个元素彼此结合的紧密程度。 服务内聚(service cohesion)：一个服务只完成一个功能。
类内聚(class cohesion)：一个类只有一个用途，否则分 解之。
一般-特殊内聚（general-particular cohesion):
17
类构件
类构件：面向对象技术中的“类” 。类构件有3种 重用方式：
–实例重用 –继承重用 –多态重用 1. 可重用类构件应具备的特点 (1) 模块独立性强。具有单一、完整的功能，且经 过反复测试被确认是正确的。是一个不受或很少受 外界干扰的封装体，其内部实现在外面是不可见的。
18
(2) 具有高度可塑性。软构件的应用环境比集成电 路更广阔、更复杂。显然，要求一个软构件能满足 任何一个系统的设计需求是不现实的。因此，可重 用的软构件必须具有高度可裁剪性，必须提供为适 应特定需求而扩充或修改已有构件的机制，而且所 提供的机制必须使用起来非常简单方便。
对象 设计
面向对 象分析
人机界 面设计
任务管 理设计
数据管 理设计
4
§1. OOD准则
§1. OOD准则：优秀软件设计的一个重要特点是 容易维护
回顾：SD准则包括
Modularization Information hiding
Abstraction
Module independence
对于 OOD有类似的准则： 1、Module = Object
• Inheritance —— 无须改动原有代码
13
② 设计重用 —— 当移植系统时
§3. 软件重用
③ 分析重用 —— 当需求未变，而系统结构改变 时（例如将HDIS改为OO实现）
软件工程第七章PPT资料(正式版)
此时，应当再设计与执行一些测试用例，以获得更多的数据。
调试（Debug）
❖软件调试是在进行了成功的测试之后才 开始的工作。它与软件测试不同，调试 的任务是进一步诊断和改正程序中潜在 的错误。
❖调试活动由两部分组成：
▪ 确定程序中可疑错误的确切性质 和位置。
▪ 对程序(设计,编码)进行修改，排 除这个错误。
▪ 现象实际上是由一些非错误原因 (例如，舍入不精确)引起的。
▪ 现象可能是由于一些不容易发现 的人为错误引起的。
▪ 错误是由于时序问题引起的，与 处理过程无关。
▪ 现象是由于难于精确再现的输入 状态（例如，实时应用中输入顺 序不确定）引起。
▪ 现象可能是周期出现的。在软、 硬件结合的嵌入式系统中常常遇 到。
或某些有关测试。 修改错误的过程将迫使人们暂时回到程序设计阶段。
利用某些程序语言的调试功能或专门的交互式调试工具，分析程序的动态过程，而不必修改程序。
❖从技术角度来看，查找错误的难度在于：
▪ 现象与原因所处的位置可能相距 甚远。
▪ 当其它错误得到纠正时，这一错 误所表现出的现象可能会暂时消 失，但并未实际排除。
几种主要的调试方法
调试的关键在于推断程序内部的错误位 置及原因。可以采用以下方法：
强行排错 这种调试方法目前使用较多，效率较低。
它不需要过多的思考，比较省脑筋。例 如：
▪ 通过内存全部打印来调试，在这 大量的数据中寻找出错的位置。
▪ 在程序特定部位设置打印语句， 把打印语句插在出错的源程序的 各个关键变量改变部位、重要分 支部位、子程序调用部位，跟踪 程序的执行，监视重要变量的变 化。
（-10，-10，10) ……
它不需要过多的思考，比较省脑筋。
《软件工程》各章课后习题答案
第一章课后参考答案1.什么是软件危机？它们有哪些典型表现？为什么会出现软件危机？“软件危机”是指计算机软件的“开发”和“维护”过程中所遇到的一系列“严重问题”。
这些问题决不仅仅是不能正常运行的软件才具有的，实际上，几乎“所有软件”都不同程度地存在这些问题。
它们有以下表现：（1）对软件开发成本和进度的估计常常很不准确；（2）用户对“已完成的”软件系统不满意的现象经常发生；（3）软件产品的质量往往靠不住；（4）软件常常是不可维护的；（5）软件通常没有适当的文档资料；（6）软件成本在计算机系统总成本中所占的比例逐年上升；（7）软件开发生产率提高的速度，远远跟不上计算机应用普及深入的趋势。
出现软件危机的主要原因（1）与软件本身的特点有关（2）与软件开发和维护过程中使用的方法不正确有关2.假设自己是一家软件公司的总工程师，当把图1.1给手下的软件工程师们观看，告诉他们及时发现并改正错误的重要性时，有人不同意这个观点，认为要求在错误进入软件之前就清楚它们是不现实的，并举例说：“如果一个故障是编码错误造成的，那么，一个人怎么能在设计阶段清除它呢？”应该怎么反驳他？答：在软件开发的不同阶段进行修改付出的代价是很不相同的，在早期引入变动，涉及的面较少，因而代价也比较低；在开发的中期，软件配置的许多成分已经完成，引入一个变动要对所有已完成的配置成分都做相应的修改，不仅工作量大，而且逻辑上也更复杂，因此付出的代价剧增；在软件“已经完成”时在引入变动，当然付出的代价更高。
一个故障是代码错误造成的，有时这种错误是不可避免的，但要修改的成本是很小的，因为这不是整体构架的错误。
3.什么是软件工程？它有哪些本质特征？怎么用软件工程消除软件危机？软件工程是指导知道计算机软件开发和维护的一门工程学科。
采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好技术方法结合起来，以经济地开发出高质量的软件并有效地维护它，这就是软件工程。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
7.1.4 维护的副作用 编码副作用 数据副作用 文档副作用
《软件工程(第2版)》陆惠恩主编 3
7.2 软件的可维护性
软件可维护性指软件被理解、改正、• 整 调 和改进的难易程度。 7.2.1 决定可维护性的因素 是否拥有一组训练有素的软件人员； 系统结构是否可理解、是否合理； 文档结构是否标准化； 测试用例是否合适； 是否已有嵌入系统的调试工具； 是否使用标准的程序设计语言； 是否使用标准的操作系统和程序设计语言等。
《软件工程(第2版)》陆惠恩主编 1
7.1.2 Байду номын сангаас件维护的困难 1.结构性维护与非结构性维护
《软件工程(第2版)》陆惠恩主编
2
7.1.2 软件维护的困难 2. 软件工程中不考虑维护问题会造成维护的困难. 7.1.3 软件维护的实施
1. 维护组织 2. 维护文档 有两种：维护要求表，维护修改报告。 3. 维护的流程 （1）确定维护的类型 （2）维护记录的保存 （3）维护的复审
《软件工程(第2版)》陆惠恩主编
4
7.2.2 可维护性的度量 7.2.3 提高软件的可维护性
1．明确软件工程的质量目标 2．利用先进的软件技术和工具 3．选择便于维护的程序设计语言 4．采取有效的质量保证措施 5．完善程序的文档
《软件工程(第2版)》陆惠恩主编
5
第7章小结
软件维护（software maintenance）就是在软件产品交付之后 对其进行修改，以纠正错误，或改进性能和其它属性，或使 产品适应改变了的环境。 四种软件维护：改正性维护、适应性维护、完善性维护和预 防性维护。 软件可维护性就是维护人员对该软件进行维护的难易程度， 具体包括理解、改正、改动和改进该软件的难易程度。 提高软件的可维护性是软件工程各阶段追求的目标之一。 在开发时明确质量目标、考虑软件的维护问题是必须的、重 要的。 在软件开发阶段提供完整、一致的文档，采用先进的软件开 发方法和软件开发工具是提高软件可维护性的关键。
《软件工程(第2版)》陆惠恩主编
6
习题7
选择题答案
8. （1）、（3）、（5）、（6）、（7）、（8）、 （10） 9．A（4）、B（5）、C（6）、D（1）、E（7） 10. A（1）、B（4）、C（1）、D（3）
《软件工程(第2版)》陆惠恩主编
7
第7章软件维护
本章内容：软件维护过程 软件的可维护性 本章重点：软件的可维护性。 7.1 软件维护过程 软件维护（software maintenance）就是在软件产品 交付之后为了延长使用寿命，对其进行修改以改正错 误，或改进性能和其它属性，或使产品适应改变了的 环境。 7.1.1 维护的种类 改正性维护、适应性维护、完善性维护和预防性维护。