数据测试教程

什么是数据库测试？

数据库测试检查被测数据库的模式，表，触发器等。 它可能涉及使用负载/压力测试创建复杂查询并检查其响应性。 它检查数据的完整性和一致性。

GUI和数据测试的区别

GUI	数据测试
图形用户界面测试或前端测试	属于后台测试
用户可见部分，如表单，演示文稿，图表，菜单和报告等。	通常对用户隐藏的可测试项目
关注文本框、下拉菜单等控件，页面跳转、图像和主观体验等。	关注架构， 数据库表， 列 ， 键和索引， 存储过程， 触发器， 数据库服务器验证， 验证数据重复
了解业务需求以及开发工具的使用以及自动化框架和工具的使用。	具有数据库服务器和结构化查询语言概念的强大背景。

数据库测试的类型

图片.png

结构测试、功能测试、非功能测试

结构测试

结构数据测试涉及验证数据存储库内的所有元素，这些元素主要用于存储数据，并且不允许最终用户直接操作。 在这些类型的测试中，数据库服务器的验证也是一个非常重要的考虑因素。 测试人员需掌握SQL查询。

schema测试

模式测试确保前端和后端之间的模式映射是一致。 因此，我们也可以将模式测试称为映射测试。

最重要检查点。

1. 验证与数据库关联的各种模式格式。 很多时候，表的映射格式可能与应用程序的用户界面级中存在的映射格式不兼容。
2. 验证在未映射的表/视图/列。
3. 还需要验证环境中的异构数据库是否与整个应用程序映射一致。

我们还要看一些用于验证数据库模式的有趣工具。

• 与Ant集成的DBUnit非常适合映射测试。
• 通过编写简单查询或代码来检查和查询数据库的模式。

数据库表，列测试

让我们看一下数据库和列测试的各种检查。

1. 后端中数据库字段和列的映射是否与前端中的映射兼容。
2. 数据库字段和列的长度和命名约定。
3. 是否存在任何未使用/未映射的数据库表/列。
4. 验证兼容性

• 数据类型
• 字段长

后端数据库列的大小与应用程序前端中的列的数据库列的大小相同。

5. 数据库字段是否允许用户按业务需求规范文档的要求提供所需的用户输入。

密钥和索引测试的检查点

1. 检查是否需要：主键和外键及其约束。
2. 检查外键引用是否有效。
3. 检查两个表中主键的数据类型和对应的外键是否相同。
4. 检查是否已对所有键和索引遵循所需的命名约定。
5. 检查所需字段和索引的大小和长度。
6. 是否需要聚集索引和非聚集索引

存储过程测试

要为存储过程验证的最重要事项的列表。

1. 开发团队是否确实采用了所需要的

• 编码标准惯例
• 异常和错误处理

用于所测试应用程序的所有模块的所有存储过程。

2. 开发团队是否通过将所需的输入数据应用于被测应用程序来覆盖所有条件/循环。
3. 每当从数据库中的所需表中提取数据时，开发团队是否正确应用了TRIM操作。
4. 手动执行存储过程是否为最终用户提供所需结果
5. 手动执行存储过程是否确保按正在测试的应用程序的要求更新表字段。
6. 执行存储过程是否允许隐式调用所需的触发器。
7. 验证是否存在任何未使用的存储过程。
8. 验证可以在数据库级别完成的Null条件。
9. 验证当被测试数据库为空时，所有存储过程和函数已成功执行。
10. 根据被测应用程序的要求验证存储过程模块的整体集成。

一些用于测试存储过程的有趣工具是LINQ，测试工具等。

触发测试

1. 在触发器的编码阶段是否遵循了所需的编码约定。
2. 检查为各个DML事务执行的触发器是否已满足所需条件。
3. 触发器是否在执行后正确更新数据。
4. 在所测试的应用程序字段中验证所需的更新/插入/删除触发器功能。

数据库服务器验证

1. 检查业务要求指定的数据库服务器配置。
2. 检查所需用户的授权。
3. 检查数据库服务器是否能够满足业务需求规范所指定的最大允许用户事务数量的需求。

功能测试

确保最终用户执行的大多数事务和操作与需求规范一致。

以下是数据库验证需要遵守的基本条件。

• 字段是否必需，同时允许该字段上的NULL值。
• 字段的长度是否足够大？
• 是否所有类似字段在表中都具有相同的名称？
• 数据库中是否存在任何计算字段？

此特定过程是从最终用户角度验证字段映射。 在该特定场景中，测试器将在数据库级执行操作，然后将导航到相关用户界面项以观察并验证是否已经执行了适当的字段验证。

反之亦然条件，其中首先由测试者在用户界面处执行操作，然后从后端验证操作，也被认为是有效选项。

数据完整性和一致性

以下检查很重要

1. 数据是否在逻辑上组织良好
2. 存储在表中的数据是否正确并且是否符合业务要求。
3. 被测应用程序中是否存在任何不必要的数据。
4. 数据是否已根据对从用户界面更新的数据的要求进行存储。
5. 在将数据插入到测试数据库之前，是否对数据执行了TRIM操作。
6. 交易是否已根据业务需求规范执行以及结果是否正确。
7. 如果根据业务要求成功执行了事务，是否已正确提交数据。
8. 如果最终用户未成功执行事务，则数据是否已成功回滚。
9. 在事务尚未成功执行且多个异构数据库参与相关事务的情况下，数据是否已完全回滚。
10. 是否已使用系统业务要求指定的所需设计过程执行所有事务。

参考资料

