【软件工程导论】从已考完期末的角度记录软导常考内容_快速原型模型又称为圆形模型是处理单元通过通信和协作能更快的解决大规模的计

软件工程概念

什么是软件工程？它的目标和内容是什么？

软件工程是一种用科学知识和技术原理来定义、开发、维护软件的一门学科。软件工程是一门工程性学科，目的是成功的建造一个大型软件系统，所谓成功是要达到以下几个目标：付出较低的开发成本，达到要求的软件功能；取得较好的软件性能；开发的软件易于移植；需要较低的维护费用；能按时完成开发任务，及时交付使用；开发的软件可靠性高。软件工程研究的主要内容是软件开发技术和软件开发管理两方面，在软件开发技术中，主要研究软件开发方法、软件开发过程、软件开发工具和环境。在软件开发管理中，主要研究软件管理学、软件经济学、软件心理学等。
软件文档的作用是：提高软件开发过程的能见度；提高开发效率；作为开发人员阶段工作成果和结束标志；记录开发过程的有关信息便于使用与维护；提供软件运行、维护和培训有关资料；便于用户了解软件功能、性能。 软件开发项目生存期各阶段应包括得文档以及与各类人员的关系如下：可行性研究报告、项目开发计划、软件需求说明书、数据要求说明书、测试计划、概要设计说明书、详细设计说明书、用户手册、操作手册、测试分析报告、开发进度月报、项目开发总结、程序维护手册（维护修改建议）

软件过程模型（了解）

什么是瀑布模型(又叫作生命周期模型)？

瀑布模型是将软件生存周期的各项活动规定为按固定顺序而连接的若干阶段工作，形如瀑布流水，最终得到软件产品。核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。

增量模型的基本思想是什么？

为了克服瀑布模型的局限性，使开发过程具有一定的灵活性和可修改性，于是产生了增量模型。它是在瀑布模型的基础上加以修改而形成的。增量模型和瀑布模型之间的本质区别是：瀑布模型属于整体开发模型，它规定在开始下一个阶段的工作之前，必须完成前一阶段的所有细节。而增量模型属于非整体开发模型，它推迟某些阶段或所有阶段中的细节，从而较早的产生工作软件。增量模型是在项目的开发过程中以一系列的增量方式开发系统。增量方式包括增量开发和增量提交。增量开发是指在项目开发周期内，以一定的时间间隔开发部分工作软件；增量提交是指在项目开发周期内，以一定的时间间隔增量方式向用户提交工作软件及相应文档。增量开发和增量提交可以同时使用，也可以单独使用。

快速原型模型有几种？

根据原型的不同作用，有三类原型模型：⑴探索型原型。⑵实验型原型。⑶演化型原型。

快速原型模型的主要特点之一是：及早提供工作软件：快速原型技术适用于软件产品要求大量的用户交互、或产生大量的可视输出、或设计一些复杂的算法等场合。基本思路是：先给出一个系统的最初实现，让用户去使用和评价，不断进行细化和改善，经过多次这样的反复过程后形成最终的完善的系统。

一、瀑布模型

1. 特点：
   阶段间具有顺序性和依赖性。其中包含两重含义：①必须等前一阶段的工作完成之后，才能开始后一阶段的工作；②前一阶段的输出文档就是后一阶段的输入文档。

2. 优点：
   ①可强迫开发人员采用规范化的方法。
   ②严格地规定了每个阶段必须提交的文档。
   ③要求每个阶段交出的所有产品都必须是经过验证的。

3. 缺点：
   ①由于瀑布模型几乎完全依赖于书面的规格说明，很可能导致最终开发出的软件产品不能真正满足用户的需要。如果需求规格说明与用户需求之间有差异，就会发生这种情况；
   ②瀑布模型只适用于项目开始时需求已确定的情况。

4. 适用场合：需求明确且很少变更的项目，如二次开发或升级型项目。

