Welcome to Galaxy Software Services Corporation !
徵才專區
CSR專區
Vital CRM 國際認證
GSS部落格
叡揚資訊
關於叡揚
新聞與活動
產品與服務
叡揚e論壇
投資人關係
EN
中
簡
日
搜尋
關於叡揚
叡揚簡介
創辦人的話
叡揚大事紀
得獎肯定
合作夥伴
營業據點
聯絡我們
新聞與活動
新聞中心
資安電子報
影音專區
成功案例
行銷活動
產品與服務
企業e化應用軟體
S.P.E.E.D. 公文線上簽核管理系統
Radar 睿達人力資源管理系統
iota C.ai 對話服務平台
Tracko 多源智慧追蹤平台
B.E.S.T. 銀行信用風險資訊解決方案
BoDms 董事會提案暨會務管理系統
Vitals ESP 企業知識協作平台
Vitals HCA 評鑑協同管理系統
Vitals HAS 醫療數據分析系統
Vitals KPIM 指標管理系統
Openfind 網擎訊息安全解決方案
資訊安全
資訊安全系列產品
Checkmarx 源碼安全檢測
Digital.ai APP & Web 防護
Digital.ai APP & Web 相容性功能驗測
illumio 零信任微切分
Orca Security 雲端原生應用程式防護平台
Azul 安全高效 Java JDK
Mend.io Open Source 檢測
HCL 網頁應用程式弱點掃描軟體
Quokka APP 黑箱檢測
Secure Code Warrior 安全開發培訓平台
資安檢測服務
資安學程
資安白皮書
資安電子報
企業數位化智慧維運
企業數位化智慧維運
Axway API 管理平台
Axway ST 集中檔案傳輸管理
AVC 應用程式弱點整合平台
BMC Control-M 批次管理解決方案
BMC Helix Discovery & AISM 探索打造企業IT智慧管理平台
Dynatrace AI智慧維運與效能管理
DMP 數據治理平台
Noname Security 完整主動式API安全平台
Servicenow ITSM一站式IT服務管理平台
TIBCO 智能化資料平台
RPA 機器人流程自動化
Automation Anywhere 業務流程自動化RPA平台
UiPath 機器人流程自動化平台
Woodpecker XVR 次世代資安可視性解決方案
資源中心
雲端與大數據服務
Vital NetZero 零碳雲
Vital CRM 客戶關係管理
Vital BizForm 雲端智慧表單
Vital Knowledge 協同知識管理
Vital Finance 財務會計管理
Vital OD 雲端公文管理
Vital HCM 雲端人力資源管理
大數據分析解決方案
運帷服務
資訊系統維運與開發服務
QuEye CIA 軟體變更衝擊分析器
AI 解決方案
AI 解決方案介紹
AI 智慧公文解決方案
AI 財務報表辨識系統
政府共同供應契約
ESG解決方案
叡揚e論壇
叡揚e論壇
產品使用真心話
投資人關係
股東專區
重大訊息
主要股東
股東會
歷年股利
股利政策
法人說明會
聯繫窗口
公開資訊觀測站
公司治理
營運團隊
公司治理
董事會
功能性委員會
誠信經營
風險管理
智慧財產管理計畫
利害關係人與溝通
公司重要內規
CSR專區
財務資訊
每月營收資訊
財務報告
EN
中
簡
日
搜尋
徵才專區
CSR專區
Vital CRM 國際認證
GSS部落格
選單
首頁
分類
標籤
選擇分類
園丁來閒聊
工具平台
專案管理
資料庫
經驗分享
測試
設計
效能調校
程式語言
|_
.NET MVC
|_
.NET
|_
Java
|_
C#
|_
Python
|_
TypeScript
|_
VB.NET
園丁
資訊安全
開發工法
作業系統
前端
搜尋
訂閱文章
取消訂閱文章
設置
登入
帳號
密碼
記住我
登入
忘記帳號
重置密碼
GSS 技術部落格
在這個園地裡我們將從技術、專案管理、客戶對談面和大家分享我們多年的經驗,希望大家不管是喜歡或是有意見,都可以回饋給我們,讓我們有機會和大家對話並一起成長!
若有任何問題請來信:gss_crm@gss.com.tw
3 分鐘閱讀時間
(631 個字)
字體大小:
+
–
訂閱
取消訂閱
從【一例一休】續談測試案例設計
經驗分享
測試
2017/02/28, 週二
1473 點擊
0 評論
在
前一篇
文章中我們體會到了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上定期執行(每週兩次)。下圖是用來驗證的答案:
以上大致以一例一休制度上路後,公司內部加班模組進行調整時,從一開始的需求釐清,到開發階段的案例設計,以及測試案例的選擇過程。如果對內容有興趣想進一步了解,可以再和品質保證中心聯絡。
你覺得這篇文章怎麽樣?
開心
(
0
)
喜愛
(
0
)
驚奇
(
0
)
悲傷
(
0
)
生氣
(
0
)
標籤:
specification by example
testing
為什麼我的 APS.Net Form Authentication 在 timeout 時間還沒到前...
Scrum手法在waterfall軟體開發專案的應用
相關文章
從【一例一休】牽拖Specification By Example
測試
如何確認需求是否有未釐清的規則呢
經驗分享
評論
尚無評論
已經注冊了?
這裡登入
Guest
2024/04/27, 週六
Captcha 圖像
提交您的評論