数据库测试 - 快速指南

数据库测试 – 概述

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

例子

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

• 来自应用程序的事务信息应存储在数据库中，并且应向用户提供正确的信息。

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

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

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

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

执行数据库测试的原因有多种。由于后端系统负责存储数据并出于多种目的进行访问，因此需要对数据库进行数据完整性、验证和数据一致性检查。

下面给出了数据库测试的一些常见原因 -

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

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

• 在前端执行的黑盒测试很重要，但很难隔离问题。后端系统的测试增加了数据的稳健性。这就是为什么数据库测试是在后端系统上执行的。

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

数据库测试与前端测试

数据库测试与前端 UI 测试不同。下表突出显示了主要差异 -

数据库测试 – 类型

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

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

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

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

结构数据库测试

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

讨论的是结构测试方面测试的常见组件 -

模式/映射测试

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

在模式测试中 -

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

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

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

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

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

存储过程和视图测试

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

测试仪确保 -

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

• 开发团队是否已通过将输入传递给过程中的应用程序来涵盖所有循环和条件。

• 数据库中是否有未使用的存储过程。

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

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

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

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

触发测试

在触发测试中，测试人员需要确保以下几点 -

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

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

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

• 更新/插入/删除的验证会触发测试应用程序的功能。

表和列测试

此测试涵盖的关键领域是 -

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

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

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

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

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

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

• 检查维护键的唯一性和非空特性。

• 键和索引的长度和数据类型根据要求进行维护。

数据库服务器检查

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

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

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

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

功能测试

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

黑盒测试

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

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

其优点如下：

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

它的缺点如下：

• 无法检测到一些错误
• 目前尚不清楚有多少程序需要测试。

白盒测试

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

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

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

白盒测试可以检测到编码错误，从而消除数据库的内部错误。白盒测试的局限性是不覆盖SQL语句。

非功能测试

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

负载测试

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

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

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

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

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

压力测试

执行压力测试来识别系统断点。在此测试中，应用程序的加载方式导致系统在某一点出现故障。这个点称为数据库系统的断点。

确定数据库事务的状态需要付出大量的努力。需要适当的规划以避免任何基于时间和成本的问题。

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

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

数据库测试——流程

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

• 设置环境
• 运行测试
• 检查测试结果
• 根据预期结果进行验证
• 向相关利益相关者报告调查结果

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

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

数据库测试阶段

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

数据库测试的关键阶段是 -

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

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

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

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

• 设置夹具- 这涉及将数据输入数据库并检查数据库的当前状态。

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

数据库测试——技术

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

数据库模式测试

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

验证数据库和设备

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

表、列、列类型规则检查

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

• 数据库中所有表的名称

• 每个表的列名称

• 每个表的列类型

• 是否检查NULL值

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

• 用于更正表名称和访问权限的规则定义

键和索引

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

• 每个表的主键

• 每个表的外键

• 外键列与其他表中的列之间的数据类型 索引，聚簇或非聚簇 唯一或不唯一

存储过程测试

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

• 存储过程名称

• 参数名称、参数类型等

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

• 存储过程的作用是什么以及存储过程不应该做什么？

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

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

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

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

触发测试

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

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

服务器设置脚本

应进行两种类型的测试 -

• 从头开始设置数据库，并且
• 设置现有数据库。

SQL Server 集成测试

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

• 应集中调用存储过程来选择、插入、更新和删除不同表中的记录，以发现任何冲突和不兼容的情况。

• 架构和触发器之间的任何冲突。

• 存储过程和架构之间的任何冲突。

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

功能测试方法

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

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

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

发生以下过​​程 -

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

• 该过程将更新一些表。

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

压力测试

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

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

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

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

基准测试

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

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

通过前端测试数据库

有时也可以通过前端测试来发现后端错误。您可以按照下面给出的简单步骤通过前端测试来检测错误。

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

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

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

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

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

数据库测试 – 场景

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

结构化数据库测试

下面给出了与结构化数据库测试相关的常见数据库场景 -

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

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

• 外键列与其他表中的列之间的数据类型 索引、聚簇或非聚簇唯一或不唯一。

功能数据库测试

与功能数据库测试相关的常见数据库测试场景是 -

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

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

