从零开始搭建一个简单的ui自动化测试框架02(pytest+selenium+allure)

  1. 云栖社区>
  2. 博客>
  3. 正文

从零开始搭建一个简单的ui自动化测试框架02(pytest+selenium+allure)

icesword 2017-10-31 17:40:00 浏览891
展开阅读全文

二、先搭一个架子

在我还是小白连py语法都不太熟悉的时候,经常在网上看关于自学ui自动化测试的博客,最熟悉的套路莫过于先给你介绍一下selenium的各个api,然后写一套代码去登陆微博或者百度什么的,但我今天不愿意这么写,因为这样的话,实际上并没有什么卵用,他不能用到实际的项目里,今天我们来先搭一个架子。

搭架子先画图

我们首先来确定一下我们的项目架构图,也即是我们打算怎么具体设计我们的项目,下面来聊一聊我设计时的思路。

其他的先不谈,测试用例肯定是集中放到一个地方的,于是我创建了一个testcase的位置专门用来放用例,此时我们的架构图是这样的:
—————testcase

接下来我又想到,我们的用例可能需要按照要求集合执行,所以我又创建了一个testsuite的位置专门放集合的用例,于是架构图多了一个:
—————testcase
—————testsuite

然后又想到,因为我们的测试用例需要支持单独执行,所以必然需要重复的测试前和测试后的动作,先不谈更多的动作,但是打开和关闭浏览器肯定是必须的,所以要想不在每个case里重复的写这些动作,我们就需要一个测试用例的主类用以被case继承,我把这个主类单独的放置到了一个位置maincase,于是架构图:
—————testcase
—————testsuite
—————maincase

我们再来想一下case里更具体的问题吧,比如说,我们可能需要一个(除开浏览器操作外的)工具集用以对case提供支持,包括发送Email,打开windows窗口选择文件还有其他可能遇到的奇奇怪怪的事情,我们给这个部分留了一个util的位置,再来看看架构图:
—————testcase
—————testsuite
—————maincase
—————util

再想想,如果我们发送email,那当然是要先生成测试报告,测试里遇到问题的话,最好可以有截图用来看看当时为什么出错了,那么我们各留一个位置给报告和截图:
—————testcase
—————testsuite
—————maincase
—————util
—————testreport
—————sreenshot

接下来,处理一下我们的元素存放位置,元素的管理是UI自动化里的重要点,如果不做到case和元素分离的话,维护用例将会变得非常困难,每次迭代只要元素变动了,你就得一个一个case的改,这里我们把元素集中到一个config里,稍后在具体编写阶段告诉大家如何存储,这里先分一个config的位置给元素:
—————testcase
—————testsuite
—————maincase
—————util
—————testreport
—————sreenshot
—————config

最后,如果我们希望我们的用例足够简洁的话,我们就应该把那些常用的操作封装起来,这里的封装分为两个层面封装,第一是对常用基础操作的封装,第二是对常用业务操作的封装。

解释一下的话,就是我们首先把基础的操作封装到一起,例如,寻找元素,如果我们想统一使用隐式等待(不明白的话后续篇章会介绍到)去查找元素的话,就需要把selenium里的find方法封装一下,这种是对原先的基础操作的封装;
而比如说,我们写case的时候发现,很多个case都会有一个同样的跳转路径,都是通过点击xx,再点击xx到达这个页面,我们就把这个操作路径封装了给我们的case使用,避免case里重复的写这些路径,这层封装是对复用性高的业务逻辑操作的封装。

我们给这两层封装留个位置operate:

—————testcase
—————testsuite
—————maincase
—————util
—————testreport
—————sreenshot
—————config
—————operate

这样目前来看,我们的架构图大体就画完了,剩下的如果有遗漏再开发过程里修复吧,我们看看最终的项目架构(目前还是空的):

img_628a4d64ad5a5764b4c224e5dc673da9.png
image

网友评论

登录后评论
0/500
评论
icesword
+ 关注