openjdk platform binary是什么进程_基于pytest实现appium多进程兼容性测试

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多进程兼容性测试的全部内容，希望文章能够帮你解决所遇到的问题。

如果觉得生活随笔网站内容还不错，欢迎将生活随笔推荐给好友。