非功能数据库测试

与非功能数据库测试相关的常见数据库测试场景是 -

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

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

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

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

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

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

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

数据库测试 – 对象

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

模式

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

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

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

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

数据仓库中使用的常见模式类型是 -

• 星型模式
• Snowflake模式
• 银河图式

数据库中的表

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

示例- 客户表包含客户 ID、地址、电话号码等一系列列的信息。

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

存储过程

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

触发器

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

数据库测试——数据完整性

数据完整性在数据库中很重要。它包括插入、更新和删除之前的数据验证。必须有触发器来验证引用表记录。

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

• 您需要检查每个表中的主要列并验证是否存在错误数据。（姓名字段中的字符、负百分比等）

• 找出不一致的数据，插入到相关表中，看看是否出现故障。

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

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

数据库测试 – 数据映射

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

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

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

数据映射的关键方面

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

• 检查UI/前端表单中的字段并与相应的数据库表映射一致。如上所述，该映射信息在需求文档中定义。

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

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

数据映射测试的步骤

下面给出了数据映射测试遵循的步骤 -

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

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

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

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

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

数据库测试 – 性能

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

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

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

负载测试

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

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

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

• 对于普通事务，您应该包括一个非编辑事务来检查这些类型事务的数据库性能。

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

压力测试

执行压力测试是为了识别系统断点。此处应用程序的加载方式导致系统在某一时刻出现故障。这个点称为数据库系统的断点。压力测试也称为疲劳测试。

确定数据库事务的状态需要付出大量的努力。需要适当的规划以避免任何基于时间和成本的问题。

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

数据库测试 – 工具

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

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

数据库测试-备份

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

假设一家金融公司拥有与其客户相关的数据，例如账户号码、客户名称、贷方和借方、期限等。这样的组织将如何应对在数据故障时丢失如此重要信息的压力？

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

数据备份的类型

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

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

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

示例- 进行数据备份的常用工具之一是Oracle Recovery Manager (RMAN)，它是一种用于进行数据库备份的 Oracle 实用程序。

RMAN由两个组件组成 -

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

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

BACKUP VALIDATE用于测试您是否能够对数据库文件进行有效备份。它确保 -

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

数据库测试 – 恢复

数据库恢复测试用于确保数据库能够恢复。恢复测试使您可以查明应用程序是否正常运行，并检查是否检索了如果恢复方法设置不正确就会丢失的宝贵数据。

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

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

• 备份软件中出现任何错误或错误，您需要尽早解决这些问题。

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

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

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

您需要在项目的早期阶段运行恢复测试。这允许您从系统中删除并丢弃各种类型的错误。以下是测试时应考虑的一些重要要点的列表 -

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

• 您希望执行恢复计划的时间段。

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

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

在数据库恢复测试中，需要在实际环境中进行测试，看看在业务环境中发生灾难或其他不可预见的事件时，系统或数据是否能够真正恢复。

下面给出了数据库恢复测试中执行的常见操作 -

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

数据库测试 – 安全

数据库安全测试的目的是发现安全机制中的漏洞，也可以发现数据库系统的漏洞或弱点。

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

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

• 验证
• 授权
• 保密
• 可用性
• 正直
• 弹力

数据库系统上的威胁类型

SQL注入

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

数据库中的权限提升

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

拒绝服务

在此类攻击中，攻击者会使其合法用户无法使用数据库系统或应用程序资源。应用程序还可能受到导致应用程序（有时甚至是整个机器）无法使用的攻击。

未经授权访问数据

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

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

身份欺骗

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

数据处理

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

数据库安全测试技术

渗透测试

渗透测试是对计算机系统的攻击，目的是发现安全漏洞，从而可能获得对其及其功能和数据的访问权限。

风险发现

风险发现是评估和决定涉及损失类型和漏洞发生可能性的风险的过程。这是在组织内部通过各种访谈、讨论和分析来确定的。

SQL注入测试

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

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

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

密码破解

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

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

数据库系统安全审计

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

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

数据库安全测试工具

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

Zed 攻击代理

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

帕罗斯岛

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

社会工程师工具包

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

跳鱼

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

织女星

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

麋鹿

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

网状圣甲虫

它是用 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);