1. 【基础题】软件有哪些分类？

答：

2. 【基础题】什么是软件测试？

答：使用人工或自动手段，运行或检查某个系统的过程。其目的在于检查它是否满足规

定的需求或弄清预期结果与实际结果之间的差别。

3. 【基础题】什么是Bug？

答：软件的Bug指的是软件中（包括程序和文档）不符合用户需求的问题。 常见的软件Bug分为以下三类：

1) 没有实现的功能

2) 完成了用户需求的功能，但是运行时会出现一些功能或性能上的问题

3) 实现了用户不需要的多余的功能

4. 【基础题】测试工作的基本原则？

答：

? 所有的软件测试都应追溯到用户需求

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

? 完全测试是不可能的，测试需要终止

? 测试无法显示软件潜在的缺陷

? 充分注意测试中地群集现象

? 程序员应避免检查自己地程序

? 尽量避免测试的随意性

5. 【基础题】黑盒测试方法有哪些？

? 答：等价类划分法，边界值分析法，因果图法，判定表驱动法，决策表法，错

误推测法，

? 正交试验法，功能图法，场景法。

【基础题】简述黑盒测试的综合策略？

? 答：首先应用场景法画出被侧软件的总体业务流程。

? 然后针对某个具体页面或模块进行等价类划分，包括输入条件和输出条件的等

价划分，将无限测试变成有效测试，这是减少工作量和提高测试效率最有效的方法。

? 在任何情况下都必须使用边界值分析方法。经验表明，用这种方法设计出的测

试用例发现程序错误的能力最强。

? 可以用错误推测法追加一些测试用例，这需要依靠测试工程师的智慧和经验。 ? 对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。如果没有达到要求

的覆盖标准，应当再补充足够的测试用例。

? 如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法

和判定表驱动法。

? 对于参数配置类的软件，要用正交试验法选择较少的组合方式达到最佳效果。 ? 功能图法也是很好的测试用例设计方法，我们可以通过不同时期条件的有效性

设计不同的测试数据。

?

? 【基础题】等价类划分法中等价类分为 有效等价类 和 无效等价类 ? 【基础题】场景法中流程分为 基本流 和 备选流 。

? 【基础题】因果图法中基本状态有 恒等 非 或 与 ，约束条件有 E（互斥）

I（包含）

? O（唯一） R（要求） M（屏蔽）

【基础题】常见的测试策略有哪些？

答：

? 界面测试

? 功能测试

? 易用性测试

? 安装卸载测试

? 兼容性测试

? 数据库测试

? 可靠性测试

? 安全性测试

? 文档测试

【基础题】Web应用测试的功能测试主要测试哪几个方面？

答：

? 链接测试

? 表单测试

? Cookies测试 6. 7. 8.

9.

10.

11.

12.

13. ? 设计语言测试 ? 数据库测试 【基础题】Web应用测试的性能测试主要测试哪几个方面？ 答： ? 连接速度测试 ? 压力测试 ? 负载测试 【基础题】Web应用系统客户端兼容性测试主要测试哪几个方面？ 答： ? 平台测试 ? 浏览器测试 【基础题】界面测试包括哪些方面？ 答： ? 整体界面测试，包括易用性，规范性，合理性，美观与协调，一致性 ? 界面元素测试，包括窗口，菜单，图标，鼠标，文字，辅助系统等 【基础题】分别解释什么是单元测试、集成测试、系统测试、验收测试以及它们之间的关系？ 答： ? 单元测试中，单元是认为规定的最小的被测功能模块，其具体含义需要根据实际情况来判定。如：在C语言中单元一般指一个函数；在Java中单元一般指一个类；在图形化软件中单元也可以指一个窗口或一个菜单。单元测试的依据主要有两个：一是源程序本身，包括代码和注释；还有一个是项目的《详细设计》文档。 ? 集成测试是单元测试的下一个阶段，是指将通过测试的单元模块组装成系统或子系统，再进行测试。重点测试不同模块的接口部分，检查各个单元模块结合到一起能否协同配合，正常运行。集成测试一般由白盒测试工程师或开发人员进行。集成测试应该在单元测试之后进行。但实际项目中，如果等到所有单元测试都完成再进行集成测试则效率太低，所以往往单元测试和集成测试同步进行。也即是：在单元测试中先测试几个单元的自身功能，然后再集成测试一下这几个单元的接口（即参数传递）。集成测试的依据是单元测试的模块以及《概要设计》文档。 ? 集成测试之后，就进行系统测试。系统测试是为了验证和确认系统是否达到其原始目标，而对集成的硬件和软件系统进行的测试。系统测试是在真实或模拟系统运行的环境下，检查完整的程序系统是否能和系统（包括硬件、外设、网络和系统平台、支持平台等）正确配置、连接，并满足用户需求等。系统测试将整个软件系统看做一个整体进行测试，包括对功能、性能，以及软件所运行的软硬件环境进行测试。主要依据是《系统需求规格说明书》文档。 ? 验收测试是指按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审，用户决定是接收或拒收系统。验收测试在系统测试后期进行，以用户测试为主，或者有测试人员等质量保障人员共同参与的测试。它是软件正式交给用户使用的最后一道工序。 【基础题】功能测试分为哪几种？

答：

