前言

现在是2021年6月4日上午 10 点 03 分，本来这个 dome 昨晚加班应该就面世了，不知道我们平台宵禁功能是怎么处理的，点了保存，东西就找不到。可能平台也觉得我 demo 太简单了，没有讨论的必要，思考了 6 秒，我也这么觉得，所以决定重新写一个。做 UI 主要背景是上个版本有个需求导致生产出现一个弹框没弹开，分析事故发现原因：一个小特性引入的，由于开发测试都没评估到会影响这个弹框；然后接口自动化覆盖不到这个问题；回归测试重点在影响功能，未覆盖到。那问题来了，这个锅算谁的，几个参考答案，背锅侠欢迎大家留言讨论：A.开发的，因为他未作出正确风险评估 B.负责这个特性测试同学的，测试未覆盖全 C.负责回归测试同学的，回归不到位。

demo 效果截图

效果必须发，再 low 也要看效果，要以结果为导向。
测试用例描述：登录系统、检测指定目标菜单展开、找到子菜单进入、找到测试数据进入详情、找到操作进入详情、测试按钮弹框。
执行用例结果截图：

失败的案例会截图保存到指定的位置，并用函数名_测试名命名，这是重要现场凭证。
测试报告，用的是 pytest 自带的报告和 allure 提供的报告，一个邮件链接发送直接看，一个作为附件查看更美观。
报告大概展开就是这样子的记录，详细操作会记录，方便追溯结果。

邮件发送结果，复用了接口自动化框架里面那个封装好的邮件方法，主要用的 smtplib 这个库。
Jenkins 构建流水线，每日构建，和接口自动化同时进行。

demo 架构

临时抱的狂狮大佬的大腿，鸣谢下这篇文章：selenium2 python 自动化测试。这个有介绍 selenium 家族的介绍，入门的看看这个很不错，我也是入门的，深有体会。
demo 目录：

common:这是公共模块，常用的函数放里面，目前放了一个执行函数异常捕获的截图的装饰器。
report:报告模块，测试报告文件存储的地方。
test_case:测试用例模块，测试场景的编写维护
Page_object:Page 模块，程序的核心，一个 test_case 对应一个 page。
file:文件中心，失败截图、参数化的文件等文件保存
config:配置中心，测试环境地址、数据库配置信息、邮箱配置等等在这里配置
RunCase:程序执行的入口

demo 能走多远

毕竟是一个 demo 和能运行成千上万个用例的平台相比需要优化的绝对还有很长的路要走，但是想给自己说一句，同时也送给那些想写 ui 但是考虑太多的兄弟一句话：不怕开始晚，就怕从未开始。我相信不久这个 demo 会变大变强，到时候在来和大家谈谈这个过程。都看到这里了，别忘了我们开始的背锅侠讨论哦