数据库测试 – 快速指南

数据库测试 – 概述

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

例子

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

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

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

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

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

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

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

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

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

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

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

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

数据库测试与前端测试

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

数据库测试 – 类型

基于数据库的功能和结构，数据库测试可以分为三类 –

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

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

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

结构数据库测试

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

讨论了在结构测试方面测试的常见组件 –

架构/映射测试

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

在模式测试中 –

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

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

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

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

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

存储过程和视图测试

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

测试人员确保 –

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

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

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

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

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

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

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

触发测试

在触发测试中，测试人员需要确保以下内容 –

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

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

• 一旦数据被执行，触发器是否正确更新数据。

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

表和列测试

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

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

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

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

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

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

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

• 检查保持键的唯一和非空特性。

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

数据库服务器检查

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

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

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

• 如果按照要求维护用户授权。

功能测试

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

黑盒测试

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

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

它的优点如下 –

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

它的缺点如下 –

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

白盒测试

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

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

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

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

非功能测试

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

负载测试

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

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

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

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

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

压力测试

执行压力测试以识别系统断点。在此测试中，应用程序的加载方式使得系统在某一时刻出现故障。该点称为数据库系统断点。

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

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

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

数据库测试 – 流程

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

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

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

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

数据库测试阶段

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

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

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

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

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

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

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

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

数据库测试 – 技术

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

数据库模式测试

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

验证数据库和设备

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

表、列、列类型规则检查

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

• 数据库中所有表的名称

• 每个表的列名

• 每个表的列类型

• 是否检查NULL值

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

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

键和索引

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

• 每个表的主键

• 每个表的外键

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

存储过程测试

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

• 存储过程名称

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

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

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

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

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

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

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

触发测试

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

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

服务器设置脚本

应执行两种类型的测试 –

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

SQL Server 集成测试

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

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

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

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

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

功能测试方法

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

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

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

发生以下过​​程 –

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

• 程序将更新一些表。

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

压力测试

压力测试涉及获取主要数据库功能和相应存储过程的列表。按照下面给出的步骤进行压力测试 –

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

• 在特定时间段内一次又一次地执行测试脚本。

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

基准测试

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

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

通过前端测试数据库

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

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

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

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

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

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

数据库测试——场景

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

结构化数据库测试

下面给出了关于结构化数据库测试的常见数据库场景 –

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

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

• 外键列和其他表索引列之间的数据类型，聚集或非聚集唯一或不唯一。

功能数据库测试

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

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

• 检查数据流并查看可以检查数据的位置。从前端开始。

非功能性数据库测试

关于非功能性数据库测试的常见数据库测试场景是 –

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

• 在特定时间段内一次又一次地执行测试脚本。

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

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

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

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

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

数据库测试——对象

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

模式

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

数据库模式是一组被称为强加于数据库的完整性约束的公式。这些完整性约束确保架构各部分之间的兼容性。

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

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

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

• 星型架构
• 雪花架构
• 银河架构

数据库中的表

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

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

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

存储过程

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

触发器

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

数据库测试 – 数据完整性

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

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

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

• 找出不一致的数据，插入到相关表中，看看有没有失败。

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

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

数据库测试 – 数据映射

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

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

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

数据映射的关键方面

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

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

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

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

数据映射测试的步骤

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

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

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

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

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

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

数据库测试 – 性能

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

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

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

负载测试

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

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

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

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

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

压力测试

执行压力测试以识别系统断点。在这里，应用程序的加载方式使得系统在某一时刻出现故障。这个点称为数据库系统的断点。压力测试也称为疲劳测试。

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

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

数据库测试——工具

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

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

数据库测试 – 备份

组织增长的最重要部分是其数据。如果系统出现故障，则需要恢复数据。备份是数据库的精确副本，可帮助您在数据丢失时恢复数据。

假设一家财务公司拥有与其客户相关的数据，例如账号、客户姓名、贷记和借记、期限等。如果发生数据故障，这样的组织将如何应对丢失这些重要信息的压力？

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

数据备份的类型

有两种类型的备份可以使用 –

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

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

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

RMAN由两个组件组成 –

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

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

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

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

数据库测试 – 恢复

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

数据库测试 – 安全

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

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

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

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

数据库系统上的威胁类型

SQL注入

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

数据库中的提权

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

拒绝服务

在这种类型的攻击中，攻击者会使其合法用户无法使用数据库系统或应用程序资源。应用程序也可能以导致应用程序（有时是整台机器）无法使用的方式受到攻击。

未经授权访问数据

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

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

身份欺骗

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

数据操作

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

数据库安全测试技术

渗透测试

渗透测试是对计算机系统的一种攻击，其目的是寻找安全漏洞，潜在地获得对其、其功能和数据的访问权限。

风险发现

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

SQL注入测试

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

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

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

密码破解

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

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

数据库系统安全审计

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

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

数据库安全测试工具

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

Zed 攻击代理

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

帕罗斯

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

社会工程师工具包

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

跳鱼

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

织女星

它是一种开源的多平台 Web 安全工具，用于查找 Web 应用程序中的 SQL 注入、跨站点脚本 (XSS) 和其他漏洞的实例。它是 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);