? 逻辑功能测试

? 界面测试

? 易用性测试

? 安装测试

? 兼容性测试

14. 【基础题】测试过程会产生哪些文档？

答：

? 测试计划

? 测试用例

? 缺陷报告

? 测试总结报告

15. 【基础题】测试计划应包含哪些内容？

答：

? 对测试范围的界定

（在有时间约束，工作产品质量约束的情况下，唯一能够调整就是测试范围）

? 对风险的确定

（项目中总是有不确定的因素。 这些因素一旦发生之后记录对项目的顺利执

行产生相当大的消极影响。所以在项目中，首先需要识别出存在的风险。风险识别的原则可以有很多，常见的一种就是如果一件事情发生后，会对项目的进度产生较大影响，那么就可以把该事件作为一个风险。风险识别出之后，管理者需要按照这些风险制定出规避风险的方法）

? 对资源的规划

（确定完成任务需要消耗的人力资源，物资资源）

? 时间表的制定

（在识别出子任务和资源之后，我们便可以将任务，资源和时间 关联起来形

成时间进度表）

16. 【基础题】编写测试计划应该注意哪些事项？

答：

? 增强测试计划的实用性

（在制定测试计划时一定要注意针对实际项目、实际情况制定一个实用的计

划，以便指导和规划整个测试过程）

? 明确内容与过程

（明确测试的范围和内容，测试的目的，测试的开始和结束日期，给出测试文

档和软件的存放位置，测试人员的分配，指出测试的方法和工具）

? 采用评审和更新机制，保证测试计划满足实际需求

（评审是指需要采取相应的评审机制对测试计划的完整性、正确性、可行性进

行评估） ? 分别创建测试计划和测试策略

（有时为了避免测试计划篇幅过长，重点不突出，也可把测试策略从测试计划中分离出来，单独撰写一个文档

17. 【基础题】TestDirector的总体管理流程？

18.

1.

2.

3. 答： ? Specify Requirements：分析并确认测试需求。 ? Plan Tests：依据测试需求制定测试计划。 ? Execute Tests：创建测试实例并执行。 ? Track Defects：缺陷跟踪和管理，并生成测试报告和各种测试统计图表。 【基础题】TestDirector缺陷跟踪的流程？ 答： ? Add Defects：添加缺陷报告。质量保障人员、开发人员、项目经理、最终用户，都可以在测试的任何阶段添加缺陷报告。 ? Review New Defects ：分析评估新提交的缺陷，确认哪些缺陷需要解决。 ? Repair Open Defects：修复状态为Open的缺陷。 ? Test New Build：回归测试新的版本。 ? Analyze Defect Data：通过自动生成的报告和统计图表进行分析。 【基础题】业务组件（或组件）特定任务的一个或多个步骤。业务组件可能需要来自外部源或其他组件的输入值，并可向其他组件返回输出值。 【基础题】务流程。 【基础题】请简述使用QTP进行自动化测试的优点？

答：

1. 【基础题】并发：狭义的并发是指所有用户同一时刻做同一事件或操作。特例：操作同

一条数据（完全一样）；广义的并发是指用户同时与服务器交互，但有可能是在进行不同操作

2. 【基础题】吞吐量：一次测试中系统处理的客户请求的数量

3. 【基础题】吞吐率：单位时间内系统处理的客户请求的数量

4. 【基础题】可靠性测试：通过给系统加载一定的业务压力（例如资源在70%~90%的使

用率）的情况下，让应用持续运行一段时间，测试系统在这种条件下是否能够稳定运行。

5. 【基础题】负载测试：通过在被测系统上不断增加压力，直到性能指标，例如“响应时

间”超过预定指标或者某种资源使用已经达到饱和状态。

6. 【基础题】压力测试：对系统不断施加压力的测试。通过确定一个系统的瓶颈或不能接

收用户请求的性能点，来获得系统提供的最大服务级别的测试。

7. 【基础题】强度测试：迫使资源在异常的系统资源配置下运行，检查程序对异常情况的

抵抗能力，对测试系统的稳定性和扩展性都很重要。

19. 【基础题】简述性能测试流程及Loadrunner测试步骤

答：性能测试流程如下：

1) 测试需求分析

2) 测试计划的制定与评审

3) 测试用例的设计与开发

4) 测试的执行与监控

5) 分析测试结果

6) 编写性能测试报告

7) 总结测试经验

Loadrunner测试步骤如下：

1) 计划测试

2) 设计测试

3) 创建VUser脚本

4) 创建测试场景 5) 运行测试场景

测试用例

测试用例通常根据它们所关联关系的测试类型或测试需求来分类，而且将随类型和需求进行相应地改变。最佳方案是为每个测试需求至少编制两个测试用例： ·一个测试用例用于证明该需求已经满足，通常称作正面测试用例； ·另一个测试用例反映某个无法接受、反常或意外的条件或数据，用于论证只有在所需条件下才能够满足该需求，这个测试用例称作负面测试用例。

数据库

1 关系型数据库系统主要有：Access、FoxPro、SQL Server、My SQL、Oracle??

Access 小型数据库，配置简单、移植方便、但访问率比较低，适合小型网站（如个人网站）。 SQL Server 中型数据库，运行稳定、访问率高、速度快，但配置、移植比较复杂。 利用SQL Server 的导入功能可以将Acess数据库转化为SQL Server 数据库

Oracle 具有伸缩性的大型网站，访问率高。

2 SQL server 2000数据库

使用步骤：

一、启动服务管理器

二、运行企业管理器

SQL server组—local--数据库(系统数据库、用户数据库)

建立用户数据库（保存路径一般与应用程序路径根目录下的某个位置）

在用户数据库中建立数据表（包括字段、字段类型、长度的设计、数据记录的输入和编辑） 设计表（修改表的格式）

打开表（返回所有行或查询，可以修改记录）

建立存储过程

3 常用的SQL：

Select语句 ——查询数据

Insert语句 ——添加记录

Delete语句 ——删除记录

Update语句——更新记录

Select 字段列表 from 表 (where 条件)

按某一（或多个）字段升序或降序的方式排列记录。

语法为：Order By 字段1 ASC 或者

Order By 字段1 ASC [，字段2 DESC ]

2. Insert语句——添加记录

在ASP中，我们经常会添加数据到数据库中。这项任务可以由Insert语句实现。 语 法：

Insert Into 表(字段1，字段2，……)

values(字段1的值，字段2的值，……)

3. Delete语句——删除记录

可删除表中无用的记录来维护数据库。

语 法：Delete from 表 [条件]

4. Update语句——更新记录

实现数据库中数据的更新以维护数据库。

语 法：

Update 数据表名 set 字段1＝字段值1，字段2＝字段值2，…… [where 条件] 5表的操作

创建表

Create table [databasename.]tablename

(

{column_name data_type [default “default_value”] | [constraint constraint_name]}, ??

[indentity [seed,increment]]

)

第二篇：第19章 数据库测试

第十九章 数据库测试

一、 数据库测试概述

1、数据库现状：

主流数据库系统现状：

代表性作品有：Oracle、 DB2、 Sydbse 、 SQL server

2、数据库系统评测体系

（1） TPC组织提出数据库测试标准，但国际上还没有被普遍接受的数据库综合

评测体系。

（2） 863计划“数据库管理系统测试及其工具开发”课题将测试分为：产品确

认测试、标准符合性测试、基准性能测试及应用综合测试四个方面

二、 产品确认测试

（1） 系统功能测试

1、概述：从扩展性、可靠性、安全性、大数据量、系统功能和用户文档等六个方面来评估数据库的基本功能。

2、测试内容：安全配置、数据库存储管理、模式对象管理（表管理、索引管理、视图管理、约束管理、存储过程管理、触发器管理）、非模式对象管理、交互式查询工具、性能检测与调优、数据迁移工具、作业管理。

3、测试方法：使用黑匣测试方法对数据库管理系统的功能特性进行测试，以功能验证为主。

4、测试用例：设计相应测试用例对每个测试点进行考察。

（2） 可靠性测试

1、测试内容：数据库备份、故障恢复、运行稳定性、数据库复制。

2、测试方法：黑盒测试（功能验证性）

3、测试用例：对测试点分别设计测试用例（利用TPCC测试程序）

（3） 安全性测试：

1、测试内容：用户及口令管理、授权审计管理。

2、测试方法：黑盒测试

3、测试用例设计

（4） 扩展性测试：

1、测试内容：数据库跨平台支持、CPU加速比。

2、测试方法：黑盒测试，在CPU加速比中使用TPCC测试工具。

3、测试用例设计：包括WINDOWS、LINUX和SOLARIS平台。

三、 系统性能测试（详见P597-608）

1、概述①TPC对联机交易处理系统、数据仓库或决策支持系统、电子商务解决方案等特定领域制定的性能测试规范②TPC组织制定的数据库评测规范主要有：TPC-A、TPC-B、TPC-C、TPC-D、TPC-H/ TPC-R、TPC-W等。

2、TPC-C测试：规范概要、测试模型、事务说明、测试指标、测试工具、测试流程、测试结果

3、TPC-W测试：规范概要、测试模型、事务说明、测试指标、测试工具、测试流程、结果分析

4、解读TPC组织公布的性能测试报告

① 检查测试环境的建立过程

② 挤掉性价比的水分

③ 检查数据库的配置过程

④ 比较测试日期和可以供货的日期

⑤ 分析系统的可扩展性

四、 标准符合性测试（详细测试过程见P593-596）

五、数据库的接口技术

众所周知，软件安装是软件测试的第一步。现在各类C/S、B/S软件常常涉及对数据库的操作，安装过程中用户经常被数据库接口的问题搞得焦头烂额，而各种数据库接口名词也让我们眼花缭乱，下面我们就当前软件中广泛使用的一些数据库接口技术为大家做一个简单介绍：

ODBC——开放式的数据库连接，是Microsoft Windows 开放服务体系（WOSA）的一部分，是数据库访问的标准接口。它建立一组规范，并提供一组对数据库访问的标准API（应用程序编程接口），使应用程序可以应用ODBC提供的API来访问任何带有ODBC驱动程序的数据库。ODBC已经成为一种标准，目前所有关系数据库都提供ODBC驱动程序，但ODBC对任何数据源都未作优化，这也许会对数据库存取速度有影响；同时由于ODBC只能用于关系数据库，使得很难利用ODBC访问对象数据库及其他非关系数据库。使用ODBC连接数据库时，提供了三种DSN：用户DSN、系统DSN、文件DSN。用户DSN只能用于本用户，即建立此DSN的用户；系统DSN和文件DSN之间的区别只是在于连接信息的存放位置，系统DSN存放在ODBC存储区里，而文件DSN放在一个文本文件中。

