Wednesday, November 17, 2010

淺談測試

這篇是寫給自己懺悔的

     「人長久處於安逸的情況,就會慢慢的不求上進,對於自己的工作麻痺,許多錯誤的習慣就視而不見。」

     最近在處理客戶的一個小小需求,這個需求也不過是把一個日常例行的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). 提供新舊資料轉換的功能

結論
     即便有充足的時間測試,程式還是會有錯誤,更不要說沒有測試急就章的上架了。執行者不管是客戶或是程式設計師,都應該多想一點,把使用者可能會操作的過程都模擬一遍,如此,才能夠盡量減少事後的彌補,以及專案的成敗。

No comments: