51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 3386|回复: 7
打印 上一主题 下一主题

[求助] TD数据合并-TD8SP2oracle版

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2007-8-10 11:12:53 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
[原创]TD数据合并-TD8SP2oracle版
Version:
TD数据合并-gqn20070304
TD数据合并-gqn20070306修改
TD数据合并-gqn20070810修改for 51testing

背景:
      在2007年一、二月份封闭开发工作中,为了方便软件缺陷(bug)的管理和追踪,1月17日在B服务器安装配置了Test Direct 8.0 SP2,并将公司截止到1月17日A的TD数据库进行了克隆。2月17日,由于春节的原因,封闭开发工作中止,所有人员设备返回公司。节后集中开发工作重新开始,同时需要对两套TD的数据进行合并,以增加可维护性和易管理性。两套TD环境分别为:
      A. A服务器:公司TD正式环境;
      B. B服务器:封闭开发工作中配置的TD环境;
      TD环境版本:Test Direct 8.0 SP2。
      合并目标:B的使用完毕,也就是封闭开发工作结束后,将其所有的数据尽可能安全完整的合并到A中。
本文中多数的操作,都是在对TD的表结构不清晰的情况下进行探索式考虑的,如果有条件可以事先弄清楚这些表结构,会对以后的合并工作有极大帮助。

正文:
      和所有Test Direct 的初学者类似,我们平时对于TD中的Test Plan、Defects等部分的印象较为深刻,而对于其他部分的功能和作用很少涉及。因此,此次的合并工作也是目标明确的学习机会,就像每天适量的锻炼身体,只要参与就可以从中受益。
      深吸口气,让我们开始。

      A---->B的克隆
      A的准备工作
      1月17日的A的TD8.0数据库备份,并没有采用TD自己的备份系统功能(主要是不了解这个功能是否对以后的数据合并有帮助,汗=_=!,有时间可以学习下),而是采用了Oracle数据库的备份方式exp-->*.dmp,对备份后的dmp文件进行压缩后,文件大小变为只有几兆的rar,通过电子邮件就可以进行传送。(bug的附件存放在服务器TD共享文件夹的相应project下,不能确定合并后复制到目标下的project,路径更改是否会影响附件使用,有时间可以尝试下。)
