一、有贊低代碼平台-bos介紹
1.1、什么是低代碼平台
低代碼開發平台已經成為現在很多企業開發管理應用程序的重要工具，低代碼平台的出現幫助企業降低了軟件開發的成本，提高了軟件開發的效率，越來越多的公司開始開發低代碼平台，甚至基於低代碼平台開始商業化，比如微軟的Power Platform,Salesforce的Lightning，阿里的星環等，我在這里介紹一下有贊的低代碼開發平台-BOS。1.2、什么是BOS，解決什么問題
商業操作系統（Business Operating System），商家的經營需要廣告曝光，銷售員，貨品，快遞，資產，營銷策划，服務等要素，企業數字化前提是對經營要素進行數字化，現實世界承擔執行和信息采集，而虛擬世界事前模擬推演得出最佳路徑和步驟，從而提升商家經營效率。
BOS對經營要素進行數字化登記，並提供了搭建工具，用於集成數字化后的要素，按商家的意願來調度要素，來構建企業數字化的各種業務鏈路，被數字化后的要素稱之為”組件“。”組件“多來自生態，市場化運作方式商家可以集成優質的要素從而豐富貨源，提升服務水平，內容得到精准的曝光，用戶體驗鏈路更加細膩。要素需要生態共識的”數據標准“才能被按需集成，而有贊則是標准的起草者，便於買家認知，也是組件接入和執行的依據，還能建立組件之間的通訊。
商業操作系統致力於用無代碼編排替代傳統編碼方式來集成要素實現業務需求，來滿足千差萬別的企業數字化要求。另外，也降低了研發門檻，倡導“全民研發”的理念，讓運營人員自行調整邏輯和交互，最大限度釋放創造力還原一個點子，即時、高效、低成本驗證數字化方案的可行性，並且全鏈路的邏輯一覽無余。
接入的組件都依賴數據標准，彼此之間無依賴，這就讓分布式獨立開發組件變得可行，從而垂直業務，ISV，商家都能提供組件，運營按編排成為產品，多版本的迭代並相互隔離。
綜上，BOS由數據標准，組件接入標准，應用層編排模型，規則引擎，數據連接器，組件擴展標准，自動測試/運維，產品授權和鑒權，產品模板，開發者准入、培訓和認證體系，經營者商業關系管理，以及市場化運作方式構成。1.3、以交易接入為例，講述一下bos發展
小結：因為本文重點講的是bos的測試體系，對於bos的內容不過多贅述了，有興趣的小伙伴可以查看有贊coder的文章，里面有更多相關bos的內容。
二、業務代碼接入低代碼平台的測試用例設計和自動化介紹
2.1、bos測試case的設計思路
bos主要的核心主要是將業務需求結構化，比如針對交易，先是把交易業務抽象成訂單確認，下單等一個一個工作流，工作流是由一個一個業務產品組成，如這里的（訂單基礎產品，渠道數量產品，自提產品等），產品之間會有一些疊加互斥的關系，然后產品內部，又是由一個一個活動任務組成如（數據初始化，業務校驗，業務裝配等），再然后活動任務，又是由一個一個組件組成（組件由開發編碼並上傳到bos）。針對這樣的結構化的需求，我們需要把對應的case也做結構化，需要針對不同組件改動設計組件的測試case，針對活動任務合在一起的產品設計針對產品的測試case，針對整個大的工作流設計工作流的測試case。我們的測試case，需要跟着業務代碼的結構化，而做結構化，從而達到精准並且全面得測試到某個組件，某個產品，某個工作流的目的。
2.2、bos測試case的自動化
bos的產品是一個持續迭代的過程，其實對於測試同學來講這就相當於一個大規模的重構項目，所以自動化回歸是必不可少的手段，針對bos開發流程，我的自動化測試策略也做了一些適配，bos在開發之前會先做大量的需求結構化，然后把原來的需求拆分成一個一個組件，所以開始階段，我們先對組件進行case的結構化梳理，並編寫自動化case，在開發提測時，之前的自動化case可以作為開發的准入case，同時這部分case也可以賦能開發自測，然后進行qa測試，這個階段主要執行之前編寫自動化case執行，並在上預發之前，把全量針對組件的自動化case執行通過，作為上預發之前的准入執行。預發測試過程中除了必要的功能回歸，這邊還會執行全量的預發自動化case，以及流量回放（流量回放的具體策略在下一節詳細描述），待這些都通過后開始發布組件。組件依次發布完成后，開發同學會把組件配置到bos上去，形成一個個可視化的產品，工作流。具體的測試策略和組件的測試一致，只是把之前組件級的自動化case換成了產品級和工作流級的自動化case。
三、業務代碼接入低代碼平台的流量回放介紹
3.1、流量回放介紹
先簡要介紹一些有贊的流量回放平台，流量回放顧名思義就是采集線上的流量，在預發或者測試環境跑線上的流量，differ結果，找到差異的一種手段。有贊這邊的流量回放，是基於開源的sandbox實現的，原理上是通過sandbox采集線上的流量，並通過消息的方式告知到流量回放平台，流量回放平台再把這部分流量到預發上跑（主要是讀接口），或者把這部分流量到qa環境跑，不過需要mock外部依賴（讀寫都有）。有贊這里預發回放目前只支持讀接口，因為如果是寫接口，會寫入線上db，變成臟數據，污染線上環境。3.2、bos基於流量回放的測試
前面說到業務接入bos，對測試來講其實就類似於一個大規模的重構，如此大規模的重構，靠人工設計測試用例，勢必很容易會有遺漏的地方，所以做完人工的自動化回歸之后，我們引入流量回放的方式來輔助測試，來防治遺漏一些我們設計用例過程中場景比較偏比較容易遺漏的場景。針對於讀接口，我們采用線上采集線下回放的方式，因為平台天然適配，取得了不錯的效果。但是對於寫接口，因為平台不支持，但是如果采用線上采集，qa環境回放，因為是外部依賴是mock，需要根據調用外部依賴的入參，去匹配mock的值，但是我們這邊有很多借口是隨機值，經常會導致回放失敗，走不通，所以我們最后選擇了一個中間方案。對於寫接口（這邊以訂單創建接口為例），我們將訂單創建接口剝離出了只讀的部分（下單在[業務裝配]活動任務前無數據寫入），預發提供兩套讀接口，一套老流程無數據寫入返回合同，一套bos流程無數據寫入返回合同。抓取線上流量，在預發執行兩個接口，比對返回值是否符合預期，主要實現如下圖：
這個方案目前僅僅是一個過渡方案，后面對於這樣寫接口，我們的初步想法，是利用影子鏈路，在寫接口落庫操作的時候帶上影子標，進入影子表，然后比對生產和影子鏈路的數據，也可以比較接口的返回，初步設想如下圖：
四、業務代碼接入低代碼平台的壓測方案介紹
對於壓測方案，我們主要是希望，在進行bos化改造之后，系統的性能不要下降，所以我們這邊的壓測策略選擇了單機壓測，相同的qps，觀察分別走新老鏈路的性能指標。
五、業務代碼接入低代碼平台的兜底方案介紹
在上線過程中，為了防止接入bos出現bug，我們有一套比較詳細的兜底方案，我們會針對在切流過程中，出現對各種由bos平台導致的異常進行降級兜底，觸發兜底之后，會走到老的鏈路，同時配置監控告警，防止對線上業務產生影響。兜底方案如下圖：
六、總結
bos在有贊是一個比較新的東西，針對bos的測試手段目前也在摸索當中，針對現有的業務，我們沉淀了一些測試策略，並在不斷迭代改進中，比如我們設想在測試過程中，可以顯式告訴我們組件的調用過程，幫助我們進行問題排查；比如目前無論是組件的，產品的，工作流級別的case入口，都是工作流的接口，是否可以將其拆分開來，做具有針對性的測試，等等。希望在不久的將來，我們可以有一套非常完備的業務接入bos的測試解決方案。end