二、先搭一个架子

在我还是小白连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

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

image