一个实习生的自动化测试框架搭建计划文档

自动化测试框架搭建

由于公司的需求，本小小实习生接起了搭建自动化测试框架的任务。该文档为粗略的计划文档，之后会补充上其他端的部分，后续搭建过程也会写成教程

UI自动化调研

UI自动化基本情况分析

• 什么是UI自动化
  UI自动化测试，指的就是使用工具或者脚本对需要测试的软件的前端界面在预设的条件下和已经的测试数据下运行系统或者应用程序，并获取其前端页面显示的数据结果进行校验，评估得出测试结论。

• 为什么要使用UI自动化测试

  • 案例的步骤繁琐，场景复杂，制作测试数据的过程复杂，导致人工执行时间过长；
  • 需求简单，无前端功能开发的需求可以使用UI自动化进行测试并得出结论；
  • 编写好的脚本可以帮助开发人员进行自测。

• UI自动化测试可用于哪里

  • 目前互联网医院测试渠道可分为：手机App（医生端）、PC Web端（医院后台、运营后台）、小程序端（未来患者端）；
  • 基于测试阶段可分为：
    • 开发提测前自用，配置环境和工具，下载脚本执行，可通过测试报告查看执行情况和结果
    • 冒烟测试中，测试在开发提测后执行，通过测试报告查看执行情况和测试结果
    • 回归测试中，测试人员执行执行纳入回归测试的测试脚本并执行
    • 生产验收，UI自动化测试脚本可用于生产验收中，无须手动操作就可验证生产的情况
    • 未来希望将脚本注入到Jenkins中进行冒烟测试

• UI自动化测试利弊分析

  • 利：快捷、方便、无须手工操作、提高拥有大量简单操作的用例的测试效率

    • 对回归测试来讲一般情况下，回归测试里面的案例都很多都是之前的版本需求中的案例，在迭代多了之后回归测试中的案例就会慢慢的增加，到最后就会出现一个在封板之后执行回归测试案例时会执行不完的情况，使用UI自动化测试之后，以前的回归测试案例可以不需人工执行，等脚本执行完之后查看脚本测试报告和截图，成功失败一目了然，然后测试人员可以把注意力放在了当前迭代的需求中
    • 对于冒烟测试来讲（无前端改动的需求前提下），开发提测前都需要进行自测，他们可以在电脑上配置好UI自动化测试的环境后，利用工具自己执行进行自测

  • 弊：脚本编写成本高、案例开发时间长、需要长期维护

    • 只能验功能不能验样式：例如“前端把按钮从蓝色改为绿色，圆形改为方形”这种需求UI自动化无法验证。
    • 测试人员需要学习工具和脚本编写，需要额外时间成本
    • 部分案例开发时间长，一些场景比较复杂的流程，和数据制作的过程比较繁琐，需要不停的调试脚本
    • 长期维护成本高，需要有人根据迭代的需求进行维护，如果长期不维护，脚本就会变得不可用

PC Web端 UI自动化测试搭建计划

测试工具

目前选择Python+Selenium+Pytest+Chrome for Testing+ChromeDriver+Allure+Jenkins这一套框架进行UI自动化测试

• Selenium
  较为广泛的自动化测试工具，目前决定使用SeleniumWebDriver和SeleniumIDE进行UI自动化测试，前者用于编写测试脚本，后者用于录制测试脚本，两者可以结合使用
• Pytest
  Python的单元测试框架，使用pytest可以方便的编写测试用例，并且pytest支持测试用例的分组执行，测试用例的参数化，测试用例的跳过，测试用例的标记等功能，并且pytest可以生成测试报告
• Allure
  用于生成测试报告，可以生成比较美观的测试报告，并且支持测试用例的分组执行，测试用例的参数化，测试用例的跳过，测试用例的标记等功能
• Jenkins
  CI/CD持续集成工具，可以用于自动化测试脚本的执行，并且可以生成测试报告
• Chrome for Testing
  Chrome浏览器专为自动化测试推出的版本
• ChromeDriver
  Chrome浏览器的驱动程序，用于UI自动化测试

测试框架搭建

PO模式

在自动化测试中，Page Object（PO）模式是一种常见的设计模式，它将页面的元素定位和操作逻辑封装在单独的类中。这种模式有助于提高测试代码的可读性、可维护性和可扩展性。

1. 创建PO类：在 test_case 目录下为每个页面创建一个PO类。这些类通常以页面名称命名，例如 LoginPage.py、HomePage.py。
2. 封装元素定位：在PO类中，将页面元素的定位信息封装为私有属性。这些属性通常使用Selenium的定位策略，如 id、name、class_name 等。
3. 封装操作方法：在PO类中，为页面元素的操作定义公共方法，如点击、输入文本、选择等。这些方法通常以页面元素的功能命名，例如 click_login_button()、enter_username()、select_dropdown()。
4. 使用PO类：在测试用例中，通过导入PO类来使用页面元素的操作方法。这样可以避免在测试用例中重复编写定位和操作代码，提高代码的复用性。
5. 集成PO类：在测试用例中，使用PO类的方法来执行页面操作，并验证预期结果。这样可以确保测试用例更加专注于业务逻辑的验证，而不是页面元素的定位和操作。
6. 维护和扩展：当页面结构发生变化时，只需更新对应的PO类，而不需要修改测试用例。这有助于提高测试代码的维护性和可扩展性。
   以下是PO模式的一个简单示例：

