精华内容
下载资源
问答
  • 软件工程

    千次阅读 多人点赞 2021-01-24 17:13:02
    软件工程——原理、方法与应用(学习笔记)

    软件工程

    一、绪论

    1.软件的定义

    软件是计算机系统中与硬件相互依存的另一部分,它包括程序、数据及其相关文档的完整集合。软件=程序+文档+数据

    • 程序是按事先设计的功能和性能要求执行的指令序列;
    • 数据是使程序能正常操纵信息的数据结构,具体来说包括使系统初始运行所必须的数据如数据库和表的结构及初始的数据,系统运行中所需要的各种代码表、各种标志等。
    • 文档是与程序开发,维护和使用有关的图文材料(是有关于管理、开发、用户、维护人员使用的文档)

    2.软件技术面临的问题

    • 规模,复杂性,生产率

    3.软件危机

    介绍:

    • 软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题;概括地说,软件危机包含下述两方面的问题:如何开发软件,以满足对软件日益增长的需求;如何维护数量不断膨胀的已有软件。开发软件所需高成本和产品的低质量之间有着尖锐的矛盾,这种现象称做软件危机

    表现:

    • 对软件开发成本和进度的估计常常很不准确;
    • 用户对“已完成的”软件系统不满意的现象经常发生;
    • 软件产品的质量往往靠不住;
    • 软件常常是不可维护的;
    • 软件通常没有适当的文档资料;
    • 软件成本在计算机系统总成本中所占的比例逐年上升;
    • 软件开发生产率提高的速度,远远跟不上计算机应用迅速普及深入的趋势。

    原因: 内在原因:复杂性

    • 软件开发无计划性,项目没有被很好地理解;计划不周,最终导致进度拖延,经费预算上升。
    • 软件需求不充分,开发的软件不能满足用户的需求。
    • 软件开发过程无规范,没有充分的文档资料。
    • 软件可靠性缺少度量的标准,质量无法保证。
    • 软件难以维护,易升级。

    解决方法:

    • 组织管理——工程项目管理方法
    • 技术措施——软件开发技术与方法、软件工具
    • 工程化的原理和方法组织软件开发是软件开发中的问题的一个主要出路。

    在这里插入图片描述

    4.软件工程

    定义:

    • 软件工程是用工程、科学和数学的原则与方法研制、维护计算机软件和有关技术及管理方法。
    • 把系统的、规范的、可度量的途径应用于软件开发、运行和维护过程,也就是把工程应用于软件。(IEEE定义)
    • 软件工程包括技术和管理两方面的内容,是技术与管理紧密结合所形成的工程学科。

    三要素:

    • 方法、过程、工具

    中心思想:

    • 把软件当作一种工业产品,要求“采用工程化的原理与方法对软件进行计划、开发和维护”。

    基本原理:

    • 确保软件产品质量和开发效率的原理的最小集合。

    5.软件开发方法

    • 个性化方法->结构化方法->面向对象方法->软件复用

    6.三种编程范式

    • 过程式编程范型:程序=数据结构+算法
    • 面向对象编程范型:程序=对象+消息
    • 基于构件技术的编程范型:程序=构件+架构

    7.三代软件工程

    传统软件工程

    • 结构化分析->结构化设计->面向过程的编码->软件测试

    面向对象软件工程

    • 面向对象基本概念:对象+类+继承+消息通信
    • OO分析与对象抽取->对象详细设计->面向对象的编码和测试

    基于构件的软件工程

    • 领域分析和测试计划定制->领域设计->建立可复用构件库->查找并集成构件

    二、软件生存周期与软件过程

    1.软件生存周期

    • 一个软件项目从开始立项起,到废弃不用止,统称为软件的生存周期。
    • 软件生存周期被划分为计划、开发、运行三个时期。
    • 由于软件生存周期被划分为较小的阶段,使得因为软件规模增长而大大增加的软件复杂性变得较易控制和管理。

    2.典型的软件生存周期

    • 计划->需求分析->软件分析->软件设计->编码(测试)

      ->软件测试->运行维护

    在这里插入图片描述
    需求分析:(准确回答,系统必须做什么)

    • 提交:软件需求说明书/系统功能说明书/初步的系统用户手册

    软件设计:(回答怎么做的问题)概要设计、详细设计

    • 提交:设计说明书(软件结构图)

    程序编写:(具体实现)

    • 提交:源程序清单

    软件测试:(挑错)单元测试、组装测试 有效性测试

    • 提交:测试报告文档(测试计划、测试用例、测试结果)

    运行维护:改正性维护、适应性维护、完善性维护

    3.软件过程

    围绕软件开发所进行的一系列活动
    软件生存周期中的阶段和软件过程中的活动是基本一致的。

    (1) 传统的软件过程:瀑布模型、快速原型模型

    瀑布模型

    • 基于软件生存周期的线性开发模型

    强调软件文档:

    • 每一个阶段必须完成规定的文档
    • 每一个阶段都要复审完成的文档

    特点:

    • 阶段间的顺序性和依赖性、推迟实现的观点、质量保证的观点

    顺序性:

    • 前一阶段的工作完成后才能执行下一阶段的任务

    依赖性:

    • 前一阶段的输出文档是下一阶段的输入文档

    存在问题:

    • 不适合需求模糊的系统,开发初始阶段很难彻底弄清软件需求

    需求定义与分析->总体设计->详细设计->编码->测试->使用维护

    在这里插入图片描述

    快速原型模型

    特点:

    • “逼真”的原型可以使用户迅速作出反馈
    • 循环回溯和迭代:非线性模型
    • 使用快速开发工具

    种类:

    • 渐进型:对原型补充和修改获得最终系统
    • 抛弃型:原型废弃不用

    应防止的倾向:

    • 舍不得抛弃,从而影响软件质量
      在这里插入图片描述

    (2) 软件演化模型(采用渐增式或迭代式的开发方法):增量模型、螺旋模型、构件集成模型

    增量模型

    定义:

    • 把软件看作一系列相互联系的增量,每次迭代完成一个增量。

    增量:

    • 小而可用的软件
    • 第一个增量通常是软件的核心

    特点:

    • 在前面增量的基础上开发后面的增量
    • 每个增量的开发可用瀑布或快速原型模型
    • 每个增量开发的顺序性和总体的迭代性相结合
    • 有利于控制技术风险
      在这里插入图片描述

    螺旋模型

    特点:

    • 瀑布模型(顺序性、边开发边复审)+快速原型(迭代性)
    • 风险分析->发现、控制风险

    一个螺旋式周期:

    • 计划:确定目标,选择方案,选定完成目标的策略
    • 风险分析:从风险角度分析该策略
    • 开发:启动一个开发活动
    • 评审:评价前一步的结果,计划下一轮的工作
      在这里插入图片描述

    迭代和瀑布的区别:

    • 迭代和瀑布的最大的差别就在于风险的暴露时间上。
    • 瀑布模型的特点(文档是主体),很多问题再最后才会暴露出来。
    • 迭代模型的特点,根据风险列表选择要在迭代中开发新的增量内容,每次迭代完成时都会生成一个经过测试的可执行文件,可核实是否降低了目标风险。

    构件集成模型

    构件:

    • 在某个领域中具有通用性,可以复用的软件部件
    • 将可以复用的构件存储起来,形成构件库

    特点:

    • 面向对象
    • 基于构件库
    • 融合螺旋模型特征
    • 支持软件开发的迭代方法
    • 软件复用
      在这里插入图片描述

    (3) 形式化方法模型(基于程序变换和验证技术的软件开发):转换模型,净室模型

    转换模型

    开发过程:

    • 确定形式化需求规格说明书
    • 进行自动的程序变换
    • 针对形式化开发记录进行测试

    特点:

    • 形式化软件开发方法
    • 形式化需求规格说明
    • 变换技术
    • 程序自动生成技术
    • 确保正确
      在这里插入图片描述

    净室模型

    净室思想:

    • 在分析和设计阶段消除错误
    • 在“洁净”状态下实现软件制作

    形式化:

    • 盒结构表示分析和设计
    • 正确性验证

    增量模型:

    • ·把软件看成一系列的增量

    在这里插入图片描述

    (4) 软件过程模型的特点汇总

    瀑布模型:

    • 线性模型,每一阶段必须完成规定的文档,适合需求明确的中小型软件开发

    快速原型:

    • 用户介入早,通过迭代完善用户需求,原型废弃不用,适合需求模糊的小型软件开发

    增量模型:

    • 每次迭代完成一个增量,可用于OO开发。适合容易分块的大型软件开发

    螺旋模型:

    • 典型迭代模型,重视风险分析,可用于OO开发。适合具有不确定性大型软件开发

    构件集成模型:

    • 软件开发与构件开发平行进行,适用于领域工程、行业的中型软件开发

    转换模型:

    • 形式化的规格说明,自动的程序变换系统。属于理想化模型,尚无成熟工具支持

    净室模型:

    • 形式化的增量模型,在洁净状态下实现软件制作。适合开发团队熟悉形式化方法,中小型软件开发。

    (5) 统一过程和敏捷过程

    统一过程(RUP)

    • 描述了软件开发中各个环节应该做什么、怎么做、什么时候做以及为什么要做,描述了一组以某种顺序完成的活动。
    • 基本特征是“用例驱动、以架构为中心的和受控的迭代式增量开发”

    RUP将软件开发分为四个阶段:

    • 初始阶段:该阶段的主要任务包括确定项目范围和边界,识别系统的关键用例,展示系统的候选架构,估计项目费用和时间,评估项目风险。其意图是建立项目的范围和版本,确定业务实现的可能性和项目目标的稳定性。提交结果包括原始的项目需求和业务用例。

    制品:构想文档、有关用例模型的调查、初始的业务用例、早期风险评估、显示阶段和迭代的项目计划等制品;

    • 细化阶段:该阶段的主要任务包括分析系统问题领域,建立软件架构基础,淘汰最高风险元素。其意图是对问题域进行分析,建立系统的需求和架构,确定技术实现的可行性和系统架构的稳定性。提交结果包括系统架构及其相关文档、领域模型、修改后的业务用例和整个项目的开发计划。

    制品:补充需求分析、软件架构描述、可执行的架构原型

    • 构建阶段:该阶段相对简单一些,其主要任务包括资源管理、控制和流程优化,开发剩余的构件,然后进行构件组装和测试等。其主要意图是增量式开发一个可以交付用户的软件产品。

    制品:准备交到最终用户手中的产品,包括具有最初运作能力的在适当的平台上集成的软件产品、用户手册和对当前版本的描述。

    • 提交(迁移)阶段:该阶段的主要任务包括进行β测试,制作发布版本,用户文档定稿,确认新系统,获取用户反馈,培训、调整产品使最终用户可以使用产品。其主要意图是将软件产品提交用户。

    每个阶段又分为若干次迭代,每次迭代有一个核心工作流,都会经历需求、分析、设计、实现和测试等活动。

    在这里插入图片描述

    • 9个核心工作流,分为6个核心过程工作流和3个核心支持流。
    • 核心过程工作流:商业建模、需求、分析和设计、实现、测试、部署
    • 核心支持流:配置和变更管理、项目管理、环境

    敏捷过程

    • 一种以人为核心、迭代、循序渐进的开发方法,其软件开发过程称为“敏捷过程”

    敏捷过程价值观:

    • 个人和交互胜过过程和工具
    • 可以运行的软件胜过面面俱到的文档
    • 客户合作胜过合同谈判
    • 响应变化胜过遵循计划

    极限过程

    • 一种轻量级的、敏捷的软件开发方法
    • 4个价值观:交流、简单、反馈、勇气
    • 4个方面改善:加强交流、从简单做起、寻求反馈、用于实事求是
    • 12个核心实践:完整团队、计划对策、测试、简单设计、结对编程、小软件版本、设计改进、持续集成、代码共有、编码标准、系统比喻、可持续的速度

    (6) 软件可行性研究

    目的:

    • 研究项目是否可能实现和值得进行
    • 回答Why to do

    研究的内容:

    • 经济可行性
    • 运行可行性
    • 技术可行性
    • 法律可行性

    可行性研究的步骤:

    • 对当前系统进行调查和研究
    • 弄清当前系统
    • 导出新系统逻辑模型
    • 导出新系统的解决方案
    • 设计不同的解决方案
    • 提出推荐的方案
    • 本项目的开发价值
    • 推荐这个方案的理由
    • 编写可行性认证报告
    • 系统概述
    • 可行性分析
    • 结论意见

    (7) 软件风险分析

    风险识别:

    • 项目风险
    • 技术风险
    • 商业风险

    风险预测:

    • 风险发生的可能性
    • 风险发生后的后果
    • 风险的驾驭和监控

    三、结构化分析与设计

    1. 结构化分析与设计

    • SP(结构化程序设计)->SD(结构化设计)->SA(结构化分析)
    • 讨论传统软件工程的系统开发技术,重点放在基于瀑布模型的结构化分析与设计和模块设计上,但不涉及同为传统软件工程的快速原型开发等内容。

    2. SA与SD的流程

    • 结构化分析(工具:DFD数据流图、PSPEC加工策略)
      –>分析模型(分层DFD图)+SRS软件需求规格说明书)
    • 结构化设计(工具:SC图)映射–>初始设计模型(初始SC图)
    • 初始设计模型(初始SC图)优化–>最终设计模型(最终SC图)

    3. 基本任务与指导思想

    结构化分析:

    • 建立分析模型
    • 编写需求说明

    结构化设计:

    • 软件设计=总体设计+详细设计
    • SC图需要分两步完成:初始SC图、最终SC图

    细化与分解:

    • 逐步细化,细化的本质就是分解

    4. SA模型的组成与描述

    SA模型的描述工具:

    • DFD、PSPEC,这是早期SA模型的基本组成部分;
    • CFD、CSPEC和STD是早期SA模型的扩展成分,适应实时软件的建模需要;
    • ER图,适用于描述具有复杂数据结构的软件数据模型。
      在这里插入图片描述
      备注:
    • DFD数据流图、PSPEC加工规格说明/加工策略、STD状态转换图、DD数据字典、CSPEC控制规格说明

    数据流图(DFD)

    • 数据流图(DFD)是一种图形化技术,它描绘信息流和数据从输入移动到输出的过程中所经受的变换,描述对数据流进行变换的功能和子功能
      在这里插入图片描述

    组成符号:

    • 圆框代表加工
    • 箭头代表数据的流向,数据名称总是标在箭头的边上
    • 方框表示数据的源点和终点
    • 双杠(或单杠)表示数据文件或数据库
    • 文件与加工之间用带箭头的直线连接,单向表示只读或只写,双向表示又读又写

    数据字典(DD)

    • 数据字典的任务:对于数据流图中出现的所有被命名的图形元素在字典中作为一个词条加以定义,使得每一个图形元素的名字都有一个确切的解释。
    • 对软件中的每个数据规定一个定义条目

    ①数据流:

    数据流名: 发票
    别 名: 购书发票
    组 成: 学号+姓名+{书号+单价+数量+总价} +书费合计
    备 注:

    ②数据文件
    ③数据项

    数据流图与数据字典共同构成系统的逻辑模型

    加工说明(PSPEC)

    • 对数据流图中出现的每个加工/处理的功能描述
    • 主要工具:结构化语言,判定树或判定表
      在这里插入图片描述

    5. SD模型的组成与描述

    • 包含数据设计、接口设计、过程设计、体系结构设计
    • 体系结构设计是用来确定软件结构的,其描述工具是结构图,简称SC图
    • 过程设计主要指模块内部的详细设计
      在这里插入图片描述

    SC图组成符号和模块调用关系的标识:

    • 矩形框表示模块,带箭头的连线表示模块间的调用,并在调用线的两旁标出传入和传出模块的数据流
      简单调用、选择调用、循环调用:
      在这里插入图片描述
      例:在模块A的箭头尾部标以一个菱形符号,表示模块A有条件地调用另一个模块B,当一个在调用箭头尾部标以一个弧形符号,表示模块A反复调用模块C和模块D。
      在这里插入图片描述
    • 程序的系统结构图
      在这里插入图片描述

    6. 结构化系统分析

    结构化分析的基本步骤:

    • 自顶向下对系统进行功能分解,画出分层DFD图
    • 由后向前定义系统的数据和加工,编制DD和PSPEC
    • 最终写出SRS

    (1)画分层数据流图:(自顶向下,逐步细化)

    好处:便于实现,便于使用

    通常把整个系统当作一个大的加工标明系统的输入与输出,以及数据的源点与终点(统称为“外部项”)

    • 顶层DFD:
      在这里插入图片描述

    • 第二层DFD:
      在这里插入图片描述

    • 第三层DFD:
      在这里插入图片描述

    • 采购子系统:
      在这里插入图片描述

    (2)确定数据定义与加工策略(从数据的终点开始)

    • 数据定义DD
    • 加工策略PSPEC
    • 需求规格说明书SRS

    (3)需求分析的复审

    7. 结构化系统设计

    SD概述

    面向数据流设计和面向数据设计

    • 面向数据流:数据流是考虑一切问题的出发点
    • 面向数据:以数据结构作为分析与设计的基础

    结构化设计的描述工具:SC图

    从分析模型导出设计模型
    在这里插入图片描述

    • 分析模型:数据对象描述、数据流图DFD、数据字典DD、实体联系图ER图、加工规格说明书PSPEC、状态转换图STD、控制规格说明CSPEC

    • 设计模型:过程设计、接口设计、体系设计、数据设计 由分析模型导出设计模型: 过程设计可以由PSPEC,CSPEC、STD导出;

    • 接口设计可以由DFD导出; 体系结构设计可以由DFD导出; 数据设计可以由E-R、DD导出。

    数据流图的类型——变换型、事务型

    变换(transform)型结构:

    • 传入路径
    • 变换中心
    • 传出路径
      在这里插入图片描述

    事务(transaction)型结构:

    • 一条接受路径
    • 一个事务中心
    • 若干条动作路径
      在这里插入图片描述

    同时存在变换型结构和事务型结构:
    在这里插入图片描述

    SD方法

    在这里插入图片描述

    结构化软件设计方法——变换映射,事务映射

    • 变换映射是软件系统结构设计的主要方法。一般一个大型的软件系统是变换型结构和事务型结构的混合结构。所以,我们通常利用以变换映射为主,事务映射为辅的方式进行软件结构设计。

    变换映射:

    • 划分DFD图的边界;
    • 建立初始SC图的框架;
    • 分解SC图的各个分支
      在这里插入图片描述
      在这里插入图片描述在这里插入图片描述
      在这里插入图片描述
      在这里插入图片描述
    • 深度:5层;宽度(广度):7层;
    • 注意:必须对一个模块的全部直接下属模块都设计完成之后,才能转向另一个模块的下层模块的设计;在设计下层模块时,应考虑模块的耦合和内聚问题;使用“黑箱”技术,先把这个模块的所有下层模块定义成“黑箱”,不考虑其内部结构和实现;一个模块的直接下属模块一般在五个左右,如果直接下属模块超过10个,可设立中间层次。

    事务映射:

    • 在DFD图上确定事务中心、接受部分(包括接受路径)和发送部分(包括全部动作路径)
    • 画出SC图框架,把DFD图的3个部分分别映射为事务控制模块、接受模块和动作发送模块
    • 分解和细化接受分支和发送分支,完成初始的SC图
      在这里插入图片描述
      在这里插入图片描述

    扇入扇出

    在这里插入图片描述

    • 煎饼型不可取,应增加中间层减少扇出,实现塔型结构
    • 设计良好的软件通常具有瓮型结构,两头小,中间打,在低层模块使用了较多高扇入的共享模块

    优化结构设计的指导原则

    对模块划分的指导原则

    • 提高内聚,降低耦合
    • 简化模块接口
    • 少用全局性数据和控制型信息

    保持高扇入/低扇出的原则

    • 扇入高则上级模块多,能够增加模块的利用率
    • 扇出低则表示下级模块少,可以减少模块调用和控制的复杂度

    8. 模块设计

    • 模块设计是传统软件工程的重要组成部分,其性质属于详细设计。

    目的:

    • 为SC图中的每个模块确定算法和数据结构,用选定的表达工具给出清晰的描述

    主要任务

    • 编写软件的“模块设计说明书”

    原则与方法:

    • 清晰第一的设计风格
    • 结构化的控制结构
    • 仅用这三种控制结构(顺序、选择、循环)来构成程序
    • 每个控制结构只应有一个入口和一个出口
    • 逐步细化的实现方法

    详细设计中常用的表达工具

    • 流程图、N-S图、伪代码、PDL语言
      在这里插入图片描述

    四、面向对象与UML

    1. 面向对象概述

    (1) 类和对象的关系

    对象:代表客观世界中实际或抽象的事物

    • 客观世界是由各种对象组成的
    • 数据以及在其上的操作的封装体

    类:一组相似的对象的共性抽象

    • 类是一组客观对象的抽象
    • 实现抽象数据类型的工具

    类与对象的关系

    • 抽象与具体的关系
    • 组成类的每个对象都是该类的实例
    • 实例是类的具体事物
    • 类是各个实例的综合抽象

    (2) 面向对象的基本特征

    • 抽象、封装、继承、多态

    (3) 面向对象开发的优点

    • 可复用性、可扩展性、可维护性

    2. UML(统一建模语言)简介

    • 通用的可视化的建模语言
    • 目前在软件工程里主要用于系统分析与系统设计
    • 软件生存周期:RUP(统一过程)
    • 软件建模方式:可视化的语言
    • 软件文档规范:文档由UML建模工具自动产生
    • 软件人员分工:岗位界面逐渐趋向模糊

    静态图:

    • 类图:类以及类之间的相互关系
    • 对象图:对象以及对象之间相互关系

    实现图:

    • 构件图:构件及其相互依赖关系
    • 部署图:构件在各节点上的部署

    交互图:

    • 时序图:强调时间顺序的交互图
    • 协作图:强调对象协作的交互图

    行为图:

    • 状态图:类所经历的各种状态
    • 活动图:对工作流建模

    用例图:

    • 用例图:需求捕获,测试依据

    (1) UML的模型元素

    表示模型中的某个概念

    • 类、对象、构件、用例、结点、接口、包、注释

    表示模型元素之间的关系

    • 关联、泛化、依赖、实现、聚集、组合

    在这里插入图片描述

    (2) UML的元模型结构

    • 元元模型层、元模型层、模型层、用户模型层
      在这里插入图片描述

    (3) UML的组成

    ①图

    静态图

    • 用例图
    • 静态图:类图、对象图
    • 实现图:构件图、部署图

    动态图

    • 行为图:状态图、活动图
    • 交互图:时序图、协作图

    ②视图

    • 用例视图(用例图 [活动图] )
      从用户角度看到的系统应有的外部功能
    • 逻辑视图(静态:类图,对象图;动态:状态图,时序图,协作图,活动图)
      描述系统的静态结构和对象间的动态协作关系
    • 进程视图(状态图、时序图、协作图、活动图、构件图、部署图)
      展示系统的动态行为及其并发性
    • 构件视图(构件图)
      展示系统实现的结构和行为特征
    • 部署视图(部署图)
      显示系统的实现环境和构件被部署到物理结构中的映射

    ③模型元素

    ④通用机制

    (4) UML的特点

    • 统一标准
    • 面向对象
    • 表达功能强大、可视化
    • 独立于过程
    • 易掌握、易用

    (5) UML五类九种图的符号体系

    在这里插入图片描述在这里插入图片描述在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

    3. UML主要内容

    • 静态建模机制、动态建模机制

    (1) 静态建模

    静态建模包括

    • 用例图、类图、对象图

    用例模型

    • 使用用例图表示
    • 从最终用户的角度描述系统功能

    类和对象模型

    • 类图和对象图表示

    1) 用例图与用例模型

    用例图的组成符号
    在这里插入图片描述

    用例之间的关系
    ①扩展关系

    • 根据指定的条件,一个用例中有可能加入另一个用例的动作;
      如果一个用例明显地混合了两种或者两种以上的不同场景,即根据情况可能发生多种分支,则可以将这个用例分为一个基本用例和一个或多个扩展用例,这样可能会使描述更加清晰。扩展用例为基用例添加新的行为,可以访问基用例的属性,因此它能根据基用例中扩展点的当前状态来判断是否执行自己。但是扩展用例对基用例不可见。
      <extend>是扩展关系的构造型,箭头指向基本用例。

      在这里插入图片描述
      在这里插入图片描述在这里插入图片描述
      在这里插入图片描述

    ②包含关系

    • 一个用例的行为包含另一个用例的行为
      当可以从两个或两个以上的用例中提取公共行为时,应该使用包含的关系来表示它们。其中这个提取出来的公共用例成为抽象用例,而把原始用例成为基本用例或基础用例。
      <include>是包含关系的构造型,箭头指向抽象用例。
      在这里插入图片描述
      在这里插入图片描述
      在这里插入图片描述

    包含关系和扩展关系的联系和区别:

    • 联系:都是从现有的用例中抽取出公共的那部分信息,作为一个单独的用例,然后通过不同的方法来重用这个公共的用例,以减少模型维护的工作量。
    • 区别:扩展关系中基本用例的基本流执行时,扩展用例不一定执行,即扩展用例只有在基本用例满足某种条件的时候才会执行。
      包含关系中基本用例的基本流执行时,包含用例一定会执行。

    例:
    现有一医院病房监护系统,病症监视器安置在每个病房,将病人的病症信号实时传送到中央监视系统进行分析处理。在中心值班室里,值班护士使用中央监视系统对病员的情况进行监控,根据医生的要求随时打印病人的病情报告,定期更新病历,当病症出现异常时,系统会立即自动报警, 并实时打印病人的病情报告,立及更新病历。
    要求根据现场情景,对医院病房监护系统进行需求分析, 建立系统的用例模型。

    简单的需求分析说明
    系统名称:医院病房监护系统
    根据分析系统主要实现以下功能:
      1、病症监视器可以将采集到的病症信号(组合),格式化后实时的传送到中央监护系统。
      2、中央监护系统将病人的病症信号开解后与标准的病症信号库里的病症信号的正常值进行比较,当病症出现异常时系统自动报警。
      3、当病症信号异常时,系统自动更新病历并打印病情报告。
      4、值班护士可以查看病情报告并进行打印。
      5、医生可以查看病情报告,要求打印病情报告,也可以查看或要求打印病历。
      6、系统定期自动更新病历。

    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

    在这里插入图片描述
    在这里插入图片描述

    2) 类图Class Diagram

    在这里插入图片描述

    类图表示类间关系:

    关联关系(Association)
    • 类之间存在的语义上的关系
    • 普通关联、递归关联、多重关联等
      在这里插入图片描述

    二元关联:

    • 表示为在两个类之间用一条直线连接,直线上可写上关联名
      在这里插入图片描述
    • 关联的两端可加上重数,表示该类有多少个对象可与对方的一个对象关联
      在这里插入图片描述
    • 允许一个类与自身关联
      在这里插入图片描述

    多元关联:

    • 三个或三个以上的类之间可以互相关联
      在这里插入图片描述
      在这里插入图片描述

    受限关联:

    • 用于一对多或多对多的关联,限定符用来区分关联”多”端的对象集合,它指明了在关联“多”端的某个特殊对象
      在这里插入图片描述
    聚集关系(Aggregation)
    • 特殊的关联:表示类之间具有整体与部分的关系
    • 特征是“部分”对象可以是多个任意“整体”对象的一部分,“部分”可以参与到多个“整体”中,部分可以脱离整体。

    在这里插入图片描述

    组合关系(Composition)
    • 特殊的聚集:整体强烈拥有部分
    • 在组合中,“整体”强烈拥有“部分”,“部分”与“整体”共存。如果“整体”不存在了,“部分”也会随之消失。“整体”的重数必须是0或1,“部分”的重数可以是任意的。
      在这里插入图片描述
    泛化关系(Generalization)
    • 又称继承
    • 普通泛化,限制泛化

    此处的一般元素可视作父类,特殊元素视作子类。

    • 一般元素所具有的关联、属性和操作,特殊元素也都隐含性地拥有;
    • 特殊元素应包含额外信息;
    • 允许使用特殊元素实例的地方,也应能使用一般元素。
      在这里插入图片描述
    实现关系
    • 实现关系将一个模型元素(如类)连接到另一个模型元素(如接口),后者是行为的规约,而不是结构,前者必须至少支持(通过集成或直接声明)后者的所有操作,可以认为前者是后者的实现。
      在这里插入图片描述
    依赖关系(Dependency)
    • 对一个类/对象的修改会影响另一个类/对象

    例如,某个类中使用另一个类的对象作为操作中的参数,一个类存取作为全局对象的另一个类的对象,或一个类的对象是另一个类的类操作中的局部变量等,都表示这两个类之间有依赖关系。
    class Boss{
    void do(Staff s){
    s.do();
    }
    }
    在这里插入图片描述
    约束与派生:

    • 约束与派生机制能应用于任何模型元素
    • 用花括号括起放在模型元素旁边
    • 典型的属性约束是该属性的取值范围
    • 派生属性可由其它属性通过某种方式计算得到,通常在派生属性前面加一个“/”表示
    • 关联关系可以被约束,也可以被派生
      在这里插入图片描述

    包图

    • 描述系统的分层结构
      在这里插入图片描述

    3) 对象图Object Diagram

    • 对象图是类图的实例。

    在这里插入图片描述

    (2) 动态建模

    • 消息
      在这里插入图片描述
    • 状态图
      状态图描述对象的所有可能状态及事件发生时状态的转移条件
      在这里插入图片描述
    • 状态图之间发送消息
      在这里插入图片描述
    • 时序图(元素:对象、对象生命线、消息)
      时序图用来描述对象之间的动态交互,着重体现对象间消息传递的时间顺序。它以垂直轴表示时间,水平轴表示不同的对象。对象用一个带有垂直虚线的矩形框表示,并标有对象名和类名。垂直虚线是对象的生命线,用于表示在某段时间内对象是存在的。对象间的通信在对象的生命线间通过消息符号来表示,消息的箭头指明消息的类型。
      在这里插入图片描述在这里插入图片描述
    • 协作图(元素有对象、链接和消息流)
      协作图描述了对象间的动态协作关系,但它强调消息发生和接收的对象的结构组织(及连接关系)(协作对象之间的交互和链接)
      在这里插入图片描述
      在这里插入图片描述

    (3) 物理架构建模

    • 逻辑架构和物理架构
    • 构件图:显示软件构件直接的依赖关系。一般来说,软件构件就是一个实际文件,可以是源代码文件、二进制代码文件和可执行文件。构件图可以用来表现编译、链接或执行时构件之间的依赖关系。
      在这里插入图片描述
    • 部署图:描述系统硬件的物理拓扑结构以及在此结构上执行的软件。部署图可以显示计算节点的拓扑结构和通信路径、结点上运行的软件构件、软件构件包含对的逻辑单元(对象、类)等。
      在这里插入图片描述

    五、需求工程与需求分析

    1. 软件需求工程

    软件需求的定义

    一个软件系统必须遵循的条件或具备的能力

    • 系统的外部行为——解决用户的问题
    • 系统的内部特性——满足了文档的要求

    软件需求三个层次

    • 业务需求——从业务的角度评估
    • 用户需求——从用户使用的角度描述软件必须完成的任务
    • 功能需求——开发人员必须实现的功能

    软件需求的特性

    软件质量准则“FURPS”

    • 功能性
    • 可用性(易用性)
    • 可靠性(平均无故障时间、精确度等)
    • 性能(响应时间、吞吐量等)
    • 可支持性(与系统相关的特性要求)
    • 设计约束

    软件需求工程

    • 一门应用有效的技术和方法、合适的工具和符号,来确定、管理和描述目标系统及其外部行为特征的学科。

    2. 需求分析与建模

    需求分析的步骤(迭代):

    • 需求获取、需求建模、需求描述(编写SRS)、需求验证
    • 需求获取的目的是让开发人员通过各种方式充分和用户交流,全面、准确地了解系统需求;
    • 建立需求模型是需求分析的核心,它通过各种图形及符合,可视化地从各个侧面描述系统需求;(结构化方法(包括数据流、数据字典、加工规格说明)和面向对象方法(面向对象方法包括用例模型、补充规约和术语表))
    • 需求描述即编写需求规格说明书,它以各方共同认可的文档形式表述,是软件设计和系统验收的可靠依据;
    • 需求验证用来检验以上各步的工作成果。

    需求分析是一个迭代的过程

    3. 需求获取的常用方法

    常规的需求获取方法:

    • 联合分析小组
    • 用户代表、领域专家和系统分析员
    • 客户访谈
    • 充分准备,寻找共同语言
    • 循序渐进、逐步逼近
    • 问题分析与确认
    • 多个来回

    用快速原型法获取需求

    • 利用各种分析技术和方法,生成一个简化的需求规格说明;
    • 对需求规格说明进行必要的检查和修改后,确定原型的软件结构、用户界面和数据结构等;
    • 在现有的工具和环境的帮助下快速生成可运行的软件原型并进行测试、改进;
    • 将原型提交给用户评估并征求用户的修改意见;
    • 重复上述过程,直到原型得到用户的认可。

    4. 需求模型

    需求模型概述

    • 结构化需求模型
    • 面向对象需求模型

    面向对象的需求建模

    • 画用例图

    • 写用例规约

    • 描述补充规约

    • 编写术语表

    结构化需求模型
    在这里插入图片描述

    • 该模型主要由3部分组成,即:包括数据流图和加工规格说明的功能模型;主要由数据字典和E-R图等组成的数据模型;由状态转换图、控制流图和控制规格说明等组成的行为模型。

    面向对象需求模型
    在这里插入图片描述

    • 面向对象需求模型由3个部分组成:用例模型、补充规约和术语表,其中用例模型又包括用例图和用例规约

    用例建模

    确定参与者

    • 存在与系统外部、与系统交互的人、硬件、其他系统

    确定用例

    • 考察每个参与者与系统的交互和需要系统提供的服务

    绘制和检查用例图

    • 按UML标准画用例图
    • 检查用例图

    细化每个用例的用例规约

    内容包括:

    • 简要说明:简要介绍该用例的作用和目的

    • 事件流:包括基本流和备选流,表示出所有可能的活动及流程
      基本流:指该用例最正常的一种场景
      备选流:用于描述用例执行过程中的异常或偶尔发生的情况。
      它和基本流合起来,能够覆盖该用例所有可能发生的场景。
      包含元素:
      1、起点:该备选流从事件流的那一步开始
      2、条件:在什么条件下会触发该备选流
      3、动作:系统在该备选流下会采取哪些动作
      4、恢复:该备选流结束之后,该用例应如何继续执行

    • 特殊需求: 描述与该用例相关的非功能性需求(包括性能、可靠性、可用性和可扩展性等)和设计约束(所使用的操作系统和开发工具等)

    • 前置条件和后置条件
      前置条件是执行用例之前必须存在的系统状态,后置条件是用例执行完毕后系统可能处于的一组状态。

    用例模型的检查

    • 功能需求的完备性
    • 模型是否易于理解
    • 是否存在不一致性
    • 避免二义性语义

    5. 软件需求描述

    软件需求规格说明书

    • 引言
    • 信息描述
    • 功能描述
    • 行为描述
    • 质量保证
    • 接口描述
    • 其他

    6. 需求管理

    需求管理的流程

    需求确认

    • 需求评审
    • 需求承诺

    需求跟踪

    需求变更控制

    • 需求变更利弊
    • 需求变更流程

    在这里插入图片描述

    六、 面向对象分析

    1. 软件分析概述

    软件需求和软件分析

    • 软件需求:用户角度,注重软件外在表现
    • 软件分析:开发者角度,注重软件内部逻辑结构

    2. 面向对象软件分析

    (1) OOA的主要任务

    • 理解用户需求
    • 进行分析,提取类和对象,并结合分析进行建模。其基本步骤是:标识类,定义属性和方法;刻画类的层次;表示对象以及对象与对象之间的关系;为对象的行为建模。这些步骤反复进行,直至完成建模。

    (2) OOA的模型

    • 处于OOA模型核心的是以用例模型为主体的需求模型,抽取和定义OOA模型的3种子模型:
    • 类/对象模型,描述系统所涉及的全部类和对象,每一类/对象都可通过属性、操作和协作者来进一步描述;
    • 对象-关系模型,描述对象之间的静态关系,同时定义了系统中对象间所有重要的信息路径,也可以具体到对象的属性、操作和协作者;
    • 对象-行为模型,描述了系统的动态行为,即在特定的状态下对象间如何协作来响应外界的事件。
      在这里插入图片描述

    (3) OOA的优点

    • ①同时加强了对问题域和软件系统的理解
    • ②改进包括用户在内的与软件分析有关的各类人员之间的交流
    • ③对需求的变化具有较强的适应性
    • ④很好地支持软件复用
    • ⑤确保从需求模型到设计模型的一致性

    (4) 分析模型的特点

    • 全面覆盖软件的功能需求
    • 分析模型与软件的实现无关
    • 分析模型的表述方法与所采用的分析技术有关

    (5) OOA的共同特征

    共同特征

    • 类和类层次的表示
    • 建立对象-关系模型
    • 建立对象-行为模型

    (6) OOA的建模步骤

    • 需求理解
    • 定义类和对象
    • 标识对象的属性和操作
    • 标识类的结构和层次
    • 建立对象-关系模型
    • 建立对象-行为模型
    • 评审OOA模型
      在这里插入图片描述

    面向对象开发的全过程是OOA,OOD,OOP和OOT的迭代过程。

    • 面向对象分析(OOA)是一种从问题空间中提取类和对象来进行分析的方法,用于建立一个与具体实现无关的面向对象分析模型;
    • 面向对象设计(OOD)则从问题空间转移到解空间,在分析模型的基础上考虑实现细节,形成面向对象的设计模型;
    • 面向对象编程(OOP)则用于将设计模型转换成实现模型,可获得源代码和相应的可执行代码;
    • 面向对象测试(OOT)则通过运行可执行代码来检测程序存在的问题。

    3. 面向对象分析建模

    (1) 识别与确定分析类

    边界类<<boundary>>

    • 用户界面
    • 系统接口
    • 硬件接口
    • 负责和用户进行交互的界面即用户界面

    控制类<<control>>

    • 封装用例所特有的控制行为
    • 负责实体类和边界类之间的交互

    实体类<<entity>>

    • 系统存储的信息及其相关行为
    • 主要负责数据和业务逻辑
      在这里插入图片描述
      为每对参与者/用例确定一个边界类
      在这里插入图片描述
      为每个用例设置一个控制类
      在这里插入图片描述
      确定相关的各个实体(包括属性与方法)
      在这里插入图片描述

    (2) 建立对象-行为模型

    时序图(以选课用例中创建课表事件流的时序图)
    在这里插入图片描述
    协作图(以选课用例为例创建课表事件流的协作图)
    在这里插入图片描述

    (3) 建立对象-关系模型

    分析类的属性:

    • 分析类本身具有的信息

    分析类的关联:

    • 通过关联可以找到其他分析类,链与关联的对应关系

    分析类图:表现分析类及其关系

    • 描述用例的分析类图称为参与类图(VOPC)
    • 每个用例可对应一张完整的参与类图,参与类图可以显示类的实例之间的数量关系。
      在这里插入图片描述
    • 100个用例->100个VOPC类图(每个类图有3个类)->全类图(<=300)个类

    分析类的合并:

    • 每个分析类都代表一个明确定义的概念,具有不相重叠的职责。一个类可以参与不同数量的用例,因此就整个系统而言,需要合并分析类,把具有相似行为的类合并为一个。每当更新了一个类,就要更新或补充用例规约,必要时还有更新原始的需求。
      在这里插入图片描述
      控制类(很少合并)
      实体类(基本都合并)
      边界类(部分合并)

    • 软件分析将软件需求阶段产生的需求模型转变为软件分析模型。分析模型其实就是从软件开发者的角度,在静态组成结构和动态行为两个方面来描述的待开发的软件系统。

    • 面向对象分析利用面向对象的技术来分析问题、建立问题域的静态模型和动态模型,并用UML等工具来表示这一需求对应的类对象模型、对象–关系模型和对象–行为模型等,从而完成对问题域建模,形成面向对象的分析模型。

    • 软件分析通常从用例分析开始,建立系统需求的静态结构模型和动态行为模型。

    七、 面向对象设计

    1. 软件设计的目标

    • 设计的目标,是细化解决方案的可视化设计模型,确保设计模型最终能平滑地过渡到程序代码。关键是构造解决问题的方案,并在决定实施细节的基础上获得该方案的设计模型。

    2. 设计模型和分析模型

    • 分析模型强调的是软件“应该做什么”,并不给出解决问题的方案,也不涉及具体的技术和平台。

    • 设计模式要回答“该怎么做”的问题,而且要提供解决问题的全部方案,包括软件如何实现、如何适应特定的实施环境等。

    • 分析=内容;设计=方式

    分析VS设计

    分析

    • 关注问题的理解
    • 理想化设计
    • 行为
    • 系统结构
    • 功能需求
    • 一个小的模型

    设计

    • 关注解决方案的理解
    • 操作和属性
    • 性能
    • 接近实际的代码
    • 对象的生命周期
    • 非功能需求
    • 一个大的模型

    3. 软件设计的概念及基本原则

    • 模块与构件、抽象与细化、信息隐藏、软件复用

    4. 软件设计的任务

    把分析阶段产生的分析模型转换为用适当手段表示的软件设计模型;

    软件设计一般包括数据设计、体系结构设计、过程设计、接口设计

    • 数据设计将分析阶段创建的信息模型转变成实现软件所需的数据结构;
    • 体系结构设计定义软件主要组成部件之间的关系;
    • 接口设计描述软件内部、软件和接口系统直接以及软件与人直接是如何通信的(包括数据流和控制流);
    • 过程设计将软件体系结构的组成部件转变为对软件组件的过程性描述

    数据和过程被封装为类/对象的属性和操作;接口被封装成对象间的消息;体系结构的设计则表现为系统的技术基础设计和具有控制流程的对象间的协作

    5. 模块化设计

    • 分解
    • 模块独立性
    • 自顶向下
    • 自底向上
    • 模块是一个拥有明确定义的输入、输出和特性的程序实体。模块的所有输入都是事先功能必不可少的,所有输出都有动作产生。
    • 在软件的体系结构中,模块是可组合、分解和更换的单元。

    模块的基本属性:

    • 接口:指模块的输入与输出;
    • 功能:指模块实现什么功能;
    • 逻辑:描述内部如何实现要求的功能即所需的数据。

    模块化设计

    • 目的是按照规定的原则把大型软件划分为一个较小的、相对独立但相互关联的模块。
    • 依据:开发一个大而复杂的软件系统,将它进行适当的分解,不但可降低其复杂性,还可减少开发工作量,从而降低开发成本,提高软件生产率,这就是模块化的依据。

    模块的独立性

    • 模块的独立性是指软件系统中每个模块只涉及软件要求的具体的子功能,而和软件系统中其他模块的接口是简单的。

    模块独立的含义

    • 模块完成独立的功能
    • 符合信息隐蔽和信息局部化的原则
    • 模块间关联和依赖程度尽量小

    模块独立程度可由两个定性标准度量:内聚、耦合

    • 内聚:指模块内部各个成分之间的联系,也称为块内联系或模块强度;
    • 耦合:指一个模块与其他模块间的联系,也称为块间联系。
    • 模块的独立性愈高,则块内联系越强,块间联系越弱。

    内聚

    内聚是从功能的角度对模块内部聚合能力的量度,按照由弱到强的顺序,内聚可分为7类,从小到大内聚强度逐步增强
    1)低内聚:
    ①偶然性内聚 ②逻辑性内聚 ③时间性内聚
    2) 中内聚
    ①过程性内聚 ②通信性内聚
    3) 高内聚
    ①顺序性内聚 ②功能性内聚

    • 偶然性内聚:当模块内各部分之间没有联系,或者即使有联系,这种联系也很松散,则称这种模块为偶然性内聚或巧合内聚模块,是内聚程度最低的模块。
    • 逻辑内聚:把几种相关功能(逻辑上相似的功能)组合在一模块内,每次调用由传给模块的参数确定执行哪种功能。
      例:由参数决定执行读操作还是写操作:
      在这里插入图片描述
    • 时间内聚:又称经典内聚。这种模块大多为多功能模块,但模块的各个功能的执行与时间有关,通常要求所有功能必须在同一时间段内执行。
      例如初始化模块和终止模块,系统结束模块、紧急故障处理模块等均是时间性内聚模块。
    • 过程内聚:一个模块中包含的一组任务必须按照某一特定的次序执行时,就称为过程性模块。
    • 通信内聚:模块内部的各个成分都使用同一种输入数据,或者产生同一个输出数据。
    • 顺序性内聚:模块中的各组成成分是顺序执行的。通常情况下,上一个处理框的输出就是下一个处理框的输入。
    • 功能性内聚:一个模块中各个部分都是完成某一具体功能必不可少的组成部分,或者说该模块中所有部分都是为了完成一项具体功能而协同工作,紧密联系,不可分割的。是内聚性最强的模块。

    耦合

    耦合性是程序结构中各个模块之间相互关联的度量,它取决于各个模块之间接口的复杂程度、调用模块的方式以及哪些信息通过接口。
    在这里插入图片描述

    • 非直接耦合:两个模块之间没有直接关系,模块独立性最强
    • 数据耦合:一模块调用另一模块时,被调用模块的输入、输出都是简单的数据(若干参数),属松散耦合。
      在这里插入图片描述

    在这里插入图片描述

    • 特征耦合(标记耦合)
      两个模块通过传递数据结构,(不是简单数据,而是记录、数组等)加以联系,或都与一个数据结构有关系,则称这两个模块间存在特征耦合。
      在这里插入图片描述
    • 控制耦合 如果一个模块通过传送开关、标志、名字等控制信息,明显地控制选择另一模块的功能,就是控制耦合。
      在这里插入图片描述
      去除模块间控制耦合的方法:
      将被调用模块内的判定上移到调用模块中进行;
      被调用模块分解成若干单一功能模块
      在这里插入图片描述
    • 外部耦合 一组模块均与同一外部环境关联(例如, I/O模块与特定的设备、格式和通信协议相关联),它们之间便存在外部耦合。
      外部偶合必不可少,但这种模块数目应尽量少
    • 公共环境耦合
      在这里插入图片描述
    • 内容耦合 耦合最强。如果一个模块可以直接调用另一模块中的数据,或者允许一个模块直接转移到另一个模块中去,就称内容耦合。
      在这里插入图片描述

    耦合是影响软件复杂程度的一个重要因素,应该采取下述设计原则:

    • 尽量使用数据耦合,少用控制耦合和特征耦合;
    • 限制公共环境耦合的范围,完全不用内容耦合

    内聚和耦合关系密切,与其他模块直接强耦合的模块意味着弱内聚,强内聚模块意味着与其它模块间松散耦合。

    设计目标:高内聚、低耦合

    • 耦合、内聚与模块独立性关系:
    • 耦合与内聚都是模块独立性的定性标准,都反映模块独立性的良好程度,但耦合是直接的主导因素,内聚则辅助耦合共同对模块独立性进行衡量。

    6. 面向对象设计建模

    面向对象设计模型:

    • 系统架构层(系统架构层描述了整个系统的总体结构)
    • 类和对象层(包含类层次信息,同时包含了每个对象的设计表示)
    • 消息层(对象间的消息模型,建立了系统的内部和外部接口)
    • 责任层(每个对象的所有属性和操作的数据结构和算法)
      在这里插入图片描述

    面向对象设计的任务

    • 系统架构设计
    • 系统元素设计

    模式的应用

    • 模式是解决某一类问题的方法论,也是对通用问题的通用解决方案;
    • 软件模式可以分为架构模式、设计模式和习惯用法三种

    7. 子系统VS包

    子系统:

    • 提供行为
    • 完全封装实现细节
    • 容易替换

    包:

    • 不提供行为
    • 不完全封装实现细节
    • 难以替换

    子系统的主要用途:子系统可以将系统划分成独立的部分,将被实现为独立的构件,这些构件在保持结构不变的情况下,可以

    • 独立地开发和部署
    • 适应变更,而不影响其他系统

    子系统也可用于

    • 将系统划分成若干单元
    • 表示设计中的既存产品或外部系统

    八、 编码与测试

    1、软件测试

    • 动态查找程序代码中的各类错误和问题的过程。
    • 软件测试是一个与项目开发并行的过程,按照新的观点,测试活动应分布于需求、分析、设计、编码、测试和验收等各个阶段。它是软件开发时期最繁重的任务,也是保证软件可靠性的最主要手段。

    测试与纠错

    测试:

    • 目的:发现程序的错误;
    • 任务:通过在计算机上执行程序,暴露程序中潜在的错误

    纠错:

    • 目的:定位和纠正错误
    • 任务:消除软件故障,保证程序的可靠运行

    测试用例:一次执行需要的测试数据。
    测试用例={测试数据+预期结果}({}表示重复)
    测试结果={测试数据+预期结果+实际结果}

    每一个测试用例产生一个相应的测试结果,如果它与期望结果不相符合,便说明程序中存在错误,需要通过纠错来改正。

    选择测试用例的目标:是用尽可能少的测试数据,达到尽可能大的程序覆盖面,发现尽可能多的软件错误和问题。

    测试的特性

    • 挑剔性、复杂性、不彻底性、经济性
    • 穷举测试:让被测程序在一切可能的输入情况下全部执行一遍。
    • 选择测试:选择一些典型的、有代表性的测试用例进行有限的测试。

    测试的种类

    • 静态分析(程序不执行):
      静态分析器分析(自动方式) 代码评审(人工方式):代码会审、走查、办公室检查
    • 动态测试(程序执行):
      黑盒测试(测试程序功能)、白盒测试(测试程序结构)

    黑盒测试(功能测试)

    等价分类法

    • 所谓等价分类,就是把输入数据的可能值划分为若干等价类,使每类中的任何一个测试用例,都能代表同一等价类中的其他测试用例。
    • 注意:
      一是划分等价类不仅要考虑代表有效输入值的有效等价类,还需考虑代表无效输入值的无效等价类;
      二是每一无效等价类至少要用一个测试用例,不然就可能漏掉某一类错误,但允许若干有效等价类合用同一个测试用例,以便进一步减少测试的次数。

    例:某公司公开招工,规定报名者年龄应在16周岁至35周岁之间(到2008年3月止)。若出生年月不在上述范围内,将拒绝接受,并显示“年龄不合格”等出错信息。试用等价分类法设计对这一程序功能的测试用例。

    测试等价类表:

    输入数据 有效等价类 无效等价类
    出生年月 ①6位有效数字 ②少于6位 ③多于6位 ④存在除数字以外的其他字符
    对应数值 ⑤197302~199203之间 ⑥小于197302 ⑦大于199203
    月份对应数值 ⑧1~12之间 ⑨小于1 ⑩大于12

    测试用例:

    测试数据 期望结果 测试范围
    198808 输入有效 ① ⑤ ⑧
    1988 输入无效
    1988008 输入无效
    1988AA 输入无效
    197201 年龄不合格
    199304 年龄不合格
    198800 输入无效
    198822 输入无效

    边界值分析法

    • 在数组容量、循环次数以及输入数据域输出数据的边界值附近程序出错的概率往往较大。采用边界值分析法,就是要这样来选择测试用例,使得被测程序能在边界值及其附近运行,从而更有效地暴露程序中隐藏的错误。
    • 所谓边界值分析,就是要把测试的重点放在各个等价类的边界上,选取刚好等于,刚好小于,刚好大于边界值的数据为测试数据,并据此设计出相应的测试用例。
      在这里插入图片描述

    比较:

    • ①等价分类法的测试数据是在各个等价类允许的值域内任意选取的,而边界类分析的测试数据必须在边界值附近选取;
    • ②一般的说,用边界值分析法设计的测试用例比等价分类法的代表性更广,发现错误的能力也更强。

    错误猜测法

    • 所谓猜错,就是猜测被测程序在哪些地方容易出错,然后针对可能的薄弱环节来设计测试用例。

    因果图法

    • 是一种简化了的逻辑图,当被测程序具有多种输入条件,程序的输出又依赖于输入条件的各种组合时,用因果图直观地表明输入条件和输出动作之间的因果关系,能帮助测试人员把注意力集中到与程序功能有关的那些输入组合上,比采用等价分类法有更高明的测试效率。

    白盒测试

    • 白盒测试以程序的结构为依据,所以又称为结构测试早期的白盒测试把注意咯放在流程图的各个判定框,使用不同的逻辑覆盖标准来表达对程序进行测试的详尽程度,称为逻辑覆盖测试;
    • 用程序图代替流程图来设计测试用例,称为路径测试。

    逻辑覆盖测试的5种标准
    发现错误的能力由弱到强

    • 语句覆盖:每条语句至少执行一次 A与B为true
    • 判定覆盖:每一判定的每个分支至少执行一次 A与B为true,A与B为false
    • 条件覆盖:每一判定中的每个条件,分别按“真”“假”至少各执行一次
      A=true,B=true,A=fasle,B=false
    • 判定/条件覆盖:同时满足判定覆盖和条件覆盖的要求 A与B=true,A与B=false,A=true,B=true,A=false,B=false
    • 条件组合覆盖:求出判定中所有条件的各种可能组合值,每一可能的条件组合至少执行一次 A=true与B=true,A=true与B=false,A=false与B=true,A=false与B=false

    语句覆盖发现错误的能力最弱,一般不单独采用

    判定覆盖与条件覆盖的差别在于:前者把判定看成一个整体,后者则着眼于其中的一个条件。当一个判定只含一个条件时,判定覆盖也就是条件覆盖。但如果一个判定含有一个以上的条件(称其为复合条件)

    采用判定覆盖有可能出现漏洞:盘定制有些条件得到测试,另一些条件却被忽略。判定/条件覆盖解决了条件覆盖的不足之处。条件组合覆盖在5种覆盖中发现错误的能力最强。

    路径测试法

    着眼于程序的执行路径,程序图是考察测试路径的有用工具。

    • 顺序执行的多个结点,在程序图中可以合并画成一个结点。
    • 含有复合条件的判定框,应先将其分解成几个简单条件判定框,然后再画程序图

    程序图关心的是程序中的判定框,而不是顺序执行部分的细节。

    路径测试的特征

    对程序图中每一条可能的程序执行路径至少测试一次,如果程序中含有循环(在程序图中表现为环),则每个循环至少执行一次。

    ①满足结构测试的最低要求。语句覆盖(点覆盖)加判定覆盖(边覆盖)是对白盒测试的最低要求,同时满足这两种标准的覆盖称为完全覆盖。

    ②有利于安排循环测试。对单循环结构的路径测试包括:

    • 零次循环,即不执行循环体,直接从循环入口跳到出口;
    • 一次循环,循环体仅执行一次,主要检查在循环初始化中可能存在的错误;
    • 典型次数的循环
    • 最大值次循环,如果循环次数存在最大值,应按此最大值进行循环,需要时还可增加比最大值次数少一次或多一次的循环测试

    选择测试路径的原则

    • ①选择具有功能含义的路径
    • ②尽量用短路径代替长路径
    • ③从上一条测试路径到下一条测试路径,应尽量减少变动的部分(包括变动的边和结点)
    • ④由简入繁,如果可能,应先考虑不含循环的测试路径,然后补充对循环的测试;
    • ⑤除非不得已(如为了要覆盖某条边),不要选取没有明显功能含义的复杂路径。

    2、多模块程序的测试策略

    测试的层次:
    单元测试、集成测试、高级测试(确认测试、系统测试)

    单元测试(编码阶段,以白盒(结构)测试为主)

    • 单元测试是层次测试的第一步,也是整个测试的基础。在编码阶段完成。单元一般以模块或子程序为单位,故又称模块测试。
    • 目的:通过对象模块的静态分析与动态测试,使其代码达到模块说明书的需求。
    • 静态分析与动态测试的重点,均应放在模块内部的重要执行路径、出错处理路径和局部数据结构,也要重视模块的对外接口。

    集成测试(测试阶段,以黑盒(功能)测试为主)

    • 集成测试是一个逐步组装的过程,它从一个单元开始,逐一地添加新的单元,边添加边测试边纠错,直至最终将所有单元集成为一个系统。
    • 除进行新的测试项目外,还需重复先前已经进行过的测试,也称为回归测试。回归测试可用于防止因软件组装改变而导致新的不协调,出现不可预料的错误。
    • 目的:将经过单元测试的模块逐步组装成具有良好一致性的完整的程序 集成测试的策略:可以分为自顶向下、由底向上以及两头逼近的混合方式。

    确认测试(测试阶段,以黑盒(功能)测试为主)

    确认测试是对整个程序的测试,用于确认组装完毕的程序确能满足需求规格说明书(SRS)的要求。

    • ①有效性测试(黑盒测试)和配置复审
    • ②验收测试(由用户进行)
    • ③a与β测试
      -a测试是在一个受控的环境下,由用户在开发者的指导下进行的测试,由开发者负责记录错误和使用中出现的问题。
      β测试是由最终用户在自己的场所进行的,开发者通常不会在场,也不能控制应用的环境。所有在β测试中遇到的问题均由用户记录,并定期把报告给开发者。

    系统测试(安装与验收阶段,以黑盒(功能)测试为主)

    • 系统测试是在验收阶段进行。
    • 目的是检查把确认测试合格的软件安装到系统以后,能否与系统的其余部分协调进行,并且实现SRS的要求。

    九、软件维护

    软件维护的种类:

    • 完善性维护、适应性维护、纠错性维护、预防性维护

    软件的可维护性:

    • 是衡量维护容易程度的一种软件属性。定性的说,可维护性取决于软件的可理解性、可修改性与可测试性,三者一起构成软件的质量属性。

    软件维护的副作用:因修改而引起副作用

    • 修改编码的副作用;
    • 修改数据的副作用;
    • 修改文档的副作用
    展开全文
  • 软件工程导论—软件测试

    万次阅读 多人点赞 2020-05-13 21:26:49
    1. 软件测试基础 2. 单元测试 3. 集成测试 4. 确认测试 5. 白盒测试技术 6. 黑盒测试技术 7. 调试 8. 软件可靠性

    1. 软件测试基础

    1.1. 软件测试的目的和准则

    测试是为了发现程序中的错误而执行程序的过程,好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案,成功的测试是发现了至今为止尚未发现的错误的测试。

    一般来说,软件测试有以下几条准则:

    1. 所有测试都应该能追溯到用户需求;
    2. 应该远在测试开始之前就制定出测试计划;
    3. 把Pareto原理应用到软件测试中;
    4. 应该从“小规模”测试开始,并逐步进行“大规模”测试;
    5. 穷举测试是不可能的;
    6. 为了达到最佳的测试效果,应该由独立的第三方从事测试工作。

    1.2. 软件测试方法和步骤

    软件测试方法主要分为黑盒测试和白盒测试:

    1. 黑盒测试(功能测试)
      把程序看作一个黑盒子,完全不考虑程序的内部结构和处理过程,而是在程序接口进行的测试;
    2. 白盒测试(结构测试)
      把程序看成装在一个透明的盒子里,测试者完全知道程序的结构和处理算法,按照程序内部的逻辑测试程序,检测程序中的主要执行通路是否都能按预定要求正确工作。
    黑盒测试 白盒测试
    优点 适用于各阶段测试
    从产品功能角度测试
    容易入手生成测试数据
    可构成测试数据使特定程序部分得到测试
    有一定的充分性度量手段
    可获较多工具支持
    缺点 某些代码得不到测试
    如果规格说明有误,则无法发现
    不易进行充分性测试
    通常不易生成测试数据
    无法对未实现规格说明的部分进行测试
    工作量大,通常只用于单元测试,有应用局限
    性质 一种确认技术,回答"我们在构造一个正确的系统吗?" 一种验证技术,回答"我们在正确地构造一个系统吗?"

    一般来说,测试的按照以下步骤进行:

    1. 模块测试(单元测试)
      模块测试主要发现的往往是编码和详细设计的错误,目的是保证每个模块作为一个单元能正确运行;
    2. 子系统测试
      子系统测试把经过单元测试的模块放在一起形成一个子系统来测试,着重测试模块的接口。
    3. 系统测试
      把经过测试的子系统装配成一个完整的系统来测试,发现的往往是软件设计中的错误,也可能发现需求说明中的错误。不论是子系统测试还是系统测试,都兼有检测和组装两重含义,通常也称为集成测试。
    4. 验收测试(确认测试)
      验收测试是在用户积极参与下进行的,而且可能主要使用实际数据(系统将来要处理的信息)把软件系统作为单一的实体进行测试进行测试,它发现的往往是系统需求说明书中的错误
    5. 平行运行
      同时运行新开发出来的系统和将被它取代的旧系统,然后比较新旧两个系统的处理结果。平行运行可以在准生产环境中运行新系统而又不冒风险,同时用户能有一段熟悉新系统的时间,用户可以趁这段时间验证用户指南和使用手册之类的文档。以准生产模式对新系统进行全负荷测试,可以用测试结果验证性能指标。

    详细步骤说明如下表所示:

    测试阶段 主要依据 测试人员 测试方法 测试内容
    单元测试 系统设计文档 开发小组 白盒测试 接口测试
    路径测试
    子系统测试 系统设计文档
    需求文档
    独立测试小组 白盒测试
    黑盒测试
    接口测试
    路径测试
    功能测试
    性能测试
    系统测试 需求文档 独立测试小组 黑盒测试 功能测试、健壮性测试
    性能测试、用户界面测试
    安全性测试、压力测试
    可靠性测试、安装/卸载测试
    验收测试 需求文档 用户 黑盒测试 功能测试、健壮性测试
    性能测试、用户界面测试
    安全性测试、压力测试
    可靠性测试、安装/卸载测试

    1.3. 测试内容

    1. 接口测试
      每个接口可能有多个输入参数,每个参数有 “典型值”、“边界值”、“异常值”之分,根据接口的定义,可以推断某种输入应当产生什么样的输出。输出包括函数的返回值和输出参数。 同时要观察是否有程序语句从来没有被执行过,特别留意函数体内的错误处理程序块。
    2. 路径测试
      路径测试就是测试程序的流程路径,想遍历全部路径几乎是不可能的,不测试或者胡乱找几条路径测试却又不行,输入与对应的输出之间的路径是唯一的。由于接口测试时的输入要有代表性的,因此相应的路径也具有代表性,制定的路径测试检查表应该包括:数据类型、变量值、逻辑判断、循环、内存管理、文件I/O、错误处理。
    3. 功能测试
      功能测试的基本方法是构造一些合理输入(在需求范围之内),检查输出是否与期望相同。有两种比较好的测试方法:等价划分法和边界值分析法,等价划分是指把输入空间划分为几个“等价区间”,在每个“等价区间”中只需要测试一个典型值就可以了;边界值测试法是对等价划分法的补充。除了典型值外还要用边界值作为测试用例。
    4. 健壮性测试
      健壮性是指在异常情况下,软件能正常运行的能力。它有两层含义:(1)容错能力,容错性测试通常构造一些不合理的输入来引诱软件出错;(2)恢复能力,恢复测试重点考察系统能否重新运行、有无重要的数据丢失、是否毁坏了其它相关的软件硬件。
    5. 性能测试
      性能测试即测试软件处理事务的速度,一是为了检验性能是否符合需求,二是为了得到某些性能数据供人们参考,有时人们关心测试的“绝对值” ,有时关心测试的“相对值” 。
    6. 用户界面测试
      绝大多数软件拥有图形用户界面,图形用户界面的测试重点是正确性、易用性和视觉效果,在评价易用性和视觉效果时,主观性非常强,应当考虑多个人的观点。
    7. 信息安全测试
      信息安全性是指防止系统被非法入侵的能力,既属于技术问题又属于管理问题。主要有如下步骤:(1)为非法入侵设立目标、(2)邀请一些人扮演黑客,让他们想尽办法入侵系统,实现“目标”、(3)如果有人成功了,请他详述入侵的过程。
    8. 压力测试
      压力测试也叫负荷测试,即获取系统能正常运行的极限状态。 主要任务是:构造正确的输入,使劲折腾系统却让它刚好不瘫痪。 压力测试的一个变种是敏感测试,敏感测试目的是发现什么样的输入可能会引发不稳定现象。
    9. 可靠性测试
      可靠性是指在一定的环境下、给定的时间内、系统不发生故障的概率。软件可靠性测试可能会花费很长时间。 比较实用的办法是,让用户使用该系统,记录每一次发生故障的时刻。计算出相邻故障的时间间隔,注意要去掉非工作时间。然后统计出不发生故障的“最小时间间隔”、“最大时间间隔”和“平均时间间隔”。
    10. 安装/卸载测试
      目前市面上有非常流行的、专门制作安装/卸载程序的一些工具,如Install Shelled。主要的测试工作是:(1)至少在标准配置和最低配置两种环境下测试;(2)如果有安装界面,应当尝试各种选项,如选择“全部”、“部分”、“升级”等。

    1.4. 测试阶段的信息流

    测试阶段输入的信息有两类: 软件配置测试配置,其中软件配置包括需求说明书、设计说明书和源程序清单等,测试配置包括测试计划和测试方案。

    在这里插入图片描述

    2. 单元测试

    单元测试和编码属于软件过程的同一个阶段,它应用人工测试和计算机测试这样两种不同类型的测试方法对模块进行集中检测。单元测试主要使用白盒测试技术,对多个模块的测试可以并行地进行。

    人工测试的方法由审查小组进行,其主要使用白盒测试技术进行代码审查,审查的重点是模块接口、局部数据结构、重要的执行通路、出错处理通路和边界条件,一般来说可以查出30%~70%的逻辑设计错误和编码错误,这可以减少系统验证的总工作量。

    审查小组一般由一名审查组长,带领程序的设计人员、编码人员和测试人员共同进行。

    计算机测试的方法必须为每个单元测试开发驱动程序和(或)存根程序,驱动程序是一个“主程序”,它接收测试数据,传送给被测试的模块,并且输出有关的结果。

    存根程序代替被测试的模块所调用的模块。它使用被它代替的模块的接口,可能做最少量的数据操作,输出对入口的检验或操作结果,并且把控制归还给调用它的模块。

    3. 集成测试

    3.1. 集成测试概述

    集成测试是测试和组装软件的系统化技术,主要目标是发现与接口有关的问题。

    由模块组装成程序时有两种方法:

    1. 非渐增式测试方法
      先分别测试每个模块,再把所有模块按设计要求放在一起结合成所要的程序。非渐增式测试一下子把所有模块放在一起,并把庞大的程序作为一个整体来测试,测试者面对的情况十分复杂,在庞大的程序中想要诊断定位一个错误是非常困难的,改正错误更是极端困难,而且一旦改正一个错误之后,马上又会遇到新的错误。
    2. 渐增式测试方法
      把下一个要测试的模块同已经测试好的那些模块结合起来进行测试,测试完以后再把下一个应该测试的模块结合进来测试,每次增加一个模块,实际上同时完成单元测试和集成测试。把程序划分成小段来构造和测试,在这个过程中比较容易定位和改正错误;

    而渐增方式也有两种集成策略:自顶向下集成和自底向上集成,下面分别对它们进行介绍

    3.2. 自顶向下集成

    从主控制模块开始,沿着程序的控制层次向下移动,逐渐把各个模块结合起来,就是自顶向下的集成。
    在这里插入图片描述
    在把附属于主控制模块的那些模块组装到程序结构中去时,可以使用深度优先的策略或者使用宽度优先的策略。

    所谓深度优先,就是先组装在软件结构的一条主控制通路上的所有模块;宽度优先就是沿软件结构水平地移动,把处于同一个控制层次上的所有模块组装起来。

    在这里插入图片描述
    然后按照下述4个步骤完成把模块结合进软件结构的过程:

    1. 对主控制模块进行测试,测试时用存根程序代替所有直接附属于主控制模块的模块;
    2. 根据选定的结合策略(深度优先或宽度优先),每次用一个实际模块代换一个存根程序(新结合进来的模块往往又需要新的存根程序);
    3. 在结合进一个模块的同时进行测试;
    4. 为了保证加入模块没有引进新的错误,可能需要进行回归测试(即,全部或部分地重复以前做过的测试);
    5. 不断地重复2~4步,直到构造起完整的软件结构为止。

    自顶向下的测试能够在测试的早期对主要的控制或关键的抉择进行检验,如果选择深度优先的结合方法,可以在早期实现软件的一个完整的功能并且验证这个功能。但是由于存根程序代替了低层次的模块,在软件结构中没有重要的数据自下往上流。

    3.3. 自底向上集成

    在这里插入图片描述
    用下述步骤可以实现自底向上的结合策略:

    1. 把低层模块组合成实现某个特定的软件子功能的族;
    2. 写一个驱动程序(用于测试的控制程序),协调测试数据的输入和输出;
    3. 对由模块组成的子功能族进行测试;
    4. 去掉驱动程序,沿软件结构自下向上移动,把子功能族组合起来形成更大的子功能族。
    5. 不断重复2~4步,直到构造起完整的软件结构为止。
      在这里插入图片描述

    3.4. 不同集成测试策略的比较与回归测试

    集成测试策略 优点 缺点
    非渐增式 没有错误隔离手段
    主要设计错误发现迟
    潜在可重用代码测试不充分
    需要驱动程序和存根程序
    自顶向下 具有错误隔离手段
    主要设计错误发现早
    不需要驱动程序
    潜在可重用代码测试不充分
    需要存根程序
    自底向上 具有错误隔离手段
    潜在可重用代码能充分测试
    不需要存根程序
    主要设计错误发现迟
    需要驱动程序
    混合 具有错误隔离手段
    主要设计错误发现早
    潜在可重用代码能充分测试
    较少

    所谓混合集成测试策略,主要有两种:

    1. 改进的自顶向下测试方法
      基本上使用自顶向下的测试方法,但是在早期使用自底向上的方法测试软件中的少数关键模块。该策略能在测试的早期发现关键模块中的错误;测试关键模块时需要驱动程序。
    2. 混合法
      对软件结构中较上层使用的自顶向下方法与对软件结构中较下层使用的自底向上方法相结合,该策略兼有两种方法的优缺点,当被测试的软件中关键模块比较多时,这种混合法可能是最好的折衷方法。

    每一轮集成测试后都要尽可能的进行回归测试,用于保证由于调试或其他原因引起的变化,不会导致非预期的软件行为或额外错误的测试活动,可以通过重新执行全部测试用例的一个子集人工地进行,也可以使用自动化的捕获回放工具自动进行。

    4. 确认测试

    4.1. 确认测试概述

    确认测试也称为验收测试,它的目标是验证软件的有效性(即软件的功能和性能是否符合用户预期)。

    需求分析阶段产生的软件需求规格说明书,准确地描述了用户对软件的合理预期,因此是软件有效性的标准,也是进行确认测试的基础。

    4.2. 确认测试的范围和软件配置复查

    确认测试必须有用户积极参与,或者以用户为主进行,使用用户界面输入测试数据并且分析评价测试的输出结果,在验收之前通常要由开发单位对用户进行培训,一般来说确认测试分为Alpha和Beta测试。

    确认测试的一个重要内容是复查软件配置。复查的目的是保证软件配置的所有成分都齐全,质量符合要求,文档与程序完全一致,具有完成软件维护所必须的细节。

    4.3. Alpha和Beta测试

    Alpha测试就是由开发者“指导”用户在开发环境下进行的测试。Alpha测试是在受控的环境中进行的。

    Beta测试就是由软件的最终用户们在一个或多个实际生产环境下进行的测试。开发者通常不在Beta测试的现场,因此,Beta测试是软件在开发者不能控制的环境中的“真实”应用。

    5. 白盒测试技术

    5.1. 白盒测试技术概述

    白盒测试应包含完整的测试方案,所谓测试方案包括具体的测试目的(例如,预定要测试的具体功能),应该输入的测试数据和预期的结果。通常又把测试数据和预期的输出结果称为测试用例。
    在这里插入图片描述

    5.2. 逻辑覆盖

    有选择地执行程序中某些最有代表性的通路是对穷尽测试的惟一可行的替代办法。从覆盖源程序语句的详尽程度分析,大致有以下一些不同的覆盖标准:

    1. 语句覆盖
      选择足够多的测试数据,使被测程序中每个语句至少执行一次。语句覆盖对程序的逻辑覆盖很少。语句覆盖只关心判定表达式的值,而没有分别测试判定表达式中每个条件取不同值时的情况。语句覆盖是很弱的逻辑覆盖标准。
    2. 判定覆盖
      不仅每个语句必须至少执行一次,而且每个判定的每种可能的结果都应该至少执行一次。
    3. 条件覆盖
      不仅每个语句至少执行一次,而且使判定表达式中的每个条件都取到各种可能的结果。条件覆盖通常比判定覆盖强,因为它使每个条件都取到了两个不同的结果,判定覆盖却只关心整个判定表达式的值。但也有反例,总之,判定覆盖不一定包含条件覆盖,条件覆盖也不一定包含判定覆盖。
    4. 判定/条件覆盖
      使得判定表达式中的每个条件都取到各种可能的值,每个判定表达式也都取到各种可能的结果。
    5. 条件组合覆盖
      要求选取足够多的测试数据,使得每个判定表达式中条件的各种可能组合都至少出现一次。条件组合覆盖是前述几种覆盖标准中最强的。满足条件组合覆盖标准的测试数据,也一定满足判定覆盖、条件覆盖和判定/条件覆盖标准。但是,条件组合覆盖标准的测试数据并不一定能使程序中的每条路径都执行到,是从对程序路径的覆盖程度分析的逻辑覆盖标准。
    6. 点覆盖
      选取足够多的测试数据,使得程序执行路径至少经过流图的每个结点一次。由于流图的每个结点与一条或多条语句相对应,因此点覆盖标准和语句覆盖标准是相同的。
    7. 边覆盖
      选取足够多测试数据,使得程序执行路径至少经过流图中每条边一次。通常边覆盖和判定覆盖是一致的。
    8. 路径覆盖
      选取足够多测试数据,使程序的每条可能路径都至少执行一次(如果程序图中有环,则要求每个环至少经过一次。

    在这里插入图片描述

    5.3. 控制结构测试

    控制结果测试分为基本路径测试和循环测试,具体如下

    1. 基本路径测试
      基本路径测试是Tom McCabe提出的一种白盒测试技术。首先计算程序的环形复杂度,以该复杂度为指南定义执行路径的基本集合,从该基本集合导出的测试用例可保证程序中的每条语句至少执行一次,而且每个条件在执行时都将分别取真、假两种值。
    2. 循环测试
      循环测试是一种白盒测试技术,它专注于测试循环结构的有效性。在结构化的程序中通常只有3种循环,即简单循环、串接循环和嵌套循环。
      (1)简单循环
      应该使用下列测试集来测试简单循环,其中n是允许通过循环的最大次数:
      跳过循环、只通过循环一次、通过循环两次、通过循环m次,其中m<n-1、通过循环n-1,n,n+1次。
      (2)嵌套循环
      从最内层循环开始测试,其他循环都设置为最小值。对最内层循环使用简单循环测试方法,而使外层循环的迭代参数取最小值,并为越界值或非法值增加一些额外的测试。由内向外,对下一个循环进行测试,但保持所有其他外层循环为最小值,其他嵌套循环为“典型”值。然后继续进行下去,直到测试完所有循环。
      (3)串接循环
      如果串接循环的各个循环都彼此独立,则可以使用测试简单循环的方法来测试串接循环。如果两个循环串接,而且第一个循环的循环计数器值是第二个循环的初始值,则这两个循环并不是独立的。当循环不独立时,建议使用测试嵌套循环的方法来测试串接循环。

    在这里插入图片描述

    6. 黑盒测试技术

    6.1. 黑盒测试概述

    黑盒测试着重测试软件功能,主要的错误类型为: 功能不正确或遗漏了功能、界面错误、数据结构错误或外部数据库访问错误、性能错误、初始化和终止错误

    黑盒测试的公认标准主要有两个:(1)测试用例尽可能少;(2)一个测试用例能指出一类错误。

    6.2. 等价划分

    使用等价划分法设计测试方案首先需要划分输入数据的等价类,等价划分是一种黑盒测试技术,把程序的输入域划分成若干个数据类,据此导出测试用例。设计测试方案时尽量设计出能发现若干类错误的测试用例,从而减少测试用例的数目,每类中的一个典型值在测试中的作用要与这一类中所有其他值的作用相同。此外常常还需要分析输出数据的等价类,以便根据输出数据的等价类导出对应的输入数据等价类。

    等价类划分的启发式规则

    1. 如果规定了输入值的范围,则可划分出一个有效的等价类(输入值在此范围内),两个无效的等价类(输入值小于最小值或大于最大值);
    2. 如果规定了输入数据的个数,则类似地也可划分出一个有效的等价类和两个无效的等价类;
    3. 如果规定了输入数据的一组值,而且程序对不同输入值做不同处理,则每个允许的输入值是一个有效的等价类,此外还有一个无效的等价类(任一个不允许的输入值);
    4. 如果规定了输入数据必须遵循的规则,则可以划分出一个有效的等价类(符合规则)和若干个无效的等价类(从各种不同角度违反规则);
    5. 如果规定了输入数据为整型,则可以划分出正整数、零和负整数等3个有效类;
    6. 如果程序的处理对象是表格,则应该使用空表,以及含一项或多项的表。

    使用等价划分法设计黑盒测试的方案时可以按照如下两个步骤进行:

    1. 设计一个新的测试方案以尽可能多地覆盖尚未被覆盖的有效等价类,重复这一步骤直到所有有效等价类都被覆盖为止;
    2. 设计一个新的测试方案,使它覆盖一个而且只覆盖一个尚未被覆盖的无效等价类,重复这一步骤直到所有无效等价类都被覆盖为止。

    6.3. 边界值分析

    经验表明,处理边界情况时程序最容易发生错误。例如,许多程序错误出现在下标、纯量、数据结构和循环等等的边界附近。使用边界值分析方法设计测试方案首先应该确定边界情况。选取的测试数据应该刚好等于、刚刚小于和刚刚大于边界值。

    通常设计黑盒测试方案时总是联合使用等价划分和边界值分析两种技术。

    6.4. 错误推测

    不同类型不同特点的程序通常又有一些特殊的容易出错的情况。因此必须依靠测试人员的经验和直觉,从各种可能的测试方案中选出一些最可能引起程序出错的方案。它的基本想法是列举出程序中可能有的错误和容易发生错误的特殊情况,并且根据它们选择测试方案。

    7. 调试

    7.1. 调试概述

    调试是在测试发现错误之后排除错误的过程,软件错误的外部表现和它的内在原因之间可能并没有明显的联系,调试就是把症状和原因联系起来的尚未被人深入认识的智力过程。

    7.2. 调试过程和途径

    调试发生在测试之后,调试过程从执行一个测试用例开始,评估测试结果,如果发现实际结果与预期结果不一致,则这种不一致就是一个症状,它表明在软件中存在着隐藏的问题。

    调试过程试图找出产生症状的原因,以便改正错误。
    在这里插入图片描述
    调试可以通过下列途径进行:

    1. 蛮干法
      蛮干法可能是寻找软件错误原因的最低效的方法。其他方法都失败时才使用这种方法,这种方法印出内存的内容,激活对运行过程的跟踪,在程序中到处都写上WRITE(输出)语句。更多情况下这种方法只会浪费时间和精力。必须首先进行周密的思考,有明确的目的,尽量减少无关信息的数量。
    2. 回溯法
      回溯是一种相当常用的调试方法,当调试小程序时这种方法是有效的。具体做法是,从发现症状的地方开始,人工沿程序的控制流往回追踪分析源程序代码,直到找出错误原因为止。但是随着程序规模扩大,应该回溯的路径数目也变得越来越大,以至彻底回溯大程序变成完全不可能了。
    3. 原因排除法
      (1)对分查找法
      如果已经知道每个变量在程序内若干个关键点的正确值,则可以用赋值语句或输入语句在程序中点附近“注入”这些变量的正确值,然后运行程序并检查所得到的输出,如果输出结果是正确的,则错误原因在程序前半部分;反之,错误原因在程序后半部分,对错误原因所在的那部分重复使用这个方法,直到把出错范围缩小到容易诊断的程度为止。
      (2)归纳法
      归纳法是从个别现象推断出一般性结论的思维方法。首先把和错误有关的数据组织起来进行分析,以便发现可能的错误原因,然后导出对错误原因的一个或多个假设,并利用已有的数据来证明或排除这些假设。
      (3)演绎法
      演绎法从一般原理或前提出发,经过排除和精化的过程推导出结论。首先设想出所有可能的出错原因,然后试图用测试来排除每一个假设的原因。

    8. 软件可靠性

    8.1. 软件可靠性相关的几个概念

    软件可靠性:程序在给定的时间间隔内,按照规格说明书的规定成功地运行的概率。

    软件的可用性:程序在给定的时间点,按照规格说明书的规定,成功地运行的概率。

    稳态可用性(Ass):如果在一段时间内,软件系统故障停机时间分别为tdown1t_{down1}tdown2t_{down2},…,正常运行时间分别为tup1t_{up1}tup2t_{up2},…,则系统的稳态可用性为:

    Ass=TupTup+TdownAss=\frac{T_{up}}{T_{up}+T_{down}}

    其中Tup=tupiT_up=\sum t_{upi}Tdown=tdowniT_down=\sum t_{downi}

    平均维修时间(MTTR):是修复一个故障平均需要用的时间,它取决于维护人员的技术水平和对系统的熟悉程度,也和系统的可维护性有重要关系。

    平均无故障时间(MTTF):是系统按规格说明书规定成功地运行的平均时间,它主要取决于系统中潜伏的错误的数目,因此和测试的关系十分密切。稳态可用性也可以表示为:

    Ass=MTTFMTTF+MTTRAss=\frac{MTTF}{MTTF+MTTR}

    8.2. 估算平均无故障时间的方法

    1、相关量的符号
    ETET——测试之前程序中错误总数;
    ITIT——程序长度(机器指令总数);
    τ\tau——测试(包括调试)时间;
    Ed(τ)E_d(\tau)——在00τ\tau期间发现的错误数;
    Ec(τ)E_c(\tau)——在00τ\tau期间改正的错误数。

    2、基本假定
    在类似的程序中,单位长度里的错误数ETIT\frac{ET}{IT}近似为常数。通常:0.5×102ETIT2×1020.5×10^{-2} \leqslant \frac{ET}{IT} \leqslant 2×10^{-2}

    失效率正比于软件中剩余的错误数,而平均无故障时间MTTF与剩余的错误数成反比。

    假设发现的每一个错误都立即正确地改正了,则Ed(τ)Ec(τ)E_d(\tau)=E_c(\tau),剩余的错误数为Er(τ)ETEc(τ)E_r(\tau)=ET-E_c(\tau),单位长度程序中剩余的错误数为:er(τ)ETITEc(τ)ITer(\tau)=\frac{ET}{IT}-\frac{E_c(\tau)}{IT}

    3、估算平均无故障时间
    经验表明,平均无故障时间与单位长度程序中剩余的错误数成反比,即:MTTF1K(ETITEc(τ)IT)MTTF=\frac{1}{K(\frac{ET}{IT}-\frac{E_c(\tau)}{IT})}其中K为常数,典型值是200。

    估算平均无故障时间的公式,可以评价软件测试的进展情况,其公式为EcETITK×MTTFEc=ET-\frac{IT}{K×MTTF}

    因此,也可以根据对软件平均无故障时间的要求,估计需要改正多少个错误之后,测试工作才能结束。

    4、估计错误总数的方法
    程序中的错误总数ETET与程序规模、类型、开发环境、开发方法论、开发人员的技术水平和管理水平等都有密切关系。

    估计ET的两个方法:

    1. 植入错误法
      在测试之前由专人在程序中随机地植入一些错误。测试之后,根据测试小组发现的错误中原有的和植入的两种错误的比例,来估计程序中原有错误的总数ETET
      假设人为地植入的错误数为NsN_s,经过一段时间的测试之后发现nsn_s个植入的错误,此外还发现了nn个原有的错误。如果可以认为测试方案发现植入错误和发现原有错误的能力相同,则能够估计出程序中原有错误的总数为:N=n/ns×NsN=n/n_s×N_s
      在这里插入图片描述
    2. 分别测试法
      植入错误法的基本假定是所用的测试方案发现植入错误和发现原有错误的概率相同,这个基本假定可能有时和事实不完全一致。如果有办法随机地把程序中一部分原有的错误加上标记,然后根据测试过程中发现的有标记错误和无标记错误的比例,估计程序中的错误总数,那就可以做分别测试。
      分别测试法使用两个测试员(小组),彼此独立地测试同一个程序的两个副本,把其中一个测试员发现的错误作为有标记的错误。
      τ\tau表示测试时间,设:
      τ=0\tau=0 时错误总数为B0B_0
      τ=τ1\tau=\tau 1时测试员甲发现的错误数为B1B_1,测试员乙发现的错误数为B2B_2,两个测试员发现的相同错误数为bcbc
      如果认为测试员甲发现的错误是有标记的,即程序中有标记的错误总数为B1B_1,则测试员乙发现的B2B_2个错误中有bcbc个是有标记的。假定测试员乙发现有标记错误和发现无标记错误的概率相同,则错误总数为B0=B2bc×B1B_0=\frac{B_2}{bc}×B_1
      在这里插入图片描述
    展开全文
  • 软件工程导论--软件工程概述

    万次阅读 多人点赞 2019-09-26 17:41:23
    1 软件软件危机 1.1 软件的特性 软件是一种逻辑实体,而非具体的物理...  软件产品一般分为两类:通用软件产品(如数据库软件、文字处理软件、绘图软件工程管理工具…)和定制软件产品(如电子设备的控制软...

    1 软件与软件危机

    1.1 软件的特性

    • 软件是一种逻辑实体,而非具体的物理实体;
    • 软件产品的生产主要是研制
    • 软件具有“复杂性”,其开发和运行常受到计算机系统的限制;
    • 软件成本昂贵,其开发方式目前未完全摆脱手工生产方式;
    • 软件不存在磨损和老化问题,但是存在退化问题

      软件产品一般分为两类:通用软件产品(如数据库软件、文字处理软件、绘图软件、工程管理工具…)和定制软件产品(如电子设备的控制软件、特定的业务处理系统、空中交通管制系统…)。

    1.2 软件的发展

    • 程序设计时代:1946~1956年,生产方式为个体手工劳动,使用机器语言和汇编语言,程序难读难修改,可靠性差;
    • 程序系统时代:1956~1968年,生产方式为作坊式的小集团合作生产,使用高级语言,提出了结构化方法,该阶段产生软件危机。
    • 软件工程时代:1968年至今,生产方式为工程化的生产,使用数据库、开发工具、分布式、面向对象技术等来开发软件,开发技术有很大进步,但没有突破性进展,软件价格不断上升,没有完全摆脱软件危机。

    1.3 软件危机
      随着计算机应用的日益普及,软件数量急剧增长,软件产品质量低下,可维护性差,这些问题不断堆积形成日益尖锐的矛盾,这种现象即为软件危机。
      为此,NATO(北约组织)于1967年提出“软件工程”概念,次年于计算机科学国际会议上得到签署,软件工程学由此产生。

    1.软件危机的主要表现

    • 对软件开发成本和进度的估计常常很不准确;
    • 用户对“已完成的”软件系统不满意的现象经常发生;
    • 软件产品的质量往往靠不住;
    • 软件常常是不可维护的;
    • 软件通常没有对应的文档资料;
    • 软件成本在计算机系统总成本中所占的比例逐年上升;
    • 软件开发生产率提高的速度远远跟不上计算机应用迅速普及及深入的趋势。

    2.产生软件危机的原因

    • 软件是计算机的逻辑部件而不是物理部件。软件问题是在开发时期引入的而在测试阶段没能测出来的故障,修改软件故障要修改软件原来的设计。
    • 软件不同于一般程序,它的一个显著特点是规模庞大,而且程序复杂性将随着程序规模的增加而呈指数上升。为了在预定时间内开发出规模庞大的软件,必须由许多人分工合作,软件开发工作量随软件规模增大非线性增长。
    • 与早期软件开发个体化特点有关:认为软件开发就是写程序并设法使之运行,轻视需求分析和软件维护。也就是说是和软件开发和维护有关的许多错误认识和作法的形成,可以归因于在计算机系统发展的早期阶段软件开发的个体化特点。
    • 缺乏正确的理论指导。缺乏有力的方法学和工具方面的支持。由于软件开发不同于大多数其他工业产品,其开发过程是复杂的逻辑思维过程,其产品极大程度地依赖于开发人员高度的智力投入。由于过分地依靠程序设计人员在软件开发过程中的技巧和创造性,加剧软件开发产品的个性化,也是发生软件开发危机的一个重要原因。

    3.缓解软件危机的途径

    • 方法:推广使用在实践中总结出来的开发软件的成功的技术和方法;
    • 工具:开发和使用好的软件工具;
    • 组织管理:组织良好、管理严密、各类人员协同配合。

    2 软件工程

    2.1 软件工程的概念

      软件工程是一类工程,是将理论与知识应用于实践的科学,它借鉴了传统工程的原则与方法以求高效的开发高质量的软件。

    2.2 软件工程框架

      软件工程的框架可概括为:目标、过程、原则。

    • 目标:生产具有正确性、可用性以及开销合宜的产品;
    • 过程:生产一个最终可以满足需求且达到工程目标的软件产品所需要的步骤,包括开发过程、运作i过程、维护过程;
    • 原则:选取适宜的开发范型、采用合适的设计方法、提供高质量的工程支持、重视开发过程的管理。

    2.3 软件生命周期

      软件生命周期(Software Life Cycle,SLC)是指软件产生直到报废的生命周期,包括可行性分析和项目开发计划、需求分析、概要设计、详细设计、编码、测试、维护等阶段。

    • 可行性分析和项目开发计划:该阶段回答的问题是要解决什么问题?需要多少费用?需要多长时间?
    • 需求分析:确定软件系统必须具备的功能;
    • 概要设计:开发人员把确定的个项功能需求转换成需要的体系结构,即设计软件的结构;
    • 详细设计:为每个模块的功能进行具体描述,即模块的控制结构是怎样的;
    • 编码:把每个模块的控制结构转换成程序代码;
    • 测试:保证软件质量的重要手段,设计测试用例以检验软件的组成;
    • 维护:已交付的软件投入正式使用后,为了改正软件运行错误,或者为了满足用户新的需求而加入新功能的修改软件的过程。

    3 软件过程模型

    3.1 瀑布模型
      该模型规定了各项关键的软件工程活动,自上而下,如同瀑布一样固定次序。

    1.特点
      瀑布模型是以文档形式驱动的,是一种整体开发模型,逆转性很差或着说不可逆转。

    2.适用条件

    • 开发期间需求没有或者很少变化;
    • 分析设计人员对应用领域很熟悉;
    • 低风险项目;
    • 用户使用环境很稳定;
    • 用户提出需求以外,很少参与开发工作。

    3.优点

    • 每个阶段的任务与目标很明确;
    • 可为每个阶段指定开发计划,进行成本预算,组织开发力量了;
    • 通过阶段评审,将开发过程纳入正确轨道;
    • 严格的计划性保证软件产品按时交付。

    4.缺点

    • 缺乏灵活性,无法适应用户需求的改变;
    • 开始阶段的小错误被逐渐放大,可能导致软件产品报废;
    • 返回上一级的开发需要十分高昂的代价;
    • 随着软件规模和复杂性的增加,软件成品成功的概率大幅下降。

    3.2 快速原型模型

      借助软件开发工具或环境尽快的构造一个实际系统的简化模型。

    1.特点

    • 利用原型法技术能够快速实现系统的初步模型,以便准确的获取用户的需求;
    • 采用逐步求精方法使原型逐步完善。

    2.适用条件

    • 不能预先确切定义需求的软件开发;
    • 项目组成员不能很好协同配合,相互交流或通信上存在困难;
    • 已有产品或产品的原型,只需客户化的工程项目;
    • 项目所在领域是那些简单而熟悉的行业;
    • 要求进行产品移植或升级的软件项目。

    3.优点

    • 开发者与用户充分交流,可以澄清模糊需求;
    • 开发过程与用户培训过程同步;
    • 为用户需求的改变提供了充分的余地;
    • 开发风险低,产品柔性好;
    • 开发费用低,时间短;
    • 系统易维护,对用户友好。

    4.缺点

    • 开发者在不熟悉的领域中不易分清主次,原型不切题;
    • 限制了开发人员的创新;

    3.3 增量模型

      也称为渐增模型,是遵循递增方式来进行软件开发的。在该模型中,软件产品被作为一组增量构件(模块),其中第一个增量构件往往实现软件的基本需求,提供最核心的功能。

    1.特点

    • 任务或功能模块驱动,可以分阶段提交产品;
    • 开发过程中有多个任务单,多个任务单的集合构成项目的《需求规格说明书》。

    2.适用条件

    • 客户能够接收分阶段交付;
    • 项目为中等或高风险项目;
    • 用户可参与到整个软件开发过程中;
    • 开发需要使用面向对象语言或第四代语言;
    • 软件开发组织拥有较好的类库,构件库。

    3.优点

    • 短时间内向用户交付可完成部分工作的产品;
    • 逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品;
    • 项目总体性失败的风险比较低。

    4.缺点

    • 分析设计人员若对应用领域不熟悉,难以一步到位;
    • 软件系统的组装和拆卸行不强。

    3.4 螺旋模型

      该模型综合了瀑布模型和快速原型模型的优点,还增加了两者都忽视的风险分析,把开发活动和风险管理结合起来,将风险减到最小并控制风险。

    1.特点

    • 每一圈是一个阶段;
    • 每一个阶段又有一个活动;
    • 降低了开发的风险。

    2.适用

    • 内部开发的大规模软件项目。

    3.优点:风险驱动
    4.缺点:只能用于大型内部软件产品,开发者必须精通风险分析和风险排除。

    展开全文
  • 一种系统软件开发方法,包括: 结构分析方法——需求 结构设计方法——设计 结构程序设计方法——coding 一、 结构分析方法 目的是为了给出问题的模型。 1.1基本术语 一个抽象层是由一组确定的术语...

    首先回顾一下软件开发方法学在整个软件开发过程中的位置:
    在这里插入图片描述

    结构化方法

    一种系统化的软件开发方法,包括:

    • 结构化分析方法——需求
    • 结构化设计方法——设计
    • 结构化程序设计方法——coding

    一、 结构化分析方法

    目的是为了给出问题的模型。
    在这里插入图片描述

    1.1基本术语

    一个抽象层是由一组确定的术语定义的,为支持需求分析中有关要使用的那些信息的表达,结构化分析方法给出了以下五个术语/符号:
    在这里插入图片描述

    1.2 模型表达工具

    (a)数据流图(DFD图)——表达系统功能模型的工具
    是一种描述数据变换的图形工具,它包含的元素可以是数据流、数据存储、加工、数据源和数据潭等。
    在这里插入图片描述

    (b)数据字典——定义数据流和数据存储
    用于定义数据流和数据存储的结构,并给出构成所给出的数据流和数据存储的各数据项的基本数据类型。

    引入:一些逻辑操作符——用于定义数据结构
    在这里插入图片描述

    (c)判定表或判定树等——定义加工小说明
    描述加工“做什么”,即加工逻辑,也包括其它一些与加工有关的信息,如执行条件、优先级、执行频率、出错处理等。

    如判定表,判定树,结构化自然语言。

    1.3结构化分析过程

    ①建立系统的功能模型
    使用的工具为数据流图DFD
    首先:建立系统环境图(顶层数据流图),确定系统边界。
    继之:自顶向下,逐步求精,建立系统的层次数据流图。

    ②建立数据字典
    使用的工具为结构符:+、I、{}等
    定义数据流定义数据存储
    定义数据项

    ③给出加工小说明:集中描述一个加工“做什么”,即加工逻辑,也包括其它一些与加工有关的信息,如执行条件、优先级、执行频率、出错处理等。

    1.4 案例

    建立一个简化的商业自动化系统,其中:

    营业员通过该系统记录每日销售的商品(商品名,商品编号,单价,数量,销售时间);

    收款员通过该系统记录收到的现金数额以及购物余额;

    商店经理每日统计销售额,并在必要时查看某种商品的销售情况(商品名,商品编码,金额)。

    ①建立系统的功能模型首先:建立系统环境图,确定系统边界

    在这里插入图片描述
    其中:
    1数据流为:销售的商品,日销售额等3个输入流,3个输出流
    数据源为:营业员,经理,收款员
    数据潭为:经理,收款员
    2加工名为:要建立的系统名字立的系统名字

    继之:自顶向下,逐层分解
    A、按人或部门的功能要求,将加工“打碎”(将“父图”的每一加工按其功能分解为若干子加工),形成:
    在这里插入图片描述

    B、“分派”数据流(将“父图”的输入流和输出流“分派”到子加工),形成:
    在这里插入图片描述

    C、引入文件,使之形成一个有机整体一系统(在各加工之间建立合理的关系):
    在这里插入图片描述

    继续A、B、C:自顶向下,逐层分解。继续细化。

    ②建立数据字典

    在这里插入图片描述
    数据字典:
    1、数据流:
    销售的商品=商品名+商品编号+单价+数量+销售时间
    现金额=余额=日销售额=非负实数
    查询要求=[商品编号旧期]
    查询要求1=商品编号
    查询要求2=日期
    销售情况=商品名+商品编号+金额
    2、数据存贮:
    销售文件={销售的商品}
    3、数据项(数据流及数据存储的组成成分)
    给出所有数据项的数据结构类型定义

    ③给出加工小说明

    描述一个加工,一般遵循如下模版:
    加工编号:给出加工编号
    加工名:给出该加工的标识
    输入流:给出该加工的所有输入数据流输出流:给出该加工的所有输出数据流加工逻辑:采用结构化自然语言或判定表或判定树等工具,给出该加工输入数据和输出数据之间的关系

    注意:
    结构化分析方法是一种半形式化的规约方法,给出了一组特定的术语表和标准化的表达格式-数据流图,在表达上均必须遵循一些约定,即应以一种准确和一致方式使用之。

    展开全文
  • 软件工程导论

    千次阅读 热门讨论 2020-11-08 17:20:10
    软件工程(Software Engineering),是应用计算机科学理论和技术以及工程管理原则和方法,按预算和进度实现满足用户需求的软件产品的工程,或以此为研究对象的学科。
  • 软件工程概述

    千次阅读 2019-11-13 09:22:08
    软件工程是针对软件这一具有特殊性质的产品的工程化方法,它涵盖了软件生存周期的所有阶段,它是一门用工程学的知识来指导软件开发、维护的一门学科。 IEEE对软件工程的定义是对软件开发、实施、维护的系统化、规范...
  • IT项目工程化

    万次阅读 2019-07-17 21:55:05
    JS项目工程化: 版本控制 自动化持续继承,继续交付(CI / CD) 代码质量控制(QA) 工具 模块化 文档 demo 编译过程: 自动化处理每次push,tag,release的任务队列 安装: 安装npm命令行工具 安全审计:npm audit...
  • 软件工程标准与文档

    千次阅读 2012-11-26 21:29:29
    什么事都有一套标准,当然做系统共也不例外,那么软件工程的标准又是什么呢? 总结构图: 软件工程标准: ISO9000系列标准及软件质量认证: 软件文档: 软件文档有这么多,我们一个都不能...
  • 一、信息系统软件实施工程师概述 软件实施工程师是软件服务的重要环节,承担着软件交付的重任。工作能力常规上至少包含以下几项:软件安装调试,部分硬件服务器的调试;客户培训;编制验收过程文档;把控项目...
  • 什么是前端工程化

    万次阅读 多人点赞 2019-06-28 11:38:18
    前端越来越复杂,前端面试的要求也越来越高。如何提升前端开发水平?如何应对前端面试?我在日常工作中前端的开发框架以 ...对前端的要求相比几年前已经从单纯的 JavaScript、CSS 问题变成了更多以工程化为主的问题。
  • 工程化的思想

    千次阅读 热门讨论 2014-11-22 17:42:22
    工程化的思想 工程这一词:  最先了解“工程”这一词是从建设、建筑方面有所听闻,建筑工程、项目工程,水利工程、化学工程、土木工程、生物工程等的,之后接触了“软件工程”——是自己详细的学习和了解的一个...
  • 软件工程-软件工程基本概念

    千次阅读 2018-10-16 22:38:30
    软件工程的概念、基本原理、方法学; 软件生命周期,主要软件过程的特点。 一、软件危机的定义:软件开发和维护过程中所遇到的一系列严重问题; 二、软件危机产生原因:用户需求不明确、缺乏科学理论作为指导、...
  • 软件工程—结构分析设计

    千次阅读 2013-10-06 23:44:50
    软件工程—结构分析设计
  • 软件工程名词解释

    万次阅读 2019-11-06 16:01:00
     软件工程是研究和应用如何以系统化的、规范的、可度量的方法去开发、运行和维护软件,即把工程化应用到软件上。 软件生存周期  软件生存周期是指软件产品从考虑其概念开始到该软件产品交付使用,直至最终退...
  • 前端工程化、模块化、组件化

    千次阅读 多人点赞 2019-04-28 12:31:53
    工程化     前端工程化是一种高层次思想而不是某种技术,所谓前端工程化就是将前端项目当成一项系统工程进行分析、组织和构建从而达到项目结构清晰、分工明确、团队配合默契、开发效率提高的目的。而模块化和...
  • 软件工程软件工程管理

    千次阅读 热门讨论 2014-01-07 16:56:43
    那么我们的软件工程管理又是怎么回事呢?让我们一起来揭晓她的答案,软件工程管理是指对工程建设的过程以及在建设过程中涉及的人、财、物、时间的综合管理。我们从两个方面来认识一下软件工程管理:首先,从过程来看...
  • 工程化软件项目开发的流程、步骤 需求分析 (1)相关系统分析员向用户初步了解需求,然后用相关的工具软件列出要开发的系统的大功能模块,每个大功能模块有哪些小功能模块,对于有些需求比较明确相关的界面时,在这...
  • 软件工程专业

    千次阅读 2016-10-04 16:03:34
    软件工程是将工程应用于软件的设计、开发、实施、测试和维护的一种系统方法。 软件工程的典型形式定义是: 1.研究、设计、开发和测试操作系统级软件、编译器和网络分发软件,用于医疗、工业、军事、通信、...
  • 软件工程】什么是软件工程

    千次阅读 热门讨论 2018-02-28 23:11:20
    软件工程的视频看了一半了,看的也是一头雾水,看视频的时候我就在想软件工程究竟是什么,它是干什么的,有什么用呢?如果这个不了解清楚,我感觉我视频看了也是白看。就按照我这不将就的小脾气,我就要整明白这是个...
  • 前端工程化的理解

    千次阅读 2021-02-02 20:28:11
    很久没写过博客沉淀下,最近看了几篇前端工程化的文章,结合自己实践所学,阐述下什么是前端工程化。 大前端其实分为很多种 移动应用开发的前端 web前端 本篇主要是说下web前端的工程化 什么是前端工程化 在...
  • 软件工程 银行业务管理和现金结算系统 --- 结构设计文档
  • 软件工程面试

    千次阅读 2018-07-05 20:32:57
    一、软件分析:是一个对用户的需求进行去粗取精、去伪存真、正确理解,然后把它用软件工程开发语言表达出来的过程,基本任务是和用户一起确定要解决的问题,建立软件的逻辑模型,编写需求规格说明书文档并最终得到...
  • 1.前端模块: 可以理解为一组自定义业务的抽象封装,是根据项目的情况来进行封装组合到一起的,比如我们可以分为登录模块,评论模块。...概念:指使用软件工程的技术和方法来进行前端项目的开发、维护和管...
  • 软件工程软件工程过程与方法

    万次阅读 2016-06-23 17:29:48
    尽管程序员领着一份不错的薪水,可是他们也同样付出了巨大的精力与时间。随着软件规模的日益庞大,用户...而软件工程正是研究如何以系统性的、规范的 、可定量的过程方法高效开发与管理、维护软件的交叉性学科。
  • 软件工程的定义有很多种说法,这里写出两个在大学软件工程期末考试出简答题给出的定义两者选其一。 一: 软件工程是指导计算机软件开发和维护的工程学科。...软件工程是研究和应用如何以系统性的、规范的、可定...
  • 软件工程(三)—— 结构方法

    千次阅读 2019-03-09 14:37:18
    一、结构需求分析 在软件系统的需求工作中,通常面临三大挑战,即问题空间理解、人与人之间的通信、需求的变化性。为了应对这三大挑战,支持需求工作目标的实现,一种好的需求技术应具有以下基本特征: ①提供...
  • 前端工程化-规范化篇

    万次阅读 2020-08-13 20:24:40
    这一篇文章主要是关于前端规范化的内容,前端规范化是我们践行前端工程化过程中的重要的组成部分 有利于项目维护,以及二次开发,减低维护成本,便于后续人员接手 为什么要有规范化 1、软件开发需要多人协同 2、...
  • 第2章 软件工程与需求工程

    千次阅读 2017-04-23 21:23:29
    第2章 软件工程与需求工程标签: 软件需求工程 《软件需求工程》 毋国庆 第二版 个人笔记 第2章 软件工程与需求工程软件工程 软件开发过程模型 需求工程在软件开发中的地位 软件需求的开发和管理过程1. 软件工程 ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 496,636
精华内容 198,654
关键字:

软件工程化