也談測試資料

盡管我們有系統測試，有回歸測試，但是細心的同學可能都會發現，在預釋出測試階段，雖然時間相對很短，但是仍然有可能發現問題。那麼我們是不是該思考為什麼會在如此短的時間裡（比如十分鐘）就能發現我們花費了很多時間和精力卻在測試環境沒有發現的問題？ 當然環境配置引起的差異我們可以先不去深究，那麼在同樣邏輯功能點的覆寫下，很顯然我們會發現引起這一差異的根源在于我們測試最為基本的單元——資料。 我們都認可這樣一個事實——真實環境數量的豐富性和真實性是我們在測試環境下無法比拟。如果說隻是簡單的同步真實環境到測試環境，那麼已有的垃 圾資料不清除，依然會影響到測試。或者即便是一套與真實環境一模一樣的資料背景，倘若我們不能停止無效資料的注入，那麼所有的資料完整性、唯一性還是一樣 的被破壞，那麼一切還是回到了原點。 為什麼真實環境的資料不會輕易遭到破壞，我想最基本的原因有兩點，一是我們不會人為的直接幹預資料庫，二是我們在使用真實環境時本身就帶有一種真實行為的操作傾向。 在測試環境下，很多時候我們為了友善測試，會直接修改資料庫，甚至在沒有弄清表與表之間的關聯性，表與程式之間的關聯，就進行操作，并且很多時候，我們隻關注邏輯而忽略實際應用的場景，資料本身已缺乏邏輯，那麼在此之上建立的測試執行結果，本身就有所欠缺。 是以我們的功能測試設計應該基于實際的應用場景 并描述表之間的關聯，而我們的TC同樣應該基于這些内容去編寫，包括測試資料的描述，我想隻有這樣，我們才能盡早的發現問題，比如內建測試階段，而非在預釋出環境下，因為我們知道越早發現的好處。