網頁

2021/2/25

工作踩坑紀錄 20210225

今天踩到兩個坑造成很嚴重的問題。

第一個坑是因為主管從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部門的任務嗎?

總之搬移舊程式或重構一定要寫測試驗證過,這樣才不會新程式上線跑完程式才發現資料都是錯的,這真的很糟。

把上述整理一下

  1. 詢問誰最懂舊程式的業務邏輯
  2. 詢問舊程式對資料的影響範圍
  3. 詢問各種情境對資料的影響
  4. 詢問既有產生測試資料的方法
  5. 產生測試資料
  6. 撰寫單元測試
  7. 手動整合測試

幾份工作下來發現自己非常討厭測試,尤其是在資料庫手動塞假資料的工作(尤其有外鍵限制的資料表),反而蠻喜歡寫單元測試。深覺對測試的手段及方法認識不多,所以日後學習重點應轉向軟體測試及品質相關的知識。


沒有留言:

張貼留言