软件工程的主要知识领域

软件工程是一种工程形式，它运用计算机科学和数学原理，针对软件问题获得一种经济有效的解决方案。

b.用系统的、规范的、可度量的方法，开发、运行和维护软件。

2.软件工程的目标是高质量和高生产力。

3.五种软件生存期模型：

(1)、瀑布模型：

包括问题定义、可行性研究、需求分析、概要设计、详细设计、编码、测试和维护。

优点：

a.提供了一个模板，模板使得分析、设计、编码、测试和维护的方法可以在该模板下有一个共同的指导。

b.虽然有不少缺点，但比在软件开发中随意的状态要好得多。

缺点：

a.实际的大项目难以按照该模型给出的顺序进行，而且这种模型的迭代是间接的，容易由微小的变化造成大的混乱。

b.在通常情况下，用户难以表达真正的需求，而这种模型却要如此，这种模型不欢迎有二义性的问题存在的。

c.用户要等到开发周期晚期才能看到程序运行的测试版本，而在这时若发现大的错误，可能引起用户的恐慌，

而后果也是灾难性的。

d.采用这种线性模型，经常在过程的开始和结束时，要等到其他成员完成后，才能进行下去，有可能花在等待的时间

比开发的时间要长，即为堵塞状态。

(2)、增量模型：

优点：

a.人员分配灵活，刚开始不用投入大量的人力资源，当核心产品很受欢迎时，可增加人力实现下一个增量。

b.当配备的人员不能在设定限期内完成产品时，它提供了一种先推出核心产品的途径，这样就可以先发布部分功能

给用户对用户起到镇静剂的作用。

c.具有一定的市场。

缺点：

a.自始至终开发者和用户纠缠在一起，直到完全版本出来。

(3)、螺旋模型：

优点：

对于大型系统及软件的开发，这种模型是一种很好的方法。开发者和客户能够较好地对待和理解每一个演化级别上的风险。

缺点：

a.需要相当的风险分析评估的技术，且成功就依赖于这种技术。

b.显然，若存在一个没有被发现的大风险，将会出现问题，甚至可能导致演化过程失去控制。

c.这种模型相对较新，应用不广泛，其功效需要进一步的验证。

(4)、喷泉模型：

优点：

喷泉模型的各个阶段没有明显的界限，开发人员可以同步开发。其优点是可以提高软件项目的开发效率，节省开发时间，

适应于面向对象的软件开发过程。

缺点:

由于喷泉模型在各个开发阶段是重叠的。

(5)、变换模型：

定义：基于形式化规格说明语言及程序变换的软件开发模型。

优点：

a.形式化规约可直接作为程序验证的基础，可以尽早地发现和纠正错误，包括那些在其他情况下不能发现的错误。

b.开发出来的软件具有很好的安全性和健壮性，特别适合安全部门或者软件错误会造成经济损失的开发项目。

缺点：

a.开发费用高，而且需要很长的时间。

b.不能将该模型作为对客户通信的机制，因为客户对这些数学语言一无所知。

c.具有开发无缺陷软件的错误。

第二章可行性研究

1.可行性研究三要素：

a.经济

b.技术

c.管理

2.四个方面可行性研究：

a.经济可行性：

包括成本和效益

b.技术可行性：

技术现状、技术潜力、生产率和风险处理、软件质量

c.社会可行性：

市场、政策、知识产权、道德

d.操作可行性：

项目的运行方式是否行得通、现有管理制度、人员素质和操作方式是否可行。

3.数据流图P26

4.系统流程图P28

第三章需求分析

1.需求的种类：

a.功能需求：

功能需求是指目标软件必须完成的全部功能。

b.性能需求：

性能需求是指目标软件系统必须满足的定时约束或容量约束。

通常包括：响应时间、CPU的使用率、内外存的使用率、网络传送速率、磁盘容量、系统安全性、系统的吞吐量等。

c.可靠性和可用性需求：

可靠性需求是指软件系统在给定的时间间隔内可以成功运行的概率的度量。

