软件测试基础知识二（期末复习提纲）

一、软件缺陷的基本概念。

p 从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题；

p 从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。

如以下五种：

（1）软件未达到产品说明书中已经标明的功能；

（2）软件出现了产品说明书中指明不会出现的错误；

（3）软件未达到产品说明书中虽未指出但应当达到的目标；

（4）软件功能超出了产品说明书中指明的范围；

（5）软件测试人员认为软件难以理解、不易使用，或者最终用户认为该软件使用效果不良。

二、软件测试定义。

² 发现并指出软件（包含软件经过建模、需求、设计等阶段所产生的大量输出工件及程序代码）中存在缺陷的过程，这个过程指明和标注问题存在的正确位置，详细记录导致问题出现的操作步骤，存储当时的错误状态，以上组合在一起便于测试后问题能够准确再现。

三、软件工程与软件测试的关系。

        软件测试是软件工程的必要组成部分。

        测试在开发阶段的作用如下：

（1）项目规划阶段：负责从单元测试到系统测试的整个测试阶段的监控。

（2）需求分析阶段：确定测试需求分析、系统测试计划的制定。

（3）概要设计和详细设计阶段：确保集成测试计划和单元测试计划完成。

（4）编码阶段：由开发人员进行自己负责部分的测试代码。

四、软件测试的分类：按照开发阶段划分，按照测试技术划分，按照测试实施组织划分。

•
按照开发阶段划分

–
单元测试：模块测试，检查每个程序单元能否正确实现详细设计说明中的模块功能等。

–
集成测试：组装测试，将所有的程序模块进行有序、递增的测试，检验程序单元或部件的接口关系

–
系统测试：检查完整的程序系统能否和系统（包括硬件、外设和网络、系统软件、支持平台等）正确配置、连接，并满足用户需求。

–
确认测试：证实软件是否满足特定于其用途的需求，是否满足软件需求说明书的规定。

–
验收测试：按照项目任务或合同，供需双方签订的验收依据文档进行的对整个系统的测试与评审，决定是否接受或拒收系统。

•
按照测试技术划分

–
白盒测试：通过对程序内部结构的分析、检测来寻找问题。检查是否所有的结构及逻辑都是正确的，检查软件内部动作是否按照设计说明的规定正常进行。–结构测试

–
黑盒测试：通过软件的外部表现来发现错误，是在程序界面处进行测试，只是检查是否按照需求规格说明书的规定正常实现。

–
灰盒测试：介于白盒测试与黑盒测试之间的测试，关注输出对输入的正确性；同时，也关注内部表现，不像白盒那样详细，只是通过一些表征性现象、事件、标志来判断内部的运行状态。

•
按照测试实施组织划分

•
开发方测试：在开发环境下，开发方对提交的软件进行全面的自我检查。

•
用户测试：在用户的应用环境中，用户通过运行软件，检测软件实现是否符合自己预期的要求。

•
第三方测试：介于软件开发方和用户方之间的测试组织的测试。

五、软件测试的原则。

• 1 完全测试的不可能性

• 2 软件测试是有风险的活动

•
3.测试无法显示潜伏的软件缺陷和故障

•
4. 充分注意测试中的群集现象

•
5.杀虫剂现象

•
6.并非所有的软件缺陷都要修复

• 7.难以描述的软件缺陷

• 8. 80-20 原则

•
9.软件测试必须有预期结果

•
10. 应当把“尽早地和不断地进行软件测试”作为软件测试者的座右铭

•
11. 程序员应该避免检查自己的程序

•
12 追溯至用户需求

13 及时更新测试

六、软件测试关键问题。

• （1）测试由谁来执行？

软件测试可分为开发方测试、用户测试（β测试）、第三方测试.

开发方测试：

主要是指在软件开发完成以后，开发方对要提交的软件进行全面的自我检查与验证。

用户测试：

在用户的应用环境下，用户通过运行和使用软件，检测与核实软件实现是否符合自己预期的要求。

第三方测试：

  由在技术、管理和财务上与开发方和用户方相对独立的组织进行的软件测试。

• （2）测试什么？

软件开发过程中产生的需求分析、概要设计、详细设计以及编码等各个阶段所得到的文档，包括需求规格说明、概要设计说明、详细设计规格说明以及源程序。

• （3）什么时候进行测试。

测试可以是一个与开发并行的过程，也可以是开发完成某个阶段任务后的活动。

• （4）怎样进行测试。

根据软件的功能规范说明和程序实现，利用各种测试方法，生成有效的测试用例，对软件进行测试。

• （5）测试停止的标准是什么

实用的停止测试标准应该基于以下几个因素：

（1）成功地采用了具体的测试用例设计方法；

（2）每一类覆盖的覆盖率；

（3）故障检测率（即每一单元测试时间内检测出的故障数）低于指定的限度。

（4）检测出故障的具体数量或消耗的具体时间等。

常用的停止测试的标准有5类：

•
测试超过了预定的时间，停止测试；

•
执行了所有测试用例但没有发现故障，停止测试；

•
使用特定的测试用例设计方法作为判断测试停止的基础；

•
正面指出测试停止的要求，比如发现并修改70个软件故障；

•
根据单位时间内查出故障的数量决定是否停止测试。

七、软件测试中的误区。

n 误区1 调试和测试是一样的

n 误区2软件测试对象就是程序

n 误区3 软件测试是测试人员的事情，与开发人员无关

n 误区4好的软件质量是通过测试得到的

n 误区5把不合格的开发人员安排做测试

n 误区6关注于测试的执行而忽略测试的设计

n 误区7测试自动化是万能的

n 误区8测试是为了证明软件的正确性

八、软件质量的定义。

软件产品满足规定的和隐含的与需求能力有关的全部特征和特性：

(1) 软件产品质量满足用户要求的程度；

(2) 软件各种属性的组合程度；

(3) 用户对软件产品的综合反映程度；

(4) 软件在使用过程中满足用户要求的程度。

九、RUP 软件质量的三个维度。

1、 功能（Functionality）：按照既定意图和要求，执行指定用例的能力。

2、可靠性（Reliability ）：软件坚固性和可靠性（防故障能力，如防止崩溃、内存丢失等能力）、资源利用率、代码完整性以及技术兼容性等。

3、性能（Performance）：用来衡量系统占用系统资源(CPU时间、内存)和系统响应、表现的状态

十、软件产品质量属性。

• 功能性
  Functionality

• 可用性
  Usability (简单安装; 轻松使用; 友好界面)

• 可靠性
  Reliability (用户使用的根本)

• 性能
  Performance

• 容量
  Capacity

• 可测量性
  Scalability

• 可维护性
  Service manageability

• 兼容性
  Compatibility

• 可扩展性 Extensibility

十一、设计测试用例的三个基本准则。

•
测试用例的代表性

能够代表并覆盖各种合理的和不合理的、合法的和非法的、边界的和越界的以及极限的输入数据、操作和环境设置等。

•
测试结果的可判定性

即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果。

• 测试结果的可再现性

即对同样的测试用例，系统的执行结果应当是相同的。

十二、黑盒测试用例设计的几种方法。

•
（一）等价类划分法

•
（二）边界值分析法

•
（三）决策表法

•
（四）因果图法

•
（五）场景法

•
（六）正交表法

十三、等价类划分法的思想

•
等价类划分设计方法是把所有可能的输入数据，即程序的输入域划分成若干部分（子集），然后从每一个子集中选取少量具有代表性的数据作为测试用例。

十四、等价类的类型。

（1）有效等价类

• 对规格说明而言，有意义、合理的输入数据所组成的集合；

• 检验程序是否实现了规格说明预先规定的功能和性能。

（2）无效等价类

对规格说明而言，无意义的、不合理的输入数据所组成的集合；

