在看 model-based testing 時，我們會用各種測試路徑來設計測試案例，然後期望能夠把所有的路徑都考慮進去，這麼一來就會達成涵蓋率百分之百的成就。 繼續閱讀 “程式碼涵蓋率 100% 這樣夠了嗎？"
標籤: mbt
MBT 相關概念及文章
在做建模的時候，我們有機會在塑模的時候發現到有缺陷的地方，發現到之後，我們就可以將這個錯誤糾正過來，並且撰寫成 test case，以防之後的版本再度發生一樣的問題。塑模出來的模型也可以讓之後的 tester 可以比較快速的了解 spec。
GUI Testing
GUI Testing 因為常常需要做重複的動作，所以適合拿來自動化。裡頭提到 Model Based Testing，就是類似我們畫出流程圖來的意思，藉由模型來設計測試案例，讓每一個狀態都有走到，並且可以知道預期的結果來檢驗程式是否正確。
基於模型的測試 (Mode base testing)
參考網址：关于基于模型的测试的那些事
文中提到如何來建模型，要先將大的系統拆解成小的部分，就像軟體測試之道裡面提到的，『太小，才是一個好的模型適當的大小』，從小模型開始瞭解系統的功能，在慢慢的組成整個系統的架構。文中也舉例如何進行數據模型與狀態機模型，在狀態機模型中，我們可以看出其實可以測試的路徑有很多，所以我們必須先想說我們的覆蓋目標是什麼？然後透過狀態機模型來建立我們的測試。所以我們之前畫的FSM 也要繼續維護，也許有一天我們可以利用它來建立我們測試。
MBT 結合 Event-B 模型的自動化測試
此文介紹 MBT 結合 Event-B 模型的自動化測試
其中帶到 MBT 限制，他說對於正確的塑模的能力和正確的設計驗證機制，以及使用的工具會影響 MBT 的成效。
如果我們想要應用 MBT 在測試上，還需要培養更豐富的測試領域的能力，才能做出邏輯正確、表達清楚的模型。
MBT 的模型簡介
本文介紹 MBT 的模型有以下：
1. Finite State Machines（FSM）
2. State charts：FSM 結合 real-time 的模型
3. Unified Modeling Language（UML）
4. Markov Chains：一種具有狀態的隨機模型
不管是要應用何種模型，都應清楚定義狀態、轉換條件和驗證規則，才能得到最大的效益。
利用 MBT 自動生成 Test Cases 和驗證結果
此篇文章說明 MBT 可用於自動生成測試用例，並且也是個預言（Oracle），用來檢查測試結果是否通過。
在應用測試時有分兩種動作：
(1) Controllable Action：可依照需求來執行的動作。例：方法調用
(2) Observable Action：只能觀測的動作。例：事件通知
利用動作的可控性和確定性又可劃分系統：
(1) Closed System：完全可控且確定的
(2) Reactive System：有可控的和可觀測的動作
最後介紹可建立 Sandbox 利用測試套件讓 observable action 變得 controllable。例：生成需要的消息或事件
運用 MBT 的優勢
此文說明運用 MBT 的優勢，
除了在實際測試前可以讓我們更瞭解 SUT(被測系統) 的結構/ 邏輯，找出問題所在，也可以更有效率地理清測試 path 分支，標記出優先級；並對 code 的變動更敏感，快速分析出哪些關聯的地方需要進行 regression testing。
目前我們對於公司產品的測試都是針對行為做測試，尚未針對產品 code 作瞭解、分析。
雖然 MBT 多數提及是針對程式碼作分析、測試，但其原理應用到行為測試上也很受用，更能清楚定義出現在測試案例的行為與狀態。
基於有限狀態機和利用 Junit Model 的測試
此作者介紹 MBT（基於有限狀態機）的理論，以及 MBT Junit Model 的實現 – pymodel。
之後可以來研究一下 MBT Junit Model，應用到我們的 MBT 測試中。
Model-Based Testing 的例子
此文作者說明被 Harry Robinson 分享的 MBT 工作經驗啓發，自己也實作一個小型的 web 測試，並分享出來。
其中他說明 MBT 可以自動化生成測試案例（含產生路徑＆驗證是否成功的規則）。
雖然 MBT 很方便，但還是會有一些錯誤，需要測試人員去驗證。
如何設計驗證的規則、檢視驗證的規則是否需要調整，是我們需要思考的。
科科和測試 
你必須登入才能發表留言。