1、 数据库备份是保障数据库安全的重要手段之一。绝大部分数据库管理员都已经发现对数据库进行备份的重要性，甚至对其具有很大的依赖性。为此数据库管理员必需肯定备份策略确实可靠。一个没有经过测试的备份策略其实比没有进行备份更加糟糕，因为它会给各位数据库管理员一种假的安全感。但是笔者发现不少的数据库管理员在遇到服务器故障时，却不时的会遇到无法顺利利用故障文件恢复数据库或者数据库备份文件不完整等问题。这主要是因为大家只注重数据库的备份策略，但是却忽视了数据库备份文件的测试策略。如果备份文件不完整或者出现错误的话，那么及时备份策略制定的再好，也是竹篮子打水一场空。为此笔者在这里郑重建议大家，数据库备份测试策略
2、与数据库备份策略一样的重要。那么做为 Oracle 数据库管理员，该如何做好这方面的测试工作呢？对此笔者有一家几个招数，或许能够帮助大家解决这方面的问题。招数一：模拟各种现实中可能出现的问题。很多原因会导致数据库服务器罢工，而这些罢工很有可能造成数据库中现有数据的损坏。为此数据库管理员必需凭借自己的经验列举出现实中可能出现的故障情况。然后针对这些可能发生的故障，去测试现有备份策略能否有效的应对。如笔者给企业部署完 Oracle 数据库之后，一般都会模拟各种现实中可能出现的问题。然后针对这些问题进行一一测试。如笔者会在一个更新事务处理的过程中，突然关闭电源。然后再重新启动数据库服务器，查看这次断
3、电事故对服务器可能造成哪些影响？能否利用现有的备份文件与日志文件把数据库中的数据恢复到断电的那一个点上？如笔者还会测试用户错误的更新了大量的数据，并且已经递交了事务。此时需要测试看看能否利用重做日至文件来恢复更新之前的数据？如企业如果采用了磁盘阵列的话，那么笔者还需要测试磁盘阵列的有效性。如把某一块硬盘拿掉，添加上一块新的硬盘，看看其数据库服务器能否正常恢复数据。总之一句话，通过模拟各种失败以及从这些失败中进行恢复，看看能否恢复到故障发生时的点。这些测试工作将会给数据库管理员获得书本上没有的无价经验。具体来说，笔者认为数据库管理员在模拟失败时，以下几个失败的原因不能够放过。一是服务器突然断电，
4、这可能导致配置文件的错误导致无法访问或者数据的丢失；二是重做日志发生损坏，这可能导致数据库管理员无法把数据恢复到故障发生时的点；三是硬盘发生故障而导致数据丢失，这主要是要测试备份文件异地存放的有效性；四是数据批量更新的错误处理，这主要是测试数据库管理员在进行批量更新之前是否有先对数据库进行备份的习惯，等等。数据库管理员只有预先模拟现实中各种可能出现的问题，并得到解决方案。只有如此，在真正遇到这些问题的时候，数据库管理员才能够临危不乱，迅速解决故障。当然这些测试最好是能够在另外一台主机上进行测试。在生产服务器上进行这些破坏性测试的话，可不是一个明智的做法。招数二：需要详细记录备份与还原测试的数据
5、。笔者建议数据库管理员，无论你做了哪些测试，测试的工作是否充分，都需要一五一十的记录下相关的备份与还原测试数据。因为这些故障可能随时发生。到那个时候可没有时间让数据库管理员去研究分析该如何处理。那时如果数据库管理员有类似文档的话，那么只要按照相关文档去处理，就可以减少中间思考的时间，可以迅速利用备份文件与日志文档进行数据库恢复作业。具体来说，笔者认为数据库管理员在测试的时候需要记录如下内容。一是需要记录遇到故障时还原所需要用到的文件以及基本的操作步骤。如当发生硬盘故障时，此时需要恢复故障硬盘中的数据，需要用到哪些文件（可能需要用到保存在其他硬盘上的备份文件与重做日志文件），以及一些操作步骤。记
6、录这些内容有利于数据库管理员在遇到问题的时候迅速找到这些文件并且熟练的应用这些文件进行数据库的恢复作业。二是需要记录备份或者恢复过程中遇到的意外事件。虽然只是模拟失败，但是这个故障以及解决故障过程中出现的意外事件，在实际工作中很有可能会出现。而数据库管理员在遇到这些意外事件时能否轻松应对则是考验数据库管理员能力的地方。笔者在日常工作中，对于这些意外事件无论大小都会一一的进行记录，并且对于如何解决这些意外也会做相关的说明。要知道，这些内容可是数据库管理员的无价之宝，因为这些东西在任何教科书上或者讲座上都是学不到的。只要在模拟过程中经历了一次失败，数据库管理员就应该把当时的情况以及如果处理这种意外
7、事件的解决方案加入到你的工作笔记中。必须切记，意外事件往往不会只发生一次，它很有可能在未来的某个时刻再次发生。养成及时更新自己的工作笔记的习惯，有利于数据库管理员提高自身的水平，提高应对意外事件的能力。三是要勤于跟其他这方面的专家进行交流。如笔者经常会逛各种论坛。在论坛上，有些数据库管理员会把自己遇到的问题在上面列出来，有不少就是在备份或者恢复过程中出现的一些意外事件。这些意外事件有些是数据库管理员以前遇到过的，而有些则是由于工作经验限制没有碰见过的。但是很有可能在以后的工作中为碰到。为此数据库管理员需要预先去了解、收集这些别人碰到的问题，并在可能的情况下模拟这些意外事件，并寻求解决方案。因为
8、别人遇到的意外情况，很可能我们自己在下次也可能会遇到。防范与未然，提早想好解决措施。有利于我们在遇到这些问题时，迅速采取有力的措施解决。招数三：测试，测试，再测试。俗话说，熟能生巧。如果数据库管理员了解了意外事件，也知道该如何处理。但是如果因为不熟悉相关的操作，则很可能会因为操作不当而造成新的意外事件或者造成不可挽回的损失。所以数据库管理员在工作比较空的时候，需要对这些解决方案进行测试。一来是看看随着数据库版本的升级，这些解决方案是否仍然有效；二是提高自己操作的熟练程度，确保以后在遇到类似故障时能够万无一失的进行操作。为了达到这个目的，笔者对自己提出了如下几个要求。一是当数据库新版本出来之后，
9、需要对工作笔记中记录下的解决方案进行测试，以判断这些解决方案是否过期。没有过期最好，如果过期了的话，则必须解决它。如需要考虑这些意外事件在新版中是否仍然会出现。如果仍然会出现的话，则就要在新版本功能的基础上寻找新的解决方案。有些意外事件则可能会随着数据库版本的升级而被解决掉。故数据库管理需要随着数据库版本的升级而不断的进行测试，以提高相关解决方案的时效性。二是给企业部署完成新的解决方案之后，需要挑选一些重要的内容进行测试。如笔者给企业部署完成 Oracle 数据库（采用磁盘阵列）。如果要模拟所有的失败情况并测试相关对解决方案是否可行是不现实的，因为这需要花费很长的时间，得不偿失。此时笔者会挑选
10、一些重要的或者经常发生的意外情况，并测试相关的解决方案是否可行。同时，这也是对企业用户的一种培训，以提高他们独立自主解决问题的能力。如对于上面这个案例，笔者会跟数企业用户一起，进行磁盘阵列有效性的测试。如换一块新的硬盘之后看看数据库服务器是否会自动恢复相关的数据。把企业用户培养起来了，那么我们数据库管理员也可以轻松很多。三是对于一些新的解决方案也需要进行测试。如笔者平时比较喜欢逛论坛。在论坛上有人提出一个问题，后面有很多数据库管理员会把相关的方案写出来。这些方案有些可能是数据库管理员已经知道了的；有些则是他们还没有想到的。此时数据库管理员需要对新的方案进行测试，因为也许这个新的解决方案能够在更
11、短时间内解决故障。以上几个要求就是笔者日常工作中在备份还原测试方面对自己提出的几个要求。大家若认为觉得合理的话，则也可以这么去做。一、黑盒测试在快速应用开发（rad）环境中的重要作用软件测试方法一般分为两种：白盒测试与黑盒测试。其中，白盒测试又称为结构测试、逻辑驱动测试或基于程序本身的测试，着重于程序的内部结构及算法，通常不关心功能与性能指标。黑盒测试又被称为功能测试、数据驱动测试或基于规格说明的测试，实际上是站在最终用户的立场上，检验输入输出信息及系统性能指标是否符合规格说明书中有关功能需求及性能需求的规定。随着 rad 环境的发展，软件工程面临新的挑战，其中包括： 应用系统的规模越来越庞大
12、，结构越来越复杂； 开发团队人员越来越多，分工越来越细； 项目投资日益提高，导致投资风险增大。在这样一种背景下，软件质量面临着更大的危机，而解决问题的关键正是黑盒测试，可是由于传统的黑盒测试往往局限于手工测试，凭借工程人员的经验自发地进行，缺乏严格的测试管理机制，因而效果并不明显。在分发一个应用系统之前，若没有经过科学、周密的黑盒测试，就相当于将大量隐含的缺陷（defect）交付到最终用户手中，这对于开发团队自身、项目投资方及最终用户来说都是不负责任的表现，也将严重损害三方的利益。今天，软件的质量要求越来越受到重视，在对软件的质量监督中，黑盒测试起着重要的、不可替代的作用；而随着软件开发平台及
13、软件设计思想的进步和发展，特别是 rad 技术的发展，对黑盒测试提出了更明确的要求，人们发现，必须遵循一定的测试理论，依赖于优秀的测试工具，才能进行科学、完备的测试。二、黑盒测试的操作步骤在传统的软件开发生命周期当中，测试工作往往被搁置到整个开发过程的后期进行，也就是说，当应用程序的编码工作已经基本完成，才开始进行测试，这样做的缺点在于：a）由于应用程序庞大而复杂，测试工作千头万绪，测试人员难以组织科学、全面的测试用例，从而大幅度提高了测试成本，并严重影响测试的全面性和有效性；b）由于缺陷所涉及的模块从开发到测试之间的时间间隔较长，使得程序员的修改和维护工作要付出更大的代价；c）由于受到分发日
14、期的限制，测试工作往往是在忙碌中结束的，而将大量的缺陷遗留给最终用户，也就是说，真正的测试工作实际上是由最终用户来完成的。因此，为了保证测试工作科学、精确、全面、有序地进行，应该采取一边开发一边测试的策略，使得开发工作与测试工作平行进行，这也就是俗话所说的“越早测试越好 ”的概念。一套完整的测试应该由五个阶段组成：1测试计划首先，根据用户需求报告中关于功能要求和性能指标的规格说明书，定义相应的测试需求报告，即制订黑盒测试的最高标准，以后所有的测试工作都将围绕着测试需求来进行，符合测试需求的应用程序即是合格的，反之即是不合格的；同时，还要适当选择测试内容，合理安排测试人员、测试时间及测试资源等。
15、2测试设计将测试计划阶段制订的测试需求分解、细化为若干个可执行的测试过程，并为每个测试过程选择适当的测试用例（测试用例选择的好坏将直接影响到测试结果的有效性） 。3测试开发建立可重复使用的自动测试过程。4测试执行执行测试开发阶段建立的自动测试过程，并对所发现的缺陷进行跟踪管理。测试执行一般由单元测试、组合测试、集成测试、系统联调及回归测试等步骤组成，测试人员应本着科学负责的态度，一步一个脚印地进行测试。5测试评估结合量化的测试覆盖域及缺陷跟踪报告，对于应用软件的质量和开发团队的工作进度及工作效率进行综合评价。显然，黑盒测试只有严格按照步骤进行，才可能对应用程序的质量进行把关。然而，如果没有一种
16、优秀的测试工具的帮助，单纯凭借手工测试，不但将耗费大量的人力、物力和财力，而且有很多测试工作是难以实现甚至是无法实现的。三、手工测试与自动测试的比较手工测试无法保证黑盒测试的科学性与严密性，这是因为： 测试人员要负责大量文档、报表的制订和整理工作，会变得力不从心； 受软件分发日期、开发成本及人员、资源等诸多方面因素的限制，难以进行全面的测试； 如果修正缺陷所花费的时间相当长，回归测试将变得异常困难； 对测试过程中发现的大量缺陷缺乏科学、有效的管理手段，责任变得含混不清，没有人能向决策层提供精确的数据以度量当前的工作进度及工作效率； 反复测试带来的倦怠情绪及其他人为因素使得测试标准前后不一，测试
17、花费的时间越长，测试的严格性也就越低； 难以对不可视对象或对象的不可视属性进行测试。因此，自动测试成为最佳的解决方案。所谓自动测试，实际上是将大量的重复性工作交给计算机去完成，一个优秀的自动测试工具，不但可以满足科学测试的基本要求，而且可以节约大量的时间、成本、人员和资源，并且测试脚本可以被重复利用（包括被不同的项目所利用） 。问题 1：如果设置 10 个虚拟用户，这些虚拟用户都是用 admin 这个账号登录的吗？-如果脚本没有做参数化，那么 10 个虚拟用户执行的同一个脚本，登陆帐户肯定都是 admin。问题 2：如果 10 个虚拟用户都是 admin 账号登录的话，这个系统中用相同的账号登录会被踢出来的，那真正执行查询操作的还是只有一个 admin 用户了。对吗？-执行一下试试，如果被提出来，会出现事物失败的，看一下结果就明白了。问题 3：如果要测试更多的用户登录系统执行查询操作，是不是要把用户参数化？如果测试 100 个用户同时登录查询的话，就得参数化 100 个用户？这 100个用户就匹配参数中的 100 个用户吧？-LR 是没有用户参数化的这个概念的，参数化的是脚本，每个虚拟用户都是去读脚本，在脚本中参数化对象时可以设置脚本迭代关系（Update value on ）和不同用户读取形式（Select next row ）。
