软件工程复习

神tm全书复习，复习千万别像我这样，要面向题纲复习，即根据老师的题纲复习，经过本次的复习，这是我的反思，还差点挂科！！！！

一、名词解释10道 30分
二、简答题 5道 40分
（写要点）ppt有答案
1第二章 系统工程
2第五章 设计工程一个题 写数据字典
3第四章 与数据设计相关的题
4第十五章 软件维护和再工程
5第十三章 软件测试
三、综合题2道30分
（详细描述）
都是书上世界通用经典内容
第三章需求和第16章项目管理

第一章.概论

系统软件，支撑软件，应用软件

软件语言

(1)需求定义语言
(2)功能性语言
(3)设计性语言
(4)程序设计语言
(5)文档语言

软件工程

软件工程定义

软件工程是建立和使用一套合理的工程原则，以便获得经济的软件，这种软件是可靠的，可以在实际机器上高效地运行。
软件工程是将系统化，严格约束的，可量化的方法应用于软件的开发，运行和维护，即将工程化应用于软件。

框架

(1)选取适宜的开发风范
(2)采用合适的设计方法
(3)提供高质量的工程支持
(4)有效的软件工程管理

生存周期

1.计算机系统工程
确定待开发软件的总体要求和范围，以及该软件与其他计算机系统元素之间的关系，进行成本估算，做出进度安排，并进行可行性分析；
2.需求分析
确定软件的功能，性能，数据，界面等要求，生成需求规格说明书
3.设计
分为系统设计（也称为概要设计或总体设计）和详细设计。
系统设计：设计软件系统的体系结构，包括软件系统的组成成分，各成分的功能和接口，成分间的连接和通信，同时设计全局数据结构；
详细设计：设计各个组成成分的实现细节，包括局部数据结构和算法；
4.编码

5.测试

6.运行和维护

软件过程

软件过程是生产一个最终满足需求且达到工程目标的软件产品所需的步骤；

软件生存周期过程

(1)基本过程
(2)支持过程
(3)组织过程

软件过程成熟度的5个等级

(1)初始级
(2)可重复级
(3)已定义级
(4)已管理级
(5)优化级

软件过程模型

瀑布模型

上一阶段的活动完成并经过评审后才可以开始下一阶段的活动。

演化模型

从构造初始的原型出发，逐步将其演化成最终软件产品的过程。

增量模型

将软件的开发过程分成若干个日程时间交错的线性序列，每个线性序列产生软件的一个可发布的“增量版本”，后一个版本是对前一个版本的修改和补充，重复增量发布的过程，直至产生最终的完善产品。

快速原型模型

原型是预期系统的一个可执行版本，反映了系统性质的一个选定的子集。
探索型
实验型
演化型
原型使用策略：
废弃策略：
追加策略：

螺旋模型

螺旋模型沿着螺旋线自内向外旋转，在4个象限上分别表示以下4个方面的任务。
(1)制定计划
(2)风险分析
(3)工程实施
(4)客户评估
螺旋模型指引的软件项目开发沿着螺旋线自内向外旋转，每旋转一周，表示开发出一个更为完善的新版本软件。

喷泉模型

支持面向对象开发的过程模型；

基于构件的开发模型

基于构建的开发是指利用预先包装的构件来构造应用系统。构件可以是组织内部开发的构件，也可以是商品化的，现存的软件构件。

领域工程的目的是构建领域模型，领域基准体系结构和可复用构建库。

第二章.系统工程

基于计算机的系统

计算机系统：通过处理信息来完成某些预定义目标而组织在一起的元素的集合或排列；组成基于计算机系统的元素主要有：软件，硬件，人员，数据库，文档和规程；
软件：计算机程序，数据结构和一些相关的工作产品；
硬件：提供计算能力的电子设备，支持数据流的互连设备；
规程：定义每个系统元素或其外部相关流程的具体使用步骤；

系统工程任务

(1)识别用户要求
(2)系统建模和模拟
(3)成本估算及进度安排
(4)可行性分析
(5)生成系统规格说明书