• 下载：https://itbooks.pipipan.com/fs/18113597-368513654
• 讨论qq群630011153 144081101
• python测试开发项目实战-目录
• 本文涉及的python测试开发库 谢谢点赞！
• 本文相关海量书籍下载
• 2018最佳人工智能机器学习工具书及下载(持续更新)
• 软件测试专家工具包3移动端
• 软件测试专家工具包2性能测试
• 软件测试专家工具包1web测试
• https://www.guru99.com/data-testing.html
• 40+ Best Database Testing Tools - Popular Data Testing Solutions
• Database Testing In a Nutshell https://www.techbeamers.com/database-testing/
• Database Testing Complete Guide (Why, What, and How to Test Data)

登录和用户安全

登录和用户安全凭证的验证需要考虑以下事项。

1. 应用程序是否阻止用户在应用程序中进一步继续进行操作

• 用户名无效但密码有效
• 有效用户名但密码无效。
• 用户名无效，密码无效。
• 有效的用户名和有效的密码。

2. 是否允许用户仅执行业务要求指定的特定操作。
3. 数据是否受到未经授权的访问
4. 是否使用不同的权限创建了不同的用户角色
5. 是否所有用户都按照业务规范的要求对指定的数据库具有所需的访问级别。
6. 检查密码，信用卡号等敏感数据是否已加密，而不是作为纯文本存储在数据库中。 确保所有帐户都应具有复杂且不易猜到的密码是一种很好的做法。

非功能测试

数据库测试环境中的非功能测试可以根据业务需求分类为各种类别。 这些可以是负载测试， 压力测试 ，安全测试， 可用性测试[兼容性测试等。 在涉及非功能测试的角色时，负载测试以及可在性能测试的范围内进行分组的压力测试有两个特定目的。

风险量化 - 风险量化实际上有助于利益相关者确定在所需负载水平下的各种系统响应时间要求。 这是任何质量保证任务的初衷。 我们需要注意的是，负载测试不能直接降低风险，但通过风险识别和风险量化过程，可以提供纠正机会，并提供可以降低风险的补救措施。

最低系统设备要求 - 我们通过正式测试观察到的理解，最低系统配置将使系统满足利益相关者正式规定的性能期望。 这样可以最大限度地减少无关的硬件，软件和相关的拥有成本。 此特定要求可归类为整体业务优化要求。

负载测试

应清楚地理解和记录任何负载测试的目的。

以下类型的配置是负载测试的必要条件。

1. 如果效率不高，最常用的用户事务可能会影响所有其他事务的性能。
2. 最终测试套件中应包含至少一个非编辑用户事务，以便可以将此类事务的性能与其他更复杂的事务区分开来。
3. 应该包括促进系统核心目标的更重要的交易，因为根据定义，这些交易的负载失败具有最大的影响。
4. 应包括至少一个可编辑的事务，以便可以将此类事务的性能与其他事务区分开来。
5. 观察大量虚拟用户对所有预期需求的最佳响应时间。
6. 观察各种记录的有效时间。

参考：

• 性能测试工具nGrinder介绍 https://china-testing.github.io/testing_performance_tool_ngrinder.html
• 性能测试工具开发基础：python库介绍-multiprocessing：多进程 https://www.jianshu.com/p/5d5b6225edbc
• 2018最佳12个开源或免费web服务器和客户端性能测试工具 https://www.jianshu.com/p/52f32a312b9a

压力测试

压力测试强调测试中的应用程序具有大量工作，使得系统失效。这有助于识别系统的故障点。

最常见的问题

1. 为了确定数据库事务的状态，可能涉及大量的开销。
2. 解决方案：应整理整个流程规划和时间安排，以避免出现基于时间和成本的问题。
3. 在清理旧测试数据后，必须设计新的测试数据。
4. 解决方案：应该掌握测试数据生成的先前计划和方法。
5. 需要SQL生成器来转换SQL验证器，以确保SQL查询易于处理所需的数据库测试用例。
6. 解决方案：维护SQL查询及其持续更新是整个测试过程的重要组成部分，应该是整个测试策略的一部分。
7. 上述先决条件确保数据库测试程序的设置既昂贵又耗时。
8. 解决方案：质量和整个项目进度持续时间之间应该有一个很好的平衡。

与数据库测试相关的误区或误解。

1. 数据库测试需要大量的专业知识，这是一项非常繁琐的工作

• 现实：有效和高效的数据库测试为整个应用程序提供了长期的功能稳定性，因此有必要在其背后付出艰苦的努力。

2. 数据库测试增加了额外的工作瓶颈

• 现实：相反，数据库测试通过发现隐藏的问题为主要工作增加了更多价值，从而积极地帮助改进整体应用。

3. 数据库测试会降低整个开发过程的速度

• 现实：大量的数据库测试有助于整体提高数据库应用程序的质量。

4. 数据库测试可能成本过高

• 现实：数据库测试的任何支出都是一项长期投资，可以实现应用程序的长期稳定性和稳健性。 因此，数据库测试的开支是必要的。

最佳实践

• 包括元数据和功能数据在内的所有数据都需要根据需求规范文档的映射进行验证。
• 需要验证由/与开发团队协商创建的测试数据的验证。
• 使用手动和自动化程序验证输出数据。
• 部署各种技术，例如原因效果绘图技术，等效分割技术和边界值分析技术，用于生成所需的测试数据条件。
• 还需要验证所需数据库表的引用完整性验证规则。
• 为数据库一致性验证选择默认表值是一个非常重要的概念是否已在数据库中成功添加日志事件以用于所有必需的登录事件
• 预定的工作是否及时执行？
• 及时备份数据库。