二、快速原型模型
1．特点：快速构建可运行的软件模型，以便理解和澄清问题，进一步细化需求，在新获取需求基础上进行系统开发。
2．优点：
(1)有助于满足用户的真实需求；
(2)原型系统已经通过与用户的交互而得到验证，据此产生的规格说明文档能够正确地描述用户需求；
(3)软件产品的开发基本上是按线性顺序进行；
(4)因为规格说明文档正确地描述了用户需求，因此，在开发过程的后续阶段不会因为发现规格说明文档的错误而进行较大的返工；
(5)开发人员通过建立原型系统已经学到了许多东西，因此，在设计和编码阶段发生错误的可能性也比较小，这自然减少了在后续阶段需要改正前面阶段所犯错误的可能性；
(6) 快速原型的突出特点是“快速”。开发人员应该尽可能快地建造出原型系统，以加速软件开发过程，节约软件开发成本。
3．缺点：快速建立的模型加上连续的修改可能造成产品质量低下。
4．适用场合：用户需求模糊不明的情况下。

三、增量模型
1.特点及内容:增量模型也称为渐增模型，是Mills等于1980年提出来的。使用增量模型开发软件时，把软件产品作为一系列的增量构件来设计、编码、集成和测试。每个构件由多个相互作用的模块构成，并且能够完成特定的功能。
2.优点:
(1)能在较短时间内向用户提交可完成一些有用的工作产品，即从第1个构件交付之日起，用户就能做一些有用的工作。
(2)逐步增加产品的功能可以使用户有较充裕的时间学习和适应新产品，从而减少一个全新的软件可能给用户组织带来的冲击。
(3)项目失败的风险较低，虽然在某些增量构件中可能遇到一些问题，但其他增量构件将能够成功地交付给客户。
(4)优先级最高的服务首先交付，然后再将其他增量构件逐次集成进来。因此，最重要的系统服务将接受最多的测试。
3.缺点:
(1)由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。
(2)在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性。
(3)如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析，这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程。
4.使用场合: 需求经常发生改变的软件开发过程
5.针对的应用:
(1)进行已有产品升级或新版本开发，增量模型是非常适合的；
(2)对完成期限严格要求的产品，可以使用增量模型；
(3)对所开发的领域比较熟悉而且已有原型系统，增量模型也是非常适合的。

四、螺旋模型
1.特点：
该模型将瀑布模型与快速原型模型结合起来，并且加入两种模型均忽略了的风险分析。螺旋模型的基本思想是，使用原型及其他方法来尽量降低风险。
2.优点：
对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标。减少了过多测试或测试不足所带来的风险。在螺旋模型中维护只是模型的另一个周期，因而在维护和开发之间并没有本质区别。
3.缺点：
螺旋模型是风险驱动的，因此要求软件开发人员必须具有丰富的风险评估经验和这方面的专门知识，否则将出现真正的风险：当项目实际上正在走向灾难时，开发人员可能还以为一切正常。
4.适用场合：
支持需求不明确、特别是大型软件系统的开发，并支持面向规格说明、面向过程、面向对象等多种软件开发方法，是一种具有广阔前景的模型。
五、喷泉模型
1.特点：
喷泉模型是典型的面向对象生命周期模型。“喷泉”一词体现了迭代和无间隙特性。
2.优点：
可以提升项目开发效率、缩短开发周期，因为喷泉模型各个阶段之间无间隙，没有顺序要求，开发人员可以同步开发;而且开发人员可以在某个开发阶段中随时补充遗漏的开发需求。
3.缺点：
难以管理，因为喷泉模型的各个阶段的开发是重叠的，所以需要大量的开发人员，所以不利于项目管理。
4.适用场合：
用于采用对象技术的软件开发项目。

软件生存周期划分