# LoginPage.py
class LoginPage:
    def __init__(self, driver):
        self.driver = driver
        self.username_input = self.driver.find_element_by_id('username')
        self.password_input = self.driver.find_element_by_id('password')
        self.login_button = self.driver.find_element_by_id('login-button')
    def enter_username(self, username):
        self.username_input.send_keys(username)
    def enter_password(self, password):
        self.password_input.send_keys(password)
    def click_login_button(self):
        self.login_button.click()

# test_login.py
import pytest
from test_case.LoginPage import LoginPage
@pytest.fixture(scope='function')
def login_page(driver):
    return LoginPage(driver)
def test_login_success(login_page):
    login_page.enter_username('user1')
    login_page.enter_password('pass1')
    login_page.click_login_button()
    assert 'Welcome user1' in driver.page_source

目录结构概览

以下是整个测试框架的目录结构概览：

project_root/
│
├── tests/                        # 主测试目录
│   ├── auth/                     # 认证模块的测试目录
│   │   ├── test_login.py         # 登录测试用例
│   │   ├── test_logout.py        # 登出测试用例
│   │   └── auth_suite.py         # 认证模块的测试套件脚本
│   │
│   ├── search/                   # 搜索模块的测试目录
│   │   ├── test_search.py        # 搜索功能测试用例
│   │   └── search_suite.py       # 搜索模块的测试套件脚本
│   │
│   └── main_run.py               # 统一执行所有测试套件的入口脚本
│
├── data/                    # 测试数据存储区
│   ├── auth/                     # 认证模块测试数据
│   │   ├── login_data.json       # 登录数据
│   │   └── logout_data.yaml      # 登出数据
│   │
│   ├── search/                   # 搜索模块测试数据
│   │   └── search_data.json      # 搜索数据
│
├── report/                  # 测试报告生成区
│   ├── allure-results/           # Allure 报告结果
│   └── latest/                   # 最新的测试报告
│       └── report.html           # 最新的测试报告
│
├── tools/                        # 工具存放区
│   ├── webdriver/                # WebDriver 相关工具
│   │   └── webdriver_setup.py    # WebDriver 设置脚本
│   │
│   └── utils/                    # 通用工具
│       └── logger.py             # 日志工具脚本
│
├── config/                  # 测试配置文件存放区
│   ├── config.ini                # 默认配置文件
│   │
│   └── env/                      # 环境配置文件
│       ├── dev_config.ini        # 开发环境配置
│       └── prod_config.ini       # 生产环境配置
│
├── log/                     # 测试日志存放区
│   └── test_run.log              # 测试运行日志
│
├── pages/                        # 页面对象存放区
│   ├── base_page.py              # 基础页面类
│   │
│   └── auth/                     # 认证模块页面对象
│       └── login_page.py         # 登录页面对象
│
├── requirements.txt              # 项目依赖文件
└── pytest.ini                    # pytest配置文件

详细说明

1. tests/:

   • auth/: 存储认证模块的测试用例和套件。
     • test_login.py: 登录测试用例。
     • test_logout.py: 登出测试用例。
     • auth_suite.py: 认证模块的测试套件脚本，用于选择并执行特定测试用例。
   • search/: 存储搜索模块的测试用例和套件。
     • test_search.py: 搜索功能测试用例。
     • search_suite.py: 搜索模块的测试套件脚本，用于选择并执行特定测试用例。
   • main_run.py: 统一执行所有测试套件的入口脚本。

2. test_data/:

   • auth/: 存储认证模块的测试数据，包括登录和登出数据文件。
   • search/: 存储搜索模块的测试数据文件。

3. test_report/:

   • allure-results/: 存储Allure生成的报告结果。
   • latest/: 存储最新的测试报告，方便快速查看。

4. tools/:

   • webdriver/: 存储与WebDriver相关的工具和脚本。
     • webdriver_setup.py: 用于设置和管理WebDriver。
   • utils/: 存储通用工具脚本。
     • logger.py: 用于日志记录的工具脚本。

5. test_config/:

   • config.ini: 默认的测试配置文件。
   • env/: 存储不同环境的配置文件。
     • dev_config.ini: 开发环境配置文件。
     • prod_config.ini: 生产环境配置文件。

6. test_log/:

   • 存储测试运行日志的目录，包含详细的运行记录以便调试。

7. pages/:

   • base_page.py: 基础页面类，定义通用页面操作。
   • auth/: 存储认证模块的页面对象。
     • login_page.py: 登录页面的对象类，包含页面元素和操作。

8. requirements.txt:

   • 列出项目依赖的所有Python包和版本。

9. pytest.ini:

   • 配置pytest的选项和参数，优化测试执行。

小程序 UI自动化搭建计划

（待补充）

App端 UI自动化搭建计划

（待补充）