软件设计师——四、软件工程
一、软件与软件危机
软件是计算机系统中与硬件相互依存的部分，包括：
- 程序。是按事先设计的功能和性能要求执行的指令序列；
- 数据。是程序处理、加工的对象和处理信息的数据结构；
- 文档。是与程序开发、维护和使用相关的各类资料总称。
软件是三者的完整集合。
二、软件工程概述
1、定义
软件工程是应用计算机科学理论、技术及工程管理原则和方法，研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件，以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来。
工程项目的三个基本要素：进度、成本和质量的可控
软件工程是一门工程性学科，目的是成功地建造一个大型软件系统。所谓成功，就是要达到以下几个目标：
付出较低的开发成本。
达到要求的软件功能。
取得较好的软件性能。
开发的软件易于移植。
需要较低的维护费用。
能按时完成开发任务，及时交付费用。
开发的软件可靠性高。
软件工程方法学包括三个要素，即方法、工具和过程。
方法是完成软件工程项目的技术手段，回答“怎么做”问题；
工具是为运用方法提供自动或半自动的支撑环境；
过程是为了获取高质量软件所需要完成的一系列任务框架，包括支持软件开发各个环节的控制和管理。
2、软件开发方法
2.1、传统方法学
也称为结构化方法—结构化分析（SA，Structure Analysis）、结构化设计（SD，Structure Design）和结构化编程（SP，Structure Programming），使用适当的软件工具和软件工程环境来支持结构化技术的应用。
结构化方法是用的开发模式是瀑布模型；
是文档驱动开发的一种方法；
便于分工协作，降低软件复杂度和开发难度；
提高了生产率和软件的可维护性。
适合中小型软件项目的开发。
2.2、面向对象方法学
面向对象方法学解决问题的过程是一个从一般到特殊的演绎思维过程，也包括了从特殊到一般的归纳思维过程。
- 面向对象方法开发软件的过程是一个主动、多次反复迭代（OOA、OOD、OOP）的过程，在概念和表示方法上的一致性保证了在各个开发阶段之间的无缝过渡。
- 往往采用UML语言驱动开发软件。
- 降低了软件产品的复杂性，提高了软件的可理解性，简化了软件的开发和维护难度。
- 对象的相对独立、继承和多态性，促进和提高了软件的可重用性。
适合大型软件项目的开发。
结构化方法和面向对象方法对于不同的软件系统各有优劣。
结构化方法把解空间分数据和功能两部分，可以更加清晰地进行需求分析和功能分解，数据流图能够细致地说明数据在各个功能模块之间的流动和变化，更适于系统设计的前期阶段。
面向对象方法能够把数据和功能以对象为单位封装成一个整体，更直观地表达对象的状态变化和对象间的交互，更加准确地分析功能的实现过程，更适于在软件后期细化系统的具体行为。
2.3、混合式软件开发方法，开发步骤如下所示
- 使用SA进行需求分析，建立数据字典，构建总的和分层的数据流图。
- 使用模块结构图设计系统的独立功能块，做出模块内的程序流图。
- 结合数据流图，聚合同类模块，规约类（归纳出用例图）；根据程序流图，设计类的属性和类的方法。
- 使用OOD建立系统的动态模型，分析对象的行为和协作。
- 总体面向对象程序设计，细节结构化程序设计优化，实现代码层。
无论使用哪种开发方法，或者是混合哪几种开发方法，都要因地制宜，依据需求分析和系统要求，做出最好的选择或组合。
3、基本原则
- 采取适宜的开发模型。与系统设计有关，强调的是控制易变的需求。
- 采用合适的设计方法。有助于实现软件的模块化、抽象与信息隐藏、局部化、一致性以及适应性等。
- 提供高质量的工程支持。在软件过程中，软件开发、测试、管理工具和环境对软件工程的支持颇为重要。
- 重视开发过程的管理。利用可用的资源、提高软件产品的质量、提高软件组织的生产能力等，实现有效的软件工程。
每项基本原则都非常重要，既重视软件技术的应用，又强调软件工程的支持和管理，最重要的是在实践中实施。
4、软件生命周期（Software Life Cycle，SLC）
是指软件从构思之日起，到报废或停止使用的生命周期。
周期内有问题定义、可行性分析、需求分析、系统设计、编码和单元测试、综合测试、验收与运行、维护升级到废弃等阶段。
这种按时间分程的思想方法是软件工程中的一种思想原则，即按部就班、逐步推进，每个阶段都要有定义、过程、审查、并形成文档，文档便于交流或备查，以提高软件的质量且便于软件的维护。
4.1、软件定义时期
主要任务：
- 确定软件开发工程必须完成的总目标。
- 确定工程的可行性。
- 导出实现工程目标应该采用的策略及系统必须完成的功能。
- 估计实现该工程需要的资源和成本，并制定工程进度表。
这个时期的工作通常称为系统分析，由系统分析员负责完成。
软件定义时期又可以进一步划分为问题定义、可行性研究和需求分析3个阶段。
4.2、软件开发时期
主要任务：
- 总体设计阶段应该设计出实现目标系统的几种可能的方案；制定出实现最佳方案的详细计划；根据计划设计程序的体系结构。
- 详细设计也称模块设计，其任务不是编程序，而是设计出程序的详细规格说明；需要确定实现模块功能的算法和数据结构。
- 编码的关键任务是写出正确的、易理解的、易维护的功能模块源代码。
- 测试阶段的任务是把经过单元测试检验的模块按选定的策略进行装配和集成测试，经过确认测试和系统测后，由用户根据软件需求规格说明书（通常在需求分析阶段确定）的规定对目标系统进行验收。
软件开发时期具体设计和实现在前一个时期定义的软件，前两个阶段统称系统设计，后两个阶段则称为系统实现。
4.3、维护时期
主要任务：是使软件持久地满足用户的需要，具体表示为：
- 当软件在使用过程中发现错误时应该加以改正。
- 当环境改变时应该修改软件以适应新的环境。
- 当用户有新要求时应该及时改进软件满足用户的新需要。
通常对维护时期不再进一步划分阶段，但是每一次维护活动本质上都是一次压缩和简化了的定义和开发过程。
5、软件过程定义
软件过程是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。
概括地说，软件过程描述为了开发出用户需要的软件，什么人（Who）、在什么时候（When）、做什么事（What）以及怎么做（How）这些事以实现某一个特定的具体目标。
过程定义了运用方法的顺序、应该交付的文档资料、为保证软件质量和协调变化所需要采取的管理措施，以及标志软件开发各个阶段任务完成的里程碑。
6、软件工程模型
软件过程模型就是一种开发策略，这种策略针对软件工程的各个阶段提供了一套泛型，使工程的进展达到预期的目的。
对一个软件的开发无论其大小，都需要选择一个合适的软件过程模型，这种选择基于项目和应用的性质、采用的方法、需要的控制，以及要交付的产品的特点。
通常使用生命周期模型简洁地描述软件工程。生命周期模型规定了把生命周期划分成各个阶段以及各阶段的执行顺序。因此，也称为过程模型。
6.1、瀑布模型
1970年温斯顿·罗伊斯（Winston Royce）提出了著名的“瀑布模型”，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。
定义：
- 从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动。
- 评审活动的实施，确认后继续下一项活动；否则，返回前面甚至更前面的活动。
- 需求经常变化的项目而言，瀑布模型毫无价值。
- 模型中实线箭头表示开发过程，虚线过程表示维护过程。
优点：
- 强迫开发人员采用规范的方法。
- 严格规定每个阶段必须提交的文档。
- 阶段产品要经过质量保证小组的验证。
缺点：
- 只能通过文档了解产品。
- 固定顺序使纠正前期错误的代价越高。
- 需求变动带来很大的风险。
适用于：
- 需求是预知的。
- 软件实现方法是成熟的。
6.2、快速原型模型
定义：
是快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集。
快速原型模型允许在需求分析阶段对软件的需求进行初步而非完全的分析和定义，快速设计开发出软件系统的原型，该原型向用户展示待开发软件的全部或部分功能和性能。
优点：
- 克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险。
- 更好地和客户进行沟通，澄清模糊需求，并且对需求的变化有较强的适应能力。
- 可以减少技术、应用的风险，缩短开发时间，减少费用，提高生产率。
- 提供了用户直接评价系统的方法，加强了用户信息的反馈，促进了各类人员的协调交流，减少误解，能够适应需求的变化，最终有效提高软件系统的质量。
缺点：
- 所选用的开发技术和工具不一定符合主流的发展。
- 快速建立起来的系统结构加上连续的修改可能会导致产品质量低下。
- 在一定程度上可能会限制开发人员的创新。
适应于：
- 预先不能确定需求。
- 软件实现方法是成熟的。
- 项目周期较短。
6.2.1、探索型原型
把原型用于开发的需求分析阶段，目的是要弄清用户的需求，确定所期望的特性，并探索各种方案的可行性。它主要针对开发目标模糊，用户与开发都对项目都缺乏经验的情况，通过对原型的开发来明确用户的需求。
6.2.2、实验型原型
主要用于设计阶段，考核实现方案是否合适，能否实现。对于一个大型系统，若对设计方案心中没有把握时，可通过这种原型来证实设计方案的正确性。
6.2.3、演化型原型
这种原型主要用于及早向用户提交一个原型系统，该原型系统或者包含系统的框架，或者包含系统的主要功能，在得到用户的认可后，将原型系统不断扩充演变为最终的软件系统。将原型的思想扩展到软件开发的全过程。
6.3、增量模型（渐增模型）
是把待开发的软件系统模块化，将每个模块作为一个增量组件，从而分批次地分析、设计、编码和测试这些增量组件。
运用增量模型的软件开发过程是递增式的过程。相对于瀑布模型而言，采用增量模型进行开发，开发人员不需要一次性地把整个软件产品提交给用户，而是可以分批次进行提交。
即有计划的产品改进模型，它从一组给定的需求开始，通过构造一系列可执行中间版本来实施开发活动。第一个版本纳入一部分需求，下一个版本纳入更多的需求，依此类推，直到系统完成。每个中间版本都要执行必需的过程、活动和任务。
增量模型的最大特点就是将待开发的软件系统模块化和组件化。基于这个特点，增量模型具有以下优点：
- 将待开发的软件系统模块化，可以分批次地提交软件产品，使用户可以及时了解软件项目的进展。
- 以组件为单位进行开发降低了软件开发的风险，一个开发周期内的错误不会影响到整个软件系统。
- 开发人员可以对组件的实现顺序进行优先级排序，先完成需求稳定的核心组件。当组件的优先级发生变化时，还能及时地对实现顺序进行调整。
实现难点：
- 要求待开发的软件系统可以被模块化。
- 软件体系结构必须是开放的。
- 模型本身是自相矛盾的：整体—独立构件。
- 不同的构件并行构建有可能加快工程进度，但要承担无法集成到一起的风险。
适用于：
- 软件产品可以分批次地进行交付。
- 待开发的软件系统能够被模块化。
- 开发人员对应用领域不熟悉或开发人员不确定，难以一次性地进行系统开发。
- 项目管理人员把握全局的水平较高。
- 软件开发过程中需求经常会变动。
6.4、螺旋模型
采用一种周期性的方法来进行系统开发，会导致开发出众多的中间版本。该模型是快速原型法，以进化的开发方式为中心，在每个项目阶段使用瀑布模型法。螺旋模型是在瀑布模型和快速原型模型的基础上增加了风险分析活动。
螺旋模型沿着螺线进行若干次迭代，图中的四个象限代表了以下活动：
- 制定计划。确定软件目标，选定实施方案，弄清项目开发的限制条件；
- 风险分析。分析评估所选方案，考虑如何识别和消除风险；
- 实施工程。实施软件开发和验证；
- 客户评估。评价开发工作，提出修正建议，制定下一步计划。
螺旋模型每一个开发阶段前引入一个非常严格的风险识别、风险分析和风险控制，它把软件项目分解成一个个小项目。每个小项目都标识一个或多个主要风险，直到所有的主要风险因素都被确定。
优点：
- 是一个风险驱动的模型，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发之中。
- 设计上的灵活性，可以在项目的各个阶段进行变更。
- 以小的分段来构建大型系统，使成本计算变得简单容易。
- 客户始终参与每个阶段的开发，保证了项目不偏离正确方向以及项目的可控性。
- 对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标。
- 维护只是模型的另一个周期，维护和开发之间没有本质区别。
缺点：
- 采用螺旋模型需要具有相当丰富的风险评估经验和专门知识。
- 建设周期长，可能导致技术落后因而无法满足当前用户需求。
- 过多的迭代次数会增加开发成本，延迟提交时间。
适用于：
- 需求不明确软件项目适合用螺旋模型开发，便于风险控制和需求变更。
- 螺旋模型强调风险分析，往往适应于内部的大规模软件开发。
- 风险分析影响项目的利润，因此，螺旋模型只适合于大规模软件项目。
- 开发人员应该擅长寻找可能的风险，准确地分析风险，否则，将会带来更大的风险。
6.5、喷泉模型
是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程。
该模型中，软件开发过程自下而上周期的各阶段是相互迭代和无间隙的。
在喷泉模型中，软件的某个部分常常被重复工作多次，相关对象在每次迭代中随之加入渐进的软件成分。无间隙指在各项活动之间无明显边界，如分析和设计活动之间没有明显的界限。因此，易于实现软件的复用。
优点：
- 各个阶段没有明显的界限，开发人员可以同步进行开发。
- 多次反复地增加或明确目标系统，降低错误的可能性。
- 可以提高软件项目开发效率，节省开发时间。
缺点：
- 在开发过程中需要大量的开发人员，不利于项目的管理。
- 要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。
适用于：
- 面向对象的软件开发过程。
7、软件过程管理
定义：
分阶段地通过计划、组织和控制等一系列活动，合理地配置和使用各种资源，定期达到既定目标。
7.1、能力成熟模型（CMM）
7.2、能力成熟度模型集成（CMMI）
定义：
帮助软件企业对软件工程过程进行管理和改进，增强开发与改进能力，按时地、不超预算地开发出高质量的软件
8、估算软件成本
对象点、代码行（LOC）和功能点（FP）估算法，这是不同的估算技术，但有许多共同特性：
- 项目计划人员给出一个有界的软件范围的叙述，再由此尝试着把软件分解成一些小的可分别独立进行估算的子功能；
- 对每一个子功能估算其LOC或FP（即估算变量）；
- 把基线生产率度量用做特定的估算变量，导出子功能的成本或工作量；
- 将子功能的估算进行综合后就能得到整个项目的总估算。
8.1、工作量估算
COCOMO2
给出了3个层次的软件开发工作量估算模型，这3个层次的模型在估算工作量时，对软件细节考虑的详尽程度逐级增加。
3个层次的估算模型分别是：
- 应用系统组成模型。主要用于估算构建原型的工作量，模型名字暗示在构建原型时大量使用已有的构件。
- 早期设计模型。适用于体系结构设计阶段。
- 后体系结构模型。适用于完成体系结构设计之后的软件开发阶段。
COCOMOII模型
使用规模估算信息，应用组装模型使用的是对象点；早期设计阶段模型使用的是功能点，功能点可以转换为代码行；体系结构模型使用的是代码行。
9、进度计划
甘特图（Gantt chart）又称为条状图，通过条状图来显示项目、进度，和其他时间相关的系统进展的内在关系随着时间进展的情况。以提出者亨利·劳伦斯·甘特（Henry Laurence Gantt）先生的名字命名。甘特图以图示通过活动列表和时间刻度表示出特定项目的顺序与持续时间。
Gantt图的主要优点
- Gantt图能形象地描绘任务分解情况，以及每个子任务（作业）的开始和结束时间。
- 具有直观简明和容易掌握、容易绘制的优点。
Gantt图的3个主要缺点
- 不能显式地描绘各项作业彼此间的依赖关系；
- 进度计划的关键部分不明确，难于判定哪些部分应当是主攻和主控的对象（关键对象）；
- 计划中有潜力的部分及潜力的大小不明确，往往会造成浪费。
PERT（Program Evaluation and Review Technique，PERT )图
是制定进度计划时另一种常用的图形工具，它同样能描绘任务分解情况以及每项作业的开始时间和结束时间；此外，它能显式地描绘各个作业彼此间的依赖关系。
在PERT图中，用箭头表示作业（例中的刮旧漆、刷新漆以及清理油漆），用圆圈表示事件（一项作业的开始或结束）。需要明确的是，事件仅仅定义时间点，并不消耗时间和资源。
绘制出工程网络后，系统分析员就可以借助它估算工程进度。为此，需要在PERT图上增加一些必要的信息。
- 每个作业估计需要使用的时间。箭头长度和它代表的作业持续时间没有关系，箭头仅表示依赖关系，它上方的数字才表示作业的持续时间。
- 最早时刻EET。该事件可以发生的最早时间。
- 最迟时刻LET。在不影响竣工时间的前提下，该事件最晚可以发生的时刻。
- 机动时间。实际开始时间可以比预定时间晚一些，或者实际持续时间可以比预定的持续时间长一些，而并不影响工程的结束时间。
最早时刻（EET）的计算
- 事件的最早时刻是该事件可以发生的最早时间。通常，工程网络中第一个事件的最早时刻定义为零，其他事件的最早时刻在PERT图上从左至右按事件发生顺序计算。
- 计算最早时刻EET使用下述3条简单规则。
- 考虑进入该事件的所有作业。
- 对于每个作业都计算它的持续时间与起始事件的EET之和。
- 选取上述和数中的最大值作为该事件的最早时刻EET。
最迟时刻（LET）的计算
- 事件的最迟时刻是在不影响工程竣工时间的前提下，该事件最晚可以发生的时刻，工程网络中最后一个事件的最迟时刻就是它的最早时刻。其他事件的最迟时刻在PERT图上从右至左按逆作业流的方向计算。
- 计算最迟时刻LET使用下述3条规则：
- 考虑离开该事件的所有作业。
- 从每个作业的结束事件的最迟时刻中减去该作业的持续时间。
- 选取上述差数中的最小值作为该事件的最迟时刻LET。
关键路径
- 最早时刻和最迟时刻相同的事件（机动时间为0的作业）定义了PERT图中的关键路径，在图中关键路径用粗线箭头表示。
- 关键路径上的事件（关键事件）必须准时发生（EET=LET），组成关键路径的作业（关键作业）的实际持续时间不能超过估计的持续时间，否则工程就不能准时结束。
- 软件项目的管理人员应该密切注视关键作业的进展情况，如果关键事件出现的比预计的时间迟，那么，项目最终完成的时间会拖后；如果希望缩短项目工期，只有往关键作业中投入更多的资源才会有效。
机动时间
某些作业有一定程度的机动余地，即实际开始时间可以比预定时间晚一些，或者实际持续时间可以比预定的持续时间长一些，但并不影响工程的结束时间。一个作业的全部机动时间的计算公式如下所示：
- 机动时间 =（LET）结束－（EET）开始－持续时间
= 右下角 － 左上角 － 持续时间
eg:
真题：
10、可行性研究任务
需求分析概述
需求分析任务
需求分析过程
需求分析建模与需求分析规格说明
11、数据流图与数据字典
数据流图（没有任何的物理部件，描述的是业务数据的来龙去脉及加工规则）或数据流程图（Data Flow Diagram，DFD）是描述系统中数据流程的一种图形化技术，它描绘信息流和数据从输入移动到输出的过程中所经受的变换。
数据流图是系统逻辑功能的图形表示，即使不是专业的计算机技术人员也容易理解它。因此，数据流图是系统分析员和用户之间极好的沟通工具。
此外，设计数据流图时只需要考虑必须完成的基本逻辑功能，完全不需要考虑如何具体实现这些功能，所以，数据流图也是软件设计的基础。
在结构化开发方法中，数据流图是需求分析阶段产生的结果。根据具体转化方式，可以将数据流图转化为软件结构图。因此，分层数据流图是结构化开发方法的核心和基础。
11.1、数据流图的符号表示
数据流。是数据在系统内传播的路径，因此，数据流由一组成分固定的数据组成。数据流必须有流向，除了与数据存储之间的数据流不用命名外，数据流应该用名词或名词短语命名。
数据源或终点。数据源或终点则代表系统之外的实体，可以是人、物或其他软件系统（不能是自身系统）。
对数据的加工。加工就是对数据进行处理，它接收一定的数据输入，对其进行处理，并产生输出。通常，在数据流图中忽略出错处理，基本要点是描绘“做什么”，而不是“怎么做”。
数据存储。数据存储表示信息的静态存储，可以代表文件、文件的一部分、数据库的元素等。
11.2、数据流图的绘制
1）顶层（0层）数据流图的绘制：
- 0层数据流图只有1张图，1个加工（系统自身）；
- 图中只需要指明数据源、输入流、输出流及数据终点；
2）1层数据流图的绘制：
- 1层数据流图中也只有1张图；
- 把0层数据流图中的一个加工分解成若干个加工，这些加工之间可以有0条或多条数据流；
- 1层数据流图中包括0层数据流程图中的输入数据流和输出数据流、各个加工之间数据流以及1个以上加工需要读或写的文件。
3）加工的内部绘制：
- 把每个加工看作一个小系统，把加工的输入输出数据流看成小系统的输入输出流；
- 于是可以像画0层图一样画出每个小系统的加工的DFD图；
- 一个子图对应于上层数据流图（父图）的一个加工的分解图；
- 子图中包括父图中对应加工的输入/输出数据流、子图内部各加工之间0个或多个数据流以及读写文件数据流。
4）画子加工的分解图：
- 对前一步分解出来的DFD图中的每个加工；
- 重复分解过程，直到图中尚未分解的加工都是足够简单的（即不可再分解）。至此，便可得到一套分层的数据流图。
5）对数据流图和加工编号：
- 0层图（顶层图）只有一张，所以不必为其编号。
- 1层图也只有一张，0层图中的分解加工号分别是1，2，3等等 。
- 1层以下的子图中的加工号是由父图号、圆点和序号组成，如1层加工1的3个子加工的编号分别为1.1、1.2、1.3，子加工1.1的子加工序号则分别为1.1.1、1.1.2、1.1.3 等等。
11.3、绘制注意事项
1）命名。不论数据流、数据存储还是加工，合适的命名使人们易于理解其含义。
2）画数据流而不是控制流。数据流反映系统“做什么”，不反映“如何做”，因此，箭头上的数据流名称只能是名词或名词短语，整个图中不反映加工的执行顺序。
3） 一般不画物质流。数据流反映能用计算机处理的数据，因此，对目标系统的数据流图一般不要画物质流。
4） 保证数据守恒。每个加工至少有一个输入数据流和一个输出数据流，反映出此加工数据的来源与加工的结果，且输入流不同于输出流（否则，加工只是一个管道，毫无意义）。
5）编号。分层的数据流图中，上层图为父图，直接下层图为子图。子图及其所有的加工都应按层次级别编号。
6） 父图与子图的平衡。子图的输入输出数据流同父图相应加工的输入输出数据流必须一致（在数量和名字上相同），即父图与子图的平衡。
7）局部数据存储。局部的数据存储不是父图中加工的外部接口，而只是本图中某些加工之间的数据接口。
8）提高数据流图的易懂性。合理分解加工，可以减少加工之间输入、输出数据流的数目，增加数据流图的可理解性。
9）分解要掌握适度。当分解涉及具体的实现一个功能时就不应该再分解了；每次只对一个功能进行分解。
三、软件测试基础
定义：
就是贯穿整个软件开发生命周期、对软件产品进行验证和确认的活动过程，其目的是尽快尽早地发现在软件产品中存在的各种问题，即与用户需求、预先的定义不一致的地方。
测试只能查找出程序中的错误，而不能证明程序是正确的。
1、测试技术
1.1、白盒测试（结构测试）
定义：
把程序看成装在一个透明的白盒子里，测试者完全知道程序的结构和处理算法。
白盒测试法按照程序内部的逻辑测试程序，检测程序中的主要执行通路是否能按预定要求正确工作。因此，白盒测试又称结构测试。
- 代码检查法
- 静态结构分析法
- 逻辑覆盖法
- 控制结构测试法（基本路径测试、条件测试和循环测试）等
逻辑覆盖法
定义：
是以程序内部的逻辑结构为基础的设计测试用例的技术。从覆盖源程序语句的详尽程度分析，大致有以下一些不同的覆盖标准：
- 语句覆盖
- 判定覆盖
- 条件覆盖
- 判定/条件覆盖
- 条件组合覆盖
- 路径覆盖
这六种覆盖标准按照测试路径覆盖能力由弱到强排列。