软件生存周期一般可分为以下几个阶段： 1) 问题定义： 问题定义阶段必须回答的关键问题是“要解决的问题是什么？”，正确理解用户的真正需求。 2) 可行性研究： 这个阶段要回答的关键问题是：对于上一个阶段所确定的问题“有行得通的解决办法吗?” ，可行性研究阶段应该导出系统的高层逻辑模型，准确地估计系统的成本和效益。 3) 需求分析：需求分析阶段的任务，主要是确定目标系统必须具备的功能，得出经用户确认的系统逻辑模型。根据该系统逻辑模型，准确地回答“为了解决这个问题，目标系统必须做什么”。 4) 总体设计：也叫概要设计或初步设计。这个阶段必须回答的是“概括地说，应该如何解决这个问题”。总体设计的目标是将需求分析阶段定义的系统模型转换成相应的软件结构，以规定软件的形态及各成分间的层次关系、界面及接口要求。 5) 详细设计：详细设计阶段的任务是把解法具体化，也就是回答“应该怎样具体地实现这个系统”。详细设计亦即模块设计。它是在算法设计和结构设计的基础上，针对每个模块的功能、接口和算法定义，设计模块内部的算法过程及程序的逻辑结构，并编写模块设计说明。 6) 编码：这个阶段的任务，是根据详细设计的结果，选择一种适合的程序设计语言，把详细设计的结果翻译成程序的源代码。7) 测试：以便尽早发现程序中的错误和缺陷而进行的一个过程，有单元测试、集成测试、确认测试和系统测试4种。 8) 运行与维护：通过各种必要的维护措施支持软件系统能持久地满足用户的需要。维护阶段是软件生存周期中花费精力和费用最多的阶段

可行性研究的任务是什么？

首先需要进行概要的分析研究，初步确定项目的规模和目标，确定项目的约束和限制，把他们清楚地列举出来。然后，分析员进行简要的需求分析，抽象出该项目的逻辑结构，建立逻辑模型。从逻辑模型出发，经过压缩的设计，探索出若干种可供选择的主要解决方法，对每种解决方法都要研究它的可行性，可从以下三个方面分析研究每种解决方法的可行性。㈠技术可行性：对要开发项目的功能、性能、限制条件进行分析，确定在现有的资源条件下，技术风险有多大，项目是否能实现。㈡经济可行性：进行开发成本的估算以及了解取得效益的评估，确定要开发的项目是否值得投资开发。㈢社会可行性：要开发的项目是否存在任何侵犯、妨碍等责任问题，要开发项目的运行方式在用户组织内是否行得通，现有管理制度、人员素质、操作方式是否可行。
技术可行性分析 对系统的简要描述 本系统有利于对学校教职工人员工资的发放和管理。
与现有系统比较的优越性与传统的手工记账方式相比,占据空间小、易于统计工资总额、易于更新、易于数据备份。
处理流程和数据流程

计算机系统的软件要素中的软部件由程序、数据和过程
软件=程序+文档

需求分析阶段的基本任务是什么？

需求分析阶段的基本任务是要准确的定义新系统的目标，为了满足用户需要，回答系统必须“做什么”的问题。本阶段要进行以下几方面的工作：㈠问题识别。双方确定对问题的综合需求，这些需求包括：功能需求、性能需求、环境需求、用户界面需求，另外还有可靠性、安全性、保密性、可移植性、可维护性等方面的需求。㈡分析与综合,导出软件的逻辑模型。分析人员对获取的需求，进行一致性的分析检查，在分析、综合中逐步细化软件功能，划分成各个子功能。这里也包括对数据域进行分解，并分配到各个子功能上，以确定系统的构成及主要成份，并用图文结合的形式，建立起新系统的逻辑模型。㈢编写文档。编写“需求规格说明书”、编写初步用户使用手册、编写确认测试计划、修改完善软件开发计划

软件需求工程的基本任务是准确地回答“软件系统必须做什么？”这个问题。它在系统工程和软件设计之间起到桥梁的作用。用户对软件需求的描述不精确，导致软件危机。为了使用户需求逐步精细化，使用需求工程中需求建模技术。需求规格说明书在软件开发中具有重要的作用，它也可以作为软件可行性分析的依据。
需求建模的定义：用户需求逐步精细化、完全化、一致化，需求规格说明是软件工程测试的依据