推出ODBC之后，微软又推出了OLE DB。OLE DB是一个底层的数据访问接口，它基于COM接口。OLE DB对所有文件系统包括关系数据库和非关系数据库都提供了统一的接口。这些特性使得OLE DB技术比ODBC技术更加优越。现在微软已经为所有ODBC数据源提供了一个统一的OLE DB服务程序，叫做ODBC OLE DB Provider。

现在一些基于Web数据库的软件开发大多采用ADO（ActiveX Data Object）技术。这是微软最新的数据访问技术，用来同新的数据访问层OLE DB Provider一起协同工作。它是一个应用程序层次的界面，与数据库通信时还是用OLE DB。ADO封装了OLE DB中使用的大量COM接口，对数据库的操作更加方便简单。

同时其他的数据库接口还有SUN公司的JDBC-Java Database

Connectivity(Java数据库连接)、JDBC-ODBC bridge。它们主要应用用于Java程序和Jsp程序中，前者可用于访问提供JDBC驱动程序的数据库，而后者可访问所有带有ODBC驱动程序的数据库。

六、数据库测试的分类和方法

数据库, 分类：从测试过程的角度来说我们也可以把数据库测试分为 ： 系统测试

传统软件系统测试的测试重点是需求覆盖，而对于我们的数据库测试同样也需要

对需求覆盖进行保证。那么数据库在初期设计中也需要对这个进行分析,测试.例

如存储过程，视图，触发器，约束，规则等我们都需要进行需求的验证确保这些

功能设计是符合需求的.另一方面我们需要确认数据库设计文档和最终的数据库相

同，当设计文档变化时我们同样要验证改修改是否落实到数据库上。 这个阶段我们的测试主要通过数据库设计评审来实现。

集成测试

集成测试是主要针对接口进行的测试工作，从数据库的角度来说和普通测试稍微

有些区别对于数据库测试来说，需要考虑的是 ：

数据项的修改操作

数据项的增加操作

数据项的删除操作

数据表增加满

数据表删除空

删除空表中的记录

数据表的并发操作

针对存储过程的接口测试

结合业务逻辑做关联表的接口测试

同样我们需要对这些接口考虑采用等价类、边界值、错误猜测等方法进行测试

单元测试

单元测试侧重于逻辑覆盖，相对对于复杂的代码来说，数据库开发的单元测试相

对简单些，可以通过语句覆盖和走读的方式完成

系统测试相对来说比较困难，这要求有很高的数据库设计能力和丰富的数据库测

试经验。而集成测试和单元测试就相对简单了。

而我们也可以从测试关注点的角度对数据库进行分类

功能测试

对数据库功能的测试我们可以依赖与工具进行

DBunit

一款开源的数据库功能测试框架，可以使用类似与Junit的方式对数据库的基本操

作进行白盒的单元测试，对输入输出进行校验

QTP

大名鼎鼎的自动测试工具，通过对对象的捕捉识别，我们可以通过QTP来模拟用户

的操作流程，通过其中的校验方法或者结合数据库后台的监控对整个数据库中的

数据进行测试。个人觉得比较偏向灰盒。

DataFactory

一款优秀的数据库数据自动生成工具，通过它你可以轻松的生成任意结构数据库，对数据库进行填充，帮助你生成所需要的大量数据从而验证我们数据库中的功能是否正确。这是属于黑盒测试

数据库性能

虽然我们的硬件最近几年进步很快，但是我们需要处理的数据以更快的速度在增加。几亿条记录的表格在现在是司空见惯的，如此庞大的数据量在大量并发连接操作时，我们不能像以前一样随意的使用查询，连接查询，嵌套查询，视图，这些操作如果不当会给系统带来非常巨大的压力，严重影响系统性能

性能优化分4部分

1物理存储方面

2逻辑设计方面

3数据库的参数调整

4SQL语句优化.

我们如何对性能方面进行测试呢，业界也提供了很多工具通过数据库系统的SQL语句分析工具，我们可以分析得到数据库语句执行的瓶颈，从而优化SQL语句

Loadrunner

这个不用多说，我们可以通过对协议的编程来对数据库做压力测试

Swingbench（这是一个重量级别的feature，类似LR，而且非常强大，只不过专门

针对oracle而已） 数据库厂商也意识到这点，例如 oracle11g已经提供了real application test，提供数据库性能测试，分析系统的应用瓶颈。

还有很多第三方公司开发了SQL语句优化工具来帮助你自动的进行语句优化工作从而提高执行效率。

安全测试

软件日益复杂，而数据又成为了系统中重中之重的核心，从以往对系统的破坏现在更倾向于对数据的获取和破坏。而数据库的安全被提到了最前端 自从SQL 注入攻击被发现，冒失万无一失的数据库一下从后台变为了前台，而一旦数据库被攻破，整个系统也会暴露在黑客的手下，通过数据库强大的存储过程，黑客可以轻松的获得整个系统的权限。而SQL的注入看似简单缺很难防范，对于安全测试来说，如何防范系统被注入是测试的难点。 业界也有相关的数据库注入检测工具，来帮助用户对自身系统进行安全检测。 对于这点来说业界也有标准，例如ISO IEC 21827，也叫做SSE CMM 3.0，是CMM和ISO的集成的产物，专门针对

系统安全领域的 另外一方面，数据库的健壮性，容错性和恢复能力也是我们测试的要点我们也可以发现功能测试，性能测试，安全测试，是一个由简到繁的过程，也是数据库测试人员需要逐步掌握的技能，这也是以后公司对数据库测试人员的要求

七、数据库保护

? 概述

在数据库系统运行时，DBMS要对数据库进行监控，以保证整个系统的正常运转，保证数据库中的数据安全可靠、正确有效，防止各种错误的产生，这就是对数据库的保护，有时也称为“数据控制”。这具体包括以下四个方面： ? 数据库的恢复

? 完整性控制（主键约束，外键约束，属性的值域约束）

? 并发控制（琐机制）

? 安全性控制（存储控制，审计，视图保护和日志监视）

? 事务

事务在数据库里面是一个十分重要的概念。数据库系统运行的基本工作单位是事务。它相当于操作系统中的进程，一个事务由应用程序中的一组操作序列组成。

实际上，事务可以看作是一个原子，是一个不可分割的操作序列。事务中包括的所有操作要么都执行，要么都不执行。

事务通常以BEGIN TRANSACTION语句开始，它主要涉及两个语句。、 ? 事务提交语句COMMIT

? 事务回滚语句ROLLBACK

事务的特性：

事务具有四个特性：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持续性（Durability）。这个四个特性也简称为ACID特性。

1．原子性：事务是数据库的逻辑工作单位，事务中包括的诸操作要么都做，要么都不做。

2．一致性：事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。因此当数据库只包含成功事务提交的结果时，就说数据库处于一致性状态。如果数据库系统运行中发生故障，有些事务尚未完成就被迫中断，系统将事务中对数据库的所有已完成的操作全部撤消，滚回到事务开始时的一致状态。

3．隔离性：一个事务的执行不能被其他事务干扰。即一个事务内部的操作及使用的数据对其他并发事务是隔离的，并发执行的各个事务之间不能互相干扰。

4．持续性：持续性也称永久性（Permanence），指一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。接下来的其他操作或故障不应该对其执行结果有任何影响。

数据库恢复：

尽管数据库系统中采取了各种保护措施来防止数据库的安全性和完整性被破坏，保证并发事务的正确执行，但是计算机系统中硬件的故障、软件的错误、操作员的失误以及恶意的破坏仍是不可避免的，这些故障轻则造成运行事务非正常中断，影响数据库中数据的正确性，重则破坏数据库，使数据库中全部或部分数据丢失，因此数据库管理系统（恢复子系统）必须具有把数据库从错误状态恢复到某一已知的正确状态（亦称为一致状态或完整状态）的功能，这就是数据库的恢复。

故障的种类：

一、事务内部的故障

事务内部的故障有的是可以通过事务程序本身发现的（见下面转帐事务的例子），有的是非预期的，不能由事务程序处理的。

二、系统故障

系统故障是指造成系统停止运转的任何事件，使得系统要重新启动。例如，特定类型的硬件错误（CPU故障）、操作系统故障、DBMS代码错误、突然停电等等。这类故障影响正在运行的所有事务，但不破坏数据库。这时主存内容，尤其是数据库缓冲区（在内存）中的内容都被丢失，所有运行事务都非正常终止。发生系统故障时，一些尚未完成的事务的结果可能已送入物理数据库，有些已完成的事务可能有一部分甚至全部留在缓冲区，尚未写回到磁盘上的物理数据库中，从而造成数据库可能处于不正确的状态。为保证数据一致性，恢复子系统必须在系统重新启动时让所有非正常终止的事务回滚，强行撤消（UNDO）所有未完成事务。重做（Redo）所有已提交的事务，以将数据库真正恢复到一致状态。

三、介质故障

系统故障常称为软故障（Soft Crash），介质故障称为硬故障（Hard Crash）。硬故障指外存故障，如磁盘损坏、磁头碰撞，瞬时强磁场干扰等。这类故障将破

坏数据库或部分数据库，并影响正在存取这部分数据的所有事务。这类故障比前两类故障发生的可能性小得多，但破坏性最大。

四、计算机病毒

计算机病毒是具有破坏性、可以自我复制的计算机程序。计算机病毒已成为计算机系统的主要威胁，自然也是数据库系统的主要威胁。因此数据库一旦被破坏仍要用恢复技术把数据库加以恢复。

恢复策略：

1．事务故障的恢复

事务故障是指事务在运行至正常终止点前被中止，这时恢复子系统应利用日志文件撤消（UNDO）此事务已对数据库进行的修改。事务故障的恢复是由系统自动完成的，对用户是透明的。系统的恢复步骤是：