检查被测对象的功能和性能的实现是否有不符合规格说明要求的地方。

十五、边界值分析法基本概念。

边界值分析法就是
对输入或输出的边界值进行测试的一种黑盒测试方法。

通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。

十六、决策表法思想

决策表是分析和表达多逻辑条件下执行不同操作情况的工具。

•
在一些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合，即：针对不同逻辑条件的组合值，分别执行不同的操作。决策表很适合于处理这类问题。

十七、决策表的组成。

Ø 条件桩—列出问题的所有条件

Ø 条件项—针对条件桩给出的条件列出所有可能的取值

Ø 动作桩—列出问题规定的可能采取的操作

Ø 动作项—指出在条件项的各组取值情况下应采取的动作

十八、正交表的概念

正交表是一个n行c列的表，其中第j列由数码1，2，… Sj 组成，这些数码均各出现n/Sj 次。其中，n代表试验次数，c代表因素数，1,2,…Sj代表某个因素的水平（取值）。

ž 因子（因素）（ Factor）

¡ 在一项试验中，凡欲考察的变量称为因素（变量）

ž 水平（位级） （Level）

¡ 在试验范围内，因素被考察的值称为水平（变量的取值）

ž 正交试验设计

¡ 是研究多因素多水平的一种设计方法，它是根据正交性从全面试验中挑选出部分有代表性的点进行试验，这些有代表性的点具备了
“均匀分散，齐整可比 ”的特点，正交试验设计是一种基于 正交表 的、高效率、快速、经济的试验设计方法。

十九、正交表的构成。

ž 行数 (Runs)：正交表中的行的个数，即试验的次数。

ž 因素数 (Factors)：正交表中列的个数。

ž 水平数 (Levels)：任何单个因素能够取得的值的最大个数。正交表中包含的值为从
0到“水平数-1”或从 1到“水平数
”

正交表的表示形式：
L行数 (水平数 因素数 )

二十、白盒测试定义

• 白盒测试将被测程序看作一个打开的盒子，测试者能够看到被测源程序，可以分析被测程序的内部结构，此时测试的焦点集中在根据其内部结构设计测试用例。

•
又称为 结构测试
或 逻辑驱动测试

二十一、白盒测试遵循的原则

Ø
保证一个模块中的所有独立路径至少被测试一次。

Ø
所有逻辑值均需测试真 (true) 和假 (false) 两种情况。

Ø
保证程序的内部数据结构的有效性。

Ø
在上下边界及可操作范围内运行所有循环。

二十二、白盒测试方法有哪些。

Ø
逻辑覆盖法

Ø
基本路径法

Ø
循环测试法

Ø
程序插桩法

二十三、逻辑覆盖法

主要是测试覆盖率，以程序内在逻辑结构为基础的测试。

包括以下6种类型：

u 语句覆盖

u 判定覆盖

u 条件覆盖

u 判定－条件覆盖

u 条件组合覆盖

u 路径覆盖。

语句覆盖：

• 设计若干个测试用例，运行被测程序，使得每一可执行语句至少执行一次。

判定覆盖：使得程序中每个判断的取真分支和取假分支至少经历一次。

条件覆盖：使得程序中每个判断的每个条件的可能取值至少执行一次。

判定－条件覆盖：

• 使得判断中每个条件的所有可能取值至少执行一次，同时每个判定的可能结果也至少出现一次。

条件组合覆盖：使得每个判断的所有可能的条件取值组合至少执行一次。

路径覆盖：设计足够的测试用例，覆盖程序中所有可能的路径

（第一次作业题型）

二十四、基本路径测试方法

• 从一个程序的入口开始，执行所经历的各个语句的完整过程。从广义的角度讲，任何有关路径分析的测试都可以被称为路径测试。

但对于复杂性大的程序要做到所有路径覆盖是不可能的。

