系统测试
传统软件系统测试的测试重点是需求覆盖,而对于我们的数据库测试同样也需要对需求覆盖进行保证。那么数据库在初期设计中也需要对这个进行分析,测试。例如存储过程,视图,触发器,约束,规则等我们都需要进行需求的验证确保这些功能设计是符合需求的另一方面我们需要确认数据库设计文档和最终的数据库相同,当设计文档变化时我们同样要验证改修改是否落实到数据库上。
这个阶段我们的测试主要通过数据库设计评审来实现。
集成测试
集成测试是主要针对接口进行的测试工作,从数据库的角度来说和普通测试稍微有些区别对于数据库测试来说,需要考虑的是数据项的修改 *** 作、数据项的增加 *** 作、数据项的删除 *** 作、数据表增加满、数据表删除空、删除空表中的记录、数据表的并发 *** 作、针对存储过程的接口测试、结合业务逻辑做关联表的接口测试。
同样我们需要对这些接口考虑采用等价类、边界值、错误猜测等方法进行测试。
单元测试
单元测试侧重于逻辑覆盖,相对对于复杂的代码来说,数据库开发的单元测试相对简单些,可以通过语句覆盖和走读的方式完成。
系统测试相对来说比较困难,这要求有很高的数据库设计能力和丰富的数据库测试经验。而集成测试和单元测试就相对简单了。
而我们也可以从测试关注点的角度对数据库进行分类:
功能测试
对数据库功能的测试我们可以依赖与工具进行:
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,也叫做SSE CMM 30,是CMM和ISO的集成的产物,专门针对系统安全领域的另外一方面,数据库的健壮性,容错性和恢复能力也是我们测试的要点
我们也可以发现功能测试,性能测试,安全测试,是一个由简到繁的过程,也是数据库测试人员需要逐步掌握的技能,这也是以后公司对数据库测试人员的要求。
为了不影响其他的数据库表,新建一张数据库表t_worker_info,代码如下:
create table t_worker_info(
id int(8) primary key not null auto_increment,
w_id int(10) not null,
w_name varchar(20) not null,
w_age int(3),
w_sex varchar(10),
w_birth varchar(20)
);
创建t_worker_info后,查看一下数据结构,代码如下:
desc t_worker_info;
双击选中的数据库,在Views鼠标右键“Create View”,打开编辑窗口,并在窗口中输入代码,代码如下:
CREATE VIEW `view_worker_info` AS
SELECT FROM t_worker_info;
查看创建视图的基本信息,利用desc或describe语句,代码如下:
desc view_worker_info;
查看视图信息,如存储引擎、数据长度等,如果上述指标都为null,说明视图是虚表,代码如下:
show table status like 'view_worker_info';
查看创建视图的详细信息,需要用到show create view 视图名,代码如下:
show create view view_worker_info;
视图 对于数据库来说 是一个最基本的 也是最重要的功能之一 数据库视图设计的好坏 直接跟数据库的性能相关 而且 在大型数据库设计中 大家分工合作 基础表的设计与报表视图的设计往往由不同的人负责 所以 视图的设计管理跟基础表的设计管理一样 都有很大的学问 在这篇文章中 笔者将结合自己在视图设计管理方面的工作经验 谈谈在这方面的一些鲜为人知的技巧
技巧一 把基础表与视图脱离开来
一般来说 视图都是在基础表的上面建立起来的 也就是说 要先有基础表 而后有视图 但是 在大型数据库的设计过程中 出于项目时间的考虑 往往基础表与视图的设计是同时进行的 如一些人负责基础表的建立 另一些人则负责视图的设计与建立等等 在这个过程中 往往基础表不存在的时候 就需要建立一些视图 以加快项目的进度
为了使得基础表的创建和修改与视图的创建于修改没有必然的联系 以便于员工之间工作的同步 提高工作效率 所以 在Oracle数据库中提出了一个 强制创建视图 的概念 也就是说 正常情况下 如果基本表不存在 则创建视图就会失败 但是 我们可以在创建视图的过程中 加入一个参数 只要创建视图的语法没有错误的话 即使基础表不存在 仍然可以建立这张表格 这个有用的参数就是force选项 如我们建立视图时 CREATE FORCE VIEW TEXT 只需要在关键字VIEW之前加入FORCE参数即可 如此的话 系统在编译视图的时候 就不会去考虑基础表是否存在
不过这里要注意一点 若基础表不存在的话 则编译后该视图的状态为 无效 不能再这个视图的基础上执行一些 *** 作 如查询 *** 作等等 当下次访问这个视图的时候 则数据库会对这个视图进行重新编译 若此时基础表存在了 则该基础表就会变为有效;若基础表不存在 则这视图就会失效
Oracle数据库之所以如此设置 主要是出于在数据库设计过程中协同办公的需要 有了这个功能之后 则在数据库建立的过程中 只要把数据库基础表与视图设计好之后 大家就可以分工合作 在数据库中建立相关的对象 不然的话 要等基础表建立好之后再建立视图 如此就会明显的影响数据库建立的进度 所以 在数据库建立的过程中 特别是中大型的数据库系统 这是一个很实用的功能
技巧二 创建视图的理想步骤
无论是简单视图 还是比较复杂的视图 笔者觉得数据库管理员在创建视图的时候 最好能够遵循一定的步骤 这一方面是因为视图的更改相对来说 是一件比较麻烦的工作 所以 我们在建立视图的时候 要确保视图的准确性 另一方面 视图是基础表的一个体现形式 若不按步骤来做的话 有可能就不能够达到我们预计的需求
当然这个步骤没有官方的版本 完全是数据库管理员根据实际的经验总结出来的 这个步骤不仅对Oracle数据库有效 对于其他数据库来说 也是类似的道理
一般来说 视图创建可以分为五步走
第一步 先考虑Select语句的编写 我们知道 视图其实就是一个Select语句的集合 所以 我们建立视图的第一步 就是考虑这个Select语句该如何编写 这个Select语句编写的是否合理 执行效率的高低直接影响着这个视图的性能 另外 在Select语句中 可能还会有格式的控制 内容的编排等等 如在Select语句中 可以把一些字段合并成一个字段;也可以把相关的内容进行倒置等等 这些功能都是Select语句完成的 所以可以这么说 Select语句的编写是视图建立的基础
第二步 对这个Select语句进行测试 当我们编写好Select语句之后 就需要在数据库中执行这条语句 看其能否查询到我们想要的值 在对Select语句进行测试的时候 需要注意一个问题 有时候Select查询语句可以查到准确的数据 但是在以这条语句建立视图的时候 可能就会通不过 如在一些表之间的连接查询的时候 如果两个表中有个字段名相同 是可以的 因为他们除了字段名字之外 还有表名一起来定义这个字段 如A name与B name 这是不算重名的 但是 若在建立视图的时候 这就会被认为是重复的列明 需要对其中的一个列名进行重定义 这一点在数据库视图建立的时候 要特别的注意
第三步 考虑查询结果的准确性 通过查询语句把我们想要的结果查询出来后 我们就需要看看这个结果是否满足我们的需要 在这个过程中 我们主要注意两点 一是形式字段是否齐全 在一些应用系统中 若数据库的视图要能够被前台的应用程序调用的话 则必须包含一些形式字段 如笔者以前在设计一个ERP系统的时候 若前台系统要调用数据库中的视图的时候 必须包含记录更新时间 更新者 记录创建时间 创建者等相关信息 若缺乏这些信息的话 则前台调用这张视图的时候 就会出现错误 故在考虑查询结果准确性的问题的时候 就要考虑到前台应用程序的需要 看看这些形式字段是否齐全 二是实体内容的完整性 我们到底需要显示表中的哪些字段呢 这个我们在这里要确认清楚 若显示内容太多的话 则会影响视图的执行效率 而且也会降低视图的安全性作用;但是 若字段内容显示不足的话 则以后要添加字段的话 会比较麻烦 有一定的工作量 所以在这个检验的时候 需要根据视图的实际功用 确定视图需要显示的内容
第四步 视图的修饰 有时候 为了阅读的方便 我们需要对查询结果进行一些修饰 如现在有两张表 一张是员工基本信息表 这表中有员工姓名 员工职位编号等等;另一张表是职位基本信息表 在这表中有职位编号 职位名称 我们希望在视图中能够如下显示 职位 员工名字 如数据库工程师 Victor 也就是说 把两个字段合并起来 并且在中间加入一个冒号 这些格式性的内容都是在查询的时候实现的 所以 我们确认查询的结果没有错误之后 接下来就要确认格式问题 若能够在视图中规范这些格式问题 则前台的程序设计就会相对来说比较简单
lishixinzhi/Article/program/Oracle/201311/17034
以上就是关于数据库中视图怎么进行软件测试全部的内容,包括:数据库中视图怎么进行软件测试、如何在MySQL中利用数据库表创建视图、Oracle数据库视图管理经验技巧等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)