⑴. 反向扫描文件日志（即从最后向前扫描日志文件），查找该事务的更新操作。 ⑵. 对该事务的更新操作执行逆操作。即将日志记录中“更新前的值”写入数据库。这样，如果记录中是插入操作，则相当于做删除操作（因此时“更新前的值”为空）。若记录中是删除操作，则做插入操作，若是修改操作，则相当于用修改前值代替修改后值。

⑶. 继续反向扫描日志文件，查找该事务的其他更新操作，并做同样处理。 ⑷. 如此处理下去，直至读到此事务的开始标记，事务故障恢复就完成了。

2．系统故障的恢复

前面已讲过，系统故障造成数据库不一致状态的原因有两个，一是未完成事务对数据库的更新可能已写入数据库，二是已提交事务对数据库的更新可能还留在缓冲区没来得及写入数据库。因此恢复操作就是要撤消故障发生时未完成的事务，重做已完成的事务。

系统故障的恢复是由系统在重新启动时自动完成的，不需要用户干预。 系统的恢复步骤是：

⑴. 正向扫描日志文件（即从头扫描日志文件），找出在故障发生前已经提交的事务（这些事务既有BEGIN TRANSACTION记录，也有COMMIT记录），将其事务标识记入重做（REDO）队列。同时找出故障发生时尚未完成的事务（这些事务只有BEGIN TRANSACTION记录，无相应的COMMIT记录），将其事务标识记入撤消(UNDO)队列。

⑵. 对撤消队列中的各个事务进行撤消(UNDO)处理。

进行UNDO处理的方法是，反向扫描日志文件，对每个UNDO事务的更新操作执行逆操作，即将日志记录中“更新前的值”写入数据库。

⑶. 对重做队列中的各个事务进行重做(REDO)处理。

进行REDO处理的方法是：正向扫描日志文件，对每个REDO事务重新执行日志文件登记的操作。即将日志记录中“更新后的值”写入数据库。

3．介质故障的恢复

发生介质故障后，磁盘上的物理数据和日志文件被破坏，这是最严重的一种故障，恢复方法是重装数据库，然后重做已完成的事务。具体地说就是：

⑴. 装入最新的数据库后备副本（离故障发生时刻最近的转储副本），使数据库恢复到最近一次转储时的一致性状态。

对于动态转储的数据库副本，还须同时装入转储开始时刻的日志文件副本，利用恢复系统故障的方法（即REDO+UNDO），才能将数据库恢复到一致性状态。 ⑵. 装入相应的日志文件副本（转储结束时刻的日志文件副本），重做已完成的事务。即：

首先扫描日志文件，找出故障发生时已提交的事务的标识，将其记入重做队列。

然后正向扫描日志文件，对重做队列中的所有事务进行重做处理。即将日志记录中“更新后的值”写入数据库。

这样就可以将数据库恢复至故障前某一时刻的一致状态了。

介质故障的恢复需要DBA介入。但DBA只需要重装最近转储的数据库副本和有关的各日志文件副本，然后执行系统提供的恢复命令即可，具体的恢复操作仍由DBMS完成。

? 并发控制

在多用户共享系统中，许多事务可能同时对同一个数据进行操作，这时候就产生了并发控制的问题。DMBS的并发控制子系统负责协调并发事务的执行，保证数据库的完整性不受破坏，同时避免用户得到不正确的数据。

同时并发方式：在多处理系统中，每个处理机可以运行一个事务，多个处理机可以同时运行多个事务，实现多个事务真正的并行运行，这种并行方式称为同时并发方式。

并发控制机制是衡量一个数据库管理系统性能的重要标志之一。

数据库的并发操作通常可能带来以下的问题：

? 丢失更新问题

? 不一致分析问题（读过时的数据）

? 依赖于未提交更新问题（读“脏”数据）

处理并发控制的主要方法是采用封锁技术。封锁是实现并发控制的一个非常重要的技术。

封锁：所谓封锁就是事务T在对某个数据对象例如表、记录等操作之前，先向系统发出请求，对其加锁。加锁后事务T就对该数据对象有了一定的控制，在事务T释放它的锁之前，其它的事务不能更新此数据对象。

基本的封锁类型有两种:排它锁(Exclusive Locks，简记为X锁) 和共享锁(Share Locks，简记为S锁)。

排它锁：排它锁又称为写锁。若事务T对数据对象A加上X锁，则只允许T读取和修改A，其它任何事务都不能再对A加任何类型的锁，直到T释放A上的锁。这就保证了其它事务在T释放A上的锁之前不能再读取和修改A。

共享锁：共享锁又称为读锁。若事务T对数据对象A加上S锁，则事务T可以读A，但不能修改A，其它事务只能再对A加S锁，而不能加X锁，直到T释放A上的S锁。这就保证了其它事务可以读A，但在T释放A上的S锁之前不能对A做任何修改。有两种类型：

? 排他型封锁（X封锁）

? 共享型封锁（S封锁）

在运用X锁和S锁这两种基本封锁，对数据对象加锁时，还需要约定一些规则，例如应何时申请X锁或S锁、持锁时间、何时释放等。我们称这些规则为封锁协议（Locking Protocol）。对封锁方式规定不同的规则，就形成了各种不同的封锁协议。下面介绍三级封锁协议。对并发操作的不正确调度可能会带来丢失修改、不可重复读和读“脏”数据等不一致性问题，三级封锁协议分别在不同程度上解决了这一问题。为并发操作的正确调度提供一定的保证。不同级别的封锁协议达到的系统一致性级别是不同的。