可行性分析：

可行性分析主要从经济，技术，法律等方面分析所给出的解决方案是否可行，能否在规定资源和时间的约束下完成！

经济可行性

主要进行成本效益分析，从经济角度，确定系统是否值得开发；

成本

购买硬件，软件和设备的费用；
系统的开发费用；
系统安装，运行和维护的费用；
人员培训费用；

效益

经济效益和社会效益。

货币的时间价值

在进行成本效益分析时，通常要对投入的成本与累计的经济效益进行比较。然而，开发成本是在系统交付前投入的，而累计的经济效益实在系统交付后的若干年内得到的，然而货币有时会贬值；

投资回收期

投资回收期是指累计的经济效益正好等于投资数所需的时间。投资回收期通常用于评价开发一个工程的价值的重要经济指标，显示了需要多长时间才能回收最初的投资数。显然，投资回收期越短越好。

纯收入

纯收入 = 累计的经济效益 - 成本

技术可行性

风险分析

风险分析主要分析在给定的约束条件下设计和实现系统的风险。

资源分析

主要论证是否具备系统开发所需的各类人员，软件，硬件等资源和相应的工作环境。

技术分析

分析当前的科学技术是否支持系统开发的各项活动。

法律可行性

开发过程中涉及到的合同，侵权，责任以及各种与法律相关的问题；

方案的选择和折衷

一个基于计算机的系统可以有多个可行的实现方案，每个方案对成本，时间，人员，技术，设备都有不同的要求，不同方案开发出来的系统在功能，性能方面也会有所不同；因此要在多个可行的实现方案中做出选择。方案评估的依据是待开发系统的功能，性能，成本，开发时间，采用的技术，设备，风险以及对开发人员的要求等。

第三章.需求工程

需求工程是将软件分解为实际架构和构件之前的所有活动。
(1) 需求获取
(2)需求分析与协商
(3)系统建模
(4)需求规格说明书
(5)需求验证
(6)需求管理

需求获取

软件需求

1.功能需求
2.性能需求
3.用户或人的因素
4.环境需求
5.界面需求
6.文档需求
7.数据需求
8.资源使用需求
9.安全保密需求
10.可靠性需求
11.软件成本消耗与开发进度需求
12.其他非功能性需求

需求获取方法与策略

(1)建立顺畅的通信途径
(2)访谈与调查
(3)观察用户操作流程
(4)组成联合小组
FAST(Facilitated application specification techniques)
a.在中立地点举行由开发者和用户出席的会议
b.建立准备和参与会议的规则
c.建立一个足够正式的议程以便可以进行自由交流
d.由一个协调者来控制会议
e.使用一种定义机制
f.目标是标识问题，提出解决方案的要素，商议不同的方法以及在有利于完成目标的氛围中刻画出初步的需求；
i.确定一个FAST会议的时间和地点
ii.要求每个FAST出席者在会议之前列出一组围绕系统环境的对象列表，对这些对象的操作列表或对象之间的交互功能列表，以及约束列表。这些列表可以不是穷尽的，但是，希望每套列表反映的是每个人对系统的感觉；
iii.进行FAST会议时，当团队的每个成员提出自己的列表后，整个团队将创建一个组合的列表。
iv.一旦创建了意见一致的列表，应将团队分为更小的小组，每个小组力图为每个列表中的一个或多个项开发出小型的规约。
v.上一步完成后，将每个出席者的讨论结果形成列表的形式提交给团队，团队基于此创建一组意见一致的列表，作为需求获取的结果；

用况（用例）

(1)确定谁会直接使用该系统
(2)选取其中一个执行者
(3)定义该执行者希望系统做什么，执行者希望系统所做的每件事都将成为一个用况；
(4)对每件事来说，合适执行者会使用系统，通常会发生什么，这就是用况的基本过程
(5)描述该用况的基本过程

用况主要用来捕获系统的高层次功能性需求；
一个用况是系统所提供的一个功能的描述；

需求分析原则

信息域