数据流图

某工厂的采购部每天需要一张订货报表，报表按零件编号排序，表中列出所有需要再次订货的零件。对于每个需要再次订货的零件，应该列出下述数据：零件编号，零件名称，订货数量，目前价格，主要供应者，次要供应者。零件入库或出库称为事务，通过存放在库房的CRT终端把事务报告给定货系统。当零件库存量少于库存量临界值，决定再次订货，画出订货系统的数据流图。

问题分析：源点/终点,处理,数据存储,数据流

1）源点/终点：系统之外的实体(人,物,系统)

源点：仓库管理员

终点：采购员

2）处理：

需要报表－>产生报表

处理日常事务－>事务处理

3）数据存储：

订货信息

库存清单

4）数据流：

订货报表：零件编号、名称、数量……

事务：零件编号、事务类型、数量……

Step1：顶层数据流图——系统级

构成：基本系统模型＋源点＋终点

一般采用自顶向下逐步细化的分层绘制方法

Step2：进一步分解——功能级

Step3：进一步分解——功能级

非功能需求则是对功能需求的补充，包括了对系统的各种限制和用户对系统的质量要求。
需求分析常用的分析方法有：

1基于瀑布模型的结构化方法，结构化分析方法的分析策略是：自顶向下，逐层分解
2基于需求动态定义就的原型化方法
3基于对象的面向对象的方法：UML是软件开发中的一个重要工具
4基于数据的数据流开发方法
5面向数据结构设计Jackson方法给出三种结构是. 顺序结构，选择结构，重复结构
面向对象的需求分析
1 Booch方法
2 Rumbaugh方法
3 Coad和Yourdon方法
4 Jacobson方法
5 Wirfs―Brock方法
6 UML的OOA方法(现在主流技术基本都使用UML来建模，其他很少使用)

软件设计：
传统的结构化方法将软件设计划分为体系结构设计、数据设计、接口设计及过程设计四部分；
结构化分析特点：自顶向下，逐步求精
面向对象方法则将软件设计划分为体系结构设计、类设计∕数据设计、接口设计、构件级设计四部分。

创建良好设计的原则

1设计应遵循抽象化的原则，包含数据抽象和过程抽象
2设计应当遵循模块化的原则。
3设计应遵循信息隐蔽的原则。
4模块独立性
5 高内聚，低耦合

内聚与耦合的种类

内聚性：内聚是一个模块内部各个元素彼此结合的紧密程度的度量。

(1) 功能内聚
一个模块中各个部分都是为了完成一项具体功能而协同工作，紧密联系，不可分割的。这种模块就是功能内聚模块。功能内聚模块的模块独立性最强。
(2) 层内聚
相关服务放在一起，并有严格的层次结构，高层服务可访问低层服务，反之不可。如分层结构。
(3) 通信内聚
访问或操作同一数据的过程放在一个类中，这些过程可以互相通信。如某个类设计。
(4) 顺序内聚：存在一系列过程，其中一个过程向另一个过程提供输入，这些过程放在一起，形成顺序内聚。如面向对象系统中的消息序列。
(5) 过程内聚：几个一次调用的操作放在一个模块中，它们是相关的且必须以特定次序执行，则称这个模块为过程内聚模块。但在这种模块内，一个操作的输出不一定是下一个操作的输入。如调用结构。
(6) 时间内聚：程序执行过程中同一阶段内完成的操作放在一起，达到时间内聚。
(7) 实用程序内聚：逻辑上不能纳入其他内聚类型的相关实用程序放在一起，形成实用程序内聚。如可复用的过程或类。

耦合性: 耦合是模块间互相连接的紧密程度的度量，它取决于各个模块之间接口的复杂度、调用方式以及哪些信息通过接口。
模块之间的耦合性越高，其模块独立性就越弱。模块的内聚性越高，它与其他模块之间的耦合性就会降低，而模块独立性就越强。

