測試平台系列(94) 前置條件該怎麼支援Python呢

• 2022 年 5 月 27 日
• 筆記
• FastAPI, pity介面自動化測試平台, Pity測試平台, Python, React, 自動化測試

回顧

上一節我們狠狠操練了一番oss，但我們的任務還很長久，所以我們需要繼續打磨我們的功能。

那今天就讓我們來思考下，如何在前置條件支援python腳本，多的不說，我們也暫時不考慮其他語言，因為光考慮支援python，已經夠嗆啦。

本文旨在探討一些思路的可行性，不會實際著手編寫。

究竟缺什麼

因為我們只考慮Python腳本，所以我們必須認真考慮我們的需求。

• 能夠通過python腳本構建數據

  我舉個例子，我可以用python腳本實現一些很複雜的功能，而這些功能在當前條件下都不大可能支援。比方說，我想獲取當前月的第一天的日期，又或者我想做一些加解密/base64的運算，儘管pity可以默認幫助實現這些功能，但總會有意想不到的場景出現。為了解決這些困難，我們可以適當編寫腳本完成這些工作。

• 能夠支援參數

  這裡的參數指的是pity內置的參數${參數}

• 能夠獲取到返回值

  這個需求大家都能理解，有時候我是想觸發一個功能，比如給某些人發郵件，我不需要知道過程，我只要完成這個功能即可。而有時候呢，我需要的是執行過程，並得到確切的結果。所以這個功能是必不可少的。

思索方案

要想在python web中執行動態的python腳本，我們可以怎麼做呢？

exec

exec是一個能夠執行給定python程式碼的系統方法，可能也不是很被推薦。它接受的參數是python程式碼，舉個例子:

# 執行原生python腳本print了一條語句
exec(print("你在肝什麼"))

接著我們試試在exec中定義一個方法main，並試試能不能調用。

可以看到是能的，這個我只能說肥腸牛批！因為我也基本是沒用過，只是知道，今天也是和大家一起嘗試下。

至於為什麼不被推薦，可能是因為危險性過高，畢竟你傳入的啥人家都能給你執行掉。

不過好在exec的數據可以拿到方法執行的返回值，也可以通過字元串替換的方式獲得對應的返回值。

自建python項目

由於程式碼都是python，我們完全可以用git維護一套python工具庫。接著通過動態導入來執行對應的方法，這樣做的好處是更靈活，但也伴隨著更高的成本。

我們得去更新程式碼（包括監聽git push鉤子，或者定時拉取以及手動更新），還得提供一個編輯頁面，可以讓用戶更改對應的程式碼。

但最煩人的還是有擴展包的時候，我們的web項目甚至都需要去安裝擴展包。

說起原理倒不難，簡單的說就是內嵌了一個python文件目錄，通過import導入對應的方法並執行。

http的方式(不推薦)

新啟動一個服務，裡面提供了一個api，通過傳入method，param等資訊，實現調用方法並拿到返回值的效果。

缺點就是代價比較大，起了新服務，如果服務掛掉影響較大。優點是能夠跨語言，但是還是偏重了。

mq

有http就可以有mq的方式，通過生產者和消費者去解耦A系統依賴B系統的邏輯，用消息隊列來處理相關邏輯，可以用rabbitmq完成這樣的工作。

grpc

雖然grpc很強大，但是不推薦，雖然跨語言是個非常誘人的特性，但是對於新人不太友好，有一定的學習成本，底層雖然改用rpc調用，序列化升級為protobuf會更高效，但學習成本高，官方也沒有好的負載均衡/服務註冊發現方案，對於不同語言甚至要實現不同的一套邏輯，開發成本也不低。

總結

上面大概列舉了5種方式，我個人比較相對推薦的還是exec，內置python包和mq的形式。

mq的缺點就是需要實現不同語言的消費者以及需要引入額外的組件。由於我們暫時只支援python，所以我們優先選擇第一種exec的方式，至於第二種，我是有計劃也一併加入的。

本節內容就介紹到這裡，歡迎大家給出其他想法或者建議，也可以一起討論。

後端程式碼倉庫: //github.com/wuranxu/pity

前端程式碼倉庫: //github.com/wuranxu/pityWeb