今天踩到兩個坑造成很嚴重的問題。
第一個坑是因為主管從Java資源監控發現有Connection未關閉的問題，然而此Connection是使用老舊的ORM管理且該套件是以source code的方式存在專案中。該套件在交易結束後是以connection = null來結束，所以我和資深同事討論一下看起來沒問題去修改成呼叫Connection.close()竟造成其他功能的交易因為Connection被關閉了造成錯誤。換句話說就是整個系統似乎都用同一個Connection？WTF真是可怕。
第二個坑是搬移舊財會程式到新專案已經上線，但今天營運部門發現某情境下發現有錯並影響到業務。問題出在邏輯測試沒有完整就上線了，導致必須手動修改錯誤的資料，還好有資深同事cover。
第一個問題改善做法是舊第三方套件有問題絕對不去改。
第二個問題改善做法是弄到可測的業務邏輯資料去測，如果測試有困難或就回報留給上面去決策。
後來一直想第二個問題要怎麼解決，因為｢弄到可測的業務邏輯資料」本身就是個問題。可測的業務邏輯資料是從另外的功能頁面功能或排程產生，不是在單一資料表插入幾筆假資料就好，而是該程式會對多個資料表產生影響，所以要先搞懂資料流的順序才能產生做出可測的假資料。然而我的任務是搬移舊程式到新的專案，雖然看舊程式邏輯可以知道該程式在做什麼，但僅限於該程式影響的資料範圍，而這支程式的來源資料卻是從另一個功能或排程的結果，我無法完整得知那些老舊程式執行後的資料如何才是正確。
雖然我有寫搬移後程式的單元測試，但單元測試並無法測出業務邏輯的正確性（資料面的正確性），縱使每個單元測試都pass但業務上資料的結果是錯的(Do the right thing, but do the thing wrong)。所以要避免上面第二個問題先要知道程式執行應有的行為是什麼？對哪些資表產生影響，資料會如何變化？有沒有既有生成測試資料的方式？並依照上面的各種業務狀況撰寫測試程式（整合測試）用以測試搬移後的新程式是否滿足測試，不過話說回來這不是QA部門的任務嗎？
總之搬移舊程式或重構一定要寫測試驗證過，這樣才不會新程式上線跑完程式才發現資料都是錯的，這真的很糟。
把上述整理一下
- 詢問誰最懂舊程式的業務邏輯
- 詢問舊程式對資料的影響範圍
- 詢問各種情境對資料的影響
- 詢問既有產生測試資料的方法
- 產生測試資料
- 撰寫單元測試
- 手動整合測試
幾份工作下來發現自己非常討厭測試，尤其是在資料庫手動塞假資料的工作（尤其有外鍵限制的資料表），反而蠻喜歡寫單元測試。深覺對測試的手段及方法認識不多，所以日後學習重點應轉向軟體測試及品質相關的知識。
沒有留言:
張貼留言