一级封锁协议是：事务T在修改数据R之前必须先对其加X锁，直到事务结束才释放。事务结束包括正常结束（COMMIT）和非正常结束（ROLLBACK）。

二级封锁协议是：一级封锁协议加上事务T在读取数据R之前必须先对其加S锁，读完后即可释放S锁。二级封锁协议除防止了丢失修改，还可进一步防止读“脏”数据

三级封锁协议是：一级封锁协议加上事务T在读取数据R之前必须先对其加S锁，直到事务结束才释放。三级封锁协议除防止了丢失修改和不读‘脏’数据外，还进一步防止了不可重复读

和操作系统一样，封锁的方法可能引起活锁和死锁。

一．活锁

活锁：如果事务T1封锁了数据R，事务T2又请求封锁R，于是T2等待。T3也请求封锁R，当T1释放了R上的封锁之后系统首先批准了T3的请求，T2仍然等待。然后T4又请求封锁R，当T3释放了R上的封锁之后系统又批准了T4的请求，......，T2有可能永远等待，这就是活锁的情形

二．死锁

死锁：如果事务T1封锁了数据R1，T2封锁了数据R2，然后T1又请求封锁R2，因T2已封锁了R2，于是T1等待T2释放R2上的锁。接着T2又申请封锁R1，因T1已封锁了R1，T2也只能等待T1释放R1上的锁。这样就出现了T1在等待T2，而T2又在等待T1的局面，T1和T2两个事务永远不能结束，形成死锁。 死锁的预防：

在数据库中，产生死锁的原因是两个或多个事务都已封锁了一些数据对象，然后又都请求对已被其他事务封锁的数据对象加锁，从而出现死等待。防止死锁的发生其实就是要破坏产生死锁的条件。预防死锁通常有两种方法：

一次封锁法 ： 一次封锁法要求每个事务必须一次将所有要使用的数据全部加锁，否则就不能继续执行。一次封锁法虽然可以有效地防止死锁的发生，但也存在问题，一次就将以后要用到的全部数据加锁，势必扩大了封锁的范围，从而降低了系统的并发度。

顺序封锁法：顺序封锁法是预先对数据对象规定一个封锁顺序，所有事务都按这个顺序实行封锁。顺序封锁法可以有效地防止死锁，但也同样存在问题。事务的封锁请求可以随着事务的执行而动态地决定，很难事先确定每一个事务要封锁哪些对象，因此也就很难按规定的顺序去施加封锁。

可见，在操作系统中广为采用的预防死锁的策略并不很适合数据库的特点，因此DBMS在解决死锁的问题上普遍采用的是诊断并解除死锁的方法。

2. 死锁的诊断与解除

① 超时法

如果一个事务的等待时间超过了规定的时限，就认为发生了死锁。超时法实现简单，但其不足也很明显。一是有可能误判死锁，事务因为其他原因使等待时

间超过时限，系统会误认为发生了死锁。二是时限若设置得太长，死锁发生后不能及时发现。

②等待图法

事务等待图是一个有向图G=(T,U)。 T为结点的集合，每个结点表示正运行的事务；U为边的集合，每条边表示事务等待的情况。若T1等待T2 ,则T1、T2之间划一条有向边，从T1指向T2。事务等待图动态地反映了所有事务的等待情况。并发控制子系统周期性地（比如每隔1分钟）检测事务等待图，如果发现图中存在回路，则表示系统中出现了死锁。

DBMS的并发控制子系统一旦检测到系统中存在死锁，就要设法解除。通常采用的方法是选择一个处理死锁代价最小的事务，将其撤消，释放此事务持有的所有的锁，使其它事务得以继续运行下去。当然，对撤消的事务所执行的数据修改操作必须加以恢复。

如果一个事务运行过程中没有其他事务同时运行，也就是说它没有受到其他事务的干扰，那么就可以认为该事务的运行结果是正常的或者预想的。因此将所有事务串行起来的调度策略一定是正确的调度策略。虽然以不同的顺序串行执行事务可能会产生不同的结果，但由于不会将数据库置于不一致状态，所以都是正确的。 定义：多个事务的并发执行是正确的，当且仅当其结果与按某一次序串行地执行它们时的结果相同。我们称这种调度策略为可串行化（Serializable）的调度。 另外，在封锁技术方面，SQL提供事务的四种一致性级别，从高到低分别是： ? serializable（可串行化）

? repeatable read（可重复读）

? read committed（读提交数据）

? read uncommitted（可读未提交数据）

数据库安全：

数据库的安全性是指保护数据库以防止不合法的使用所造成的数据泄露、更改或破坏。

为降低进而消除对系统的安全攻击，尤其是弥补原有系统在安全保护方面的缺陷，在计算机安全技术方面逐步建立了一套可信标准。在目前各国所引用或制定的一系列安全标准中，最重要的当推19xx年美国国防部（DoD）正式颁布的《DoD可信计算机系统评估标准》（Trusted Computer System Evaluation Criteria，简记为TCSEC)[1]或DoD85）。

制定这个标准的目的主要有：

⑴提供一种标准，使用户可以对其计算机系统内敏感信息安全操作的可信程度做出评估。