• 在不能做到所有路径覆盖的前提下，如果某一程序的每一个独立路径都被测试过，那么可以认为程序中的每个语句都已经检验过了，即达到了语句覆盖。这种测试方法就是通常所说的基本路径测试法。

二十五、独立路径。

指包括一组以前没有处理的语句或条件的一条路径。

二十六、程序的控制流图

又称框图，一种程序控制结构的图形表示。

包含节点和控制流线或弧

二十七、程序环路复杂性计算方法。

• (1)流图中区域的数量即是

• (2) V(G)=E-N+2，E是流图中边的数量，N是流图中节点的数量。

• (3)V(G)=P+1, P是流图G中的判定节点数。

二十八、基本路径测试法的步骤。

(1)以详细或源代码作为基础，导出程序的控制流图。

(2)计算得到控制流图G的环路复杂度V(G)

(3)确定基本路径集，生成测试用例，确保基本路径集中每条路径的执行。

二十九、软件度量的作用

l 通过软件度量增加理解

l 通过软件度量管理软件项目，主要是计划和估算、跟踪和确认

l 通过软件度量指导软件过程改善，主要是理解、评估和包装。软件度量对于不同的实施对象，具有不同的效用

软件公司：改善产品质量；改善产品交付；提高生产能力；降低生产成本

项目经理：分析产品的错误和缺陷；评估现状；建立估算的基础；确定产品的复杂度

软件开发人员：可建立更加明确的作业目标；可作为具体作业中的判断标准

三十、软件质量保证模型：McCall模型；Boehm模型

McCall 软件质量模型 (GE模型,1977) 由11个指标构成,分为

产品操作：

正确性：一个程序满足她的需求规约和实现用户任务目标的程度

可使用性：学习、操作、准备输入和解释程序输出所需的工作量

完整性：对未授权人员访问软件或数据的可控制程度

可靠性：一个程序满足一所需的精确度完成它的预期功能的程度

效率：一个程序完成其功能所需的计算资源和代码的度量

        产品修订：

可维护性：定位和修复程序中一个错误所需的工作量

可测试性：测试一个程序以确保她完成所期望的功能所需的工作量

灵活性：修改一个运行的程序所需的工作量。

        产品转移：

互连性：连接一个系统和另一个系统所需的工作量

可移植性：把一个程序从一个硬件和或软件系统环境移植到另一个环境所需的工作量。

可复用：性一个程序可以在另外一个应用程序中复用的程度

Boehm 模型 (1978) 基于很多特性和 19个标准

可移植性

有效性：可靠性、效率、运行工程

可维护性：测试性、可理解性、可修改性

McCall模型：

Boehm模型。

⭐三十一、软件测试的执行过程 和 生命周期。

•
软件测试执行过程分为单元测试、集成测试、确认测试、系统测试、验收测试和回归测试

⭐生命周期 / 基本过程：

1、
拟定软件测试计划。包括测试需求、测试策略、测试资源、测试进度

2、
编制软件测试大纲。说明测试内容、参考资料、测试阶段等

3、
设计和生成测试用例。

4、
实施测试。包含测试的执行过程。

5、
生成软件测试报告。

三十二、单元测试的概念，

软件系统由多个单元组成，这些单元可能是一个具体的函数（function或procedure）、一个模块、一个类或一个类的方法（method）。

如果一个单元可以清晰的与同一程序的其他单元划分开来，就可以把它作为软件一个的单元，进行单元测试。

三十三、单元测试的目的。

– 跟踪需求和设计的实现是否一致；

– 验证代码是否与设计相符合；

– 发现设计和需求中存在的错误；

– 发现在编码过程中引入的错误。

三十四、集成测试基本概念

• 集成测试又称组装测试，是在单元测试的基础上，将所有模块按照设计要求组装成子系统或系统进行的测试活动。

• 又称子系统测试、联合测试。

三十五、集成测试分类

1、大爆炸式

2、增量式集成（自顶向下集成，自底向上集成，混合式集成）

三十六、集成测试的层次，集成测试划分的三个级别。