可用性需求是指软件系统在给定的时间点可以成功运行的概率的度量。

可靠性需求强调在一段时间范围内的系统可使用性情况；可用性则强调在一个时刻点的系统可使用性情况。

d.出错处理的需求：

出错处理需求是指目标软件系统对环境错误应该怎样响应。

e.各种接口需求：

f.安装运行需求：

g.未来可能提出的需求：

h.逆向需求：

i.约束：

第四章概要设计

1.概要设计

第五章详细设计——怎样实现

1.程序流程图

2.盒图

3.详细设计：

3.1详细设计的任务：

详细设计是对概要设计阶段划分出的每个模块进行明确的算法描述，即根据概要设计提供的说明文档，确定每一个

模块的数据结构及具体算法，并选用合适的描述工具，将其清晰地表达出来。

3.2详细设计的过程：

a.对概要设计所确定的抽象性的数据类型进行确切的定义，确定软件各个模块采用的算法和内部数据的组织形式，

确定对系统内部和外部模块的即可细节。

b.确定每个模块的算法。

c.为每个模块设计一组测试用例。

d.编写详细设计说明书。

第六章编码与测试

1.程序设计语言分为两大类：

面向机器语言：

面向机器语言包括机器语言和汇编语言；

高级语言：

高级语言分为专用语言和通用语言；

2.程序设计语言的选择

理想标准、实用标准、系统用户的要求、工程的规模、软件的运行环境、可以得到的软件开发工具、

软件开发人员的知识、软件的可移植性要求。

3.软件测试在软件开发过程中的体现：

a.寻找软件错误，以便进行修正；

b.证明软件符合要求，是可用的；

c.验证软件是否符合用户要求；

d.指导软件的开发过程；

e.提供软件的相关特征；

6.软件测试的分类

按照是否需要查看代码分类：

a.黑盒测试：

黑盒测试是将被测软件看出一个黑盒子，只考虑系统的输入和输出，完全不考虑程序内部的逻辑结构和处理过程。

黑盒测试的依据是开发各阶段的需求规格说明。

b.白盒测试：

白盒测试是将黑盒子打开，研究源代码和程序内部的逻辑结构；

按照是否需要执行被测软件分类：

a.静态测试：

又称为静态分析，是不实际运行被测软件，而是直接分析软件的形式和结构，查找缺陷。

主要包括对源代码、程序界面和各类文档及中间产品所做的测试。

b.动态测试：

又称为动态分析，是指需要实际运行被测软件，通过观察程序运行时所表现出来的状态、行为等发现软件缺陷。

包括在程序运行时，通过有效的测试用例来分析被测程序的运行情况或进行跟踪对比，发现程序所表现的行为

与设计规格或客户需求不一致的地方。

c.按照测试阶段分类：

a.单元测试：模块测试。

b.集成测试：组装测试。

c.确认测试：有效性测试。

e.系统测试：验证系统是否达标。

f.验收测试：接受测试。

d.按照是否需要人工干预分类：

手工测试：

自动测试：

e.其他测试

7.软件测试的基本原则

a.尽早地并不断地进行软件测试

b.程序员或程序设计机构应避免测试自己的程序

c.测试用例中不仅要有输入数据，还要有与之对应的预期结果

d.测试用例的设计不仅要有合法的输入数据，还要有非法的输入数据

e.在对程序进行修改之后要进行回归测试

f.程序中尚未发现的错误的数量通常与该程序中已发现的错误的数量成正比

h.妥善保留测试计划、全部测试用例、出错统计和最终分析报告，并把他们作为软件的组成部分之一，为维护提供方便。

i.应当对每一个测试结果做全面的检查

j.严格执行测试计划，排除测试的随意性。

8.白盒测试

8.1白盒测试的概念

白盒测试又称为结构测试或逻辑驱动测试，是一种透明的测试技术，它是以程序的内部逻辑结构为基础来设计测试用例的。

8.2白盒测试的原则

a.保证程序中每一独立的路径至少执行一次；

b.保证所有判定的每一个分支至少执行一次；

