数据库测试 - 快速指南

数据库测试 – 概述

数据库测试包括执行数据有效性、数据完整性测试、与数据库相关的性能检查以及数据库中过程、触发器和函数的测试。

示例

考虑一个捕获用户日常交易详细信息并将详细信息存储在数据库中的应用程序。从数据库测试的角度来看，应执行以下检查：

• 应用程序中的交易信息应存储在数据库中，并应向用户提供正确的信息。

• 信息加载到数据库时不应丢失。

• 仅应存储已完成的交易，所有未完成的操作应由应用程序中止。

• 应维护对数据库的访问授权。不应提供对用户信息的任何未经批准或未经授权的访问。

为什么要执行数据库测试？

执行数据库测试有多个原因。需要对数据库执行数据完整性、验证和数据一致性检查，因为后端系统负责存储数据并被用于多种用途。

以下是数据库测试的一些常见原因：

• 为了简化对数据库后端的调用复杂性，开发人员增加了视图和存储过程的使用。

• 这些存储过程和视图包含关键任务，例如插入客户详细信息（姓名、联系信息等）和销售数据。这些任务需要在多个级别进行测试。

• 对前端执行的黑盒测试很重要，但难以隔离问题。在后端系统进行测试可以提高数据的稳健性。这就是为什么在后端系统上执行数据库测试的原因。

• 在数据库中，数据来自多个应用程序，并且有可能将有害或不正确的数据存储在数据库中。因此，需要定期检查数据库组件。此外，应定期检查数据完整性和一致性。

数据库测试与前端测试

数据库测试不同于前端 UI 测试。下表突出显示了主要区别：

数据库测试 – 类型

根据数据库的功能和结构，数据库测试可以分为三类：

• 结构化数据库测试 - 它处理表和列测试、模式测试、存储过程和视图测试、检查触发器等。

• 功能测试 - 它涉及从用户角度检查数据库的功能。最常见的功能测试类型是白盒测试和黑盒测试。

• 非功能测试 - 它涉及数据库中的负载测试、风险测试、压力测试、最低系统要求，并处理数据库的性能。

结构化数据库测试

结构化数据库测试涉及验证数据库中那些未暴露给最终用户的组件。它涉及存储库的所有组件，这些组件用于存储数据并且不会被最终用户更改。具有良好 SQL 存储过程和其他概念命令的数据库管理员通常执行此测试。

讨论了关于结构化测试的常见测试组件：

模式/映射测试

它涉及验证前端应用程序的对象与数据库对象映射。

在模式测试中：

• 有时会发生最终用户应用程序对象未正确映射或与数据库对象不兼容的情况。因此，需要检查与数据库关联的各种模式格式的验证。

• 需要查找数据库中未映射的对象，例如表、视图、列等。

市场上有各种工具可用于在模式中执行对象映射。

示例 - 在 Microsoft SQL Server 中，测试人员可以编写简单的查询来检查和验证数据库中的模式。

如果测试人员想要更改表结构，他/她应确保所有包含该表的存储过程都与此更改兼容。

存储过程和视图测试

在此测试中，测试人员确保存储过程和视图的手动执行生成所需的结果。

测试人员确保：

• 如果它使所需的触发器按预期执行。

• 如果开发团队通过向过程中的应用程序传递输入涵盖了所有循环和条件。

• 如果数据库中存在任何未使用的存储过程。

• 从数据库中所需的表获取数据时，是否正确应用了 TRIM 操作。

• 根据被测应用程序的要求验证存储过程模块的整体集成。

• 遵循异常和错误处理机制。

用于执行存储过程测试的最常见工具是LINQ、SP 测试工具等。

触发器测试

在触发器测试中，测试人员需要确保以下事项：

• 触发器编码阶段是否遵循编码约定。

• 查看执行的触发器是否满足所需条件。

• 触发器执行后是否正确更新了数据。

• 验证更新/插入/删除触发器相对于被测应用程序的功能。

表和列测试

此测试涵盖的关键领域包括：

• 验证数据库中的数据类型与前端应用程序中的字段值。

• 验证数据库中数据字段的长度与应用程序中数据类型的长度。

• 检查数据库中是否存在任何来自应用程序字段对象的未映射表或列。

• 验证数据库表和列的命名约定，它们是否符合业务需求。

• 验证数据库中的键和索引，即表中的主键和外键是否按要求定义。