（1）模块内集成测试。

（2）子系统内集成测试：先测试子系统内的功能模块，然后将各个功能模块组合起来确认子系统的功能是否达到预期要求。

（3）子系统间集成测试：测试的单元是子系统之间的接口。子系统是可单独运行的程序或进程。

三十七、确认测试的概念。

•
又称合格性测试，用来检验软件是否符合用户的需求。

三十八、系统测试的定义

•
系统测试就是针对非功能特性展开的，验证软件产品符合质量特性的要求，从而满足用户和软件企业自身的非功能性需求。

三十九、系统测试的目的，

通过与系统的需求定义作比较，发现软件与系统定义不符合或与之矛盾的地方，以验证软件系统的功能和性能等满足其规约所制定的要求。

四十、系统测试的类型、系统测试从哪些方面展开

•
1.性能测试

– 用来测试软件在实际系统中的运行性能。

•
2.负载测试

– 让被测系统在其能忍受的压力的极限范围之内连续运行，来测试系统的稳定性。

•
3.强度测试

– 也称为压力测试，目的是调查系统在其资源超负荷的情况下的表现。

•
4.容量测试

– 使系统承受超额的数据容量来发现它是否能够正确处理。

•
5.安全性测试

– 验证安装在系统内的保护机构确定能够对系统进行保护，使之不受各种非正常的干扰。

•
6.配置测试

– 测试系统在不同的系统配置下是否有错误。

•
7.故障恢复测试

– 验证系统从软件或者硬件失败中恢复的能力。

•
8.安装测试

– 验证成功安装系统的能力。

•
9.文档测试

– 针对系统提交给用户的文档的验证。

– 目标是验证用户文档是正确的并且保证操作手册的过程能够正确工作。

•
10.用户界面测试

– 主要包括两个方面的内容，一方面是界面实现与界面设计的吻合情况；另一方面是确认界面处理的正确性。

四十一、系统测试与单元测试、集成测试的区别。

• (1) 测试方法不同：系统测试应用黑盒测试技术，而单元测试、集成测试一般应用白盒测试技术。

• (2) 测试范围不同：单元测试主要测试模块内部的接口、数据结构等对象；集成测试主要测试模块之间的接口和异常；系统测试主要测试接口输入到接口输出实践是否满足用户需求

• (3) 评估基准不同：系统测试的评估基准是测试用例对需求规格的覆盖率；而单元测试和集成测试的评估主要是代码和设计的覆盖率。

四十二、验收测试的概念

•
验收测试主要根据用户的需求而建立，是整个测试过程中的最后一个阶段。

四十三、验收测试的种类，

通常有Alpha测试(α测试)和Beta(β测试)测试两种形式

四十四、Alpha测试定义，

•
也称室内测试，是由一个用户在开发环境下进行的测试，也可以是开发机构内部的用户在模拟实际操作环境下进行的测试。

四十五、Alpha测试特点

        α测试版本bug较多，一般用于开发者内部交流，看看有没有系统缺陷或者功能缺失等；

四十六、Alpha测试参与人员需要遵循的原则

1、提出软件系统的修改建议或改进建议，而不仅仅是批评。

2、随时记录下对于系统的建议，建议应该足够详细，以便能指导修改；

3、按照计划进行Alpha测试，在时间不足的情况下，关注软件系统的重要部分；

四十七、Beta测试的特点

1、通常在产品发布到市场之前，邀请公司的客户参与产品的测试工作。

2、提升了产品的价值，因为它使那些“实际”的客户有机会把自己的
意见渗透到公司产品的设计、功能和使用过程中。

3、Beta测试并不是一种实验室的测试。

四十八、回归测试的定义。

•
回归测试是一种验证已变更的系统的完整性与正确性的测试技术，是指重新执行已经做过的测试的某个子集，以保证修改没有引入新的错误或者没有发现由于更改而引起之前未发现的错误。

四十九、面向对象测试层次：