(1) 内容耦合
如果发生下列情形，模块间就是内容耦合:
一个模块直接访问另一个模块的内部数据;
(2) 公共耦合
若一组模块都访问同一个公共数据环境，则它们之间的耦合就是公共耦合。公共数据环境可以是全局变量、全局数据结构、共享的通信区、内存的公共覆盖区等。
(3) 控制耦合
一个过程通过标志、开关或命令显式地控制另一个过程
的动作，就产生控制耦合。
(4) 标记耦合
如果一组模块通过参数表传递结构或对象（注意，不是简单变量或结构中的某一分量），就是标记耦合。
(5) 数据耦合
如果模块之间的访问是通过数据参数（不是控制参数、结构或对象参数、公共数据结构）来交换输入、输出信息的，则称这种耦合为数据耦合。
(6) 例程调用耦合
一个程序（或对象的操作）调用另一个程序（或另一个对象的操作），就产生例程调用耦合。
(7) 类型使用耦合
类将实例变量或本地变量声明为另一个类的实例，就产生类型（嵌套）耦合。
(8) 包含/引入耦合
一个构件引入（import）一个包时就产生引入耦合，一个构件包含（include）另一个构件时，就产生包含耦合。
(9) 外部耦合
模块对外部系统，如操作系统、共享库或硬件有依赖关系时就产生外部耦合。可通过信息隐蔽减少这种依赖关系。

UML中的主要图及其作用

（1）用例图：描述的是参与者（Actor）所理解的系统功能，用于需求分析阶段，列出系统中的用例和参与者，并显示哪个参与者参与了哪个用例的执行 。
（2）状态机图：通过对类对象的生存周期建立模型来描述对象随时间变化的动态行为，也可以用来描述用例、协作和方法的动态行为，它是展示状态与状态转换的图。
状态机是一个类的对象所有可能的生命历程的模型。状态机包括状态图和活动图两种表示方法。
活动图：用于描述满足用例要求所要进行的活动以及活动间的约束关系，有利于识别并行活动和工作流程情况。 活动图实际上是用来为用例的事件流建模的工具。展示的主要内容是对象的活动状态。
状态图：用于对系统的动态方面建模。
（3）类图：是逻辑视图的重要组成部分，用于对系统的静态结构建模，涉及到具体的实现细节。在系统分析阶段，类图主要用于显示角色和提供系统行为的实体的职责；在系统设计阶段，类图主要用于捕捉组成系统体系结构的类结构；在系统编码阶段，根据类图中的类及它们之间的关系实现系统的功能。
关联关系：如果A类中成员变量是用B类声明的对象，那么A和B的关系是关联关系
依赖关系： 如果A类中某个方法的参数是用B类声明的对象或某个方法返回的数据类型是B类对象，那么A和B的关系是依赖关系
泛化（继承）关系：如果一个类是另一个类的子类，那么二者之间是泛化（继承）关系
实现关系：是指一个class实现interface接口
聚合关系：表示类的对象之间是整体和部分之间的关系
组合关系：表示类的对象之间整体拥有部分，部分与整体共存之间的关系。整体不存在，部分随之消失。

（4）交互图：可以用于对一个用例的事件流程进行建模，也可以单独使用，用于可视化、详述、构造和文档化一个特定对象群体的动态方面。交互图显示一个交互，由一组对象和它们之间的关系构成，其中包括：需要什么对象、对象相互发送什么消息、什么角色启动消息以及消息按什么顺序发送。
交互图分为两种：顺序图和协作图；顺序图强调消息发送的时间顺序，协作图则强调接收和发送消息的对象的组织结构。

（5）构件图：提供当前模型的物理视图，对系统的静态实现视图建模。构件图显示一个系统物理设计
时，构件所映射的类和对象的配置。构件图主要包含以下几种内容：构件、接口、依赖关系以及构件包。
（6）部署图：对面向对象系统的物理方面建模,描述系统运行时节点、构件实例及其对象的配置。节点是各种计算资源的通用名称，包括处理器和设备两种类型，两者的区别是处理器能够执行程序的硬件构件（如计算机主机），而设备是一种不具备计算能力的硬件构件（如打印机）。

