單元測試 (Unit Test) 是一個很基本的工作, 如果你使用 Visual Studio 做為開發工具的話, 建立單元測試專案是一件再簡單不過的事了。不過, 除非你已經對單元測試很熟悉, 否則有些最基本的概念, 你最好能事先熟悉一下
2009/10/11
小心使用「全部取代」
最近在「西瓜的滋味」部落格中作者發表了一篇「小心使用「全部取代」」的文章, 讀來十分有趣。不過這也讓我回想到, 這實在也是一個程式設計者常犯的問題。「全部取代」確實是個很方便的功能, 但也或許是太方便了, 以致於該改的改了, 但不該改的也順便改了。
測試者如果看到類似或同類型的錯誤, 應該舉一反十, 要想到它可能就是「全部取代」所引發的問題。這種問題多半不會只錯一個地方, 會同時出現在不同的地方。而對於開發者而言, 如果可以使用 Refactor 工具來取代, 就盡量別使用「全部取代」這個功能。
在不疑處有疑 - 談開發工具的方便性及陷阱
今天在開發一個小工具時發現一個原本很難發現的小陷阱。是這樣的,我原本是只是寫一個電子郵件的群組管理,群組的命名規則是規畫成以日期命名,例如 20061227, 20061230 等等。但在測試時一時技癢,把以前當 SQA 時的測試精神拿出來用用,就順手把原本不會使用的中文字給打進去測試,結果真的找到問題。打進去的中文字,通通變成了問號。
這種問題應該是很容易發現的,但因為程式設計師熟知程式設計的邏輯,所以不見得會以違反設計精神的樣式去做測試,這裡舉的就是一個典型的例子。那麼,為什麼程式設計師在這裡「應該」不會主動發現這個錯誤呢?因為我在設計時,根本是按一般文字處理的規則去撰寫程式的,所以既然以數字去測試沒問題,以英文也沒問題,那麼以中文或任何符號去測試,也不應該有問題。
該死的是,當你使用像 VS2005 這種方便的開發工具在開發程式時,由於他在使用上變得太方便了,讓我程式寫得太過順手,一些細節就疏忽了。在上述狀況中,我把某一 SQL 字串的參數型態選為 SqlDbType.VarChar,但其實應該是 SqlDbType.NVarChar!在 VS2005 中,這些字都不必用手打進去,而是從 Intelisense 表單中選。一個不小心,就選到了另一個看起來很類似的項目了。
若使用 SqlDbType.VarChar 作為資料型態,和使用 SqlDbType.NVarChar 幾乎沒有什麼不一樣,但是偏偏前者不支援多位元組語系的文字,後者才支援。所以,如果我沒有剛好順手用中文字去測試看看,大概永遠不知道有這個問題存在!
所以,測試者還真的是不要知道程式的設計邏輯比較好。知道得愈多,盲點也愈大,也就愈測不出問題。
無障礙網路空間的測試
行政院研考會所製定的「無障礙網路空間」規範,向來是做政府生意的專案軟體業者最頭痛的問題之一。因為要做政府生意,通常都必須通過這個規範,但是這個規範很繁雜,幾乎至少有一半以上都是軟體設計者不會留意到的細節。所以要寫出符合規定的網站,還真不是件容易的事情。
所以軟體測試者可以不了解這個規範是什麼嗎?
如果你真的不清楚這個規範,甚至連聽都沒聽過,那麼你一定要先去拜訪一下研考會的網站,把那十四條規範以及九十條相關的檢測要點研究一下。有時間的話,把你正在測試的網站丟到「網頁檢測」那一頁,給它鑒定一下。
順便說明一下,你可能不知道上面網頁檢測最下方的「檢測等級」是什麼。研考會的無障礙網路空間可以分為三個等級:
- A
- AA
- AAA
許多政府軟體專案都會要求達到所謂的「3A」 等級,也就是 AAA 等級。至於 A+ 就代表優於 3A 等級的意思。
思慮不周的捉迷藏遊戲
在 ASP.NET 設計環境中,幾乎所有控制項都可以設定 Visibility,也就是顯示/隱藏的開關。此外,還有 Div, Panel, PlaceHolder 等等 Container,也可以設定 Visibility,一次就讓一群控制項隱藏或是消失。
在一般情況下,我認為大部份程式設計師都會使用這點便利性來設計程式。例如,我在網頁上放了一段文字和控制項,是專門用來顯示A商品的,並且以 Div 包起來(命名為 divA)。另外又寫了一段文字是控制項,是專門用來顯示B商品的,同樣用 Div 包起來(命名為 divB)。
接著,我在網頁最上面放了一個 DropDownList,當使用者從裡面挑選了A商品,我就把設定 divA.Visible = True,並設定 divB.Visible = False。而當使用者挑選了B商品,我就把設定 divA.Visible = False,並設定 divB.Visible = True。
[UserControl] 使用者控制項的測試注意事項
使用者控制項是 ASP.NET 中非常重要的一種控制項。基本上,它是一個類別,也可以看作元件,但是它卻提供視覺化 (Visualized) 的設計介面,可以方便你以堆積木的方法一塊一塊的把網頁架構起來。
我十分鼓勵大家多多使用使用者控制項來設計你的網頁。一方面,它很方便而且容易設計,因為它的作法和普通網頁幾乎沒有什麼不一樣。另一方面,你可以藉由它所提供的程式再利用的特色,簡化你的程式設計。再者,你可以把部份程式設計邏輯封裝 (Encaptualize) 起來,當你有需要修改程式的時候,就可以分割處理,用不著全部修改。
不過使用者控制項再方便,它也有它的盲點。我將在這篇文章裡列出測試使用者控制項的注意事項。
- 測試同一網頁中有兩個以上相同的使用者控制項 - 有太多程式設計上不小心忽略的疏忽,會造成同一網頁上出現兩個以上的相同使用者控制項時會出問題,包括 Cookie/Session/Membership 的使用衝突、JavaScript 的重複註冊等等。
- 把使用者控制項放置在 Container 裡面並仔細測試 - 我這裡所講的 Container,當然不是指像 ContainPlaceHoder、Div、Panel 等等,而是特別指具有 Template 功能的 Container 控制項,尤其是像 GridView/DetailsView/FormView 等等。除非你確定你的使用者控制項絕對不可能被放置在這種 Container 控制項裡面,不然你不應該忘記測試這一項。在 ASP.NET 的 Templated Container 控制項中,當你在 Runtime 時期開啟了對應的 Template 時(例如進入編輯狀況),Container 的行為和平常時候是不一樣的,所以問題時常出現在這個地方。
- 承上,特別測試 Container 控制項的連動功能 - 我們知道,在 ASP.NET 2.0 中,你可以很容易的讓 Container 控制項進行連動 (Cascade),尤其是用來作為 Master/Detail 展示的時候。例如,你可以讓一個 GridView 來做為 Master 項目的瀏覽容器,再設計一個 DetailsView 來作為 Details 項目的展示/編輯容器,中間只需要透過在 DataSource 裡面加上 ControlID,就可以讓資料來源隨著另一個控制項的選取項目而連動了。但是問題也正出現在這裡;在許多情況下,沒有連動不會出問題,有連動就會出問題,而且問題總會顯示在顯示 Master 的項目上,但問題本身卻是在顯示 Details 的控制項上。若你在 Container 的 Template 中加上了 User Control, 情況可能更形複雜, 需要額外的測試。