敏捷之旅高雄那天, 正在去會場時有位網友問了單元測試的問題, 他對於名詞解釋有些疑惑, 因此, 我花了些篇幅來解釋, 順便也分享給大家.
- 12月 10 週日 201722:39
單元測試? 黑箱單元測試? 白箱單元測試? 搞得好亂
敏捷之旅高雄那天, 正在去會場時有位網友問了單元測試的問題, 他對於名詞解釋有些疑惑, 因此, 我花了些篇幅來解釋, 順便也分享給大家.
- 9月 28 週四 201714:07
軟體測試是否能快, 完整, 和找到所有問題
在上測試相關課程, 一開始都會問大家, 期待在課堂上學到什麼. 上了幾次後, 發現有幾件事情是大多數共同期待的:
- 9月 18 週日 201618:45
Shift Left 測試? 這是什麼鬼?
今天整理一些東西, 看到一個名詞: Shift Left Testing. 平時自己為對測試懂得不少, 沒想到居然完全不曉得這是什麼, 並且從字面上也猜不出來. 只好乖乖 google, 來學學新東西.
在傳統開發方式, 測試活動的開始, 通常是在開發階段的後期. 那時候才開始進行測試, 不但錯誤不容易找, 找到之後修復所要花的代價也不低, 因為都忘了以前在寫什麼, 系統也變得複雜了. 更糟糕的是, 如果開發延遲了, 測試的時間便完全被壓縮了, 測試是需要時間去認識系統, 花時間去挖出更深入的問題, 時間太短是無法找出太多的問題. 所以傳統測試方式, 是有很多問題存在.
- 8月 19 週三 201520:20
測試的七個小矮人
James Bach, 測試界的怪才, 他曾經擔任過 apple 的測試經理, 老爸是天地一沙鷗的作者, 在每年大型的測試 conference 幾乎都可以看到他的身影. 是個超強的大怪咖.
- 5月 27 週三 201522:57
你以為你在做測試嗎?
Planning is everything. Plans are nothing! 這是艾森豪將軍的名言. 二次大戰期間, 艾森豪帶領同盟國聯軍, 跨越英倫海峽反敗為勝, 靠的就是縝密的情報蒐集和靈活應變.
- 5月 26 週二 201522:47
測試要做多久是估不準的
很多開發人員在開發軟體時, 會說他們的工作很難估得很準, 因為 spec 常常更改, 或者 spec 不明確, 所以無法確保要做多久.
- 11月 17 週一 201410:57
如何開始簡單和有效的測試工作
在最近的一門課程 - 測試個案設計與分析實戰班, 發現不少參加者是開發人員, 因為公司沒有專職的測試人員, 因此想要來學習如何測試.
- 8月 04 週一 201406:04
測試計劃該寫什麼?
在 IEEE Standard 829 中有定義測試文件的範本應該長得什麼樣子, 你可以從很多地方找到個範本
http://en.wikipedia.org/wiki/IEEE_829
可是很多人看完後會說這個太複雜了, 有沒有簡單的方式, 連做事的時間都不夠了, 哪有時間寫這麼長的文件. 我想是否要照著這個範本寫並不重要, 重要的是你需要考慮以下事情
1. 什麼東西你要測試
也就是定義測試的目標物是什麼. 有時候有些人會搞錯測試的目標物, 明明要測的是你的系統, 可是卻測到受測系統所用到的平台或是資料庫. 有時候哪些東西不是你最先要處理的重點, 可是你卻一直在找他們的問題.
2. 你要測什麼
列出你要測試的功能. 這是乎很直覺, 但是在某些狀況下, 也許有些舊功能, 或是不是這次要注意的重點, 你是可以在這次的測試先忽略他們. 但是要先和相關利害人確認清楚.
3. 你要怎麼進行測試
你需要描述你的測試策略. 像是範圍, 單元或是整合或是 end to end , 工具, 是否要自動化, 哪些東西先測...等等
4. 什麼時候要測試
也就是說明你什麼時候要做哪些事情. 何時規劃, 何時開立個案, 何時執行個案, 何時回歸測試等等.
5. 可以進入測試的條件
並不是隨便寫個屍體就可以來測試了, 開發人員要先對自己寫的東西負責任, 準備好適當的文件, 或是經過適當 review 等等. 總之要定義好一些準則, 需要通過才能開始測試.
6. 可以結束測試的條件
你需要定義什麼條件滿足了, 測試才算結束. 像是沒有嚴重的 bug, 平均無故障時間減少到某個範圍, 或是當初計劃的測試項目都已經測完, 效能已經達到某個水準... 等等.
我想如果你的計劃已經能回答這些問題, 我想是否照著標準的範本並不重要. 因為你已經把重要的事情都考慮到了.
- 5月 19 週一 201409:21
黑箱測試方法大對決
軟體測試的方法有很多種, 其中黑箱測試方法被使用最多, 主要的原因是容易上手, 進入門檻不高. 所以很多測試人員會使用這種方法. 可是很多人對於何時該使用卻不是很清楚, 因此讓我們來做個簡單的比較吧
1. ECT (Equivalence Class Testing)
a. 說明: 將受測軟體的輸入資料, 切成好幾個分割(partitions), 對於每個分割, 將會有測試個案去涵蓋它
b. 適用時機
比較小的功能, 或是單一 API. 或是畫面某個 input control
c. partition 的選擇, 是決定你測得好不好的重要關鍵
d. ECT and BVT 這兩種方法最多人使用, 可是不見得是最系統化的方法來開個案.
- 2月 24 週一 201406:41
好的黑箱測試方法應該是什麼?
很多測試人員會詢問, 是否有一種測試方法, 可以很系統化地, 來開立所有測試個案.
我也很期待有這種東西, 可惜一直沒有看到, 不管哪種黑箱測試方法, 都有它的優點和缺點.
更重要的是黑箱測試有個重大的致命點, 它是完全依賴測試人員的經驗. 如果測試人員的產品領域知識, 以及產品所處的系統知識豐富, 就能開出更好的測試個案.
例如: 等價分析法(Equivalence Class). 他要求先找出等價區域 (Partition or equivalence class), 然後對每個區域開出一個測試個案, 只要這些個案執行完, 就說測試完畢.