• 检查两个表中主键及其对应外键是否相同。

• 检查键的唯一和非空特性是否得到维护。

• 键和索引的长度和数据类型是否按要求维护。

数据库服务器检查

数据库服务器检查涉及验证：

• 数据库服务器是否可以处理根据业务需求预期的交易数量。

• 数据库服务器的配置详细信息是否满足业务需求。

• 用户授权是否按要求维护。

功能测试

功能测试是在牢记最终用户观点的情况下执行的；最终用户运行的所需交易和操作是否满足业务规范。

黑盒测试

黑盒测试涉及验证数据库的集成以检查功能。测试用例很简单，用于验证函数的传入数据和传出数据。

各种技术，例如因果图技术、等价划分和边界值分析，用于测试数据库的功能。

其优点如下：

• 它相当简单，并在开发的早期阶段执行。
• 与白盒测试相比，开发测试用例的成本更低。

其缺点如下：

• 无法检测到一些错误
• 不知道需要测试多少程序。

白盒测试

白盒测试处理数据库的内部结构，并且规格细节对用户隐藏。它涉及数据库触发器和逻辑视图的测试，这些将支持数据库重构。

它执行数据库函数、触发器、视图、SQL 查询等的模块测试。这种类型的测试验证数据库表、数据模型、数据库模式等。它检查参照完整性规则。它选择默认表值以检查数据库一致性。

执行白盒测试最常用的技术包括条件覆盖、决策覆盖、语句覆盖等。

白盒测试可以检测编码错误，因此可以消除数据库中的内部错误。白盒测试的局限性在于它没有覆盖SQL语句。

非功能测试

非功能测试包括执行负载测试、压力测试、检查满足业务规范的最低系统要求、风险查找和数据库性能优化。

负载测试

负载测试的主要目标是检查大多数正在运行的事务是否会对数据库的性能产生影响。

在负载测试中，测试人员检查 -

• 多个远程用户执行事务的响应时间。
• 数据库获取特定记录所需的时间。

不同测试类型中负载测试的示例 -

• 重复运行最常用的事务以查看数据库系统的性能。
• 从互联网下载一系列大型文件。
• 在计算机或服务器上同时运行多个应用程序。

压力测试

压力测试用于识别系统断点。在此测试中，应用程序以某种方式加载，以便系统在某一点失败。这一点称为数据库系统的断点。

确定数据库事务的状态需要大量工作。需要进行适当的计划以避免任何基于时间和成本的问题。

最常用的压力测试工具是LoadRunner和WinRunner。

让我们以示例说明压力测试。CRM 应用程序最多可以承受 50000 个并发用户的负载。假设您将负载增加到 51000 并进行一些事务，例如更新记录或添加条目。执行事务后，应用程序可以与数据库系统同步。因此，下一个测试是使用 52000 的用户负载执行。有时，压力测试也称为疲劳测试。

数据库测试 – 流程

执行数据库测试的过程类似于其他应用程序的测试。DB 测试可以用下面给出的关键流程来描述。

• 设置环境
• 运行测试
• 检查测试结果
• 根据预期结果进行验证
• 将发现的结果报告给相关利益相关者

各种 SQL 语句用于开发测试用例。执行 DB 测试最常用的 SQL 语句是Select语句。除此之外，还可以使用各种 DDL、DML、DCL 语句。

示例 - 创建、插入、选择、更新等。

数据库测试阶段

DB 测试不是一个繁琐的过程，并且根据测试流程包含数据库测试生命周期中的各个阶段。

数据库测试的关键阶段包括 -

• 检查初始状态
• 测试运行
• 根据预期结果进行结果验证
• 生成结果

DB 测试的第一阶段是在开始测试过程之前检查数据库的初始状态。然后测试数据库针对已定义测试用例的行为。根据获得的结果，自定义测试用例。

为了成功进行数据库测试，每个测试都会执行以下给出的工作流程。

• 清理数据库 - 如果数据库中有可测试数据，则应将其清空。

• 设置Fixture - 这包括将数据输入数据库并检查数据库的当前状态。

• 执行测试、验证结果和生成结果 - 运行测试并验证输出。如果输出符合预期结果，则下一步是根据需要生成结果。否则，重复测试以查找数据库中的错误。

数据库测试 – 技术

本章解释了执行数据库测试最常用的技术。

数据库模式测试

如前所述，它涉及测试模式中的每个对象。

验证数据库和设备

• 验证数据库名称
• 验证数据设备、日志设备和转储设备
• 验证是否为每个数据库分配了足够的空间
• 验证数据库选项设置

表、列、列类型规则检查

验证以下项目以找出实际设置和应用设置之间的差异。

• 数据库中所有表的名称

• 每个表的列名

• 每个表的列类型

• 是否检查了NULL值

• 默认值是否绑定到正确的表列

• 规则定义以更正表名和访问权限

键和索引

验证每个表中的键和索引 -

• 每个表的主键

• 每个表的外部键

• 外部键列和另一个表中的列之间的数据类型索引，聚簇或非聚簇唯一或不唯一

存储过程测试

它涉及检查存储过程是否已定义，并将输出结果进行比较。在存储过程测试中，检查以下几点 -

• 存储过程名称

• 参数名称、参数类型等。

• 输出 - 输出是否包含许多记录。零行受影响或仅提取几条记录。

• 存储过程的功能是什么，存储过程不应该做什么？

• 传递示例输入查询以检查存储过程是否提取了正确的数据。

• 存储过程参数 - 使用边界数据和有效数据调用存储过程。使每个参数一次无效并运行过程。

• 返回值 - 检查存储过程返回的值。如果失败，则必须返回非零值。

• 错误消息检查 - 以使存储过程失败的方式进行更改，并至少生成一次每个错误消息。检查当没有预定义错误消息时发生的任何异常情况。

触发器测试

在触发器测试中，测试人员必须执行以下任务 -

• 确保触发器名称正确。
• 验证触发器是否为特定表列生成。
• 触发器的更新验证。
• 使用有效数据更新记录。
• 使用无效数据更新记录并覆盖每个触发器错误。
• 当其他表中的行仍引用记录时更新记录。
• 确保在发生故障时回滚事务。
• 找出触发器不应该回滚事务的任何情况。

服务器设置脚本

应执行两种类型的测试 -

• 从头开始设置数据库，以及
• 设置现有数据库。

SQL Server 集成测试

在完成组件测试后，应执行集成测试。

• 应密集调用存储过程以在不同的表中选择、插入、更新和删除记录，以查找任何冲突和不兼容性。

• 模式和触发器之间的任何冲突。

• 存储过程和模式之间的任何冲突。

• 存储过程和触发器之间的任何冲突。

功能测试方法

功能测试可以通过根据功能将数据库划分为模块来执行。功能有以下两种类型 -

• 类型 1 - 在类型 1 测试中，找出项目的特性。对于每个主要特性，找出负责实现该功能的模式、触发器和存储过程，并将它们放入一个功能组中。然后一起测试每个组。

• 类型 2 - 在类型 2 测试中，后端功能组的边界并不明显。您可以检查数据流并查看可以在哪里检查数据。从前端开始。

以下流程发生 -

• 当服务有请求或保存数据时，将调用一些存储过程。

• 这些过程将更新一些表。

• 这些存储过程将成为开始测试的地方，而这些表将成为检查测试结果的地方。

压力测试

压力测试包括获取主要数据库功能和相应存储过程的列表。请按照以下步骤进行压力测试 -

• 编写测试脚本以尝试这些功能，并且每个功能必须在完整周期中至少检查一次。

• 在特定时间段内反复执行测试脚本。

• 验证日志文件以检查任何死锁、内存不足故障、数据损坏等。

基准测试

如果您的数据库没有任何数据问题或错误，则可以检查系统性能。可以通过检查以下给出的参数在基准测试中发现糟糕的系统性能 -

• 系统级性能
• 识别最可能使用的功能/特性
• 计时 - 执行功能的最大时间、最小时间和平均时间
• 访问量

通过前端测试数据库

有时也可以通过执行前端测试来查找后端错误。您可以按照以下简单步骤通过前端测试检测错误。

• 从前端编写查询并发出搜索。

• 选择现有记录，更改某些字段中的值，然后保存记录。（这涉及 UPDATE 语句或更新存储过程和更新触发器。）

• 在前端窗口中插入一个新的菜单项。填写信息并保存记录。（这涉及 INSERT 语句或插入存储过程和删除触发器。）

