基於MBT的自動化測試工具——GraphWalker介紹和實際使用

GraphWalker是一個開源的基於模型的自動化測試工具，它能夠用來經過圖形測試模型來自動生成測試用例。 
本文主要描述了使用yed畫出FSM, EFSM模型圖（常見的流程圖），而後使用GraphWalker命令生成手工自動化用例，最終經過python將手工用例讀取後自動執行並生成執行報告。

一： GraphWalker概述

         GraphWalker就是一個基於測試模型的用例生成工具。它主要應用於FSM, EFSM模型。能夠用來它能夠直接讀取FSM, EFSM圖形模型、json模型、生成測試用例。那什麼是MBT呢？ MBT中文名稱爲基於模型的測試, 基於模型的測試屬於軟件測試領域的一種測試方法。MBT步驟以下：首先由被測系統（SUT， system under test ）的一些（一般是功能）方面描述，構建出被測系統的模型。再根據模型或模型中的一部分部分生成測試用例。進而進行軟件測試。常見的MBT中模型一般有下列幾種：

• 前置後置條件模型:　Pre and post condition models (State based, OCL)
•  基於轉換的模型:　Transition based models (FSM, EFSM)
• 隨機模型：Stochastic models (Markov chains)
• .數據流模型:　Data-flowmodels(Lustre)      

二：工具下載：

     一、畫圖工具YED

        工具下載官網地址：https://www.yworks.com/products/yed，用該工具畫出來的圖大體以下：

      二、 GraphWalker的jar包下載：

        https://graphwalker.github.io/   

 

三：學習筆記整理  （關鍵知識點）

      一、頂點：如上圖所示，全部的頂點好比Start,V_ClientNotRuning.一個頂點稱爲節點，一般表示爲一個框表示咱們想要檢查的預期狀態。在任何實現代碼/測試中，能夠經過斷言或者數據校驗改結果。常見有如下幾種頂點：

• Start頂點：start頂點不是必需的。若是使用，則必須有1個（且只有1個）頂點名稱爲：start.從start頂點出發只能有1個邊。start頂點不會包括在任何生成的測試路徑中，它只表示一個開始位。

• BLOCKED頂點：  包含此關鍵字的頂點或邊將在生成路徑時排除。若是它是一個邊，它將簡單地從圖中刪除。若是它是一個頂點，頂點將被刪除與其內外邊緣。

• SHARED頂點： 意味着GraphWalker能夠跳出當前模型，到任何其餘模型到具備相同SHARED名稱的頂點。 語法是： SHARED：SOME_NAME

• INIT頂點： 只有一個頂點能夠有這個關鍵字。在模型中使用數據時，須要初始化數據。這就是這個關鍵字。容許在更多的頂點中使用INIT而不僅是一個。 語法是： INIT：loggedIn = false; rememberMe = true;

      二、邊：如上圖的e_Init。表示從一個頂點到另外一個頂點的方法。這是爲了達到下一個狀態須要作的任何動做。它能夠選擇一些菜單選項，單擊按鈕等測試動做。GraphWalker只接受單向有向邊（箭頭）。邊

  的函數下有時候會有不一樣的字符串，好比[rememberMe&vaildLogin]和/rememberMe=false； vaildLogin=true；  表示不一樣的規則，基於表有以下規則：

• 守衛(Guards)：他們的角色與if語句相同，而且使邊有資格或者沒有資格被訪問。

  守衛guard是一個用方括號括起來的JavaScript條件表達式只有一個。[rememberMe&vaildLogin]

• 操做(Action)：它放在正斜槓以後。Action能夠有多個，每一個語句必須以分號結尾。

  /rememberMe=false; vaildLogin=true ；action是動做代碼，它的執行結果將做爲數據傳遞給守衛。

     三、路徑生成器:生成器是決定如何遍歷模型的算法。不一樣的生成器將生成不一樣的測試序列，而且它們將以不一樣的方式遍歷模型。多個發生器能夠串聯。常見有如下幾種：

• random( some stop condition(s) )：以徹底隨機的方式瀏覽模型。也稱爲「醉漢走路」或「隨機步行」。該算法經過隨機從頂點選擇出邊，而且在下一個頂點時重複此過程。
• quick_random( some stop condition(s) )：嘗試運行經過模型的最短路徑，但以快速的方式。
• a_star( a stop condition that names a vertex or an edge )：將生成到特定頂點或邊的最短路徑。

      四、結束條件：常見有如下幾種：

• edge_coverage( an integer representing percentage of desired edge coverage )：邊覆蓋率達到某個值時，模型遍歷結束。中止標準是一個百分比數字。當在執行期間達到所穿過的邊的百分比時，中止測試。若是一個邊被遍歷超過一次，當計算百分比覆蓋率時，它仍然計爲1
• vertex_coverage( an integer representing percentage of desired vertex coverage )：頂點覆蓋率達到某個值時，模型遍歷結束。中止標準是一個百分比數字。當在執行期間達到所遍歷的頂點的百分比時，中止測試。若是頂點遍歷超過一次，當計算百分比覆蓋率時，它仍然計爲1。
• requirement_coverage( an integer representing percentage of desired requirement coverage )：需求覆蓋率達到某個值時，模型遍歷結束。中止標準是一個百分比數字。當在執行期間達到所需求的百分比時，測試中止。若是需求遍歷超過一次，在計算百分比覆蓋率時仍會計爲1。
• dependency_edge_coverage( an integer representing dependency treshold )：高於依賴閾值的邊都被覆蓋時，模型遍歷結束。每一個邊能夠設置一個依賴值dependency（0-100之間的百分比數字）。中止標準是一個百分比數字。當在執行期間，全部高於或等於依賴值邊被遍歷徹底時，中止測試。若是一個邊被遍歷超過一次，當計算百分比覆蓋率時，它仍然計爲1。
• reached_vertex( the name of the vertex to reach )：中止標準是指定的頂點。當在執行期間到達頂點時，測試中止。
• reached_edge( the name of the edge to reach )：中止標準是指定的邊。當在執行期間到達這條邊時，測試中止。

     五、GraphWalker提供3種工做方式:

• 做爲第三方庫，可被java測試程序直接調用。若是是使用java語言來編寫自動化測試框架，能夠考慮使用這種工做方式。
• 做爲可執行程序，以offline模式，加載model，直接運行。接口測試經常使用此方法一次獲取完整的手工測試用例。
• 做爲可執行程序，以online模式，做爲service，提供服務。改方法方便讀取自動化測試用例，可是每獲取一次須要調用一次service，有點麻煩。  

      六、學習參考文檔：

• 官網：http://graphwalker.github.io/
• 中文翻譯：https://cloud.tencent.com/developer/article/1004579 

 四：初體驗

        以2.1的圖爲例，是官網的的demo圖。下載地址：http://graphwalker.github.io/Model_design/，找到圖片後雙擊便可下載：Login.graphml

       一、可執行程序，以offline模式生成自動化用例，路徑生成器使用經常使用的quick_random，結束條件使用vertex_coverage100%覆蓋，在jar包目錄下執行命令java -jar graphwalker-cli-3.4.2.jar offline -m Login.graphml "quick_random(vertex_coverage(100))" ，以下會生成對應的自動化用例。

     也能夠把這些用例保存在txt文件中：java -jar graphwalker-cli-3.4.2.jar offline -m Login.graphml "quick_random(vertex_coverage(100))" > login_test_case.txt

    二、可執行程序，以online模式生成自動化用例，使用相同的結束條件和路徑生成器，

      第一步執行命令：java -jar graphwalker-cli-3.4.2.jar -d all online -s RESTFUL -m Login.graphml "quick_random(vertex_coverage(100))" ，結果以下：

  第二步：簡單的在web瀏覽器訪問:http://localhost:8887/graphwalker/getNext

 

    再訪問一次：

 五：實際使用心得

     目前測試工做中，經常使用的就是狀態機測試和模塊間的數據流測試。這個工具就很是適合這兩類圖的測試。在生成手工用例後，怎麼轉變成自動化測試用例是考慮的主要問題。下面以實際工做中的一個狀態機爲例

     第一步 ： 把工做中的狀態機圖，使用yed轉換成graph圖。

     狀態機以下：

  yed 畫圖以後：

   

  第二步：執行graphwalker命令生成測試用例，報錯 java -jar graphwalker-cli-3.4.2.jar offline -m rtp_status.graphml "quick_random(edge_coverage(100))" > bpn_status_test_case.txt。

  執行報錯：報錯緣由：由於狀態機內存在終點，致使算法執行不下去報錯失敗。那這就不適應有終點的狀態機了？

 忽然想起一句名言： 我是環繞着一個圓圈而行的。越接近終點也就越接近起點——-（狄斯）。人醜多讀書仍是有點用處的，靈機一動，那就乾脆把全部終點再指定起點，起點又算是一筆新的數據，講圖改造後以下：

    雖然變醜了，可是再執行不會報錯。目的達到了(每次執行的產生的用例是不徹底一致的)。用例以下圖：

   

 

   第三步：思考怎麼轉變成自動化用例。

   思考問題：

• 生成的用例集，怎麼區分每一條用例。

         從終點到頂點V_MakeData的邊都沒有標籤，那python讀取文件時，能夠根據兩個{}以前肯定是一條用例。

• python讀取每個頂點和每個邊，意味着什麼？ 

         邊意味着執行某個程序，頂點意味着檢查表的數據狀態。那在畫圖時，肯定好邊和頂點的描述，作好string和代碼對象的映射，讀取到邊，就啓動程序，讀取到頂點，就執行某個表的校驗函數便可。

• 怎麼設計總體架構？綜上問題描述，大體思路整理以下：

第四步：代碼實現：

一、主要業務流程：

       二、生成python自動化用例使用的方法，考慮到其實執行的步驟是明確的，惟一會變化的就是執行命令每次產生的用例不一致。那每次替換用例case就能夠了。作成了文件替換動態生成自動化用例的模式。

       三、自動化用例剩下以下:

四、說明：

      在編寫自動化生成用例前，已存在構建好的python自動化pyuint測試框架，我這邊結合起來使用就很方便。這個技術結合pyunit框架作效果更好。

六：總結

      這個工具的學習來源於其餘部門測試同事的分享，他們把這個工具應用於web平臺的相似登錄系統的測試，以爲確實好用。雖然這個工具和理念很早就已經有了，貌似2016年左右就已經很流行了，但不影響去深刻的學習和研究。學習和研究工具的目的，最終都是把它應用到實際項目之中。相似這種狀態機測試，若是這時在一個地方增長了一個狀態。那我只須要改下圖，再補充好對應頂點和邊的部分代碼，就能夠獲取全流程的狀態機測試用例。

      這個工具仍是很強大的，特別是在數據流的各類處理上，有時間仍是建議去看下官網，畢竟介紹更詳細。