信息域包括信息内容，信息流以及信息结构；
信息内容表示单个数据和控制对象，目标软件所有处理的信息集合由它们构成。
信息流表示了数据和控制项的内部组织形式。
信息流表示了各种数据和控制项的内部组织形式。

需求协商

折衷方案，
(1)不一致的目标
(2)责任的丧失和转移
(3)组织文化
(4)组织管理态度和士气
(5)部门差异
会议的三个阶段：
(1)叙述阶段
(2)讨论阶段
(3)决策阶段

需求建模

需求模型应关注于需要做什么，而不是怎么做；
分析方法：
(1)面向数据流的结构化分析方法(SA)
(2)面向数据结构的分析方法
(3)面向对象的分析方法

需求规约与验证

需求分析的输出就是需求规约；
(1)描述要“做什么
(2)要求使用面向对象规约语言，讨论来自环境的各种刺激可能导致系统做出什么样的功能性反应来定义一个行为模型。
(3)若被开发的软件只是一个基于计算机系统中的一个元素，那么整个大系统也应包括在规格说明书的描述之中。
(4)规约需包括运行环境
(5)规约为一个认识模型
(6)规约须允许不完备性并允许扩容；
(7)规约必须局部化和松散耦合；

需求验证

检验需求是否反映用户的意愿。需求验证需要对需求文档中定义的需求执行多种检查。
(1)系统定义的目标是否与用户的要求一致
(2)系统需求分析阶段提供的文档资料是否齐全；文档中的描述是否完善，清晰，准确地反映用户的要求；
(3)被开发项目的数据流与数据结构是否确定且充足
(4)主要功能是否已包括在规定的软件范围之内，是否都已充分说明；
(5)设计的约束条件或限制条件是否符合实际；
(6)开发的技术风险
(7)是否制定了检验标准，能否对系统定义进行确认；

需求管理

需求管理是一组用于帮助项目组在项目进展中的任何时候去标识，控制和跟踪需求的活动，
为每个需求赋予唯一的标识。进行需求跟踪的目的是为了建立和维护从用户需求开始到测试之间的一致性与完整性。
正向跟踪：以用户需求为切入点，检查《需求规约》中每个需求是否都能在后继工作产品中找到对应点；
逆向跟踪：检查设计文档，代码，测试用例等工作产品是否都能在《需求规约》中找到出处。

第四章.设计工程

软件设计是将软件需求转换成软件表示的过程，软件设计分为数据/类设计，软件体系结构设计，接口设计和部件级设计；
(1)数据/类设计
数据，类设计将分析模型变换成类的实现和软件实现所需的数据结构。
(2)体系结构设计
体系结构设计定义了软件的整体结构，由软件部件，外部可见的属性和它们之间的关系组成。体系结构设计表示可以从系统规约，分析模型和分析模型中定义的子系统交互导出。
(3)接口设计
描述了软件内部，软件和协作系统之间以及软件同人之间的通信方式。
(3)部件级设计：将软件体系结构的结构性元素变换为对软件部件的过程性描述。

软件设计的目标：
(1)满足用户的显式需求以及隐式需求
(2)设计必须是可读，可理解的，使得将来易于编程，易于测试，易于维护；
(3)设计应当从实现角度出发，给出与数据，功能，行为相关的软件全貌；
(4)设计出来的结构应当是分层结构
(5)设计应当模块化
(6)设计应当既包含数据抽象，也包含过程抽象
(7)设计应当建立具有独立功能特征的模块
(8)设计应当建立能够降低模块与外部环境之间复杂连接的接口
(9)设计应能根据软件需求分析获取的信息，建立可驱动，可重复的方法；

软件设计过程
(1)制定规范
(2)体系结构和接口设计
(3)数据/类设计
(4)部件级设计
(5)编写设计文档
(6)设计评审

软件设计原则

抽象与逐步求精

软件工程过程的每一步都是对较高一级抽象的解进行一次具体化的描述，系统定义阶段把整个软件系统抽象成基于计算机系统的一个组成部分，需求分析阶段是对问题域的抽象，使用问题域中的术语，经过软件体系结构设计，部件级设计，抽象级别一次一次降低，到编码完成后，到达最低级别的抽象；
过程抽象（功能抽象）：任何一个完成明确定义功能的操作都可以被使用者当作单个实体对待；
数据抽象：定义数据类型和施加于该类型对象的cau哦做，并限定对象的取值范围。

逐步求精是把问题的求解过程分解成若干步骤或阶段，每一步都比上一步更精化，更接近问题的解法；

模块化

将软件按照规定原则，划分为一个个较小的，相互独立的但又相互关联的部件；

信息隐藏

每个模块的实现细节对于其他模块来说应该是隐蔽的。

功能独立

功能独立的概念是模块化，抽象概念和信息隐藏；
独立性：内聚度/耦合度
内聚度：一个模块内部各元素间的紧密程度
巧合内聚 -> 逻辑内聚 -> 时间内聚 -> 过程内聚 -> 通信内聚 -> 顺序内聚 -> 功能内聚

耦合度：模块间相对独立性的度量，取决于各模块间接口的复杂程度，调用模块的方式以及通过接口的信息显示类型；
非直接耦合->数据耦合->标记耦合->控制耦合->外部耦合->公共耦合->内容耦合

软件体系结构设计

软件体系风格

1.数据为中心的体系结构
2.数据流风格的体系结构
3.调用和返回风格的体系结构
4.面向对象风格体系结构
5.层次式风格的体系结构

软件设计的分析过程：
(1)定义应用场景
(2)得出需求，约束和环境描述
(3)描述能处理上述场景和需求的体系结构风格
(4)单独地评价系统的各项性能
(5)针对不同的架构形式，评价第四步提到的性能的敏感程度
(6)通过第五步得到的敏感度评价分析第三步中的体系结构

部件级设计

在软件体系结构设计阶段，已经确定了软件系统的总体结构，给出了系统中各个组成部件的功能和部件间的联系。部件级设计是要在上述结果的基础上，考虑“如何实现”这个软件系统，直到对系统中的每个部件给出足够详细的过程性描述；

结构化程序设计

如果一个程序的代码块仅仅通过顺序，选择，循环这三种基本控制结构进行联结，且每个代码块仅有一个出口和入口，则称这个程序是结构化的；

图形化表示法

(1)程序流图
(2)N-S图
(3)PAD(Problem analysis diagram)
(4)判定表

设计性语言PDL(Program design language)

用于描述功能部件的算法设计和处理细节的语言

设计规约与设计评审

设计规约

设计评审

软件设计的最终目的是要选择的最佳方案。
(1)可追溯性
分析该软件的系统结构，子系统结构，确认该软件设计是否已覆盖了所有已确定的软件需求，软件的每一成分是否可追溯到某一项需求；

(2)接口
分析软件各部分之间的联系，确认该软件的内部接口与外部接口是否已经明确定义。部件是否满足高内聚，低耦合的要求。

(3)风险
确认该软件设计于现有技术条件下能否按时完成；

(4)实用性
确认该软件设计对于需求的解决方案是否实用

(5)技术清晰度
确认该软甲设计是否以一种易于翻译成代码的形式表示

(6)可维护型

(7)质量

(8)各种选择方案

(9)限制

(10)其他具体问题

可追溯性，接口，风险，实用性，可维护性，技术清晰度，质量，限制，其他具体问题，各种可选择的方案

第五章.结构化分析与设计

结构化分析与设计方法是一种面向数据流的传统软件开发方法，以数据流为中心构建软件的分析模型和设计模型，结构化方法包括
结构化设计，
结构化程序设计，
结构化分析；
抽象是指忽略一个问题中与当前目标无关的那些方面，以便更加充分地关注与当前目标有关的问题；

抽象和分解是处理任何复杂问题的两个基本手段；

结构化分析过程

(1)获取当前系统的物理模型
(2)从物理模型抽象处逻辑模型
(3)分析目标系统与当前系统逻辑上的差别，建立目标系统的逻辑模型
(4)为目标系统的逻辑模型做补充
数据字典是模型的核心

数据流图

软件系统的功能建模，描述系统的输入数据流如何经过一系列加工，逐步变换成系统的输出数据流
(1)源或宿
(2)加工
(3)数据流
(4)文件

实体-关系图（E-R图）

数据建模，描述数据字典中数据之间的关系

状态转移图

行为建模，描述系统接收哪些外部事件，以及在外部事件的作用下系统的状态迁移。

分层数据流图的完整性

(1)每个加工至少有一个输入数据流和一个输出数据流
(2)在整套分层数据流图中，每个文件应至少有一个加工读该文件，有另一个加工写该文件；
(3)分层数据流图中的每个数据流和文件都必须命名，并与数据字典保持一致；
(4)分层DFD中的每个基本加工都应有一个加工规约

构造分层DFD(Data Flow Diagram)时需要注意的问题

(1).适当命名
(2).画数据流而不是控制流
(3).避免一个加工有过多的数据流
(4).分解尽可能均匀
(5).先考虑稳定状态，忽略琐碎的枝节
(6).随时准备重画

分解的程度

(1)7±2
(2)分解应该自然，概念上合理，清晰
(3)只要不影响DFD的易理解性，可适当增加子加工数量，以减少层数
(4)上层分解的要快些，下层分解的要慢些
(5)分解要均匀

数据字典

数据字典由字典条目组成，每个条目描述DFD中的一个元素
字典条目：
(1)数据流
(2)文件
(3)数据项（组成数据流和文件的数据）
(4)加工
(5)源或宿

源或宿 -> 文件-> 数据流 (数据项)->加工

数据流条目：

名称：数据流名
别名：名称的另一个名字
简述：对数据流的简要说明
数据流组成：描述数据流由哪些数据项组成
数据流来源：描述数据流从哪个加工或源宿流出
数据量：系统中该数据流的总量；
峰值：某时段处理的最大数量
注解：对该数据流的其他补充说明

文件条目：

名称：文件名
别名：同数据流条目
简述：对文件的简单说明
文件组成：描述文件的记录由哪些数据项组成
写文件的加工：描述哪些加工写文件
读文件的加工：描述哪些加工读文件
文件组织：描述文件的存储方式（顺序，索引），排序的关键字
使用权限：描述各类用户对文件读，写，修改的使用权限
数据量：文件的最大记录个数
存取频率：描述对该文件的读写频率
注解：对该文件的其他补充说明

数据项条目

名称：数据项名
别名：同数据流条目
简述：对数据项的简单描述
数据类型：描述数据项的类型，如整型，实型，字符型等
计量单位：指明数据项值得计量单位
取值范围：描述数据项允许的值域
编辑方式：描述该数据项的外部表示的编辑方式
注解：对数据项的补充说明

加工条目

名称：加工名
别名：别名
加工号：加工在DFD中的编号
简述：对加工功能的简要说明
输入数据流：描述加工的输入数据流，包括读哪些文件
输出数据流：描述加工的输出数据流，包括写哪些文件
加工逻辑：简要描述加工逻辑，或者对加工规约的索引
异常处理：描述加工处理过程中可能出现的异常情况，及其处理方式
加工激发条件：描述执行加工的条件
执行频率：描述加工的执行频率
注解：补充说明

源或宿条目

名称：源或宿的名称
别名：别名
简要描述：对源或宿的简要描述
输入数据流：描述源向系统提供哪些输入数据流
输出数据流：描述系统向宿提供哪些输出数据流
注解：补充说明

别名条目

别名：…
类型：指出别名属于哪个种类（数据流，文件，数据，加工，源或宿）
基本名：别名的正式名称
简述：同正式名称的简述
说明：对别名的补充说明

需求分析是解决“做什么”，而不是“怎么做”

数据字典由字典条目（源或宿，数据项，数据流，加工，文件）组成；

结构化语言

