Ruddy Lee 分享空間

Emergent Design 演化設計

談軟體的測試模式 Testing Software Patterns

leave a comment »

何謂『模式』?

第一次出現是一個事件,
第二次發生是巧合,
第三次的發生便可能是一種模式。

模式;讓我們繼承前人的經驗累積,能夠更快速的解決所面對的問題。
(從定義上不難想像很多很多東西都可以有模式可以依循,在一般的測試運用上,有二種測試模式常常會讓人們搞混了,一種是程式員在做 Unittest時可以運用的模式技巧,這在 Gerard Meszaros的xUnit Test Patterns Refactoring Test Code 這本暢銷書裡有著絕佳的說明, 而這裡我們所謂的模式pattern, 所指的則是設計測試架構時所採用的東西,因為很少人會談到它所以才想在這裡題一下。)

測試模式的目的,是讓所有的測試人員都成為擁有豐富經驗的軟體測試師,能夠在第一眼看到軟體的狀態時,很快就能決定運用那一個方法,從哪裡開始下手測試的工作,像一個老手一般的做好開始測試的準備工作。

從哪裡開始呢?  測試清單 CheckLists
有一點像TDD測試開發法,如果沒有要寫的功能的 BreakDown listing, 那就不知道要從那裡開始了。所以一定要有CheckLists.

尤其在沒有採用任何測試工具下所進行的測試動作,最能捕捉產品測試的經驗的便是測試清單了,它記載著設計思維的過程,累積了明確的思路提供以後重用的時機或便利其他測試工程參考時能夠採用的部分。在許多情況下,我們經常在重複這些動作,例如: 欄位的長度檢核、屬性檢核、是否為 Null 或是邊界問題的極大值測試,這幾種測試其實都應該內含在撰寫開發文件時就可以明確地寫清楚測試的情境及輸入的數值大小,所以在測試清單上一定要有著良好的分類,分類是這份測試清單被重複參考的最佳基礎了。當然;每個分類所能涵蓋的問題多寡也是它被重視的指標。

糟糕! 好像可以寫很多很多東西,趕緊在這裡打住,不談廢話了,列幾個範例做結語吧! 有一篇好文章可以參考: http://msdn.microsoft.com/en-us/library/cc514239.aspx#CommonTestPatterns_topic10

範例:
屬性類型驗證模式 Data-Type Validation Pattern
1. 確定欄位的屬性特徵。在抽象的層面上,這不應該局限於簡單的數據類型,而應該包括常見的業務數據類型(例如: 電話號碼、地址、郵政編碼、日曆日期…等)。
2. 加入與這個類型相關的一般業務規則。
3. 分區塊和定義邊界值來針對每個業務規則做測試。
4. 針對每個類別Class來撰寫測試案例的設計測試值。

輸入邊界劃分模式 Input Boundary Partition Pattern
1. 一個一個陳列出來並選擇相對的輸入項目。
2. 選擇一個“有效”相等的區塊。
3. 套用一個對照表或運用隨機產出的值,運用它來做測試。

Written by ruddyllee

2010 年 12 月 12 日 於 11:19:47

張貼於未分類

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 變更 )

Twitter picture

You are commenting using your Twitter account. Log Out / 變更 )

Facebook照片

You are commenting using your Facebook account. Log Out / 變更 )

Google+ photo

You are commenting using your Google+ account. Log Out / 變更 )

連結到 %s

%d 位部落客按了讚: