本文主要是介绍数据库测试点，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
包括测试实际数据(内容)以及数据完整性,已经确保数据没有被误用以及规划的正确性,同时也对数据库应用(例如,Sql处理组件)进行功能性测试.通常会用到SqL脚本进行数据库测试.尽管不是所有的数据库都是适合Sql的,但是通过Sql数据库可以支持绝大部分数据操作,大多数的Web应用程序也是如此。
通常有两类由数据库错误引发的问题，它们是数据完整性错误以及输出错误。输出错误是在数据提取和操作数据指令过程中发生的错误引起的，这时源数据是正确的。
通常，数据操作包含了以下一些活动：
首次活动（例如安装过程）
1. 连接数据库
2. 创建新数据库
3. 创建表格,默认值和规则,填入默认数据
4. 编译存储过程和触发器
在成功安装过程完成之后，对数据库的使用由以下活动组成：
1. 连接数据库
2. 执行Sql语句,存储过程以及触发器
3. 释放与数据库的连接
在数据库活动中所包含的错误主要有以下几种常见类型:
1. 连接数据库失败,引起该类失败的许多潜在问题包括:
a. 非法的用户名，密码或者二者皆非法
b. 对于某些数据活动，如创建表和存储过程,用户拥有不适当的权限
c. 非法或错误的DSN
d. 与拥有必要的DSN文件的服务器连接失败
指令(存储过程,触发器等)中常见错误包括:
1. 数据库被配置为区分大小写的，但是代码却没有
2. 在Sql语句中使用了保留关键字,例如Select user from mytable.user为保留关键字
3. NULL被传递给不接受NULL的记录字段
4. 在字符串字段中对单引号( ‘ )的错误处理
5. 在整型字段中对逗号( ，)的错误处理
6. 数值对于字段大小来说过大，字符串对于字段的长度来说过长
7. 超时—数据库执行完某个过程所用时间长于脚本中所设定的超时值
8. 非法或错误拼写的字段,列,表或者视图的名称,未定义的字段,表或视图的名称,非法或错误拼写的存储过程名称
9. 调用错误的存储过程
10. 缺少关键字
实例介绍
缺少关键字的:create view student_view select * from student_tbl.其中语句缺少 as关键字.
数据库测试
随着软件业的迅猛发展，我们的开发也从以前的单层结构进入了三层架构甚至现在多层架构的设计，而数据库从以前一个默默无闻的后台仓库，逐渐成为了数据库系统，而数据库开发设计人员成为了炙手可热的核心人员。以前我们往往把数据库操作写在应用层，从而提高各个模块的独立性和易用性，而现在越来越多的数据库操作被作为存储过程直接放在数据库上进行执行来提高执行效率和提高安全性。
数据库开发既然在软件开发的比重逐步提高，随之而来的问题也突出。我们以前往往重视对代码的测试工作，随着流程技术的日益完善，软件质量得到了大幅度的提高，但数据库方面的测试仍然处于空白。我们从来没有真正将数据库作为一个独立的系统进行测试，而是通过对代码的测试工作间接对数据库进行一定的测试。随着数据库开发的日益升温，数据库测试也需要独立出来进行符合自身特点的测试工作。数据库开发和应用开发并没有实质上的区别，所以软件测试的方法同样适用于数据库测试。
从测试过程的角度来说我们也可以把数据库测试分为：
系统测试
传统软件系统测试的测试重点是需求覆盖，而对于我们的数据库测试同样也需要对需求覆盖进行保证。那么数据库在初期设计中也需要对这个进行分析,测试.例如存储过程，视图，触发器，约束，规则等我们都需要进行需求的验证确保这些功能设计是符合需求的.另一方面我们需要确认数据库设计文档和最终的数据库相同，当设计文档变化时我们同样要验证改修改是否落实到数据库上。
这个阶段我们的测试主要通过数据库设计评审来实现。
集成测试
集成测试是主要针对接口进行的测试工作，从数据库的角度来说和普通测试稍微有些区别对于数据库测试来说，需要考虑的是：
数据项的修改操作；
数据项的增加操作；
数据项的删除操作；
数据表增加满；
数据表删除空；
删除空表中的记录；
数据表的并发操作；
针对存储过程的接口测试；
结合业务逻辑做关联表的接口测试；
同样我们需要对这些接口考虑采用等价类，边界值，错误猜测等方法进行测试。
单元测试
单元测试侧重于逻辑覆盖，相对对于复杂的代码来说，数据库开发的单元测试相对简单些，可以通过语句覆盖和走读的方式完成系统测试相对来说比较困难，这要求有很高的数据库设计能力和丰富的数据库测试经验。而集成测试和单元测试就相对简单了。
而我们也可以从测试关注点的角度对数据库进行分类：
功能测试
对数据库功能的测试我们可以依赖与工具进行。
DBunit
一款开源的数据库功能测试框架，可以使用类似与Junit的方式对数据库的基本操作进行白盒的单元测试，对输入输出进行校验。
QTP
大名鼎鼎的自动测试工具，通过对对象的捕捉识别，我们可以通过QTP来模拟用户的操作流程，通过其中的校验方法或者结合数据库后台的监控对整个数据库中的数据进行测试。个人觉得比较偏向灰盒。
DataFactory
一款优秀的数据库数据自动生成工具，通过它你可以轻松的生成任意结构数据库，对数据库进行填充，帮助你生成所需要的大量数据从而验证我们数据库中的功能是否正确。这是属于黑盒测试。
数据库性能
虽然我们的硬件最近几年进步很快，但是我们需要处理的数据以更快的速度在增加。几亿条记录的表格在现在是司空见惯的，如此庞大的数据量在大量并发连接操作时，我们不能像以前一样随意的使用查询，连接查询，嵌套查询，视图，这些操作如果不当会给系统带来非常巨大的压力，严重影响系统性能。
性能优化分4部分：
1. 物理存储方面
2. 逻辑设计方面
3. 数据的参数调整
4. SQL语句优化
我们如何对性能方面进行测试呢，业界也提供了很多工具。
通过数据库系统的SQL语句分析工具，我们可以分析得到数据库语句执行的瓶颈，从而优化SQL语句。
Loadrunner
这个不用多说，我们可以通过对协议的编程来对数据库做压力测试。
Swingbench（这是一个重量级别的feature，类似LR，而且非常强大，只不过专门针对oracle而已）
数据库厂商也意识到这点，例如：
oracle11g已经提供了real applicationtest，提供数据库性能测试，分析系统的应用瓶颈。
还有很多第三方公司开发了SQL语句优化工具来帮助你自动的进行语句优化工作从而提高执行效率。
安全测试
软件日益复杂，而数据又成为了系统中重中之重的核心，从以往对系统的破坏现在更倾向于对数据的获取和破坏。而数据库的安全被提到了最前端。自从SQL 注入攻击被发现，冒失万无一失的数据库一下从后台变为了前台，而一旦数据库被攻破，整个系统也会暴露在黑客的手下，通过数据库强大的存储过程，黑客可以轻松的获得整个系统的权限。而SQL的注入看似简单缺很难防范，对于安全测试来说，如何防范系统被注入是测试的难点。业界也有相关的数据库注入检测工具，来帮助用户对自身系统进行安全检测。
对于这点来说业界也有标准，例如ISO IEC 21827，也叫做SSECMM3.0，是CMM和ISO的集成的产物，专门针对系统安全领域的另外一方面，数据库的健壮性，容错性和恢复能力也是我们测试的要点，我们也可以发现功能测试，性能测试，安全测试，是一个由简到繁的过程，也是数据库测试人员需要逐步掌握的技能，这也是以后公司对数据库测试人员的要求
这篇关于数据库测试点的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