结构化语言是介于自然语言和形式语言之间的一种半形式语言
(1)语句力求精炼
(2)语句必须易读，易理解无二义
(3)主要使用祈使句，祈使句中的动词需明确表达要执行的动作
(4)所有名字必须是数据字典中有定义的名字
(5)不使用形容词，副词等修饰词
(6)不使用含义相同的动词
(7)可以使用常用的算术和关系运算符

判定表

(1)条件桩
(2)条件条目
(3)动作桩
(4)动作条目

判定树 - 判定表的变种

结构化设计

结构化设计是将结构化分析得到的数据流图映射成软件体系结构的一种设计方法。
结构化方法中，软件设计分为概要设计和详细设计

概要设计

对软件系统的总体设计，采用结构化设计方法，将系统分解成模块，确定每个模块的功能，接口及其调用关系，并用模块及对模块的调用来构建软件的体系结构。

详细设计

对模块实现细节的设计，采用结构化程序设计方法。

结构图

结构化设计方法中使用结构图来描述软件系统的体系结构，指出一个软件系统由哪些模块组成以及模块之间的调用关系；
(1)模块：具有一定功能并可以使用模块名调用的一组程序语句
(2)调用：结构图中模块间的调用关系从一个模块指向另一个模块的箭头来表示；
(3)数据：模块调用时需传递的参数可通过箭头旁附加一个小箭头和数据名来表示

结构图某些概念

(1)深度：结构如中控制的层数
(2)宽度：同一层次上模块总数的最大值
(3)扇出：该模块可直接调用的模块数目
(4)扇入：该模块能被直接调用的模块的数目

5.6.2.启发式设计策略
1.改造程序结构图，降低耦合度，提高内聚度
2.避免高扇出，并随着深度的增加，力求高扇入
3.模块的影响范围应限制在该模块的控制范围内
4.降低模块接口的复杂程度和冗余程度，提高一致性
5.模块的功能应该是可预测的，避免对模块施加过多的限制
6.尽可能设计单入口和单出口的模块

结构化设计步骤

(1)建立初始结构图
(2)对结构图的改进
(3)书写设计文档
(4)设计评审

数据流图到软件体系结构的映射

变换分析：变换型数据流图
事务分析：事务型数据流图

信息流

1.变换流：输入->变换=>输出；
2.事务流：...

遇啸宇有感-其二
去年今日此校中，
广外与君初相识。
语心湖畔泛涟漪，
思君心似相思水。

第七章.面向对象方法基础

面向对象分析和设计过程

面向对象分析

OOA(Object Oriented Analysis):
(1)在客户和软件工程师之间沟通基本的用户需求
(2)标识类
(3)刻画类（定义类的结构和层次）
(4)表示类（建造对象-关系模型）
(5)为对象行为建模
(6)递进地重复(1)至(5)

OOD(面向对象设计)，是将OOA所创建的分析模型转化为设计模型；
(1)系统设计
i.将子系统分配到处理器
ii.选择实现数据管理，界面支持和任务管理的设计策略
iii.为系统设计合适的控制机制
iv.复审并考虑权衡

(2)对象设计
i.在过程级别设计每个操作
ii.定义内部类
iii.为类属性设计内部数据结构

(3)消息设计
i.使用对象间的协作和对象-关系模型，设计消息模型
(4)复审
i.对设计模型进行复审，并且在需要的时候进行迭代

系统设计

(1)将分析模型划分成子系统
(2)标识问题本身的并发性，并为子系统分配处理器
(3)任务管理设计
(4)数据管理设计
(5)资源管理设计
(6)人机界面设计
(7)子系统间的通信

对象设计

(1)对象描述
(2)设计数据结构和算法

设计模式

创建型模式(与对象创建有关)：工厂方法，抽象工厂，构造器，原型，单件
结构型模式（处理类或对象的组合）：适配器，桥接，组合，装饰器，外观，享元，代理
行为型模式（描述类或对象的交互和职责分配）：解释器，模版方法，职责链，命令，迭代器，中介者，备忘录，观察者，状态，策略，访问者；

UML

静态的用况要实现部署，状态机的交互活动为模型管理。
静态，用况，实现，部署，状态机，活动，交互，模型管理视图
建模语言由符号和一组如何使用它的规则组成。