• 选择现有记录，单击“删除”或“移除”按钮，然后确认删除。（这涉及 DELETE 语句或删除存储过程和删除触发器。）

• 使用无效数据重复这些测试用例，并查看数据库的响应方式。

数据库测试 – 场景

在本章中，我们将看到一些关于各种测试方法的常见数据库测试场景。

结构化数据库测试

关于结构化数据库测试的常见数据库场景如下 -

• 验证数据库名称、验证数据设备、日志设备和转储设备、验证是否为每个数据库分配了足够的空间以及验证数据库选项设置。

• 数据库中所有表的名称、每个表的列名、每个表的列类型、是否检查空值。验证每个表中的键和索引：每个表的主键、每个表的外部键。

• 外部键列和另一个表中的列之间的数据类型索引，聚簇或非聚簇唯一或不唯一。

功能数据库测试

关于功能数据库测试的常见数据库测试场景为 -

• 找出负责实现该功能的模式、触发器和存储过程，并将它们组合成一个功能组，然后可以一起测试每个组。

• 检查数据流并查看可以在哪里检查数据。从前端开始。

非功能数据库测试

关于非功能数据库测试的常见数据库测试场景为 -

• 编写测试脚本以尝试主要功能，并且每个功能必须在完整周期中至少检查一次。

• 在特定时间段内反复执行测试脚本。

• 验证日志文件以检查任何死锁、内存不足故障、数据损坏等。

• 从前端编写查询并发出搜索。选择现有记录，更改某些字段中的值，然后保存记录。（这涉及 UPDATE 语句或更新存储过程、更新触发器。）

• 在前端窗口中插入一个新的菜单项。填写信息并保存记录。（这涉及 INSERT 语句或插入存储过程、删除触发器。）

• 选择现有记录，单击“删除”或“移除”按钮，然后确认删除。（这涉及 DELETE 语句或删除存储过程、删除触发器。）

• 使用无效数据重复这些测试用例，并查看数据库的响应方式。

数据库测试 – 对象

模式、表、存储过程和触发器是数据库的关键对象。我们已经分享了这些数据库对象的数据库测试类型和测试场景。

模式

数据库模式以数据库管理系统支持的格式定义数据库系统的结构。模式指的是数据库是如何构建的（在关系数据库的情况下，由数据库表组成）。

数据库模式是一组称为完整性约束的公式，施加在数据库上。这些完整性约束确保模式各部分之间的兼容性。

在关系数据库中，模式由表、字段、视图、索引、包、过程、函数、触发器、类型、物化视图、同义词、数据库链接和其他元素组成。

模式通常存储在数据字典中。虽然模式是在文本数据库语言中定义的，但该术语通常用于指代数据库结构的图形描述。换句话说，模式是定义数据库中对象的数据库结构。

数据仓库中常用的模式类型有：

• 星型模式
• 雪花模式
• 星系模式

数据库中的表

在关系数据库中，表用于将信息组织成行和列。

示例 - 客户表包含诸如客户 ID、地址、电话号码等信息，作为一系列列。

每条数据都是表中的一个字段。列包含单个字段中的所有条目，例如所有客户的电话号码。字段被组织成记录，它们是完整的信息集（例如关于特定客户的信息集），每个信息集构成一行。

存储过程

存储过程是一系列存储在数据库中的已编译形式的 SQL 语句，多个程序可以共享它。使用存储过程有助于维护数据完整性、数据访问控制和提高生产力。

触发器

数据库触发器是在数据库中特定表或视图上发生某些事件时执行的代码。触发器主要用于维护数据库中信息的完整性。

数据库测试 – 数据完整性

数据完整性在数据库中非常重要。它包括在插入、更新和删除之前进行数据验证。必须设置触发器以验证参考表记录。

为了检查数据完整性，您需要执行以下操作：

• 您需要检查每个表中的主要列，并验证是否存在任何不正确的数据。（名称字段中的字符、负百分比等）。

• 找出不一致的数据并将它们插入相关表中，查看是否发生任何错误。

• 在插入父数据之前插入子数据。尝试删除仍被另一个表中的数据引用的记录。

• 如果表中的数据已更新，请检查其他相关数据是否也已更新。您需要确保复制的服务器或数据库同步并包含一致的信息。

数据库测试 – 数据映射

数据库中的数据映射是每个测试人员都需要验证的关键概念之一。通常，测试人员必须验证用户界面前端字段映射与相应的后端数据库字段。

