前言
在实际工作中,如果要用appium实现多设备的兼容性测试,大家想到的也许是“多线程”,但由于python中GIL的影响,多线程并不能做到"多机并行",这时候可以考虑使用多进程的方式
为什么基于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服务,需要考虑以下几点:
-
- appium通过什么方式启动?
-
- 设备信息如何传递给base_driver方法来生成driver
第一点很明确,客户端启动appium server的方式似乎有点不合时宜了,如果你要同时测5个手机,难道要一个个启动客户端吗?最好的方式是启动命令行,因为命令行启动更方便更快
在说第二点前,先整理一下思路:main.py定义多个设备信息-->base_driver方法调用,生成多个driver-->TestCases下的测试用例调用fixture,但是设备信息怎么传递给base_driver方法呢?这时候pytest中的初始化hook函数就派上用场了
初始化hook函数
先看看pytest官网的解释:
pytest_addoption(parser)方法:可以在插件和conftest.py中使用。该方法可以注册命令行参数,以及添加init属性。它在测试开始运行的时候被调用一次
参数:parser(_pytest.config.Parser),使用parser.addoption(...png)增加命令行参数,使用parser.addini(...png)增加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
from optparse import OptionParser
parser = OptionParser()
parser.add_option("-c", "--config",
action="store",
dest="config",
metavar="FILE",
default="config.yaml",
help="/path/to/config/file, default: config.yaml")
parser.add_option("-d", "--daemon",
action="store_true",
dest="daemon",
metavar="DAEMON",
default=False,
help="run as a demon, default: False")
options, args = parser.parse_args()
print(options)
命令行运行后,发现不跟参数"-d"时,属性"demon"的值为默认值False,跟"-d"后,变成了True
E:\python_workshop\appium_parallel>python parser_demo.py -h
Usage: parser_demo.py [options]
Options:
-h, --help show this help message and exit
-c FILE, --config=FILE
/path/to/config/file, default: config.yaml
-d, --daemon run as a demon, default: False
E:\python_workshop\appium_parallel>python parser_demo.py -c config.yaml
{'config': 'config.yaml', 'daemon': False}
E:\python_workshop\appium_parallel>python parser_demo.py -c test.yaml -d
{'config': 'test.yaml', 'daemon': True}
E:\python_workshop\appium_parallel>
具体实现
定义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"的报错
import pytest, os
from multiprocessing import Pool
device_infos = [{"platform_version": "5.1.1", "server_port": 4723, "device_port": 62001, "system_port": 8200},
{"platform_version": "7.1.2", "server_port": 4725, "device_port": 62025, "system_port": 8201}]
def run_parallel(device_info):
pytest.main([f"--cmdopt={device_info}",
"--alluredir", "Reports"])
os.system("allure generate Reports -o Reports/html --clean")
if __name__ == "__main__":
with Pool(2) as pool:
pool.map(run_parallel, device_infos)
pool.close()
pool.join()
定义Caps下的caps.yml
这里基本上定义的是多设备相同的desired_caps的公共部分
platformName: Android
appPackage: com.xxzb.fenwoo
appActivity: .activity.addition.WelcomeActivity
newCommandTimeout: 500
noReset: False
定义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,这样据说更安全
from appium import webdriver
import yaml, os
class BaseDriver:
"""
公共的base_driver类
"""
def __init__(self, device_info):
self.device_info = device_info
cmd = "start appium -p {0} -bp {1} -U 127.0.0.1:{2}".format(self.device_info["server_port"], self.device_info["server_port"]+1, self.device_info["device_port"])
os.system(cmd)
def get_base_driver(self, automationName="appium", noRest=False):
"""
返回公共的driver
:param automationName: 引擎名字
:param noRest: 是否重置
:return: driver对象
"""
fs = open(r"E:\python_workshop\appium_parallel\Caps\caps.yml", encoding="utf-8")
desired_caps = yaml.load(fs, Loader=yaml.FullLoader)
desired_caps["platformVersion"] = self.device_info["platform_version"]
desired_caps["deviceName"] = "127.0.0.1:{0}".format(self.device_info["device_port"])
desired_caps["systemPort"] = self.device_info["system_port"]
if automationName != "appium":
desired_caps["automationName"] = automationName
if noRest == True:
desired_caps["noReset"] == True
driver = webdriver.Remote("http://127.0.0.1:{0}/wd/hub".format(self.device_info["server_port"]), desired_caps)
return driver
定义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的问题
from Common.base_driver import BaseDriver
import pytest
import time
base_driver = None
def pytest_addoption(parser):
parser.addoption("--cmdopt", action="store", default="device_info", help=None)
@pytest.fixture
def cmdopt(request):
return request.config.getoption("--cmdopt")
@pytest.fixture
def common_driver(cmdopt):
global base_driver
base_driver = BaseDriver(eval(cmdopt))
time.sleep(1)
driver = base_driver.get_base_driver()
yield driver
driver.close_app()
driver.quit()
定义TestCases目录下的test_welcome.py
这里我只定义了一个很简单的测试用例方法,如果打开前程贷app的欢迎页,点击立即体验,如果点击成功,说明断言成功,否则断言失败
from PageObjects.welcome_page import WelcomePage
import pytest
import allure
class TestWelcome:
"""
欢迎页的测试用例类
"""
@allure.feature("测试欢迎页")
@allure.description("测试欢迎页,如果能够点击立即体验,则断言成功,否则测试失败")
@pytest.mark.usefixtures("common_driver")
def test_swipe_welcome(self, common_driver):
"""
欢迎页的滑屏操作
:return:
"""
with allure.step("断言"):
try:
WelcomePage(common_driver).swipe_screen()
assert True == True
allure.attach("断言成功!\n")
except:
assert True == False
allure.attch("断言失败!\n")
多进程运行的截图
allure报告
allure报告是使用os.system调用allure命令行生成的,主要也就是下面标记的两行,但是目前还没想到办法,在allure报告中将两个设备区别出来。allure的测试报告是将两个设备的结果合二为一了
兼容性测试带来的问题
多进程兼容性测试也会带来一些问题:
- 测试报告如何更好的区分多台设备
- 对于分辨率不同的机型,要保证一些操作方法的健壮性和稳定性。如A手机屏幕大,确定按钮就在屏幕可见位置,B手机屏幕小,需要多次滑动才能看到按钮,这就要求定义方法时足够健壮
- 业务逻辑问题。如果并行的去操作(调用同一个接口),会不会有业务逻辑上的限制,比如要抢一个免单券,一天同一个ip,同一个设备只能抢一件,这时候应该只会有一个成功,另一个无疑会失败。这就需要要么调整限制,要么调整方法
欢迎来到testingpai.com!
注册 关于