c.保证每个判定表达式中每个条件的所有可能结果至少出现一次；

d.保证每一循环都在边界条件和一般条件至少个执行一次；

e.验证所有内部数据结构的有效性；

8.3白盒测试技术

逻辑覆盖

逻辑覆盖是指设计测试用例对程序的内部分支逻辑结构进行部分或全部覆盖的技术。

逻辑覆盖由弱到强的几种覆盖技术：

a.语句覆盖

语句覆盖是指设计足够多的测试用例，使程序中的每条语句至少执行一次；

b.判定覆盖

判定覆盖是指设计足够多的测试用例，使每个判定的每种可能结果都至少出现一次，也就是

使每个判定的每个分支都至少自行一次。

判定覆盖也称为分支覆盖。

c.条件覆盖

条件覆盖是指设计足够多的测试用例，使每个表达式中的每个条件的每种可能值都至少出现一次。

d.判定/条件覆盖

e.条件组合覆盖

f.路径覆盖

基本路径

循环覆盖

8.4黑盒测试技术

a.黑河测试，又称功能测试或数据驱动测试，是在已知软件产品应该具有的功能的情况下，通过测试来检验是否

每个功能都能正常使用的测试。

b.黑盒测试主要测试的错误类型：

不正确或遗漏的功能；

接口错误；

性能错误；

数据结构或外部数据访问错误；

初始化或终止条件错误等。

c.黑盒测试用例设计方法：

等价类划分；

边界值分析；

因果图法；

错误推测法；

9.软件测试阶段

a.单元测试

单元测试的测试对象是经过软件设计并编码的一个个程序模块。

单元测试的主要依据是程序代码和详细设计文档；

单元测试可以并行进行；

b.集成测试

集成测试是在单元测试的基础上，按照系统设计要求把通过单元测试的单元模拟逐步组装与测试，

最后组装成一个完整的软件系统的测试过程。

集成测试的方式：

非增量集成方式：将经过单元测试的所有模块一次性地全部组装起来，然后进行整体测试，最后得到所要求的的软件系统。

增量集成方式：将经过单元测试的模块逐步组装成较大的系统，一边组装，一边测试，以便发现模块间与接口有关的问题。

自顶向下集成、自底向上集成。

c.确认测试

确认测试又称为有效性测试，任务是验证软件的功能和性能及其他特性是否与用户的要求一致。

d.系统测试

系统测试是指将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和

人员等其他系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试。

系统测试的类型：

恢复测试：

安全性测试：

强度测试：

性能测试：

e.验收测试

验收测试是软件开发结束后，软件产品投入实际应用以前进行的最后一次质量检验活动，是以用户为主，软件开发人员和质量保证人员

也参加的测试。

第七章软件维护

1.软件维护的概念：

软件维护是指软件系统交付使用以后，为了改正软件运行错误，或者为了满足用户新的需求而加入新功能的修改软件的过程。

2.软件维护的根据：

软件维护主要是根据需求变化或硬件环境的变化对应用程序进行部分或全部的修改，修改时应充分利用源程序。

修改后要填写程序登记表，并在程序变更通知书上写明新旧程序的不同之处。

3.软件维护的内容：

管理层面：

配合客户的优先级，人员配置和费用估计。

技术层面：

对需求、系统或问题有限的理解、影响分析、测试以及可维护性的测量。

4.软件维护的分类：

a.正确性维护：

正确性维护是指改正在系统开发阶段已发生而系统测试阶段尚未发现的错误。

b.适应性维护：

适应性维护是指使用软件适应信息技术变化和管理需求变化而进行的修改。

c.完善性维护：

完善性维护是指扩充功能和改善性能而进行的修改，主要是指对已有的软件系统增加

一些在系统分析和设计阶段中没有规定的功能和性能特征。

d.预防性维护：

预防性维护是指为了改进应用软件的可靠性和可维护性，为了适应未来的软硬件环境的变化，应主动增加预防性的新的功能，

以便使应用系统使用各类变化而不被淘汰。