在不疑處有疑 － 談開發工具的方便性及陷阱

今天在開發一個小工具時發現一個原本很難發現的小陷阱。是這樣的，我原本是只是寫一個電子郵件的群組管理，群組的命名規則是規畫成以日期命名，例如 20061227, 20061230 等等。但在測試時一時技癢，把以前當 SQA 時的測試精神拿出來用用，就順手把原本不會使用的中文字給打進去測試，結果真的找到問題。打進去的中文字，通通變成了問號。

這種問題應該是很容易發現的，但因為程式設計師熟知程式設計的邏輯，所以不見得會以違反設計精神的樣式去做測試，這裡舉的就是一個典型的例子。那麼，為什麼程式設計師在這裡「應該」不會主動發現這個錯誤呢？因為我在設計時，根本是按一般文字處理的規則去撰寫程式的，所以既然以數字去測試沒問題，以英文也沒問題，那麼以中文或任何符號去測試，也不應該有問題。

該死的是，當你使用像 VS2005 這種方便的開發工具在開發程式時，由於他在使用上變得太方便了，讓我程式寫得太過順手，一些細節就疏忽了。在上述狀況中，我把某一 SQL 字串的參數型態選為 SqlDbType.VarChar，但其實應該是 SqlDbType.NVarChar！在 VS2005 中，這些字都不必用手打進去，而是從 Intelisense 表單中選。一個不小心，就選到了另一個看起來很類似的項目了。

若使用 SqlDbType.VarChar 作為資料型態，和使用 SqlDbType.NVarChar 幾乎沒有什麼不一樣，但是偏偏前者不支援多位元組語系的文字，後者才支援。所以，如果我沒有剛好順手用中文字去測試看看，大概永遠不知道有這個問題存在！

所以，測試者還真的是不要知道程式的設計邏輯比較好。知道得愈多，盲點也愈大，也就愈測不出問題。