静态视图：
对应应用领域中的概念以及与系统实现有关的内部概念建模，由类及类之间的相互关系组成；不依赖于时间系统行为；

用况视图：
列出系统中的用况和执行者；并显示哪个执行者参与了哪些用况的执行；

设计视图：
对应自身的设计结构建模。

部署视图：
描述运行时结点上制品的分布；

状态机视图：
对一个类的对象的可能生命历程建模。

交互视图：
系统各部分中消息交互的顺序；

活动视图：
展示了包含在执行计算或工作流中的计算活动的控制流。

模型管理视图：
对模型自身的组织建模；

图

1.类图
展示了系统中类的静态结构，即类与类之间的相互联系；

2.内部结构图
展示了类的分解，给出了组成一个结构化类元的相互连接的部分，端口和连接器

3.协作图
协作的定义，为一种合成的结构图；

4.构件图
展示了系统中的构件，构件间通过接口连接

5.用况图
展示各类外部执行者与系统所提供的用况之间的连接。

6.状态机图
对类描述的补充，说明该类的对象所有可能的状态以及哪些事件将导致状态的改变；

7.活动图
展示
…

第十三章.软件测试

测试一个为了发现错误而执行程序的过程；
一个成功的测试是指揭示了迄今为止尚未发现的错误的测试；
软件测试基本原则：
(1)所有测试都应可追溯到客户需求
(2)Pareto原则可应用于软件测试（测试中80%的错误来自20%的代码之中）
(3)测试应从”小规模“开始，逐步转向”大规模“
(4)穷举测试是不可能的
(5)应由第三方来测试
(6)测试用例应包括合理以及不合理的
(7严格执行测试计划，排除测试的随意性
(8)对于每一个测试结果都要做全面检查
(9)保存好测试计划，测试用力，出错统计和最终分析报告，为维护提供方便；
(10)在规划过程中不要设想程序中不会查出错误；
(11)检查程序是否做了它不应该做的事情

白盒测试

结构测试，将测试对象看作一个透明的盒子，依据程序内部逻辑设计测试用例
(1)程序模块中的所有独立路径至少执行一次
(2)对所有逻辑判定的取值都至少测试一次
(3)在上下边界及可操作范围内运行所有的循环
(4)测试内部数据结构的有效性

逻辑覆盖测试，基本路径测试，数据流测试和循环测试

逻辑覆盖测试

主要考察使用测试数据运行被测试程序时对程序逻辑的覆盖程度；-> 语句覆盖，判定覆盖，条件覆盖，判定/条件覆盖，条件组合覆盖，路径覆盖

逻辑表达式错误敏感的测试

逻辑覆盖测试依赖于程序中的逻辑条件，这些逻辑条件由逻辑表达式组成。逻辑表达式由逻辑变量，关系表达式，逻辑运算符和括号组成。选择对发现逻辑表达式错误比较敏感的组合条件进行测试，以较小的测试用例来发现逻辑表达式中的绝大多数错误；

基本路径测试

根据程序或设计图画出控制流图（流图或程序图），并计算其区域数，然后确定一组独立的程序执行路径，最后为每一条基本路径设计一个测试用例；

数据流测试

根据程序中变量的定义和引用位置来设计测试用例，以发现变量赋值和引用方面的错误。

循环测试

简单循环，嵌套循环，串接循环，非结构循环

黑盒测试

测试人员不关注代码逻辑结构及内部特性，仅依照程序的需求规格说明书，检查程序功能是否符合预期功能需求。
(1)不正确或遗漏的功能
(2)接口错误
(3)数据结构错误或外部信息访问错误
(4)性能错误
(5)初始化和终止错误

等价类划分

将所有可能的输入数据划分成若干个等价类，然后在每个等价类中选取一个代表性数据作为测试数据；，测试等价类的某个代表值就等价于这一类测试的结果。
有效等价类：符合规格说明书要求的合理的输入数据集合；
无效等价类：不符合规格说明书要求的不合理的或非法的输入数据集合；

边界值分析