网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
2.E2E测试(End-to-end Test)
端到端测试,模拟用户真实使用场景的测试
测试金字塔的顶层(UI测试)并非这里字面意义上的“UI测试”,这一点比较有误导性,对于现代前端应用,UI测试侧重产品的UI交互是否正确,模拟后端进行测试也可以,放在单元测试里去做也可以。
而E2E测试,是需要模拟用户真实场景的测试,检查整个系统是否以正确的方式运作。
所以广义上的“UI测试”(测试金字塔的UI Tests)可以认为是E2E测试。
什么场景适合
- 需求稳定,不会频繁变更
- UI界面稳定,变动少
- 项目周期长
- 大量的回归测试
一、技术选型
目前市面上常见的几种E2E测试方案有
- 基于WebDriver:Selenium,Appium
- 基于CDP:Puppeteer,Playwright
- Inject Script:Cypress
二、方案落地
最终针对常用的业务场景,我选择了Codeceptjs,这是一个E2E的测试集成框架,统一了用户层的api,可以选择多种不同的测试方案,Web端支持Playwright、WebDriver、Puppeteer、Protractor、TestCafe、Nightmare,手机端支持Appium、Detox。
- 在PC端使用Playwright
- 在APP端使用Appium
在项目落地前,还有个问题需要确定:
- E2E测试代码放哪里?(有以下两个选择)
- 跟随项目代码:便于跟随项目的变动进行迭代
- 独立仓库维护:独立维护,跟项目仓库解耦
两种选择各有利弊,第一种方案适合项目开发人员维护测试代码,第二种方案适合测试人员独立维护测试代码
三、初始化项目
安装codeceptjs
npm install -D codeceptjs
初始化项目
npx codeceptjs init
选择测试框架
? What helpers do you want to use?
❯◉ Playwright
◯ WebDriver
◯ Protractor
◯ Puppeteer
◯ Appium
◯ Nightmare
◯ FileSystem
选择完Playwright
,输入完一些自定义配置就会开始安装对应的测试框架以及创建一系列的文件。 安装完成后,会提示你创建一个测试文件,输入文件名后,就可以开始愉快的编写测试代码啦。
// 目录结构
|- output // 测试报告文件夹
|- specs // 测试代码文件夹
|- login_test.js
|- codecept.conf.js // codecept配置文件
|- jsconfig.json
|- package.json
|- steps_file.js // 给实例对象绑定一些公共方法
基础示例
Feature('登录')
Scenario('跳转到首页', async ({ I }) => {
await I.amOnPage('/')
await I.seeInCurrentUrl('/login')
I.fillField('[name="login-phone"]', 1234567890)
I.fillField('[name="sms-code"]', 123)
I.click('登录', '[type="submit"]')
await I.see('经理', '.role-item')
I.click('text="经理"')
I.click('text="确 定"')
await I.seeInCurrentUrl('/home')
})
如上代码,就是一个基础登录流程的E2E测试代码,想了解Playwright的相关api可以看这里
Page Object Model
POM是自动化测试代码中最基础的设计模式,核心思想就是将交互和业务解耦,把能够复用的交互层代码进行抽离。
创建PageObject页面
npx codeceptjs gt // 也等于 npx codeceptjs generate:pageobject
POM代码
// pages/User.js
const { I } = inject()
class User {
async login (mobile, token) {
await I.seeInCurrentUrl('/login')
I.fillField('[name="login-phone"]', mobile)
I.fillField('[name="sms-code"]', token)
I.click('登录', '[type="submit"]')
}
async chooseRole (roleName, actionName = '确 定') {
const hasRoleName = tryTo(() => I.see(roleName, '.role-item'))
if (hasRoleName) {
I.click(`text="${roleName}"`)
I.click(`text="${actionName}"`)
}
}
}
module.exports = new User()
module.exports.User = User
业务测试代码
// specs/login_test.js
Feature('登录')
Scenario('跳转到首页', async ({ I, User }) => {
await I.amOnPage('/')
await User.login(1234567890, 123)
await User.chooseRole('经理')
await I.seeInCurrentUrl('/home')
})
BDD
全称:Behavior-driven Development
中文:行为驱动开发
BDD是一种敏捷软件开发的技术,大致流程如下图:
- 业务方、产品经理、开发人员、测试人员一起讨论并明确需求
- 使用
Gherkin
来编写描述业务场景的测试用例 - 开发人员根据
Gherkin
写的测试用例来编写代码 - 测试人员根据
Gherkin
写的测试用例来验收测试
BDD最重要的一个特性是:由非开发人员编写测试用例,而这些测试用例是使用自然语言编写的 DSL(领域特定语言)。
这样有助于克服开发人员对构建产品需求的理解与业务人员对需求引起的技术困难理解之间的差距。
Gherkin 是一种DSL,最初由BDD测试框架Cucumber提出。
优点:
- 支持多语言
- 业务人员可以读懂
- 可以描述软件行为
Gherkin以.feature
后缀的文件为载体。
每个Gherkin场景都有一个基本的模式,其中包括:条件(假如),事件(当)和结果(那么)
// features/login.feature
# language: zh-CN
功能: 登录
场景: 跳转到首页
假如 进入项目根路径
那么 进入到登录页面
当 登录账号1234567890
当 选择经理角色
那么 进入到首页
给对应的步骤编写测试代码
// step_definitions/steps.js
const { I } = inject()
// Add in your custom step files
Given('进入项目根路径', () => {
I.amOnPage('/')
![img](https://img-blog.csdnimg.cn/img_convert/cad8d854b8a6523b4eb814b8c641c3f8.png)
![img](https://img-blog.csdnimg.cn/img_convert/f417166d5791b06b8d05acded76a03be.png)
**网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。**
**[需要这份系统化的资料的朋友,可以戳这里获取](https://bbs.csdn.net/forums/4f45ff00ff254613a03fab5e56a57acb)**
**一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!**
图片转存中...(img-EC2OCx9g-1715486119771)]
**网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。**
**[需要这份系统化的资料的朋友,可以戳这里获取](https://bbs.csdn.net/forums/4f45ff00ff254613a03fab5e56a57acb)**
**一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!**