MVC模式

MVC模式，即模型—视图—控制器（Model-View-Controller）模式，分别对应于内部数据、数据表示和输入/输出控制部分，把它们分开设计，其过程是：首先控制器接收用户的请求，并决定调用哪个模型处理；然后模型用业务逻辑来响应用户的请求并返回数据；最后控制器用视图表示模型返回的数据呈现给用户。模型侧重数据和功能，视图侧重数据显示，控制器侧重用户输入，其优点是把数据和业务规则分开表示。

1.     模型对象
   1

模型对象是应用程序中用于处理应用程序数据逻辑的部分，模型对象的变化通过事件处理通知视图和控制器对象。
2) 视图对象
视图对象代表GUI对象，并且以用户需要的格式表示模型状态，是交互系统与外界的接口。视图对象可以包含子视图，子视图用于显示模型的不同部分。通常，每个视图对象对应一个控制器对象。
3) 控制器对象
控制器对象代表事件，处理用户的输入行为，给模型发送业务事件，将其解析为模型执行的动作，同时，模型的更新与修改经由控制器通知视图，实现各视图与模型一致。

MVVM模式

MVVM模式
MVVM模式改进了MVC模式，更好分离视图和模型。
1) MVVM的组成结构。
a) 模型层（Model）：指数据模型，或指代表内容的数据访问层，在前后端分离的架构中，可以理解为后端往前端传递的数据。
b) 视图层（View）：指用户界面。
c) 视图模型层（ViewModel）：该层主要负责Model层与View层的通信以及数据与视图的绑定。将数据封装并传递至视图层，将视图的行为与状态的变换传递到Model层。
2) MVVM与前后端分离开发。
前后端分离的信息系统设计与实现（基于MVVM的设计模式）

1. MVVM的组成结构。
   a) 模型层（Model）：指数据模型，或指代表内容的数据访问层，在前后端分离的架构中，可以理解为后端往前端传递的数据。
   b) 视图层（View）：指用户界面。
   c) 视图模型层（ViewModel）：该层主要负责Model层与View层的通信以及数据与视图的绑定。将数据封装并传递至视图层，将视图的行为与状态的变换传递到Model层。
   该模式能够实现高内聚低耦合

面向对象模型主要由以下哪些模型组成

1 对象模型 描述对象、类、层次和关系，静态结构，其作用是描述系统的静态结构，包括构成系统的类和对象，它们的属性和操作，以及它们之间 的联系。 – 对象模型包括类图
2 动态模型 其作用是描述系统的控制逻辑，主要涉及系统中各个类和对象的时序及变化情况。时序图等
3 功能模型 ：描述系统的功能 表示方法：数据流图，用例图

概要设计阶段的基本任务是什么？

⑴设计软件系统结构（简称软件结构），具体为：①采用某种设计方法，将一个复杂的系统按功能划分成模块。②确定每个模块的功能。③确定模块之间的调用关系。④确定模块之间的接口，即模块之间传递的信息。⑤评价模块结构的质量。⑵数据结构及数据库设计，汉数据结构的设计及数据库的设计。⑶编写概要设计文档。主要有：概要设计说明书；数据库设计说明书；用户手册；修订测试计划。⑷评审。

详细设计的基本任务是什么？有哪几种描述方法？

详细设计是软件设计的第二阶段，其基本任务有：为每个模块进行详细的算法设计；为模块内的数据结构进行设计；对数据库进行物理设计，即确定数据库的物理结构；其它设计，根据软件系统类型，还可能要进行代码设计、输入/输出格式设计、人机对话设计；编写详细设计说明书；评审。详细描述处理过程常用三种工具：图形、表格和语言。如结构化程序流程图、盒图和问题分析图。IPO图也是详细设计的主要工具之一。表格工具如判定表可作为详细设计中描述逻辑条件复杂的算法。过程设计语言（PDL）是一种用于描述模块算法设计和处理细节的语言工具。