Oracle数据库的导出可以使用命令方式或者PLsql等工具方式,其导出命令格式为:
Exp system/password@SID_IPaddress file=X:\backupfilename.dmp owner=TDdbuser
相应的,ATD数据库的导出备份命令为:
Exp system/****@tdbase_*.*.*.A file=E:\Abak.dmp owner=software_project_db
      以上导出工作由同事L完成后,压缩并电邮给我。
      我在接收到这个dmp后,先存放待用。

      B的准备工作
      在B服务器安装配置TD8.0后,登录Site Administrator页面,新建域[Create Domain]和项目[Create Project]。创建完毕后,默认创建[数据库用户]的格式为:domain_project_db。我在software域创建了project项目,其数据库用户对应为:software_project_db,用system登录B数据库,查看数据库用户software_project_db,一些TD的初始化表已经建立,为了防止导入(imp)时的冲突,需要对其初始化的数据库表进行删除(drop),删除完毕并确认已经完全删除后,进行导入(imp)。
Oracle数据库的导入命令格式为:
Imp system/password@SID_IPaddress [fromuser =源dbuser touser =目标dbuser] file = X:\backupfilename.dmp [ignore=y]
相应的,将ATD数据库的导出备份Abak.dmp导入到B相应TD数据库的命令为:
Imp system/****@tdbase_*.*.*.B fromuser = software_project_db touser=software_project_db file = E:\Abak.dmp

      经过1月17日-2月14日二十多天的使用,B的TD数据库新增了bug/defects(bug)、新增了用户(user)、新增了subject(all_list),相应项目的数据库用户的表多数已经更改。
而且,与此同时,A的数据库作了更大量的新增。

      TD数据库包含:actions, alert, all_lists, bug, bug_tokens, cache, change, change_cover, change_entry, common_settings, cros_ref, cycle, cycl_fold, dataconst, dessteps, groups, history, hosts, host_group, host_in_group, locks, mailcond, modules, namemap, req, req_cover, rules, run, sequences, step, step_params, system_field, systranslate, tables, test, testcycl, tokens, to_alert, tran_rules, users, vc_cros_ref, vc_dessteps, vc_step_params, vc_test, ver_ctrl 等表,但不能确定其他功能操作是否可以生成新表。

考虑合并方案。
      合并是应该遵循的基本原则
      1 确保公司正式环境的安全,保持该环境原有数据的不变;
      2 对于准备进行合并的数据的修改,要尽量与正式环境保持一致性;
      3 尽可能少的修改。

      为了防止意外对数据的损坏,在B新增并克隆了两套TD的project:Abak和Bbak,作为方案测试的专用环境。

最初考虑的方案,也是理论上可行的方案
      如果修改Bbak的bugID和subject等项,则需要修改all_list、bug、bug_tokens、history、tokens表以及users表等一系列相互关联的表。在实际试验中,修改完毕各个相关表后,对数据库进行导出Bbakedit.dmp,再导入到Abak中,导入时设置参数ignore=y,导入完毕后,登录Abak的环境查看,发现原有数据已出现问题,实验初步失败。可能的原因是,对原有数据的处理可能存在问题,另外,如果使用这种方法,应确保导入时尽可能少的重复项和尽可能少的导入导出数据。由于时间和项目管理项目的关系,我没有再在这种方案上花费更多的时间,如果有时间的话还是值得继续深入研究的。

尝试后可行的方案
      在经历了多次失败后,心情有些灰暗,先后放弃了n种方案。最后,在网上查找TD的相关资料时,看到有网友建议使用的简单而有效的方法:利用系统的copy defects直接复制bug,从而减少对bug信息的修改,剩下的只用对Bbak修改all_list表和bug表的bg_subject字段,user表的人员提前在Abak进行添加即可。
      看到这个方案的开始就有些兴奋,迅速的思考,然后画出实验流程。在Bbak和Abak进行了完整的测试后,着手正式环境的合并。

正式环境的合并
      实验可行后,进行正式的合并工作,并记录每一步的操作。正式环境为A和B,TD环境版本为Test Direct 8.0 SP2。
      正式环境的合并具体步骤:
1 提前通知所有TD使用者,包括:测试人员、开发人员等,暂时不要使用或者修改TD;
2 在确认无人继续使用后,对A和B进行最后的完整备份;
3 将B备份导入到Bbak中,或者导入到其他新建的TD环境中,打开Bbak数据库,与A对比all_list表,计算两表重复id的项目,update Bbak的id,使之跳过这部分重复id,需要注意的是,修改id时还应注意部分需要修改的fatherid (where fatherid >重复的最小id)。假设有3个id重复,那么该表的修改命令就如:
Update software_Bbak_db.all_list set faherid = faherid +3 where id>4191 and faherid>4191;
Update software_Bbak_db.all_list set id=id+3 where id>4191;
4 修改bug表的bg_subject,对应于all_list表的id,这部分内容仍然在Bbak中进行修改,此步骤用于确认all_list修改的正确性,相应命令如下:
Update software_Bbak_db.bug set bg_subject= bg_subject+3 where bg_subject>4191;
5 登录Bbak的TD环境,查看修改后的bug和subject是否正确,确认修改正确后进行后续的步骤;
6 分别使用PLsql打开Bbak的all_list表和A的all_list表,在B查询id>4191的项,进行全选后复制到A表,这样就可以完全跳过重复的id;
7 用administrator登录ATD的Site Administrator页面,手动添加B中多出的人员,此处不建议使用PLsql复制;
8 用admin同时登录A和B的TD,在B对需要合并的bug(即B有而A没有的数据,可以使用时间过滤)进行批量复制(copy defects),确认复制完整后,切换至A页面进行粘贴(paste defects)。耐心等待一段时间,在粘贴完毕后,查看复制的bug的各个属性和字段,包括附件等。注意,不是从Bbak进行复制,因为Bbak没有配置B原有的附件;
9 对复制完毕后的A修改bug表的bg_subject,使新复制的bug对应于all_list表的id,具体操作如步骤4;
10 修改sequences表list字段,该字段标示为list当前id值,修改后保存即可;
11 修改完毕后,登录A确认bug各属性各字段,测试从页面添加subject和defects;
12 确认并评估完成情况后,通知大家继续使用并且发现问题及时沟通。

此方案存在的问题:
      history中的修改者(Changer)变为步骤8的复制者admin。如果想要解决此问题,或者说你对history有特别要求,就需要重新修改history表,理论可行,但我没有测试,因此不予推荐。

总结:
      这次封闭开发,对于TD以及数据库的学习,是在一种压力下的学习的,有点临时抱佛脚,不过效率高于无目标的学习:),提前学习和用到什么学什么的方式各有各的利弊,建议相互参考。

忠告和建议:
      本文遵循“ All for free , Free for all.”的原则,希望对所有TD的学习或使用者有所帮助。所以,本文的内容不要用于非法或者商业用途,否则我罪过大了。还有,Oracle的学习很重要,中间有关oracle的问题很多都查资料和问同事,这点我还需加紧学习:)
      不要用正式TD环境或数据库做实验,原因很明显:)


致谢:
      感谢各位乐于给予他人帮助的同事、文章作者、论坛的斑竹以及跟贴的兄弟姐妹,没有你们就没有这篇文章的诞生!欢迎大家拍砖跟贴:)

[ 本帖最后由 tsingjob 于 2007-8-10 11:15 编辑 ]
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
 楼主| 发表于 2007-8-16 10:44:46 | 只看该作者
偶然在ITpub看到有人转贴,想说明下,
转贴请注明出处,并保持文章完整,谢谢哈sdlkfj3
回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2007-8-16 10:52:38 | 只看该作者
呵呵,看看
回复 支持 反对

使用道具 举报

该用户从未签到

4#
发表于 2007-8-16 11:52:13 | 只看该作者
看着眼晕,比较多。
想问下:
A是公司的环境,B是封闭环境,B中相关的项目假设是X。
那么,B建立后,A环境的X项目有新的记录么?
回复 支持 反对

使用道具 举报

该用户从未签到

5#
 楼主| 发表于 2007-8-16 12:43:39 | 只看该作者
sdlkfj2
呵呵,有的,因为B建立后就是两个并行的环境了。
A、B中不仅分别有bug增加,还有用户、subject等list数据的增加,涉及到关联的问题。

[ 本帖最后由 tsingjob 于 2007-8-16 12:45 编辑 ]
回复 支持 反对

使用道具 举报

该用户从未签到

6#
发表于 2007-8-16 15:51:38 | 只看该作者
收藏。
回复 支持 反对

使用道具 举报

该用户从未签到

7#
发表于 2007-8-16 17:01:30 | 只看该作者
原帖由 tsingjob 于 2007-8-16 12:43 发表
sdlkfj2
呵呵,有的,因为B建立后就是两个并行的环境了。
A、B中不仅分别有bug增加,还有用户、subject等list数据的增加,涉及到关联的问题。

恩,那就相当麻烦的了
回复 支持 反对

使用道具 举报

该用户从未签到

8#
 楼主| 发表于 2007-8-17 09:30:21 | 只看该作者
sdlkfj2
呵呵,由于当时还在继续封闭中未完成的部分工作,抽时间弄的这个,头都大了~~
不过真的学了不少东西。sdlkfj3
回复 支持 反对

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-11-22 07:42 , Processed in 0.077974 second(s), 27 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表