2009/10/11

在 Visual Studio 中建立及進行單元測試

單元測試 (Unit Test) 是一個很基本的工作, 如果你使用 Visual Studio 做為開發工具的話, 建立單元測試專案是一件再簡單不過的事了。不過, 除非你已經對單元測試很熟悉, 否則有些最基本的概念, 你最好能事先熟悉一下

小心使用「全部取代」

最近在「西瓜的滋味」部落格中作者發表了一篇「小心使用「全部取代」」的文章, 讀來十分有趣。不過這也讓我回想到, 這實在也是一個程式設計者常犯的問題。「全部取代」確實是個很方便的功能, 但也或許是太方便了, 以致於該改的改了, 但不該改的也順便改了。

測試者如果看到類似或同類型的錯誤, 應該舉一反十, 要想到它可能就是「全部取代」所引發的問題。這種問題多半不會只錯一個地方, 會同時出現在不同的地方。而對於開發者而言, 如果可以使用 Refactor 工具來取代, 就盡量別使用「全部取代」這個功能。

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

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

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

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

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

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

無障礙網路空間的測試

行政院研考會所製定的「無障礙網路空間」規範,向來是做政府生意的專案軟體業者最頭痛的問題之一。因為要做政府生意,通常都必須通過這個規範,但是這個規範很繁雜,幾乎至少有一半以上都是軟體設計者不會留意到的細節。所以要寫出符合規定的網站,還真不是件容易的事情。

所以軟體測試者可以不了解這個規範是什麼嗎?

如果你真的不清楚這個規範,甚至連聽都沒聽過,那麼你一定要先去拜訪一下研考會的網站,把那十四條規範以及九十條相關的檢測要點研究一下。有時間的話,把你正在測試的網站丟到「網頁檢測」那一頁,給它鑒定一下。

順便說明一下,你可能不知道上面網頁檢測最下方的「檢測等級」是什麼。研考會的無障礙網路空間可以分為三個等級:

  1. A
  2. AA
  3. AAA

許多政府軟體專案都會要求達到所謂的「3A」 等級,也就是 AAA 等級。至於 A+ 就代表優於 3A 等級的意思。

Technorati 的標籤:

思慮不周的捉迷藏遊戲

在 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。

複製而來的程式錯誤

不是每個程式設計師都擁有超強的記憶力; 或許你在電視或電影中看到的程式設計師, 好像都運指如飛似的快速寫著程式,其實那和現實的差異也未免太遠了。

除非某段程式已經寫得很熟了,否則我們多半會拿寫好的程式片段來修改。在 VS2005 之後,甚至提供了蠻好用的 Code Snippet 功能,提供程式設計師以簡單方便的方法把舊程式片段拿來塞進新程式裡面。

[UserControl] 使用者控制項的測試注意事項

使用者控制項是 ASP.NET 中非常重要的一種控制項。基本上,它是一個類別,也可以看作元件,但是它卻提供視覺化 (Visualized) 的設計介面,可以方便你以堆積木的方法一塊一塊的把網頁架構起來。

我十分鼓勵大家多多使用使用者控制項來設計你的網頁。一方面,它很方便而且容易設計,因為它的作法和普通網頁幾乎沒有什麼不一樣。另一方面,你可以藉由它所提供的程式再利用的特色,簡化你的程式設計。再者,你可以把部份程式設計邏輯封裝 (Encaptualize) 起來,當你有需要修改程式的時候,就可以分割處理,用不著全部修改。

不過使用者控制項再方便,它也有它的盲點。我將在這篇文章裡列出測試使用者控制項的注意事項。

  1. 測試同一網頁中有兩個以上相同的使用者控制項 - 有太多程式設計上不小心忽略的疏忽,會造成同一網頁上出現兩個以上的相同使用者控制項時會出問題,包括 Cookie/Session/Membership 的使用衝突、JavaScript 的重複註冊等等。
  2. 把使用者控制項放置在 Container 裡面並仔細測試 - 我這裡所講的 Container,當然不是指像 ContainPlaceHoder、Div、Panel 等等,而是特別指具有 Template 功能的 Container 控制項,尤其是像 GridView/DetailsView/FormView 等等。除非你確定你的使用者控制項絕對不可能被放置在這種 Container 控制項裡面,不然你不應該忘記測試這一項。在 ASP.NET 的 Templated Container 控制項中,當你在 Runtime 時期開啟了對應的 Template 時(例如進入編輯狀況),Container 的行為和平常時候是不一樣的,所以問題時常出現在這個地方。
  3. 承上,特別測試 Container 控制項的連動功能 - 我們知道,在 ASP.NET 2.0 中,你可以很容易的讓 Container 控制項進行連動 (Cascade),尤其是用來作為 Master/Detail 展示的時候。例如,你可以讓一個 GridView 來做為 Master 項目的瀏覽容器,再設計一個 DetailsView 來作為 Details 項目的展示/編輯容器,中間只需要透過在 DataSource 裡面加上 ControlID,就可以讓資料來源隨著另一個控制項的選取項目而連動了。但是問題也正出現在這裡;在許多情況下,沒有連動不會出問題,有連動就會出問題,而且問題總會顯示在顯示 Master 的項目上,但問題本身卻是在顯示 Details 的控制項上。若你在 Container 的 Template 中加上了 User Control, 情況可能更形複雜, 需要額外的測試。
Technorati 的標籤:,,