在面向对象测试中，通常分为三个层次，把类看做单元，分成类测试、集成测试和系统测试。其中面向对象单元测试主要对类中的成员函数及成员函数间的交互进行测试；面向对象集成测试主要对系统内部的相互服务进行测试，如类间的消息传递等；面向对象系统测试是基于面向对象集成测试的最后阶段的测试，主要以用户需求为测试标准。

面向对象分析的测试的主要内容；

1·对象测试；

在OOA测试中，对象是对问题空间中的结构、其他系统、设备、被记忆的事件等实例的抽象。

2·结构测试；

认定的结构指的是多种对象的组织方式，反映了问题空间中的复杂实例和复杂关系。认定的结构可分为分类结构和组装结构两种。

3·主题测试；

主题是在对象和结构基础上的更高一层的抽象，是为了提供OOA分析结果的可见性

4·属性和实例关联的测试；

属性是用来描述对象或结构所反映的实例的特性。而实例关联是反映实例集合间的映射关系。

5·服务和消息关联的测试。

定义的服务就是定义的每一种对象和结构在问题空间中所要求的行为。由于问题空间与实例间存在必要的通信，在OOA中相应地需要定义消息关联。

五十、面向对象设计的测试的主要内容

（1）对认定的类的测试

OOD认定的类可以是OOA中认定的对象，也可以是对象所需要的服务的抽象，对象所具有的属性的抽象。

（2）对构造的类层次结构的测试

为能充分发挥面向对象的继承特性，OOD的类层次结构通常是基于从OOA中产生的分类结构的原则来组织，着重体现父类和子类间的一般性和特殊性。

（3）对类库支持的测试

虽然对类库的支持属于类层次结构的问题，但这里强调的是软件开发的重用。由于它并不直接影响当前软件的开发和功能实现，因此，可以将其单独提出来测试，也可作为对高质量类层次结构的评估。

五十一、面向对象的单元测试：单元的定义；

在面向对象语境中，单元的概念发生了变化。传统的单元测试是针对程序的函数、过程或完成某一特定功能的程序块。在面向对象单元测试中，单元的概念还没有普遍认可的定义。有人认为应该是类成员函数，也有人认为应该是类。实际上这两种观点的区别只是单元的粒度大小不同，单元的常见指导方针是：能够自身编译的最小程序块；单一过程/函数（独立）；由一个人完成的小规模工作。

五十二、以类作为一个基本测试单元，对类的测试的分类。

-（1） 内部方法（Intra-method）测试：为具体方法构造的测试，即传统的单元测试。

-（2） 交互方法（Inter-
method）测试：一个类中多个方法一起测试，即传统的模块测试。

-（3） 内部类（Intra-
class）测试：为单独的类构建的测试，通常是类中调用各个方法的序列。

• （4） 交互类（Inter- class）测试：同时测试至少一个类，通常要观察类之间的交互，实际上这是集成测试的一类。

五十三、面向对象的集成测试：对于类之间的集成，主要的两种集成测试策略。

• （1） 基于线程的测试（thread-based
testing）：集成一组相互协作的对某个输入或事件作出响应的类，每个线程被分别测试，并使用回归测试以保证没有副作用产生。

• （2）基于使用的测试(use-based
testing)：按层次测试系统。先测试不依赖服务器的独立类，然后测试依赖独立类的其他类。逐步增加原来类，直到测试完整个系统。

五十四、面向对象的系统测试。面向对象系统测试定义。

系统测试是指测试整个系统以确定其是否能够提供应用的所有需求行为。

五十五、软件质量指标，

p 正确性：实现的功能达到设计规范，并满足用户需求的程度

p 可靠性：规定的时间和条件下，仍能维持其性能水准的程度

p 易用性：用户掌握软件操作所要付出的时间及努力程度

p 效率：软件执行某项功能所需电脑资源（含时间）的有效程度

p 可维护性：当环境改变或软件发生错误时，执行修改或恢复所做努力的程度

