基於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)      

二：工具下載：

     1、畫圖工具YED

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

      2、 GraphWalker的jar包下載：

        https://graphwalker.github.io/   

 

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

      1、頂點：如上圖所示，所有的頂點比如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;

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

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

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

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

• 操作(Action)：它放在正斜杠之后。Action可以有多個，每個語句必須以分號結尾。

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

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

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

      4、結束條件：常見有以下幾種：

• 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 )：停止標准是指定的邊。當在執行期間到達這條邊時，測試停止。

     5、GraphWalker提供3種工作方式:

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

      6、學習參考文檔：

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

 四：初體驗

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

       1、可執行程序，以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

    2、可執行程序，以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和代碼對象的映射，讀取到邊，就啟動程序，讀取到頂點，就執行某個表的校驗函數即可。

• 怎么設計整體架構？綜上問題描述，大致思路整理如下：

第四步：代碼實現：

1、主要業務流程：

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

       3、自動化用例剩下如下:

4、說明：

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

六：總結

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

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