這篇是寫給自己懺悔的
「人長久處於安逸的情況，就會慢慢的不求上進，對於自己的工作麻痺，許多錯誤的習慣就視而不見。」
最近在處理客戶的一個小小需求，這個需求也不過是把一個日常例行的SSIS Job裡的Table備份多增加幾個而已，依照以前的經驗，當然是測試之後就拿給客戶正式上線了；可是，客戶這幾天反應，這個SSIS Job一直錯誤，從更新之後就沒有成功過。
自己回去測，也沒有發現問題，看看所改的地方，也不至於出錯，那到底問題出在哪裡？抱著忐忑的心情跑去客戶的主機看看，客戶的主機端服務將近百人的業務，而提供的資料，是他們每日生財的資源，每天都有業績壓力的，當然不容許一點差錯，而在時間的壓力下，我做了一件蠢事，我竟然在running server上面跑了這個SSIS。
由於這個SSIS的主要功能是備份資料，通常執行時間是晚上，避開白天正常業務的作業時間，所以這一執行下去就不得了，備份時，各table的locking，以及發生錯誤後，資料的rollback，造成了業務單位的資料庫死結，馬上電話就如飛雪般的過來；逼不得已，業務部門的經理只好請大家停止動作，以教育訓練的名義把大家叫離開電腦前，讓資料庫rollback成功後，慢慢的把死結消化掉。
這個問題，後來還是要靠在正式環境上面執行，才能夠發現，所以，客戶就趁著離峰時間，把備份的資料減到最少，然後才看出來問題，原來是新增備份的幾個表格中，有一個Foreign Key到另外一個table，造成資料搬移後刪除時，出現了錯誤，測試環境裡面，剛好沒有相關的ForeignKey資料，以至於沒發現這個問題，更改了一下刪除順序之後，就可以正常執行了。
這種正式與測試環境之間的差異所造成的測試盲點，已經不是第一次遇到，卻沒有好好的檢討改進作法，在此特別把心得記錄下來，以力求以後的改進：
1. 測試環境與正式環境的DB務求一致：
兩邊的Table Schema需要一致之外，每次客戶給的schema還要再檢查一次，看看是否與正式環境相同，檢查項目至少有
(1). Primary Key
(2). Foreign Key
(3). Default Value
(4). Trigger
其他比較細微的如
(5). DB Encoding
(6). Case Sensitive or Insensitive等等…
最好找個有反向工程的軟體，把正式環境的實體關連圖畫出來，放在手邊隨時對照檢查。
2. 測試資料的完整性
所有的測試成功與否，與使用者提供的測試資料品質有絕對的關連，所以在事前的測試資料整理就非常重要，可是，這方面也是客戶很難提供，因為各項資料，皆牽扯到保密以及業務考量，這點一定要跟客戶好好溝通，或是提供一個轉換資料的方法，把隱密資料mark起來，原則有
(1). 姓名欄位的遮蔽
(2). 身份證字號或其他重要的卡號的遮蔽
(3). 住址的遮蔽….
3. 使用者測試的方式：
如果有可能的話，最好的方式是以平行測試的方式，讓使用者在正式與測試環境同時Key相同的資料，在一定的期間，驗證其修改的正確性，但是通常，真正Key資料的人是很懶得把相同的資料再次鍵入，所以提供自動轉換或輸入的方法也是不錯，步驟如下
(1). 平行測試
(2). 測試之後的驗證
(3). 保留舊有系統，提共緊急切換與系統支援之用
(4). 提供新舊資料轉換的功能
結論
即便有充足的時間測試，程式還是會有錯誤，更不要說沒有測試急就章的上架了。執行者不管是客戶或是程式設計師，都應該多想一點，把使用者可能會操作的過程都模擬一遍，如此，才能夠盡量減少事後的彌補，以及專案的成敗。
