web项目框架搭建

1、项目结构
web自动化框架的设计，同接口自动化框架一样，采用分层设计。

import os
# 项目根目录
BASE_DIR = os.path.dirname(os.path.abspath(__file__))

# 测试用例路径
TEST_CASE_DIR = os.path.join(BASE_DIR, 'testcases')

# 项目主机
PROJECT_HOST = 'https://blog.csdn.net'

# 接口信息
INTERFACE = {
    'login': PROJECT_HOST + '/testleaf'
}

# 日志配置
LOG_CONFIG = {
    'name': 'project',
    'filename': os.path.join(BASE_DIR, 'logs', 'testleaf.log'),
    # 'encoding': 'utf-8',
    # 'fmt': None,
    # 'when': 'd',
    # 'interval': 1,
    # 'backup_count': 7,
    'debug': True
}

# 测试账户信息
TEST_NORMAL_USERNAME = 'admin'
TEST_NORMAL_PASSWORD = '888888'

3、main.py

import pytest
import settings

if __name__ == '__main__':
    pytest.main(['-s', '-v', settings.TEST_CASE_DIR])

4、common\log_handler.py

import logging
from logging.handlers import TimedRotatingFileHandler

def get_logger(name, filename, encoding='utf-8', fmt=None, when='d', interval=1, backup_count=7, debug=False):
    logger = logging.getLogger(name)
    logger.setLevel(logging.DEBUG)
    # 文件处理器的等级一般情况一定比控制台要高
    if debug:
        file_level = logging.DEBUG
        console_level = logging.DEBUG
    else:
        file_level = logging.WARNING
        console_level = logging.INFO

    if fmt is None:
        fmt = '%(levelname)s %(asctime)s [%(filename)s-->line:%(lineno)d]:%(message)s'

    file_handler = TimedRotatingFileHandler(
        filename=filename, when=when, interval=interval, backupCount=backup_count, encoding=encoding)
    file_handler.setLevel(file_level)

    console_handler = logging.StreamHandler()
    console_handler.setLevel(console_level)

    formatter = logging.Formatter(fmt=fmt)
    file_handler.setFormatter(formatter)
    console_handler.setFormatter(formatter)

    logger.addHandler(file_handler)
    logger.addHandler(console_handler)

    return logger

if __name__ == '__main__':
    import settings
    log = get_logger(**settings.LOG_CONFIG)
    log.info('我是普通信息')
    log.warning('我是警告信息')

5、testcases\test_login.py

from selenium import webdriver
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC
from selenium.webdriver.common.by import By
import settings

class TestLogin:
    def test_login(self):
        # 1. 打开浏览器
        with webdriver.Chrome() as driver:
            # 2. 访问登录页面
            driver.get(settings.INTERFACE['login'])
            # 3. 登录
            # 3.1 定位用户名输入框
            wait = WebDriverWait(driver, timeout=3)
            username_input = wait.until(EC.visibility_of_element_located(('xpath', '//input[@name="phone"]')))
            # 3.2 输入用户名
            username_input.send_keys(settings.TEST_NORMAL_USERNAME)
            # 3.3 定位密码输入框
            # 3.4 输入密码
            # 3.5 定位登录按钮
            # 3.6 点击登录按钮
            # 4. 断言登录：根据右上角的退出按钮的出现
            assert wait.until(EC.visibility_of_element_located(('xpath', '//a[text()="退出"]')))

-前期准备
-环境
-实战: 从0开始

前期准备
为更好的学习自动化框架搭建，你需要提前了解以下知识：
python基础知识
pytest单元测试框架
PO模式
selenium使用

环境
本次我们自动化环境为：
mac+python3+selenium3+pytest==6.2.4
(不管是win还是mac，网上环境安装教程很多，参考下安装即可)

-实战: 从0开始
接下来我们以这个系统的登陆页面作为demo，开始进行web UI框架搭建：

最开始，我们设计了一个test_login.py文件,里完成了登陆脚本的设计：

from selenium.webdriver.support.ui import WebDriverWait

url = 'xx'

class TestLogin():

    def setup(self):
        self.driver = webdriver.Chrome()
        self.driver.get(url)
        self.driver.maximize_window()

    def teardown(self):
        self.driver.close()

    #以下为login页面设计的case

    #case1:输入正确的用户名密码后页面跳转正常
    def test_is_null(self,name,password):
        self.driver.find_element(By.ID, 'user_name').send_keys(name)
        self.driver.find_element(By.ID, 'password').send_keys(password)
        self.driver.find_element(By.ID, 'submit-button').click()
        assert 'user/index' in self.driver.get_url(),'failed--用户名密码正确时登陆场景失败'
        print ('case pass')

    # case2:用户名/密码不匹配
    def test_not_match(self, name, password):
        pass

写了1，2个用例时我们觉得没什么，但是随着case数量的增到，我们意识到了问题的严重性：
1.不同的case明明是同一段代码，只是传参不一致，就需要重复写多次，即便复制/粘贴也累啊—》解决：参数化，实现数据分离–创建data层
2.系统中某个页面发生变化，我准备去修改下对应的页面，结果代码写的过于分散，同一个页面的数据分散到了不同py模块，每次都修改不全，严重影响后期维护成本–》解决：引用PO模式（page object）–创建page层
3.系统中存在公共模块（比如系统中存在一个上传下载功能),多个页面/多个case都要使用—》解决：创建一个公共模块（创建public层）
……
诸如此类的问题随着case不断增多的状况下会明显感觉得到，接下来我们就开始逐一解决:

参数化(data)：
利用pytest框架提供的@pytest.mark.parametrize()来实现，代码及页面接口设计如下：

读取json文件的代码：

import os
import json

current_path = os.path.abspath(__file__)
path = os.path.dirname(current_path)

def get_json_data(specifypath):
    try:
        parent_path = os.path.dirname(current_path)
        path = f"{parent_path}/data/{specifypath}"
        with open(path) as file:
            data = json.load(file)
    
        return data
    except Exception as e:
        print (e)

用例层调用data改造后的代码：
引用PO模式（page object）：
po模式：
简单来说，就是以一个页面作为一个对象，把一个页面的内容写成一个.py文件；
这个页面对象中包含内容：当前页面的元素定位及操作的整合；
po模式中会引用一个basepage.py,这个文件里面一般包含的是driver相关的操作，比如：elements相关的改造，简单粗暴点理解：就是把self.driver.xx相关的内容都写到这里就行；其他页面都会继承basepage.py中的内容。

按照上面逻辑我们继续改造代码：
basepage.py:

login_page.py

我们看下case层怎么引用：
public层：

比如我登陆页面需要用到public中的内容，直接在login_page.py文件中继承即可使用public中的所有方法：

/以上就完成的框架设计/
框架设计核心：分层思想、PO模式
自动化框架设计一般都是设计都分为：page层、testcase层、public层、data层、report层（分层都比较灵活的，不管怎么分都是换汤不换药）
给大家看下完整的框架结构：

运行所有的case都放在这个run.sh的shell脚本里，后期做jenkins集成也只需要跑这个脚本即可：

echo 'start----------------'
pip install -r requirements.txt
pwd
pytest 
echo 'end----------------'

关于report大家可以直接用pytest-html来实现，网上有很多教程参考；
后期做jenkins集成直接参考之前写的内容。
///done//

前言：
✌ 作者简介：渴望力量的哈士奇 ✌，大家可以叫我 🐶哈士奇🐶 ，一位致力于 TFS 赋能的博主 ✌
🏆 CSDN博客专家认证、新星计划第三季全栈赛道 top_1 、华为云享专家、阿里云专家博主 🏆
📫 如果文章知识点有错误的地方，请指正！和大家一起学习，一起进步👀
💬 人生格言：优于别人,并不高贵,真正的高贵应该是优于过去的自己。💬
🔥 如果感觉博主的文章还不错的话，还请👍关注、点赞、收藏三连支持👍一下博主哦

---

专栏系列（点击解锁）	学习路线指引	知识定位
🔥Python全栈白皮书🔥	零基础入门篇	以浅显易懂的方式轻松入门，让你彻底爱上Python的魅力。
	语法进阶篇	主要围绕多线程编程、正则表达式学习、含贴近实战的项目练习 。
	自动化办公篇	实现日常办公软件的自动化操作，节省时间、提高办公效率。
	自动化测试实战篇	从实战的角度出发，先人一步，快速转型测试开发工程师。
	数据库开发实战篇	更新中
	爬虫入门与实战	更新中
	数据分析篇	更新中
	前端入门+flask 全栈篇	更新中
	django+vue全栈篇	更新中
	拓展-人工智能入门	更新中
网络安全之路	踩坑篇	记录学习及演练过程中遇到的坑，便于后来居上者
	网安知识扫盲篇	三天打鱼，不深入了解原理，只会让你成为脚本小子。
	vulhub靶场漏洞复现	让漏洞复现变得简单，让安全研究者更加专注于漏洞原理本身。
	shell编程篇	不涉及linux基础，最终案例会偏向于安全加固方向。 [待完结]
	WEB漏洞攻防篇	2021年9月3日停止更新，转战先知社区等安全社区及小密圈
	渗透工具使用集锦	2021年9月3日停止更新，转战先知社区等安全社区及小密圈
点点点工程师	测试神器 - Charles	软件测试数据包抓包分析神器
	测试神器 - Fiddler	一文学会 fiddle ，学不会倒立吃翔，稀得！
	测试神器 - Jmeter	不仅是性能测试神器，更可用于搭建轻量级接口自动化测试框架。
	RobotFrameWork	Python实现的自动化测试利器，该篇章仅介绍UI自动化部分。
	Java实现UI自动化	文档写于2016年，Java实现的UI自动化，仍有借鉴意义。
	MonkeyRunner	该工具目前的应用场景已不多，文档已删，为了排版好看才留着。

在上一篇章就软件自动化测试当中最简单也是最常用接口自动化测试进行了一个比较完整性的实战。可是当我们投入到实际工作应用中就会发现，虽然接口测试很有效也很容易推广开来，但是很多时候真正需要测试验证的不仅仅是接口测试的返回，还包括前端页面的重现。所以近下来的学习内容就将进入到 WEB 自动化（即 WEB 端 UI 自动化）。

在早之前的 基于JAVA实现的WEB端UI自动化 专栏，写过一篇文章 《基于JAVA实现的WEB端UI自动化 -自动化测试简单介绍》，感兴趣的小伙伴可以看一看，关于自动化测试基础理论略同。

🐳 什么是 WEB自动化

---

• WEB 自动化测试就是把在网页上的人工操作转化为使用机器、软件、程序来测试产品的过程。也就是把大量需要人工回归用例、人工操作的这些手段由计算机代替执行的一种测试方式。模拟人工执行的一系列操作，同时最终会抓取并判断结果是否符合我们的预期的这样一个过程。
• 换而言之，就是把 “点点点” 通过编程手段实现的一种测试的手段。（做 WEB 自动化之前首先需要知道自己要测什么，把部分的 “点点点” 的内容。转化为代码、脚本，减轻手工测试的工作量 ，从而提高产品的质量。）
• 做 WEB 自动化与做接口自动化有一个相像的地方，那就是 WEB 自动化同样是不在于发现新的功能的问题，而是保证产品、项目在迭代与重构的过程中，原有的已经上线过的功能依旧保持正常。以及执行一些手工很难达到的测试场景目的。（比如一个快速输入的场景，想要输入几百个字符，这样的快速输入的问题就需要 WEB 自动化来实现。）
• 还有就是在意比较大型的项目中，功能点太多的情况下，没有办法保证每一次上线发布之前通过手工的方式把这些功能都测试一遍，不太现实。不管是测试人员也好，还是开发人员也好都没有办法保证所有的功能在上线之前都能够验证完毕 。因此就需要这么一套自动化测试的方式，主要测试已经有的功能保证在每次交互的时候，已有的功能不会出现太大的问题。
• 下图就是实现 WEB 自动化的一种方式。

---

---

🐳 为什么要学习WEB自动化

在真实的工作场景非 WEB 的测试，也就是接口测试，和我们 WEB 测试是互为补充的。自动化的基本原则是已接口自动化测试为主，WEB 自动化作为必要的补充。

比较常见的需要 WEB 自动化补充的点，主要有两个方面：

---

• 1、偏向于用户维度的场景测试
• 2、验收的确认测试

---

偏向于用户维度的测试，要求从用户真实的角度去测试产品的实现，只有包含了 WEB 层才能完整的验证用户的真实体验。从实现的角度来看，这一类的自动化测试用例不会覆盖的那么完善，只覆盖最基本的和核心的端到端的用户场景，所以一般情况下不使用 “WEB自动化” 测试那些步骤特别负载或者边边角角的异常场景的测试用例，这是一个方面。

另一方面就是我们的测试逻辑和用户界面绑定在一起，无法绕过界面直接测试核心逻辑页面，在这种情况下也是不得已而为之的，在实际工作中也是最经常出现的。尤其是现在，频繁的使用微服务的情况下，服务与服务之间的交互变得比较复杂，就比较难直接通过接口一次性搞定。这样就会造成接口与接口之间的处理上存在着不稳定的因素，甚至有些处理是完全放到前端来做处理，这个时候就需要 " WEB自动化" 来进行辅助。

说理两个方面，无论是上面说的哪种情况。都有一个共同的特征，都是从一个 最终用户 来出发，对大多数有页面的系统来说，WEB 才是最理想的集成或者说系统测试的入口。也是对于产品来说、对于用户来说、对于公司来说最最需要测试的地方，同时也可以弥补开发自测、接口上的一些不足。

当然，我们的最终目标是服务于测试项目。取代那些重复的、枯燥的…操作，从测试进阶上的要求，将我们的技术范畴从使用什么技术去完成，变为多角度多纵深的去完成。

学习完自动化就会发现一个事情， 接口测试好不好呢？那是相当的有效！但是呢，接口是看不到摸不着的，但是如果做 WEB 自动化框架，能跳出浏览器就简直太神了。

同时呢，也是为了我们面试这一环节能够获得更好的待遇。

简单来说就是以下四点：

---

• 1、WEB自动化是面向用户的 “自动化”。
• 2、可以弥补单元测试、接口测试的不足。
• 3、取代部分重复枯燥的操作。
• 4、功能测试岗位的进阶。

---

🐳 什么样的项目适合做WEB自动化

有了要学习 WEB自动化 的必要性并不是说我们马上就要动手去做了，还需要稍微思考一个问题，是不是所有的项目都适合做 WEB自动化？上文关于 WEB自动化 的重要性说了很多，在关于自动化测试策略的手提到 “以接口测试为主，WEB自动化进行适当的补充”。为什么说是补充，而不是使用 WEB自动化 作为主力呢？因为 WEB自动化的缺点也是很明显的。

---

• 1、开发 WEB自动化 用例的成本相较于 接口自动化 要多很多
• 2、WEB自动化不是很稳定，在页面变更、迭代过于频繁的项目中，可能页面今天是这个样子，明天又变成另外的样子了。这样的话，之前辛辛苦苦写的很多的 WEB自动化测试脚本 很有可能就会废掉，需要推翻重写。

---

所以在这里，我们就来聊一聊什么样的项目能够最大程度的发挥 WEB 自动化的优势。对应前面所说的，首当其冲的就是 迭代可以很多、需要构建验证的次数也可以很多，但是尽量不要有频繁的变动，界面越稳定越好，而且项目的维护周期长，能够稳定存在。

稳定对于自动化测试来说，非常的重要，这样能够让我们的 WEB自动化脚本 能够使用的频率更高，这样脚本的成本也就降的越低。

如下：

---

• 1、任务测试明确，不会频繁变动。
• 2、每日构建后的频繁测试验证。
• 3、比较频繁的回归测试。
• 4、软件系统界面稳定，变动较少。
• 5、软件维护周期较长。
• 6、被测试系统开发比较规范，能够保证系统的可测试性。（前端代码太随意，测试人员两行泪。）
• 7、测试人员具备不错的编程能力。
• 8、项目进度压力不宜太大。（这句可能有点玩笑，目前我所接触的项目压力不大的只有银行的后台项目，一条需求审批得半年。）尤其是在任务的前期，刚开始动手写的时候，尽量争取到充裕的时间去搭建框架、编写脚本等等。

---

---

🐳 WEB 自动化面临的问题如何改进

上面我们提到过，当遇到不稳定、难以维护的项目时，是非常不适合使用 WEB自动化 的。那么面对这个问题，要如何改进呢？

有的公司在自动化测试领域有一个 721 规则，这个规则就是说 70% 的自动化测试工作集中在底层的接口测试和一些单元测试， 20% 的测试工作是一些集成的测试，10% 的测试工作是尽量通过 UI自动化 来实现。

既然 WEB 自动化是需要有它的辅助作用的，那么就需要用有限的条件、有限的精力将 WEB 自动化做的更好，怎么样才能叫更好呢？就需要做到以下三点：

---

• 更优秀的架构（框架）设计
• 更合理的维护方式
• 更稳健的测试环境

---

合理的架构可以保证我们自动化测试代码的编写更加方便、简洁；维护起来更加的容易；环境操作起来更加的简单稳定。

OKK，关于WEB自动化的介绍和一些基础理论的探讨到这里就告一段落，下一章节我们将了解一下 "软件自动化测试工具的历史与WEB自动化测试工具的选择。"