在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表，理论可行，但我没有测试，因此不予推荐。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
