在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表，理論可行，但我沒有測試，因此不予推薦。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