过程设计（详细设计）

在过程设计阶段，要决定各个模块的实现算法，并精确地表达这些算法。
对每个模块规定的功能以及算法的设计，给出适当的算法描述：
图形工具：程序流程图， N-S ，PAD， HIPO
表格工具：判定表
语言工具： PDL ， HIPO

黑盒测试

黑盒测试把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下、注重于测试软件的功能性要求，测试者在程序接口处进行测试，只检查程序功能是否按照规格说明书的规定正常使用，程序是否能接收输入数据而产生正确的输出信息，并且保持数据库和文件的完整性

采用黑盒技术（功能测试）设计测试用例的方法及各自的特点。

㈠等价类划分。等价类划分是将输入数据域按有效的或无效的（也称合理的或不合理的）划分成若干个等价类，测试每个等价类的代表值就等于对该类其它值的测试。
㈡边界值分析。该方法是将测试边界情况作为重点目标，选取正好等于，刚刚大于或刚刚小于边界值的情况，根据这些情况选择测试用例。
㈢错误推测。错误推测法没有确定的步骤，凭检验进行。它的基本思想是列出程序中可能发生错误的情况，根据这些情况选择测试用例。
㈣因果图。因果图能有效的检测输入条件的各种组合可能会引起的错误。因果图的基本原理是通过画因果图，把用自然语言描述的功能说明转换为判定表，最后为判定表的每一列设计一个测试用例。

软件测试步骤，这些步骤的测试对象

（1）单元测试：单元测试主要是将程序划分成各个小的单元，测试人员将注意力都放在这些小的单元上。模块测试的目的是：将单元模块的功能与定义单元模块的功能规格说明或者接口规格说明进行比较，找出程序中的错误。测试对象对单元模块
**（2）集成测试：**集成测试其实就是单元测试中的增量测试。在我的上一篇文章中有讲到。将各个小的单元以一定的序列慢慢集成为完整的程序。测试对象为组装后的程序模块
**（3）系统测试：**系统测试的目的是：将程序与其初始目标进行比较，去发现程序与其初始目标不一致的地方。测试对象为可运行的目标软件系统的整体功能
**（4）验收测试：**验收测试是将程序与其最初的需求及最终用户当前的需要进行比较的过程。测试对象产品是否满足规范要求是用户的要求（合同规定的所有功能和性能,人机界面等

白盒测试

白盒测试又称结构测试或逻辑驱动测试，指通过对程序内部结构的分析、检测来寻找问题。白盒测试把程序看成装在一个透明的白盒子里，也就是清楚了解程序结构和处理过程，检查是否所有的结构及路径都是正确的，检查软件的内部动作是否按照设计说明的规定正常进行。

白盒测试法的逻辑覆盖标准

1.语句覆盖每条语句至少执行一次。
2.判定覆盖每个判定的每个分支至少执行一次。
3.条件覆盖每个判定的每个条件应取到各种可能的值。
4.判定/条件覆盖同时满足判定覆盖条件覆盖。
5.条件组合覆盖每个判定中各条件的每一种组合至少出现一次。
6.路径覆盖使程序中每一条可能的路径至少执行一次。

软件维护的特点是什么？

主要体现在三个方面：<1>非结构化维护和结构化维护。软件的开发过程对软件的维护有很大的影响。若不采用软件工程的方法开发软件，则软件只有程序而无文档，维护工作非常困难，这是一种非结构化的维护。若采用软件工程的方法开发软件，则各阶段都有相应的文档，容易进行维护工作，这是一种结构化的维护。<2>维护的困难性。软件维护的困难性是由于软件需求分析和开发方法的缺陷。软件生存周期中的开发阶段没有严格而有科学的管理和规划，就会引起软件运行时的维护困难。<3>软件维护的费用。软件维护的费用在总费用中的比重是在不断增加的，这是软件维护有形的代价。另外还有无形的代价，即要占用更多的资源。软件维护费用增加的主要原因是软件维护的生产率非常低。