選單
GSS 技術部落格
在這個園地裡我們將從技術、專案管理、客戶對談面和大家分享我們多年的經驗,希望大家不管是喜歡或是有意見,都可以回饋給我們,讓我們有機會和大家對話並一起成長!
若有任何問題請來信:gss_crm@gss.com.tw
3 分鐘閱讀時間 (631 個字)

從【一例一休】續談測試案例設計

estee-janssens-zni0zgb3bkQ-unsplash-2
前一篇文章中我們體會到了SA(System Analyst 或BA(Business Analyst)如何利用"舉例說明"來和使用者釐清需求。說起來容易,但是怎麼開始下手,又是另一回事了。為了讓讀者更進一步體會在開發階段中如何利用這些案例來設計測試案例,以下仍然用一例一休的例子做為說明:

首先回顧一下我們的需求:



(由於公司內的系統不用處理薪資計算,在本文中將只針對加班規則檢核做測試。)

【規劃情境】
公司內以半小時為最小加班單位,依加班規則展開如下圖,最完整的測試至少有26*4=104種狀況:



如果全部要測過一輪,應該是會要人命。為了在有限人力時間下,有機會測到最有可能的問題,我們依相同規則的情境歸類後如下圖,可歸納成 17 種情境需要測試:



【案例設計】
有了上述的歸納之後,接下來我們就可以有系統性的來設計我們的測試案例。一般最常用的是邊界值測試,以上述的情境,我們就可以每個情境設計在門檻值上下的加班時數進行測試,如:[平日加班-前2小時],這個情境可以挑選加班0.5小時和加班2小時即可;至於[平日加班-超過4小時不可加班]則只需測試加班4.5小時。
(實務上我們只有在這次變動比較大的情境中有採用邊界值測試,其它既有的情境採抽測)


另外一個可以討論的是最右下角[超過當月上限不可加班-例假日加班]的情境是否該測?如果例假日不可加班的案例都通過了,自然不可能會發生[超過當月上限不可加班-例假日加班]的狀況,那是不是可以併入上面的[例假日不可加班]情境中?(開放討論)

藉由上述的盤點與歸納,可以讓 SA/BA 有系統的挑選測試案例,避免遺漏該測而未測的情境,或是把時間花在重覆測試相同的情境,可將人力與時間花在刀口上。
【前置資料準備】
有了測試案例之後,接下來要開始準備前置資料,以這個例子來說,我們至少需要:
  • 人員組織(包含申請人、申請人主管)
  • 行事曆工作日/休息日/例假日/國定假日的設定
 
  • 加班時數加乘規則(沒錯,我們公司加班補休是有加乘的,感動~~~)

  • 已申請的加班資料(For 超過12小時或超過46小時)


【測試資料準備】
有了前置資料之後,接下來就可以依測試案例來設計測試資料以及預期的測試結果:



【自動化測試】
以上儘管已經濃縮到19個測試案例,但如果是以人工方式進行測試,仍然是相當耗時。因此實務上則是藉由Selenium將上述案例錄製後,掛到Jenkins上定期執行(每週兩次)。下圖是用來驗證的答案:



以上大致以一例一休制度上路後,公司內部加班模組進行調整時,從一開始的需求釐清,到開發階段的案例設計,以及測試案例的選擇過程。如果對內容有興趣想進一步了解,可以再和品質保證中心聯絡。
為什麼我的 APS.Net Form Authentication 在 timeout 時間還沒到前...
Scrum手法在waterfall軟體開發專案的應用

相關文章

 

評論

尚無評論
已經注冊了? 這裡登入
Guest
2024/04/27, 週六

Captcha 圖像