Slickflow.NET 開源工做流引擎高級開發(二) -- 流程快速測試增值服務工具介紹

前言：流程是由若干個任務節點組成，流轉過程就是從一個節點轉移到下一個節點，一般須要不斷切換用戶身份來完成流程的測試，這樣使得測試效率比較低下，本文從實戰出發，介紹常見的兩種快速測試方法，用於提高流程測試和實施的效率。

1. 流程快速測試介紹

        流程引擎的核心功能是保證流程正常流轉，流程是由若干個節點組成，真實的業務系統是每一個用戶完成各自的任務後，分發給下一步任務節點，再由下一步的任務接收人員辦理任務，以此循環前進，直至流程流轉結束。

        若是按照這樣的測試策略，每一步都須要變換用戶身份來完成功能測試，這樣形成的效率確實是比較低下，因此引擎開發人員須要找出可以快速測試的方法，不斷提高流程測試的效率，自動化的測試策略的提出就是一個可行的方案。

2. 流程快速測試的解決方案

        在自動化測試方法提出以前，可以想到的就是讓流程能夠在每個任務節點上自動運行流轉，這就須要裝載一些測試數據，保證流轉運行的接口可以讀取到這些數據，而後驅動流程向下流轉。本文首先提出了腳本自動化測試和用戶身份模擬的兩種辦法來解決。

2.1 流程腳本自動化測試

        每次在流程引擎新版本發佈時候，須要確保流程的基本流轉功能可以正常運行，而後因爲工做流模式(Workflow Patten)已經包括的模型類型大概有幾十種以上，如何保證新版本發佈後，不影響每個工做流模型都可以正常運行呢？假如每個模式都逐一去作測試，又是比較費時費力的工做。

        因此可行的辦法就是經過腳本化測試，一次所有集中測試，覆蓋全部的工做流模式和功能接口方法，這樣就能夠確保新版本的順利發佈。在Slickflow引擎測試中，因爲WebApi接口的大量使用，測試人員認爲能夠創建基於WebApi接口的自動化測試，這一思路也使得能夠針對Slickflow.Engine的不一樣版本測試，尤爲是包含了.Net, .Net Core和.Net SAAS三個不一樣版本的自動化測試。以下圖所示，經過WebApi的配置，就能夠進行一次工做流模式的全覆蓋測試。

        WebApi接口須要的數據類型就是Json格式的數據，因此腳本文件就是Json數據。下面的代碼就是一個簡單的串行流程的Json數據。

//本JSON文件提供runner對象，可以測試串行流程的開始，運行到結束。
{
    "CompanyID":  "2",
    "ProcessID": "3",
    "ProcessName": "報價流程",
    "ProcessGUID": "072af8c3-482a-4b1c-890b-685ce2fcc75d",
    "AppInstanceID": "SEQ-P-1099",
    //啓動流程
    //start process
    "Start": {
        "UserID": "10",
        "UserName": "Long",
        "CompanyID": "2",
        "AppName": "SamplePrice",
        "AppInstanceID": "SEQ-P-1099",
        "ProcessGUID": "072af8c3-482a-4b1c-890b-685ce2fcc75d"
    },
    //業務員提交申請
    //run process
    "Apply": {
        "UserID": "10",
        "UserName": "Long",
        "CompanyID": "2",
        "AppName": "SamplePrice",
        "AppInstanceID": "SEQ-P-1099",
        "ProcessGUID": "072af8c3-482a-4b1c-890b-685ce2fcc75d",
        "NextActivityPerformers": {
            "eb833577-abb5-4239-875a-5f2e2fcb6d57": [
                {
                    "UserID": 10,
                    "UserName": "Long"
                }
            ]
        }
    },
    //板房簽字
    //run process
    "Sign": {
        "UserID": "10",
        "UserName": "Long",
        "CompanyID": "2",
        "AppName": "SamplePrice",
        "AppInstanceID": "SEQ-P-1099",
        "ProcessGUID": "072af8c3-482a-4b1c-890b-685ce2fcc75d",
        "NextActivityPerformers": {
            "cab57060-f433-422a-a66f-4a5ecfafd54e": [
                {
                    "UserID": 10,
                    "UserName": "Long"
                }
            ]
        }
    },
    //業務員簽字確認，流程結束
    //run process
    "Confirm": {
        "UserID": "10",
        "UserName": "Long",
        "CompanyID": "2",
        "AppName": "SamplePrice",
        "AppInstanceID": "SEQ-P-1099",
        "ProcessGUID": "072af8c3-482a-4b1c-890b-685ce2fcc75d",
        "NextActivityPerformers": {
            "b53eb9ab-3af6-41ad-d722-bed946d19792": [
                {
                    "UserID": 10,
                    "UserName": "Long"
                }
            ]
        }
    }
}

　　

2.2 流程用戶模擬測試

        用戶交互測試也是一種必不可少的測試過程，並且在交互過程當中，能夠跟蹤和調試程序，真實系統的流轉是須要用戶身份的不斷切換，可是不妨經過身份模擬來減小切換環節，經過對流程引擎接口的內部改造，證明是能夠實現這一思路的。
        以下圖所示，一個集成測試的用戶界面，左側是流程定義記錄，右側上半部分是待辦任務列表，下半部分是辦結任務列表。功能接口主要是流程的啓動、流轉、退回和返送。功能測試人員經過選擇流程定義記錄，隨時就能進行流程實例的啓動、流轉、退回和返送操做，不用重複的身份切換。

3. 流程圖形的代碼建立

        客戶有時候會提交本身的流程XML來進行測試，然而有些流程定義是比較複雜的業務流程，一般可能有幾十個甚至上百個節點記錄。引擎開發人員首先須要作到對流程圖形的簡化，可是經過流程設計器來建立流程圖，有時候是比較慢，而代碼建立流程圖就反而容易和輕鬆一些。雖然代碼方式不能徹底取代流程設計器，可是對於程序開發人員，確實也須要這種快速構建流程圖形的方法。

        以下圖所示，經過代碼建立流程圖的片斷。這裏是建立了一個帶分支並行的流程圖。

        代碼執行完成後，將會生成一條流程定義記錄，經過設計器打開這條流程記錄，流程的圖形就會被展現出來，以下圖所示：

        試想一下，若是這個圖形經過手工建立，拖拽節點，添加連線的方式，也是須要耗費一些時間的，而代碼建立，就是一步生成，節省的時間的確能夠是幾十倍的時間。

4. 總結

         本文總結了在測試過程當中，如何快速測試的方法，這些輔助工具的開發和發佈，是爲了減小開發人員重複的工做量，提高流程開發的效率。

5. 備註

        快速測試輔助模塊做爲增值服務（需額外購買獲取）供企業客戶選擇，這些輔助工具並非必需的核心功能模塊，推薦給有需求的客戶使用，是爲了適應和改善企業客戶的開發體驗。也但願企業客戶可以創建快速測試驅動的流程項目的開發測試和實施過程，從而總體提高軟件開發效率和生產力。