p 可移植性：从一个系统/环境移到另一系统/环境的容易程度

五十六、功能性和可用性的质量指标，

功能性：

p 功能的正确性

p 功能的准确性

p 软件功能的完整性

可用性：

p 可操作性

p 通用性

p 一致性

五十七、可靠性和性能的质量指标，

可靠性：

p 系统自我恢复能力（Autonomy）

p 健壮性

p 系统的分布性

性能：

p 有效性（Efficiency）

p 安全管理/完整性

p 易存取性（System Accessibility）

五十八、ISO简化的软件质量模型。

⭐五十九、软件质量控制概念，

质量控制是一个设定标准（根据质量要求）、测量结果，判定是否达到了预期要求，对质量问题采取措施进行补救并防止再发生的过程，质量控制已不再仅仅是检验，而更多地倾向于确保生产出来的产品满足要求的过程控制。

六十、软件质量保证概念和要素

质量保证是质量管理的一部分，是为保证产品和服务充分满足消费者要求的质量而进行的有计划有组织的活动，致力于提供对满足质量要求的信任 。

p 内部质量保证是组织向自己的管理者提供信任；

p 外部质量保证是组织向外部客户或其它方提供信任。

p 复审(Review)：用结束标准对该阶段生产出的软件配置成分进行严格的技术审查等活动；

p 内审(Audit)：检查组织内部是否遵守已有的模板、规则、流程等。

⭐软件质量保证要素：

1、
标准：确保遵循所采用的标准，并保证所有工作产品符合标准。

2、
评审和审核：确保软件工程工作遵循质量准则

3、
测试：确保测试计划适当和实施有效

4、
错误、缺陷的收集和分析：了解错误，衡量对策

5、
变更管理：确保足够的变更管理实践

6、
教育：组织牵头软件过程改进

7、
安全管理：确保应用适当的过程和技术来实现软件安全

8、
安全：评估软件失效的影响，负责减少风险

9、
风险管理：确保风险管理活动适当进行

六十一、软件质量改进概念。

质量改进是质量管理的一部分，是不断为改进软件开发过程、产品和服务的持续过程。同时，为确保有效性、效率或可追溯性，组织应注意识别需要改进的项目和关键质量要求，考虑改进所需的过程，以增强组织体系、改进过程和产品并提高满足要求的能力。

在质量改进工作中，有许多模型，包括PDCA模型、PEIS模型、6 Sigma模型的DMAIC、CMM模型、SPICE模型等。

六十二、软件质量控制工具。

1检查表

2 Pareto图

3 直方图

4 运行图

5 散布图

6 控制图

7 因果图

六十三、软件配置管理的概念

SCM简单而言就是管理软件的变化，应用于软件工程过程，通常由相应的工具、过程和方法学组成。在整个软件的开发活动中占有很重要的位置。

六十四、配置项的定义。

所有在软件过程中产生的信息，总称为软件配置项，主要包括：

① 计算机程序（源代码和可执行程序）；

② 描述计算机程序的文档（针对技术开发者和用户）；

③ 数据（包含在程序内部或外部）。

六十五、软件配置控制主要包括哪些内容

① 存取控制：设定了软件开发人员对软件基准库的存取权限，保证软件开发过程及软件产品的安全性；

② 版本控制：是配置管理的基本要求，使得组织在任何时刻都可以获得配置项的任何一个版本；

③ 变更控制：为软件产品变更提供了一个明确的流程，要求任何进行配置管理的软件产品变更都要经过相应的授权与批准才能实施；

④ 产品发布：保证了提交给客户的软件产品是完整的、正确的

六十六、变更管理的实施步骤。

1、变更请求提交

缺陷和增强请求通常在请求起源和收集信息类型上不同。

2、变更请求接收

项目必须建立接收提交的变更请求并进行跟踪的机制。指定接收和处理变更请求的责任人，确认变更请求。