此信息在软件需求规格说明书或业务需求规格说明书 SRS/BRS 文档中给出。如果未提供映射，则需要检查编码部分。

当您在前端应用程序中执行任何操作时，都会调用相应的 CRUD 操作，测试人员必须检查每个调用的操作是否成功。

数据映射的关键方面

以下是数据映射的关键方面：

• 检查 UI/前端表单中的字段是否与相应的 DB 表一致地映射。此映射信息在上述需求文档中定义。

• 对于在应用程序前端执行的任何操作，都会在后端启动相应的 CRUD“创建、检索、更新和删除”操作。

• 测试人员必须检查是否调用了正确的操作，以及调用的操作本身是否成功。

数据映射测试的步骤

以下是数据映射测试中遵循的步骤：

• 步骤 1 - 首先检查每个脚本中的语法错误。

• 步骤 2 - 接下来是检查表映射、列映射和数据类型映射。

• 步骤 3 - 验证查找数据映射。

• 步骤 4 - 当目标表中不存在记录时运行每个脚本。

• 步骤 5 - 当记录已存在于目标表中时运行每个脚本。

数据库测试 – 性能

响应时间更长且性能较差的应用程序会导致巨大的问题。数据库负载测试用于在您为最终用户部署数据库应用程序之前查找任何性能问题。

数据库负载测试可帮助您设计具有性能、可靠性和可扩展性的数据库应用程序。数据库应用程序的负载测试涉及使用不同的用户负载测试数据库应用程序的性能和可扩展性。

数据库负载测试涉及模拟目标数据库应用程序的真实用户负载。它可以帮助您确定当多个用户同时访问数据库应用程序时，它的行为。

负载测试

负载测试的主要目标是检查大多数正在运行的事务是否对数据库有性能影响。在负载测试中，您需要检查以下方面：

• 应检查多个远程用户执行事务的响应时间。

• 对于正常事务，您应该包含一个可编辑的事务以检查数据库对这些类型事务的性能。

• 对于正常事务，您应该包含一个非编辑事务以检查数据库对这些类型事务的性能。

• 应检查数据库获取特定记录所需的时间。

压力测试

压力测试用于识别系统断点。在此，应用程序以使系统在某一点失败的方式加载。此点称为数据库系统的断点。压力测试也称为疲劳测试。

确定数据库事务的状态需要大量工作。需要进行适当的计划以避免任何基于时间和成本的问题。

最常见的压力测试工具是LoadRunner 和WinRunner。

数据库测试 – 工具

供应商提供了各种工具，可用于生成测试数据、管理测试数据并执行数据库测试（如负载测试和回归测试）。

下面列出了一些常用的工具。

数据库测试 – 备份

组织发展最重要的部分是其数据。在系统故障的情况下，需要恢复数据。备份是数据库的精确副本，它可以帮助您在发生任何数据丢失时恢复数据。

考虑一家金融公司，它拥有与其客户相关的数据，例如账户号码、客户姓名、贷记和借记、持续时间等。如果发生数据故障，这样的组织将如何应对丢失此类重要信息的压力？

这就是您备份数据的原因，以便在磁盘、磁盘控制器等发生任何故障时，您可以依靠备份将其恢复到数据库中。

数据备份类型

可以使用两种类型的备份：

• 物理备份 - 物理备份包括使用第三方备份工具（如 Veritas Net Back、IBM Tivoli Manager）或使用操作系统实用程序的用户管理器备份进行备份。

• 逻辑备份 - 数据库的逻辑备份包括备份逻辑对象（如表、索引、过程等）。

示例 - 用于备份数据的常用工具之一是Oracle 恢复管理器 (RMAN)，它是 Oracle 用于备份数据库的实用程序。

RMAN 包含两个组件：

• 需要备份的目标数据库。

• RMAN 客户端用于运行执行数据备份的命令。

BACKUP VALIDATE 用于测试您是否能够创建数据库文件的有效备份。它确保：

• 是否为数据库的物理或逻辑对象设置了备份。
• 是否为宝贵数据设置了定期备份。
• 备份工具是否满足组织的备份要求。

数据库测试 – 恢复

数据库恢复测试用于确保数据库已恢复。恢复测试允许您找出应用程序是否正常运行，并检查检索本应丢失的宝贵数据（如果您的恢复方法设置不正确）。

