《软件工程》60’
一.、软件过程
1、软件过程的概念
答：
1）**软件过程描述为为了开发出客户需要的软件，什么人、在什么时候、做什么事以及怎么做这些事以实现某一种的具体目标。**ISO9000把过程定义为：“使用资源将输入转化为输出的活动所构成的系统”。（《软件工程导论》p14）
2）过程定义了运用方法的顺序、应该交付的文档资料、为保证软件质量和协调变化所需要采取的管理措施以及标志软件开发各个阶段任务完成的里程碑。（《软件工程导论》p14）
3）软件过程是软件生成周期中的一系列相关的过程。过程是活动的集合，活动是任务的集合。（《复旦大学软工PPT》）
软件过程有三层含义：
个体含义：
即指软件产品或系统在生存周期中的某一类活动的集合，如软件开发过程，软件管理过程等；
整体含义：
即指软件产品或系统在所有上述含义下的软件过程的总体；
工程含义：
即指解决软件过程的工程，它应用软件工程的原则、方法来构造软件过程模型，并结合软件产品的具体要求进行实例化，以及用户环境下的运作，以此进一步提高软件生产率，降低成本。
2、经典软件过程模型特点（瀑布模型、增量模型、演化模型、统一过程模型）
答：
瀑布模型
- 瀑布模型将软件生命周期划分为需求分析、规格说明、设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
- 瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。
- 瀑布模型模型的线性过程太理想化，已不再适合现代的软件开发模式，几乎被业界抛弃，主要问题是：
1.各个阶段的划分完全固定，阶段之间生成大量的文档，极大地增加了工作量；
2.由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险；
3.早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。
增量模型
与建造大厦相同，软件也是一步一步建造起来的。
在增量模型中，软件被作为一系列的增量构件来设计、实现、集成和测试，每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成。
- 增量模型在各个阶段并不交付一个可运行的完整产品，而是满足客户需求的一个子集的可运行产品。
- 增量模型侧重于每个增量都提交一个可以运行的产品。
- 整个产品被分解成若干个构件，开发人员逐个构件地交付产品，这样做的好处是软件开发可以较好地适应变化，客户可以不断地看到所开发的软件，从而降低开发风险。
但是，增量模型也存在以下缺陷：
1.由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，还需要软件具备开放式的体系结构。
2.在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其事情这种变化的能力大大优于瀑布模型和快速原型模型，但是也很容易退化为边做边改模型，从而使软件过程的控制失去整体性。
在使用增量模型时，第一个增量往往是实现基本需求的核心产品。核心产品交付用户使用后，经过评价形成下一个增量的开发计划，它包括对核心产品的修改和一些新功能的发布。每个过程在每个增量发布后不断重复，直到产生最终的完善产品。
演化模型
演化模型是一种全局的软件（或产品）生存周期模型。属于迭代开发方法。
即根据用户的基本需求，通过快速分析构造出该软件的一个初始可运行版本，这个初始的软件通常称之为原型，然后根据用户在使用原型的过程中提出的意见和建议对原型进行改进，获得原型的新版本。重复这一过程，最终可得到令用户满意的软件产品。
采用演化模型的开发过程，，实际上就是从初始的原型逐步演化成最终软件产品的过程。演化模型特别适用于对软件需求缺乏准确认识的情况。
缺点：
1.如果所有的产品需求在一开始并不完全弄清楚的话，会给总体设计带来困难以及削弱产品设计的完整性，并因而影响产品性能的优化及产品的可维护性；
2.如果缺乏严格的过程管理的话，这个生命周期模型很可能退化为一种原始的无计划的“试-错-改”模式；
统一过程模型
统一过程（RUP/UP,Rational Unified Process）是一种以用例驱动、以体系结构为核心、迭代以及增量的软件过程模型，由UML方法和工具支持，广泛应用于各类面向对象项目。
RUP是Rational公司开发并维护，和一系列软件开发工具紧密集成。RUP蕴含了大量优秀的实践方法，这些经验被称为“最佳实践”。
最佳实践包括：
- 迭代式软件开发
- 需求管理
- 基于构件的架构应用
- 建立可视化的软件模型
- 软件质量严重
- 软件变更控制等
RUP的静态结构包括6个核心工作流（业务建模、需求、分析设计、实现、测试、部署）和3个核心支持工作流（配置与变更管理、项目管理、环境）
RUP把软件的生命周期划分成4个连续的阶段。每个阶段都有明确的目标，并且定义了用来评估是否达到这些目标的里程碑。每个阶段的目标通过一次或多次迭代来完成。
4个阶段的工作目标包括：初始阶段、精华阶段、构建阶段、移交阶段。
RUP模型采用迭代开发，通过多次执行不同的开发工作流，逐步确定一部分需求分析和风险，在设计、实现并确认这部分后，再去做下一部分的需求分析、设计、实现和确认工作，依次进行下去，直到整个项目完成，这样能够在逐步集成中更好地理解需求，构建一个健壮的体系结构。
3、过程评估与CMM/CMMI的基本概念
答：
1）CMM(Capability Maturity Model)即能力成熟度模型，是美国卡耐基梅隆大学软件工程研究所（SEI）在美国国防部资助下于二十世纪八十年代末建立的，用于评价软件机构的软件过程能力成熟度的模型。此模型在建立和发展之初，主要目的在于提供一种评价软件承接方能力的方法，为大型软件项目的招投标活动提供一种全面而客观的评审依据。而发展到后来，又同时被软件组织用于改进其软件过程。（《复旦大学软件工程ppt》）
CMM提供了一个成熟度等级框架：
- 1级-初始级
- 2级-可重复级
- 3级-已定义级
- 4级-已管理级
- 5级-优化级
2）美国国防部、美国国防工业委员会和SEI/CMU于1998年启动CMMI项目，希望CMMI是若干过程模型的综合和改进，是支持多个工程学科和领域的系统的、一致的过程改进框架，能适应现代工程的特点和需要，能提高过程的质量和工作效率。（《复旦大学软件工程ppt》）
3）CMMI模型为每个学科的组合都提供两种表示法：阶段式模型和连续式模型。
4、敏捷宣言与敏捷过程的特点
1）敏捷宣言：
（《复旦大学软件工程ppt》）
（1）个人和交互高于过程和工具
不是否定过程和工具的重要性，而是强调软件开发中人的作用和交流的作用。软件是由人组成的团队来开发的，与软件项目相关的各类人员通过充分的交流和有效的合作，才能成功地开发出得到用户满意的软件。
如果光有定义良好的过程和先进的工具，而人员的技能很差，又不能很好地交流和协作，软件是很难成功地开发的。
（2）可运行软件高于详尽的文档
通过一个可运行的软件了解软件做了什么，远比阅读厚厚的文档要容易得多。
敏捷软件开发强调不断地快速地向用户提交可运行的软件（不一定是完整的软件），以得到用户的认可。
好的必要的文档仍是需要的，它帮助我们理解软件做什么，怎么做，以及如果使用，但软件开发的主要目标时创建可运行的软件。
（3）与客户协作高于合同（契约）谈判
只有客户才能明确说明需要什么样的软件，然而，大量的实践表明，在开发的早期客户常常不能完整地表达他们的全部需求，有些早期确定的需求，以后也可能会改变。
要想通过合同谈判的方式，将需求固定下来常常是困难的。
敏捷软件开发强调与客户的协作，通过与客户的交流和紧密合作来F爱心那用户的需求。
（4）对变更及时做出反应高于遵循计划
任何软件项目的开发都应该制订一个项目计划，以确定开发任务的优先顺序和起止日期。然而，随着项目的进展，需求、业务环境、技术等都可能变化，任务的优先顺序和起止日期也可能因种种原因会改变。
因此，项目计划应具有可塑性，有变动的余地。当出现变化时几十做出反应，修订计划以适应变化。
2)敏捷过程的特点
（《复旦大学软件工程ppt》）
（1）最优先的是通过尽早地和不断地提交有价值的软件使用户满意
（2）欢迎变化的需求，即使该变化出现在开发后期，为了提升对客户的竞争优势，Agile过程利用变化作为动力。
（3）以几周到几个月为周期，尽快、不断地发布可运行软件
（4）在整个项目过程中，业务人员和开发人员必须天天一起工作
（5）以积极向上的员工为中心建立项目组，给予他们所需要的环境和支持，对他们的工作予以充分的信任
（6）项目组内效率最高、最有效的信息传递方式是面对面的交流
（7）测量项目进展的首要依据是可运行的软件
（8）敏捷过程提倡可持续的开发，项目发起者、开发者和用户应能长期保持恒定的速度
（9）应时刻关注技术上的精益求精和好的设计，以增强敏捷性
（10）简单化是必不可少的，这是尽可能减少不必要工作的艺术
（11）最好的架构、需求和设计出自于自我组织的团队
（12）团队要定期反思怎样才能更有效，并据此调整自己的行为
二、软件需求
1、软件需求的概念
答：
主观需求：用户解决一个问题或达到一个目标所需要的一种状态或能力；
客观需求：系统为了满足一种约定、标准、规格说明或其它正式文件而必须满足或拥有的一种状态或能力；
功能性需求：
- 系统需要提供的服务或功能：如图书检索；
- 系统对特定输入的处理方式：如对非法输入的提示；
- 系统在特定环境下的行为：如长时间无操作的屏保；
非功能性需求：
- 对系统功能或服务附加的质量约束，例如响应时间、容错性、安全性等-客户所关心的（外部质量）；
- 从系统开发和维护角度的质量属性，例如可理解下、可扩展性等-软件开发或维护者所关心的（内部质量、软件所持有）
2、需求工程的基本过程
答：
需求获取、需求分析与协商、系统建模、需求规约、需求验证、需求管理
3、分层数据流模型
答：
分层数据流图的设计方法
第一步，画子系统的输入输出
把整个系统视为一个大的加工，然后根据数据系统从哪些外部实体接受数据流，以及系统发送数据流到哪些外部实体，就可以画出输入输出图。这张图称为顶层图。
第二步，画子系统的内部
把顶层图的加工分解成若干个加工，并用数据流将这些加工连接起来，使得顶层图的输入数据经过若干加工处理后，变成顶层图的输出数据流。这张图称为0层图。从一个加工画出一张数据流图的过程就是对加工的分解。可以用下述方法来确定加工：在数据流的组成或值发生变化的地方应该画出一个加工，这个加工的功能就是实现这一变化，也可以当作一个单位来处理（这些数据一起到达、一起处理）时，可以把这些数据看成一个数据流。关于数据存储，对于一些以后某个时间要使用的数据，可以组织成为一个数据存储来表示。
第三步，画加工的内部
把每个加工看作一个小系统，把加工的输入输出数据流看成小系统的输入输出流。于是可以像画0层图一样画出每个小系统的加工DFD图。
第四步，画子加工的分解图
对第三步分解出来的DFD图中的每个加工，重复第三步的分解过程，直到图中尚未分解的加工都是足够简单的（即不可再分解）。至此，得到一套分层数据流图。
第五步，对数据流图和加工编号
对于一个软件系统，其数据流图可能有许多层，每一层又有许多张图。为了区分不同的加工和不同的DFD子图，应该对每张图进行编号，以便于管理。
- 顶层图只有一张，图中的加工也只有一个，所以不必为其编号。
- 0层图只有一张，图中的加工号分别为0.1、0.2、…,或者1,2.
- 子图就是父图中被分解的加工号。
- 子图中的加工号是由图号、圆点和序号组成，如：1.12、1、3等等。
4、用例和场景建模及其UML表达（用例图、活动图、泳道图、顺序图）
用例图：
用例是对一个活动者使用系统的一项功能时所进行的交互过程的一个文字描述序列。对系统的用户需求的描述，表达的是系统的功能和所提供的服务，它只描述活动者和系统在交互过程中做些什么，并不描述怎么做。
活动图：
活动图是状态图的一种特殊情况。用于简化描述一个过程或者操作的工作步骤。活动用圆角矩形表示-比状态图更窄，更接近椭圆。一个活动中的处理一旦完成，则自动引起下一个活动的发生。箭头表示从一个活动转移到下一个活动。和状态图类似，活动图中的起点用一个实心圆表示，终点用一个同心圆（内圆是实心圆）表示。在活动图中可以带判定点，即一组条件引发一条执行路径，另一组条件则引发另一条执行路径，并且这两条执行路径时互斥的。判定点常用小的菱形图标表示，同时在相关路径的附近指明引起这条路径被执行的条件，条件用方括号括起来。请用活动图描述打电话过程。
泳道图：
泳道将活动图中的活动划分为若干组。并将一组指定给负责这组活动的业务组织。在活动图中，泳道使用垂直的实线绘制。
顺序图：
顺序图是强调消息时间的交互图，其描述了对象之间传送消息的时间顺序，用来表示用例中的行为顺序。在该二维图中，对象由左至右排列，消息则沿着纵轴由时间顺序排列。在构筑改图时，应布局简洁。
示意图，购买小车简图。
5、数据模型建模及其UML表达（类图）
答：
类图（Class Diagram）是描述类、接口、协作以及它们之间关系的图，用来显示系统中各个类的静态结构。类图是定义其他图的基础，在类图基础上，可以使用状态图、协作图、组件图和配置图等进一步描述系统其他方面的特性。
在UML中，类被表述成为具有相同结构、行为和关系的一组对象的描述符号。所用的属性与操作都被附在类中。类定义了一组具有状态和行为的对象。其中，属性和关联用来描述状态。属性通常使用没有身份的数据值来表示，如数字和字符串。关联则使用有身份的对象之间的关系表示。行为由操作来描述，方法是操作的具体实现。对象的生命周期则由附加给类的状态机来描述。
在UML的图形表示中，类的表示法是一个矩形，这个矩形由三个部分构成，分别是类的名称（Name）、类的属性（Attribute）和类的操作（Operation）。类的名称位于矩形的顶端，类的属性位于矩形的中间部位，而矩形的底部显示类的操作。中间部位不仅显示类的属性，还可以显示属性的类型以及属性的初始化值等。矩形的底部也可以显示操作的参数表和返回类型等，如图1所示。
在类的构成中还应当包含类的职责（Resopnsibility）、类的约束（Constraint）和类的注释（Note）等信息。
6、行为模型建模及其UML表达（状态机图）
答：
状态机图是用来为对象的状态及造成状态改变的事件建模。UML的状态机图主要用于建立对象类或对象的动态行为模型，表现一个对象所经历的状态序列，引起状态或活动转移的事件，以及因状态或活动转移而伴随的动作。状态机图也可用于描述Use Case，以及全系统的动态行为。
三、软件设计与构造
1、软件体系结构及体系结构风格的概念
答：
软件体系结构（百度版）：具有一定形式的结构化元素，即构件的集合，包括处理构件、数据构件和连接构件。处理构件负责对数据进行加工，数据构件是被加工的信息，链接构件把体系结构的不同部分分组组合连接起来。这一定义注重区分处理构件、数据构件和连接构件，这一方法在其他的定义和方法中基本上得到保持。由于软件系统具有的一些共同特性，这种模型可以在多个系统之间传递，特别是可以应用到具有相似质量属性和功能需求的系统中，并能够促进大规模软件的系统级复用。
软件体系结构（指定教材版本）：程序或计算机系统的软件体系结构是指系统的一个或者多个结构，它包括软件构件、构件的外部可以见属性以及它们之间的相互关系。
体系结构并非可运行的程序。它是一种表达，能达到以下三种目的：
1）对设计在满足既定需求方面的有效性分析
2）在设计变更相对容易的阶段，考虑体系结构可能的选择方案
3）降低与软件构建相关的风险
体系结构风格：对软件体系结构风格的研究和实践促进了对设计的复用，一些经过实践证实的解决方案也可以可靠地用于解决新的问题。体系结构风格的不变部分使不同的系统可以分享同一个实现代码。只要系统是使用常用的、规范的方法来组织，就可使别的设计者很容易地理解系统的体系结构。例如，如果某人把系统描述为“客户/服务器”模式，则不必给出设计细节，我们立刻就会明白系统是如何组合和工作的。
下面是Garlan和Shaw对通用体系结构风格的分类：
1）数据流风格：批处理序列；管道/过滤器
2）调用/返回风格：主程序/子程序；面向对象风格；层次结构
3）独立构件风格：进程通讯；事件系统
4）虚拟机风格：解释器；基于规则的系统
5）仓库风格：数据库系统；超文本系统；黑板系统
2、设计模式的概念（来自百度）
答：
软件设计模式（Design Pattern），又称设计模式，是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性、程序的重用性。
3、模块化设计的基本思想及概念（抽象、分解、模块化、封装、信息隐藏、功能独立）（来自教材）
1)模块化：模块化设计思想是把整个软件划分为几个独立命名的或者独立访问的构成成分，这些模块集合起来就满足了问题的需要，就能把一个大而复杂的软件系统划分成易于理解的比较单纯的模块化结构。
模块化的要求：需要满足信息隐蔽原则，模块之间相互独立，并且尽量符合高内聚低耦合的要求。
2）封装：是一种信息隐蔽技术，用户只能看到对象封装界面上的信息，对象的内部实现对用户是隐蔽的。封装的目的是使对象的使用和生产者分离。使对象的定义和实现分开。一个对象通常由对象名、属性和操作三部分组成。
3）信息隐蔽：每个模块的实现细节对于其它模块来说是隐蔽的（不可访问），即模块中所包含的信息（数据和过程）不允许其它不需要这些信息的模块使用。
信息隐蔽作用：设计时把一些可能发生变化的因素隐蔽在某个模块中，以提高可维护性，并且可以减少错误向外传播。
4、软件重构的概念；软件体系结构的UML建模（包图、类图、构件图、顺序图、部署图）；（来自博客与教材）
答：
1）重构：以不改变代码外部行为而改进其内部结构的方式来修改软件系统的过程。这是一种净化代码以尽可能减少引入错误的严格方法。
2)包图（略，非重点）：属于静态图的一种
3）类图（重点）：展示系统类的静态结构，即类与类之间的相互联系。
4)构件图
构件图显示代码的静态结构、是用代码组件来显示代码物理结构的。
5）顺序图（重点）
用来显示对象之间发送消息的顺序，以及对象之间的交互，例题：
6）部署图（略，非重点）
展现系统中硬件和软件的物理机构
5、接口的概念；面向对象设计原则（开闭原则、Liskov替换原则、依赖转置原则、接口隔离原则）
开闭原则：
类的改动是通过增加代码进行的，而不是修改源代码。
里氏代换原则：
任何抽象类出现的地方都可以用他的实现类进行替换，实际就是虚拟机制，语言级别实现面向对象功能。
依赖倒转原则：
依赖于抽象（接口），不要依赖具体的实现（类），也就是针对接口编程。
接口隔离原则：
不应该强迫用户的程序依赖他们不需要的接口方法。一个接口应该只提供一种对外功能，不应该把所有的操作都封装到一个接口中去。
6、内聚与耦合的概念，常见的内聚和耦合类型
答：
“高内聚，低耦合”
起因：模块独立性指每个模块只完成系统要求的独立子功能，并且与其他模块的联系最少且接口简单，两个定性的度量标准-耦合性和内聚性。
耦合性也称块间联系。指软件系统结构中各模块间互相联系紧密程度的一种度量。模块之间联系越紧密，其耦合性就越强，模块的独立性则越差。模块间耦合高低取决于模块间接口的复杂性、调用的方式及传递的信息。
耦合性分类（低-高）：无直接耦合；数据耦合；标记耦合；控制耦合；公共耦合；内容耦合；
1）无直接耦合：两个模块之间没有直接联系，它们之间的联系完全是通过主模块的控制和调用来实现的；
2）数据耦合：指两个模块之间有调用关系，传递的是简单的数据值，相当于高级语言的值传递；
3）标记耦合：指连个模块之间传递的是数据结构，如高级语言中的数组名、记录名、文件名等这些名字即标记，其实传递的是这个数据结构的地址；
4）控制耦合：指一个模块调用另外一个模块时，传递的是控制变量（如开关、标志等），被调模块通过该控制变量的值有选择地执行块内某一功能；
5）公共耦合：指通过一个公共数据环境相互作用的那些模块间的耦合。公共耦合的复杂程序随耦合模块的个数增加而增加。
6）内容耦合：这是最高程度的耦合，也是最差的耦合。当一个模块直接使用另一个模块的内部数据，或通过非正常入口而转入另一个模块内部。
内聚性又称块内联系。指模块的功能强度的度量，即一个模块内部各个元素彼此结合的紧密程度的度量。若一个模块内各元素（语名之间、程序段之间）联系的越紧密，则它的内聚性就越高。
内聚性分类（低-高）：偶然内聚；逻辑内聚；时间内聚；通信内聚；顺序内聚；功能内聚；
1）偶然内聚：指一个模块内的各处理元素之间没有任何联系。
2）逻辑内聚：指模块内执行几个逻辑上相似的功能，通过参数确定该模块完成哪一功能。
3）时间内聚：把需要同时执行的动作组合在一起形成的模块称为时间内聚模块。
4）通信内聚：指模块内所有处理元素都在同一个数据结构上操作（有时称之为信息内聚），或者指各处理使用相同的输入数据或者产生相同的数据数据。
5）顺序内聚：指一个模块中各个处理元素都密切相关于同一功能且必须顺序执行，前一功能元素输出就是下一个功能元素的输入。
6）功能内聚：这是最强的内聚，指模块内所有元素共同完成一个功能，缺一不可。与其他模块耦合是最弱的。
耦合性与内聚性是模块独立性的两个定性标准，将软件系统划分模块时，尽量做到高内聚低耦合，提高模块独立性，为设计高质量的软件结构奠定基础。
四、软件测试
1、软件测试及测试用例的概念；
答：
软件测试是在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。
测试用例是为了某个特殊的目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。
2、单元测试、集成测试、确认测试、系统测试、回归测试的概念；
答：
单元测试：又称模块测试，着重对软件设计的最小单位（程序模块）进行验证。单元测试根据设计描述，对重要的控制路径进行测试，以发现各个模块内部的错误。单元测试通常采用白盒测试，并且多个模块并行进行测试。
集成测试：又称组装测试。、联合测试，经单元测试后，每个模块都能独立工作，但把它们放在一起往往不能正常工作。确认测试以软件需求规格说明书为依据，检查软件的功能和性能及其它特写是否与用户的需求一致，包括合同规定的全部功能和性能、文档资料（正确且合理）、其他需求（如可移植性、兼容性、错误恢复能力、可维护性等）。
系统测试：是将通过确认测试的软件，作为整个基于计算机系统的一个元素，与其它系统成分（如硬件、外设、某些支持软件、数据和人员等）集成起来，在实际运行环境下，对计算机系统进行一系列的集成测试和确认测试。系统测试的目的在于通过与系统的需求定义作比较，发现软件与系统定义不符合或与之矛盾的地方。
回归测试：是指修改旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产出错误。
3、调试的概念、调试与测试的关系；
答：
测试的目的是发现错误，调试（也称排错）的目的是确定错误的原因和准确位置，并加以纠正。
调试与测试的关系：测试和调试在目标、方法和思路上都有所不同，测试是一个过程，目的是显示存在的软件错误，通常由软件测试工程师实施。而调试是一种方法，一种手段，目的是发现错误原因并解决，一般来说调试时测试后的活动，通常由开发工程师实施。
4、测试覆盖度的概念
答：
测试覆盖度评估是衡量阶段性软件测试执行状态的重要手段之一，来确定测试是否达到事先设定的测试任务完成的标准。测试覆盖率则是测试覆盖度评估中一种量化的表示方法，一般通过被测试的软件产品需求、功能点、测试用例数或程序代码等来进行计算。
5、白盒测试、黑盒测试的概念
答：
白盒测试又称结构测试，这种方法把测试对象看作一个透明的盒子，测试人员根据程序内部的逻辑结构及有关信息涉及测试用例，检查程序中所有逻辑路径是否按预定的要求正确地工作。
黑盒测试又叫做功能测试，这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。
6、代码圈复杂度的计算方法
答：
圈复杂度是一种代码复杂度的衡量标准。在软件测试的概念里，圈复杂度用来衡量一个模块判定结构的复杂程度，数量上表现为独立线性路径条数，即合理的预防 错误所需测试的最小路径条数，圈复杂度大说明程序代码可能质量低且难以测试和维护，根据经验，程序的可能错误和高的圈复杂度有很大关系。它的计算方法为：V（G）=e-n-2p。e表示控制流图中边的数量，n表示控制流图中节点的数量，p表示图的连接组件数目（图的组件数是相连节点的最大集合），因为控制流图都是连通的，所以p永远为1
V（G）=区域数=判定节点数+1
V（G）=R。R代表平面被控制流图划分成的区域数
7、白盒测试中的基本路径测试方法
答：
基本路径测试是一种白盒测试技术，这种方法首先根据程序或设计图画出控制流图，并计算其区域数，然后确定一组组里的程序执行路径（称为基本路径），最后为每一条基本路径设计一个测试用例。在实际问题中，一个不太复杂的程序，其路径数可能很大，特别在包含循环时。因此要把覆盖的路径数压缩到一定的限度内。
8、黑盒测试中等价类划分方法
答：
等价类划分是指由于不能穷举所有可能的输入数据来进行测试，所以只能选择少量有代表性的输入数据，来揭露尽可能多的程序错误，等价类划分方法将所有可能的输入数据划分成若干个等价类，然后在每个等价类中选取一个代表性的数据作为测试用例，测试用例由有效等价类和无效等价类的代表组成，从而保证测试用例具有完整性和代表性。
mg-5OugY4Ha-1607958334409)]
V（G）=区域数=判定节点数+1
[外链图片转存中…(img-Paxa2fta-1607958334410)]
V（G）=R。R代表平面被控制流图划分成的区域数
[外链图片转存中…(img-wcfd9uYF-1607958334410)]
7、白盒测试中的基本路径测试方法
答：
基本路径测试是一种白盒测试技术，这种方法首先根据程序或设计图画出控制流图，并计算其区域数，然后确定一组组里的程序执行路径（称为基本路径），最后为每一条基本路径设计一个测试用例。在实际问题中，一个不太复杂的程序，其路径数可能很大，特别在包含循环时。因此要把覆盖的路径数压缩到一定的限度内。
8、黑盒测试中等价类划分方法
答：
等价类划分是指由于不能穷举所有可能的输入数据来进行测试，所以只能选择少量有代表性的输入数据，来揭露尽可能多的程序错误，等价类划分方法将所有可能的输入数据划分成若干个等价类，然后在每个等价类中选取一个代表性的数据作为测试用例，测试用例由有效等价类和无效等价类的代表组成，从而保证测试用例具有完整性和代表性。