⑵给计算机行业的制造商提供一种可循的指导规则，使其产品能够更好的满足敏感应用的安全需求。

TCSEC又称桔皮书，19xx年4月美国NCSC（国家计算机安全中心）颁布了《可信计算机系统评估标准关于可信数据库系统的解释》（ Trusted Database Interpretation 简记为TDI，即紫皮书）。将TCSEC扩展到数据库管理系统。TDI中定义了数据库管理系统的设计与实现中需满足和用以进行安全性级别评估的标准。

在TCSEC中建立的安全级别之间具有一种偏序向下兼容的关系，即较高安全性级别提供的安全保护要包含较低级别的所有保护要求，同时提供更多或更完善的保护能力。

下面，我们简略地对各个等级作一介绍。

D级： D级是最低级别。保留D级的目的是为了将一切不符合更高标准的系统，统统归于D组。如DOS就是操作系统中安全标准为D的典型例子。它具有操作系统的基本功能，如文件系统，进程调度等等，但在安全性方面几乎没有什么专门的机制来保障。

C1级：只提供了非常初级的自主安全保护。能够实现对用户和数据的分离，进行自主存取控制（DAC），保护或限制用户权限的传播。现有的商业系统往往稍作改进即可满足要求。

C2级：实际是安全产品的最低档次，提供受控的存取保护，即将C1级的DAC进一步细化，以个人身份注册负责，并实施审计和资源隔离。很多商业产品已得到该级别的认证。达到C2级的产品在其名称中往往不突出“安全”(Security)这一特色，如操作系统中Microsoft的Windows NT 3.5，数字设备公司的Open VMS VAX 6.0和6.1。数据库产品有Oracle公司的Oracle 7，Sybase公司的 SQL Server 11.0.6 等。

B1级：标记安全保护。对系统的数据加以标记，并对标记的主体和客体实施强制存取控制（MAC）以及审计等安全机制。B1级能够较好地满足大型企业或一般政府部门对于数据的安全需求，这一级别的产品才认为是真正意义上的安全产品。满足此级别的产品前一般多冠以“安全”(Security)或“可信的”(Trusted)字样，作为区别于普通产品的安全产品出售。例如，操作系统方面，典型的有数字设备公司的SEVMS VAX Version 6.0，惠普公司的HP-UX BLS release 9.0.9+ 。数据库方面则有Oracle公司的Trusted Oracle 7，Sybase公司的Secure SQL Server version 11.0.6，Informix公司的Incorporated INFORMIX-OnLine / Secure 5.0等。

B2级：结构化保护。建立形式化的安全策略模型并对系统内的所有主体和客体实施DAC和MAC。

从互连网上的最新资料看，经过认证的、B2级以上的安全系统非常稀少。例如，符合B2标准的操作系统只有Trusted Information Systems公司的Trusted XENIX一种产品，符合B2标准的网络产品只有Cryptek Secure

Communications公司的LLC VSLAN一种产品，而数据库方面则没有符合B2标准的产品。

B3级：安全域。该级的TCB必须满足访问监控器的要求，审计跟踪能力更强，并提供系统恢复过程。

A1级：验证设计，即提供B3级保护的同时给出系统的形式化设计说明和验证以确信各安全保护真正实现。

B2以上的系统标准更多地还处于理论研究阶段，产品化以至商品化的程度都不高，其应用也多限于一些特殊的部门如军队等。但美国正在大力发展安全产品，试图将目前仅限于少数领域应用的B2安全级别或更高安全级别下放到商业应用中来，并逐步成为新的商业标准。

可以看出，支持自主存取控制的DBMS大致属于C级，而支持强制存取控制的DBMS则可以达到B1级。当然，存取控制仅是安全性标准的一个重要方面（即安全策略方面）不是全部。为了使DBMS达到一定的安全级别，还需要在其它三个方面提供相应的支持。例如审计功能就是DBMS达到C2以上安全级别必不可少的一项指标。

下面介绍Oracle的安全性措施。

Oracle的安全性措施主要有三个方面：一是用户标识和鉴定；二是授权和检查机制；三是审计技术；除此之外Oracle还允许用户通过出发器灵活定义自己的安全性措施。

用户标识和鉴定

授权与检查机制

系统权限

数据库对象的权限

⑴表级安全性

⑵行级安全性

⑶列级安全性

审计技术

用户定义的安全性措施

随着计算机特别是计算机网络的发展，数据的共享日益加强，数据的安全保密越来越重要。DBMS是管理数据的核心，因而其自身必须具有一整套完整而有效的安全性机制。

《可信计算机系统评测标准》TCSEC/TDI是目前各国所引用或制定的一系列安全标准中最重要的一个。 TCSEC/TDI从安全策略、责任、保证和文档四个方面描述了安全性级别的指标。按照这些指标，目前许多大型DBMS 达到了C2级，其安全版本达到了B1。

实现数据库系统安全性的技术和方法有多种，最重要的是存取控制技术和审计技术。C2级的DBMS必须具有自主存取控制功能和初步的审计功能，B1的DBMS必须具有强制存取控制和增强的审计功能。自主存取控制功能一般是通过SQL 的GRANT语句和REVOKE语句来实现的。

八、数据库性能调整