您还可以检查几个关键流程是否运行顺利，以确保数据恢复能够顺利通过测试阶段。

您可以对数据库恢复执行以下检查：

• 备份软件中的任何错误或错误，您需要在早期阶段解决这些问题。

• 您需要进行恢复测试，以便在紧急情况下知道该怎么做。

• 您需要检查恢复测试需求，以便您可以计划有效的恢复策略。

• 您还应该知道如何恢复文档。

您需要在项目的早期阶段运行恢复测试。这使您可以消除并丢弃系统中的所有类型的错误。以下是一些在测试时应考虑的重要事项列表：

• 数据库系统发生更改或修改的时间跨度。

• 您希望恢复计划执行的期限。

• 数据库系统中数据的敏感性。数据越关键，您就越需要定期测试软件。

数据库备份和恢复测试的常见步骤

在数据库恢复测试中，您需要在实际环境中运行测试，以检查系统或数据在发生任何灾难和业务环境中任何其他不可预见事件时是否可以实际恢复。

以下是数据库恢复测试中执行的常见操作：

• 数据库系统的测试
• SQL 文件的测试
• 部分文件的测试
• 数据备份的测试
• 备份工具的测试
• 日志备份的测试

数据库测试 – 安全性

数据库安全测试是为了查找安全机制中的漏洞，以及发现数据库系统的漏洞或弱点。

数据库安全测试的主要目标是找出系统中的漏洞，并确定其数据和资源是否受到潜在入侵者的保护。安全测试定义了一种有效识别潜在漏洞的方法，如果定期执行，则可以有效识别潜在漏洞。

以下是执行数据库安全测试的主要目标：

• 身份验证
• 授权
• 机密性
• 可用性
• 完整性
• 弹性

数据库系统中的威胁类型

SQL注入

这是数据库系统中最常见的攻击类型，其中恶意SQL语句被插入到数据库系统中并被执行，以从数据库系统中获取关键信息。这种攻击利用了用户应用程序实现中的漏洞。为了防止这种情况，应仔细处理用户输入字段。

数据库权限提升

在这种攻击中，用户已经在数据库系统中具有一定的访问权限，并且他只是试图将此访问权限提升到更高的级别，以便他/她可以在数据库系统中执行一些未经授权的活动。

拒绝服务

在这种类型的攻击中，攻击者使数据库系统或应用程序资源对合法用户不可用。应用程序也可能受到攻击，从而导致应用程序，有时甚至是整个机器无法使用。

未经授权的数据访问

另一种攻击类型是未经授权访问应用程序或数据库系统中的数据。未经授权的访问包括：

• 通过基于用户的应用程序未经授权访问数据
• 通过监控其他人的访问权限进行未经授权的访问
• 未经授权访问可重用的客户端身份验证信息

身份欺骗

在身份欺骗中，黑客使用用户或设备的凭据对网络主机发起攻击，窃取数据或绕过对数据库系统的访问控制。防止这种攻击需要IT基础设施和网络级缓解措施。

数据操纵

在数据操纵攻击中，黑客更改数据以获得一些优势或损害数据库所有者的形象。

数据库安全测试技术

渗透测试

渗透测试是对计算机系统进行攻击，目的是查找安全漏洞，潜在地访问它、它的功能和数据。

风险查找

风险查找是评估和确定与损失类型和漏洞发生可能性相关的风险的过程。这由组织通过各种访谈、讨论和分析来确定。

SQL注入测试

它涉及检查应用程序字段中的用户输入。例如，在用户应用程序的任何文本框中输入“，”或“;”等特殊字符都不允许。当发生数据库错误时，这意味着用户输入被插入到某些查询中，然后由应用程序执行。在这种情况下，应用程序容易受到SQL注入的攻击。

这些攻击对数据构成了巨大威胁，因为攻击者可以访问服务器数据库中的重要信息。要检查SQL注入进入Web应用程序的入口点，请从代码库中查找直接在数据库上执行MySQL查询的代码，方法是接受一些用户输入。

可以针对括号、逗号和引号执行SQL注入测试。

密码破解

这是执行数据库系统测试时最重要的检查。为了访问关键信息，黑客可以使用密码破解工具或猜测常见的用户名/密码。这些常见密码很容易在互联网上获得，并且密码破解工具也免费存在。

