01

前言

在實際工作中，如果要用appium實現多設備的兼容性測試，大家想到的也許是“多線程”。但由于python中GIL的影響，多線程并不能做到"多機并行"，這時候可以考慮使用多進程的方式。

02

為什么基于Pytest

我們知道，pytest中的conftest.py可以定義不同的fixture，測試用例方法可以調用這些fixture，來實現數據共享。以前的框架的思路是：Common目錄下的base_driver.py定義生成driver的方法-->conftest.py中調用前者生成driver-->TestCases下的測試用例調用fixture，來實現driver共享?。但是現在不同了，我們有多個設備，這些設備的信息如果只是單純的寫在yml中，我們并行去取的時候似乎也不方便，那可以寫在哪里？conftest.py似乎也不是寫設備信息的好地方，最后只剩下了main.py，而且將main.py作為多進程的入口再合適不過了。但問題又來了，如果我們想啟動多個appium服務，需要考慮以下幾點：1、appium通過什么方式啟動？2、設備信息如何傳遞給base_driver方法來生成driver第一點很明確，客戶端啟動appium server的方式似乎有點不合時宜了，如果你要同時測5個手機，難道要一個個啟動客戶端嗎？最好的方式是啟動命令行，因為命令行啟動更方便更快！在說第二點前，先整理一下思路：main.py定義多個設備信息-->base_driver方法調用，生成多個driver-->TestCases下的測試用例調用fixture。但是設備信息怎么傳遞給base_driver方法呢？這時候pytest中的初始化hook函數就派上用場了。

03

初始化hook函數

先看看pytest官網的解釋：pytest_addoption(parser)方法：可以在插件和conftest.py中使用。該方法可以注冊命令行參數，以及添加init屬性。它在測試開始運行的時候被調用一次。參數：parser(_pytest.config.Parser)，使用parser.addoption(...)增加命令行參數，使用parser.addini(...)增加ini屬性值。命令行參數可以通過下面的方式被接收：◆ config.getoption(name)：接收命令行參數的值◆ config.getini(name)：接收init屬性內容注意：只有插件或conftest.py在工程根目錄時，這個函數才會被調用其實有點類似OptionParser類，拿這個舉個例子：OptionParser類用來解析命令行參數，其中add_option方法可以添加我們要處理的命令行參數。如下的第一個add_option方法中的"-c"表示添加-c參數。"--config"表示完整的參數名。action的意思是，得到該參數后怎么處理它，一般使用store存儲起來。store_true是指只有在使用該參數的時候存儲。存儲屬性的名字就是缺省值dest里寫的config，help的內容是使用-h時可以打印看到的，default是默認值。相反的，optionparser是解析函數，它將返回一個字典和一個列表。字典的鍵是缺省值，值是命令行傳遞的參數值新建文件parser_demo.py命令行運行后，發現不跟參數"-d"時，屬性"demon"的值為默認值False。跟"-d"后，變成了True

04

具體實現

定義main.py

既然可以使用pytest命令行參數了，那只需要在pytest.main中加上參數--cmdopt即可。main.py類似這樣：為什么設備信息我只寫了四個？platform_version、server_port、device_port、system_port。其他的類似于appPackage、appActivity、platformName等去哪了？當然你也可以寫在這兒，其他的應該都是多個設備相同的，我寫在yml的配置信息中了。◆ 值得注意的是，這里的server_port多個設備不能重復，這是appium server啟動的端口號，如果多個設備server_port都重復，那只能啟動一個服務了，所以要不同。◆ system_port又是什么？這個是為了防止"互爭互搶"現象的發生。多進程多設備并行時，如果多個設備同時使用同一個appium remote port(如8200)。對多個設備而言，它們并不知道相互使用同一port，因此就會出現多個設備發出的Request和接收的Action銜接不上而造成的測試混亂。可能會出現"Original error：Could not proxy command to remote server"的報錯

◆ 定義Caps下的caps.yml

這里基本上定義的是多設備相同的desired_caps的公共部分

◆ 定義Common下的base_driver.py

這里有幾點需要注意下：◆ 多進程在調用BaseDriver類的base_driver方法時，實例化時應該先通過命令行的方式啟動appium server。設想一下，如果啟動appium server放在get_base_driver中，會出現什么樣的場景？conftest中每調用一次get_base_driver方法，就會打開一個cmd窗口，試圖去啟動appium server◆ yaml.load方法注意新的寫法加上參數 Loader=yaml.FullLoader，這樣據說更安全

◆ 定義conftest.py

關鍵點是pytest_addoption和request.config.getoption這兩個函數的使用，一個添加命令行，一個解析命令行。但仍有需要注意的：eval(cmdopt)：之所以使用eval將cmdopt轉為字典，是因為cmdopt本身是字符串。類似這樣的："{'platform_version': '7.1.2', 'server_port': 4725, 'device_port': 62025, 'system_port': 8201}"，這樣取值多不方便。此外，還需要解決一個問題，如果有多個fixture，必須保證第一個測試用例用到的fixture實現BaseDriver的實例化。并且將這一實例化的結果base_driver作為全局變量，供所有的fixture共用，否則就會出現啟動多個cmd窗口，啟動多個appium server的問題

◆ 定義TestCases目錄下的test_welcome.py

這里我只定義了一個很簡單的測試用例方法，如果打開前程貸app的歡迎頁，點擊立即體驗。如果點擊成功，說明斷言成功，否則斷言失敗

05

多進程運行的截圖

06

allure報告

allure報告是使用os.system調用allure命令行生成的，主要也就是下面標記的兩行，但是目前還沒想到辦法，在allure報告中將兩個設備區別出來。allure的測試報告是將兩個設備的結果合二為一了

07

兼容性測試帶來的問題

多進程兼容性測試也會帶來一些問題：◆ 測試報告如何更好的區分多臺設備◆ 對于分辨率不同的機型，要保證一些操作方法的健壯性和穩定性。如A手機屏幕大，確定按鈕就在屏幕可見位置，B手機屏幕小，需要多次滑動才能看到按鈕，這就要求定義方法時足夠健壯◆ 業務邏輯問題。如果并行的去操作(調用同一個接口)，會不會有業務邏輯上的限制，比如要搶一個免單券，一天同一個ip，同一個設備只能搶一件，這時候應該只會有一個成功，另一個無疑會失敗。這就需要要么調整限制，要么調整方法本文由檸檬班學員原創，轉載需注明出處！兼容性軟件測試報告如何編寫？想知道答案嗎？掃碼即可解鎖解題視頻

發現更多精彩

掃碼獲取解題視頻

來都來了，點個在看再走吧~~~

超強干貨來襲 云風專訪：近40年碼齡，通宵達旦的技術人生

總結

以上是生活随笔為你收集整理的openjdk platform binary是什么进程_基于pytest实现appium多进程兼容性测试的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。