3、变更请求评估

     大多数机构根据请求的类型是缺陷还是增强而使用不同的评估过程。

4、变更请求决策

       决策阶段是当选择实现一个变更请求时所做出的决定，如推迟此次实施或者永远不进行实施等。缺陷和增强请求几乎总是以不同方式进行处理。

5、变更请求实现

    增强请求实现较之缺陷实现需要更多的设计工作，这是因为增强请求经常涉及新特性或新功能。另一方面，缺陷修复需要建立一个环境，在该环境中可以对缺陷进行重现并测试相应的解决方案。

6、变更请求验证

 验证发生在最终测试及文档制作阶段。增强请求的测试通常涉及验证所做变更是否满足该增强请求的需要。缺陷测试则简单的验证开发人员的修复是否真正消除了该缺陷。 

7、变更请求完成

 完成是变更请求的最终阶段，这可能是完成了一项请求或者决定不实现某一请求。在完成阶段的主要步骤是由提交请求的原有请求者中止这一循环过程。

六十七、软件可靠性的定义。

l 在规定的条件下和时间内，软件不引起系统失效的概率，该概率是系统输入和系统使用的函数，也是软件中存在的错误的函数；系统输入将确定是否会遇到已存在的错误（如果错误存在的话）；

l 在规定的时间周期内，在所述条件下程序执行所要求的功能的能力。

六十八、软件可靠性与硬件可靠性的区别。

l 最明显的是硬件有老化损耗现象，硬件失效是物理故障，是器件物理变化的必然结果，有浴盆曲线现象；软件不发生变化，没有磨损现象，有陈旧落后的问题，没有浴盆曲线现象。

¡ 硬件可靠性的决定因素是时间，受设计、生产、运用的所有过程影响，软件可靠性的决定因素是与输入数据有关的软件差错，是输入数据和程序内部状态的函数，更多地决定于人。

¡ 硬件的纠错维护可通过修复或更换失效的系统重新恢复功能，软件只有通过重设计。

l 对硬件可采用预防性维护技术预防故障，采用断开失效部件的办法诊断故障，而软件则不能采用这些技术。

l 事先估计可靠性测试和可靠性的逐步增长等技术对软件和硬件有不同的意义。

¡ 为提高硬件可靠性可采用冗余技术，而同一软件的冗余不能提高可靠性。

¡ 硬件可靠性检验方法已建立，并已标准化且有一整套完整的理论，而软件可靠性验证方法仍未建立，更没有完整的理论体系。

l 硬件可靠性已有成熟的产品市场，而软件产品市场还很新。

¡ 软件错误是永恒的，可重现的，而一些瞬间的硬件错误可能会被误认为是软件错误。

六十九、提高软件可靠性的方法和技术

1 建立以可靠性为核心的质量标准

2 选择开发方法

目前法主有Parnas、Yourdon方法等

3 软件重用

开发过程重用，指开发规范、各种开发方法、工具和标准等

软件构件重用，指文档、程序和数据等

知识重用，如相关领域专业知识的重用

4 使用开发管理工具

辅助解决开发过程中遇到的各种各样的问题，提高开发效率和产品质量

5 加强测试

测试规范包括测试设计规范、测试用例规范、测试规程规范

测试的方法多种多样

6 容错设计

在开发过程中，尽可能不让差错和缺陷潜入软件

习题

1、输入三个整数作为三边的边长构成三角形。当此三角形为一般三角形、等腰三角形、等边三角形时，分别作计算。用等价类划分方法为该程序进行测试用例设计。

2、找零钱最佳组合

• 假设商店货品价格® 都不大于100元（且为整数），若顾客付款§在100元内，现有一个程序能在每位顾客付款后给出找零钱的最佳组合（找给顾客货币张数最少）。
假定此商店的货币面值只包括：50元(N50)、10元(N10)、 5元(N5)、1元(N1) 四种。

• 请结合等价类划分法和边界值分析法为上述程序设计
出相应的测试用例。