因此，有必要在测试时检查系统中是否维护了密码策略。对于任何银行和金融应用程序，都需要在所有关键信息数据库系统上设置严格的密码策略。

数据库系统安全审计

安全审计是一个定期评估公司安全策略的过程，以确定是否遵循必要的标准。可以根据业务需求遵循各种安全标准来定义安全策略，然后可以针对这些标准评估设定的策略。

最常见安全标准的示例包括ISO 27001、BS15999等。

数据库安全测试工具

市场上有多种系统测试工具可用，可用于测试操作系统和应用程序检查。下面讨论一些最常见的工具。

Zed Attack Proxy

它是一个用于查找Web应用程序漏洞的渗透测试工具。它旨在供具有广泛安全经验的人员使用，因此非常适合刚接触渗透测试的开发人员和功能测试人员。它通常用于Windows、Linux、Mac OS。

Paros

可以使用这些扫描程序拦截和修改服务器和客户端之间所有HTTP和HTTPS数据，包括cookie和表单字段。它用于跨平台、Java JRE/JDK 1.4.2或更高版本。

社会工程工具包

它是一个开源工具，攻击的是人的因素而不是系统元素。它使您能够发送包含攻击代码的电子邮件、Java小程序等。它首选用于Linux、Apple Mac OS X和Microsoft Windows。

Skipfish

此工具用于扫描其网站以查找漏洞。该工具生成的报告旨在作为专业Web应用程序安全评估的基础。它首选用于Linux、FreeBSD、MacOS X和Windows。

Vega

它是一个开源的多平台Web安全工具，用于查找Web应用程序中SQL注入、跨站点脚本（XSS）和其他漏洞的实例。它首选用于Java、Linux和Windows。

Wapiti

Wapiti是一个开源的基于Web的工具，它扫描Web应用程序的网页并检查脚本和表单，它可以在其中注入数据。它使用Python构建，可以检测文件处理错误、数据库、XSS、LDAP和CRLF注入、命令执行检测。

Web Scarab

它使用Java编写，用于分析通过HTTP/HTTPS协议通信的应用程序。此工具主要设计用于可以自己编写代码的开发人员。此工具不依赖于操作系统。

数据库测试 – 挑战

为了成功执行数据库测试，测试人员应从所有来源收集需求，例如技术和功能需求。一些需求可能处于高级别，因此需要将这些需求分解成小部分。测试数据库是一项复杂的任务，测试人员在执行此测试时会面临许多挑战。最常见的数据库测试挑战包括：

测试范围过大

测试人员需要识别数据库测试中的测试项，否则他可能无法清楚地了解要测试什么以及不测试什么。因此，如果您对需求很清楚，则可能会浪费大量时间来测试数据库中不重要的对象。

当您有一组要测试的对象时，接下来是估计为每个测试项设计测试和执行测试所需的精力。根据其设计和数据大小，一些数据库测试可能需要很长时间才能执行。

由于数据库规模过大，因此查找必须测试的对象以及哪些对象需要排除变得非常具有挑战性。

缩减的测试数据库

通常，测试人员会获得开发数据库的副本进行测试。该数据库仅包含少量数据，足以运行应用程序。因此，需要测试开发、暂存以及生产数据库系统。

数据库结构的更改

这是数据库测试中常见的挑战之一。有时，您设计或执行测试时，数据库结构会发生更改。有必要确保您了解测试期间对数据库进行的更改。

一旦数据库结构发生更改，您应该分析更改的影响并修改测试。此外，如果多个用户使用测试数据库，您将无法确定测试结果，因此您应确保测试数据库仅用于测试目的。

数据库测试中的另一个挑战是您同时运行多个测试。您应该至少对性能测试一次运行一个测试。您不希望数据库执行多个任务并低估性能。

复杂的测试计划

数据库结构通常很复杂，并且数据量巨大，因此您可能正在重复执行不完整或相同的测试。因此，需要创建一个测试计划并相应地进行，并定期检查进度。

良好的SQL理解

要测试数据库，您应该具备良好的SQL查询知识和所需的数据库管理工具。

数据库测试 - 面试问题

db_connect(query1 DRIVER {drivername};SERVER server_name;UID uidname;
   PWD password;DBQ database_name );

db_excecute_query (write the required query that is to execute); Specify the appropriate condition

db_disconnect(query);