基于LINUX环境的自动化测试的研究应用
Posted
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了基于LINUX环境的自动化测试的研究应用相关的知识，希望对你有一定的参考价值。
参考技术A (一)各种技术应用的前提。对于在开源社区和一些开源项目中获得的测试工具，首先需要了解工具适用于哪些类型应用的测试，以及工具发布后的发布说明和FAQ。开源的工具通常不像商业工具那样成熟稳定，因此找出工具的适用范围以及探索工具的实现程度是进行自动化测试应用的前提。(二)各种技术应用的环境需求。对于各类工具，需要关注编译和运行时对各种包和库及其版本的依赖关系以及对预先安装的应用的依赖关系。这些在用户手册中都有详尽的说明。
(三)服务器性能监视器。大部分测试工具没有提供服务器端的性能监控功能，测试工程师需要根据实际的需求编写性能监控脚本来配合工具的使用。
下面结合曾经参与进行过的Linux平台下的自动化测试的研究，面向不同类别的测试用例自动化的需求，将主要从功能测试，如GUI测试、命令行客户端的测试，以及性能测试等几个方面对Linux平台下的测试工作的自动化进行分析和说明。
GZW自动化洲试
对于GUI测试的自动化，通常的测试工具所使用的捕捉／回放技术有两种，一种是通过记录界面的鼠标事件(如点击、移动)和键盘事件来完成录制和回放，另外一种则是录制和回放都是基于控件的识别和操作进行的，每个脚本的执行都是控件对象的属性改变或事件触发。我们从开源社区可以获得如上两种类型的运行于Linux平台之上的典型测试工具，如Knee和LDTP等。
(一)Xnee工具
在Linux操作系统的xll环境下，Xnee能够录制、回放和分发用户的动作。Xnee的捕捉／回放技术是记录鼠标事件和键盘事件。进入录制模式时，Xnee记录发送至和来自X server之间的协议数据拷贝，并生成Xneesession文件。在回放模式下，Xnee读取Xnee Session中的事件，模仿整个录制过程(即用户操作过程)完成和x server之间的通讯，被录制的应用软件(Xclient)则接收来自xserver的消息，完成预设的动作。
(二)LDTP测试工具／框架
Linux Desktop Testing Project(LDTP)测试工具／框架能够基于用户在应用界面的选择进行脚本的录制。LDTPI具使用了Gnome环境下的Accessibility库即辅助选项库(at-spi)。使用辅助选项能够获得应用通过AT-SPI协议提供的关于用户界面的信息和界面控件的当前状态或者属性。LDTPI具／框架的体系结构如下：
AT-SPI的基础思想就是为用户界面的可视化元素提供对应的辅助对象，而录制完成的每个脚本的执行都是基于这些辅助对象进行的。对于希望利用LDTPI具进行测试的应用，需要激活辅助选项。
(三)GUI自动化测试工具的应用
在实际的GUI自动化测试中，LDTPI具应用的场景会更广泛一些。LDTPI具可以识别窗口中的对象(如按钮)，测试脚本使用LDTP的API接口，每个API接口对UI对象进行操作存在两个最基本的入口，即窗口和对象，窗口通过窗口的类型和名称(即标题)识别，对象通过希望操作的控件的类型和名称(标签或者关联的标签)识别。我们同样可以通过at-pokel具展现激活了辅助选项的应用程序窗口的对象及对象属性。在测试Linux桌面产品和服务器产品的过程中，使用LDTPI具可以测试任何启用辅助选项的Gnome应用，如Mozilla，OpenOffice.org、Evolution邮件客户端，Nautilus文件浏览器等等，此外还可以测试UI界面基于Swing的Java应用，以及KDE4.O上基于QT4.0的应用等等。
而Xneel具所针对的应用程序类型就没有特别的限制，对于一些简单的窗口验证测试和界面的稳定性测试等则比较有效。Xnee相对于基于控件方式捕获和回放的工具而言，不用担心存在控件不能被识别的问题。
从使用的情况来看，各个工具也都因为实现技术而存在一定的缺陷，如两个工具均不能插入验证点，从而不能实现用例级别的结果验证；LDTP对于界面的个别元素捕获不到以及不能对不支持辅助选项的应用进行测试等等；而Xneel具生成的脚本可编辑性差，同时由于录制生成的脚本中的事件和屏幕坐标相关，因此当出现窗口弹出位置发生变化等问题时，就需要考虑回放时应该如何来处理这些变化。
某城商行开发测试云平台架构设计和运维方案设计实践经验分享
【作者】李高峰，某商业银行信息科技部高级工程师，技术架构组成员，基础设施维护组负责人，主要负责数据中心的基础环境架构规划、灾备体系（两地三中心）建设和规划、基础设施的运维管理及云管理平台项目建设，擅长数据中心架构规划、容器云与分布式架构、虚拟化等相关技术。
互联网业务的快速发展给我行科技IT带来巨大的挑战，一方面，我行业务快速发展要求IT响应时间越来越短，开发测试速度越来越快，形成IT响应时间越来越短的要求与现有僵化基础设施、低效IT供给服务模式的矛盾；另一方面，资源池规模越来越大，形成日益增长的管理压力与现有低效匮乏运维管理工具和模式的矛盾。因此，我行迫切要求信息科技对IT基础架构、服务管理模式进行转型，以支撑业务快速发展，同时提升管理能力效率，减少资源浪费，释放人力资源，降低成本。
我行目前开发测试环境基础资源全部采用虚拟化部署，包括X86服务器采用VMware虚拟化，浪潮K1 Power服务器采用PowerVM虚拟化，但是PowerVM旨在实现CPU、MEM、网络、存储IO通道的虚拟化，没有实现存储和SAN网络的自动化管理，为了能够实现Power资源的自动化部署和统一管理，降低人员操作风险和项目实施周期，我行在开发测试环境引进了PowerVC云管理平台，实现资源的自动化部署和管理。
PowerVC 旨在简化浪潮K1 Power环境中的虚拟资源的管理。借助PowerVC，可以注册物理主机、存储器提供者和网络资源，并使用它们来创建虚拟环境。
Power® Virtualization Center Standard 支持较大型企业和更复杂的系统配置。通过它能够使用功能强大且易于使用的界面来最大限度地利用浪潮K1 Power硬件的虚拟化功能。它具有下列主要功能：
支持由硬件管理控制台管理的浪潮K1 Power主机。
支持存储区域网络。
支持每个主机上具有多个 Virtual I/O Server 虚拟机。
支持共享存储池。
支持主机和存储器模板，以帮助您在环境中一致并且可靠地部署虚拟机。
主机必须是硬件和软件需求中所定义的受支持的浪潮K1 Power型号。
每个主机上必须至少有一个Virtual I/O Server (VIOS) 虚拟机。需要对Virtual I/O Server配置一些特定设置，以支持执行某些PowerVC 任务。
对于由 HMC 管理的主机，最多支持 30 个由 HMC 管理的主机。
每个主机上最多可以有 1000 个虚拟机。
所有这些主机上总共最多可以有 6000 个虚拟机。
对于由 NovaLink 管理的主机，最多可支持 200 个由 NovaLink 管理的主机。
每个主机上最多可以有 1000 个虚拟机。
所有由 NovaLink 管理的主机上总共最多可以有 5000 个虚拟机。
当您所在环境由 HMC 管理的主机和 NovaLink 管理的主机组成时，所有这些主机上总共最多可以有 3000 个虚拟机。
最多可以支持 100 个主机，其中 30 个主机可由 HMC 管理。
PowerVC的架构设计如下图所示（测试环境采用NPIV方式）：
一、设计目标
根据基础资源云管理平台的建设目标，我行小型机最终是由云平台通过PowerVC 管理节点进行操作。在云管理平台建成前，分成三步走：
系统集成阶段，由HMC控制台进行管理；
在开发阶段，由PowerVC 管理节点进行管理；
在云平台投入运行后， 由云管理平台进行管理。
PowerVC具有OpenStack接口，作为一个系统管理软件，它基于 OpenStack，操作简便，并提供了 OpenStack 上标准接口。
PowerVC 软件计划安装在VMware虚拟化环境中，创建1台8核16GB的linux虚拟机，用于安装此软件。
PowerVC的特性：
PowerVC在 HMC 上再抽象一层，同时可以管理多个 HMC。
操作简洁，管理员无需具有相关领域知识即可进行操作。
提供更企业级的存储管理。
PowerVC的功能：
创建小型机上虚机并且可以 resize、以及为它们 attach volume。
PowerVC通过HMC自动导入小型机上的虚机。
监测并管理所有 Hosts 的资源。
快速同时创建多个虚机以满足业务需求。
PowerVC搭建的软件条件（安装在一台X86的服务器上即可）
PowerVC安装盘
Red Hat Enterprise Linux (RHEL) Server V7.1（或更高版本）for x86_64
二、整体架构设计
上图为我行PowerVC 的整体部署架构，PowerVC 通过HMC管理小型机，并纳管SAN交换机（F96）和SVC控制器，实现存储LUN的自动划分和交换机zone的自动配置，并映射存储给PowerVM虚拟化分区，实现操作系统的自动化部署。
PowerVC 可以实现以下操作：
通过部署映像来创建虚拟机，然后调整大小，并将卷连接到它们。
导入现有虚拟机和卷，以便它们可由PowerVC 来管理。
监视您所在环境中资源的利用率。
当过度使用主机组资源时，使用PowerVC动态资源优化器 (DRO) 能够自动重新均衡主机组资源。
当虚拟机正在运行时，迁移这些虚拟机（动态分区迁移）。
捕获恰好按您期望的方式配置的正在运行的虚拟机。然后，将该映像部署到您所在环境中的其他位置。
快速部署映像以创建满足您不断变化的业务需要的新虚拟机。
使PowerVC 能够在您部署或迁移虚拟机时，根据您指定的条件自动放置这些虚拟机。
三、运维方案设计
1、以太网络IO通道虚拟化
在设计以太网IO通道时我们主要考虑到实现Live Partition Mobility功能，设计原则如下：
每个VIOS上部署两块万兆物理网卡，配置Ether channel来增大网络带宽和提高可用性，然后配置SEA适配器为客户端LPAR提供生产网络服务，部署一块电口网卡配置SEA为VIOC提供管理网络服务。
配置SEA可采用Share的模式和standby模式，Share模式是通过VLAN的划分分别在两个VIOS负载不同的VIOC上的网络数据流量，而standby模式只能在一个VIOS上负载所有的VIOC的网络数据流量，本次项目中，鉴于网络带宽的需求，建议采用Share的模式来配置SEA。
根据需求每个VIOC上部署至少两块VEA适配器。一个配置管理IP（用作DLPAR），一个配置生产IP。
-
外部交换机上需要做trunk配置。
▲PowerVM虚拟化服务器 VIOC以太网络IO通道虚拟(SEA sharing)示意图
架构图说明如下：
每台浪潮K1 Power服务器采用2个VIOS，每个VIOS上分配1个4口电口网卡和2个双口万兆光口网卡。
每个VIOS上1个电口网卡连接两个管理交换机，万兆网卡连接两个汇聚生产交换机。
网卡首先要配置Ether channel。
共享以太网卡（即SEA）用于桥接内部虚拟网络与外部物理网络。在每一个VIOS内部，创建2个SEA，一个用于生产网段的通信，另一个用于管理网段的通信。
每个VIOC需要创建2个VEA适配器，用来配置管理和生产IP。
在交换机上，与VIOS相联的交换机端口需设置trunk。
2、存储IO通道虚拟化
2.1 存储IO通道虚拟化目标架构：vSCSI
磁盘存储IO通道架构设计
下面为虚拟SCSI的设计原则：
虚拟IO服务器部署两块光纤卡以实现IO路径的高可用。
客户分区上安装存储的驱动透明地实现双虚拟IO服务器路径的高可用性。
架构示意图：
▲使用SAN存储IO通道虚拟示意图-vSCSI
2.2 存储IO通道虚拟化目标架构：NPIV
虚拟存储IO通道架构设计
下面为NPIV的设计原则：
NPIV的采用的多口实现高可用。
通过每个VIOS各映射2个虚拟HBA卡到客户端分区。
需要配置16Gb的HBA卡，且光纤交换机支持NPIV。
目标架构示意图：
▲存储IO通道虚拟示意图-NPIV
NPIV架构说明如下：
VIOS上分别分配2块16GB HBA卡：
VSCSI方式是在VIOS上识别管理存储，然后通过虚拟SCSI协议映射到VIOC分区上，NPIV方式是VIOS通过创建虚拟FC卡链接到VIOC的虚拟FC卡，传输采用的是FC的协议，优点是在VIOS采用的协议不消耗VIOS的管理存储的资源，同时可以提高FC的效率，NPIV方式比VSCSI方式性能的线性增长要好。
每块16GB NPIV HBA卡只用1个端口，两个HBA端口用作连接SVC存储。
使用NPIV技术将其配置成VFC给虚拟主机使用，使虚拟主机用VFC卡来识别存储。
交换机和服务器连接的时候可采用上图所示，交叉连接来避免单点故障。
具体Zoning和driver设置采用NPIV方式，PowerVC 会自动在交换机上划分WWPN zone。
四、结语
综上即为我行PowerVC 架构的方案设计与具体实践，并且结合涵盖了日常运维管理的最佳实践，包括PowerVM虚拟化网络和存储等。
通过开发测试环境搭建PowerVC ，原有的资源分区创建从N天减少为数小时，提升IT响应能力，减少IT资源申请排期，减少人工操作风险及工作量，解放人力。
目前已经我行已经实现PowerVC 纳管到统一云管理平台上，实现VMware和PowerVM虚拟化分区的自动化部署，并实现权限的统一管理、资源生命周期管理、资源的统一监控等；未来将纳管SDN、F5、防火墙等网络设备，最终实现资源申请的全面自动化。同时也希望将我行的实践经验分享给大家，互相学习、共同进步，欢迎各位提出宝贵建议！
点击文末阅读原文，可以到原文下留言交流
觉得本文有用，请转发、点赞或点击“在看”，让更多同行看到
资料/文章推荐：
下载 twt 社区客户端 APP
或到应用商店搜索“twt”
以上是关于基于LINUX环境的自动化测试的研究应用的主要内容，如果未能解决你的问题，请参考以下文章