专注测试技术的课程订阅站点

chatgpt 4o 制定的软件测试学习计划强到离谱

chatgpt4o 已经发布几天了,近期关于这个模型的各种测试评测层出不穷,不过可以看到该模型在学习教育领域潜力巨大,可以教初中生学数学,教老外学英语,教学方式新颖独特,比普通老师教的都好。

今天正好被灰度到了 gpt4o,发现其知识库是 2023 年的,比之前的 3.5 要新不少,正好可以问一下跟测试同学自我提升相关的问题。

第一个问题: 请帮我制定一个 2024 年软件测试人员的技术提升计划

制定一个 2024 年软件测试人员的技术提升计划需要考虑当前的技术趋势、行业需求以及个人的职业目标。以下是一个详细的技术提升计划:

第一季度:基础夯实与工具掌握

  1. 巩固基础知识

    • 复习软件测试基础理论:测试生命周期、测试类型(如单元测试、集成测试、系统测试、验收测试等)。
    • 学习和掌握测试用例设计方法:等价类划分、边界值分析、因果图、状态转换测试等。
  2. 工具使用

    • 熟练掌握常用的测试管理工具:JIRA、TestRail、Zephyr 等。
    • 学习和使用版本控制工具:Git。
    • 学习自动化测试工具:Selenium、Appium(针对 Web 和移动应用)。
  3. 编程技能

    • 学习一门编程语言,如 Python 或 Java,掌握基础语法和编程逻辑。
    • 编写简单的测试脚本,进行单元测试和简单的自动化测试。

第二季度:深入自动化测试与持续集成

  1. 自动化测试进阶

    • 学习和掌握高级的 Selenium 用法:页面对象模型(POM)、数据驱动测试(DDT)。
    • 掌握移动应用测试工具 Appium 的进阶技巧。
    • 学习 API 测试工具:Postman、RestAssured,并掌握 API 测试的基本方法。
  2. 持续集成/持续交付(CI/CD)

    • 学习 CI/CD 基础知识和概念。
    • 掌握 CI/CD 工具:Jenkins、GitLab CI、CircleCI 等。
    • 实践在项目中配置自动化测试与 CI/CD 管道。
  3. 测试框架

    • 学习和使用测试框架:JUnit、TestNG(针对 Java),PyTest(针对 Python)。
    • 设计和实现端到端测试框架。

第三季度:性能测试与安全测试

  1. 性能测试

    • 学习性能测试的基础理论和方法。
    • 掌握性能测试工具:JMeter、LoadRunner。
    • 进行性能测试脚本编写和性能分析。
  2. 安全测试

    • 学习和掌握基本的安全测试知识:OWASP Top 10、常见的安全漏洞(如 SQL 注入、XSS 等)。
    • 使用安全测试工具:Burp Suite、OWASP ZAP。
    • 进行安全测试实践,识别和修复常见的安全问题。

第四季度:云测试与新技术探索

  1. 云测试

AI自动化探索之gpt4与playwright

之前介绍过一个使用 chatgpt4 分析 dom,然后生成 puppeteer 代码进行自动化的测试工具 Taxy AI。今天发现有人推荐了一个使用 chatgpt4 生成 playwright 代码的测试工具BrowserGPT,稍微看了一下,原理比较简单,比较适合我们去研究一下,顺便打开思路。

演示动画

https://github.com/mayt/BrowserGPT/raw/master/public/browsergpt.gif

具体使用

因为我没有 chatgpt4 的 key,所以没办法直接上手使用,只能通过文档去猜测一下具体用法。

BrowserGPT 设置了 openai 的 key 以及 start url 之后就可以在命令行里运行了,大致的使用方式是输入一些自然语言,然后 BrowserGPT 执行 AI 生成的 playwright 代码,实现自然语言自动化的功能。

go to hn
click on the abc article

比如上面的一些描述就实现了去 hacknews 网站点击 abc 这篇文章的功能。

原理分析

大致看了一下,执行的流程是这样的,代码在这里

  • 获取初始化的 url,打开 chrome 浏览器,跳转到这个 url
  • 在命令行里启动 prompt,也就是给用户一个输入的 ui
  • 初始化 openai 的 api
  • 写个死循环,每次用户输入之后调用doAction函数
  • doAction函数里简化当前页面的 dom 元素
  • 将简化过的 dom 元素传给 chatgpt,让 gpt 根据 playwright 的示例生成代码
  • 执行 chatgpt 生成的代码

这里最有意思的部分是doAction函数

破防了,我用本地运行的ai写代码,感觉它比我厉害多了

事情是这样的,前几天 facebook 发布了最新的llama3 模型,我第一时间就用ollama下载运行了一下,8b 模型的 size 很小,只有 4.6G 的样子,在我 16g 显存的台式机上,速度相当快,快到有点恍惚,现在的本地模型这么强了吗?

本着判断本地模型唯一的标准就是让它做中英文翻译的原则,我让 llama3 翻译了几个英文句子,不意外,基本言不达意,完全不可用,然后就简单了,给它贴上不可用的标签,就在我的模型库里待着好了。

然而几天后事情来了个 180 度大反转,我发现大家的测试结果都非常的正向,直呼这应该是目前为止最强的本地运行大模型了,有人测试了 70b 的版本,甚至把这个版本跟 gpt4 相提并论。

这不科学呀,明明这玩意连英译中都搞不好,怎么可能评价这么高呢?

本着试试不要钱的态度,我随便问了它几个跟自动化相关的问题,结果确实让人惊讶。

首先 llama3 应该 95%的训练材料都是英文的( over 5% of the Llama 3 pretraining dataset consists of high-quality non-English data that covers over 30 languages),所以中文不好无可厚非,跟其交互的时候最好用英文提问。于是我用蹩脚的英文问了它第一个问题。

第一个问题

Open a browser using selenium and go to www.itest.info, then write a pytest assert to verify the page title should equal to 重定向科技, please give me the entile python code

用起来,在提交代码时实现自动化验证

不怕开发写 bug,就怕开发带私货,这应该是很多小伙伴都经历过的职场噩梦。目前看来一个比较好的方案就是在开发提交的时候进行一些自动化的检查,让夹带私货这件事情成本提高,从而减少这种情况的发生。

1. 我们可以在代码提交时进行哪些检查

  • Linters:Linters 是分析源代码以找到编程问题、语法错误和其他潜在问题的工具。流行的例子包括 pylint、flake8 和 pyflakes。
  • 代码格式化器:代码格式化器自动化根据预定义的样式约定格式化源代码的过程。示例包括 black、autopep8 和 yapf。
  • 自动化测试:自动化测试,如单元和集成测试,对于确保代码的功能性和质量至关重要。框架如 unittest、pytest 和 nose 允许以自动化方式编写和运行测试。
  • 静态代码分析:静态分析工具如 bandit(用于检测安全问题)、mypy(用于静态类型检查)和 prospector(集成了几个静态分析器)可以在不需要运行代码的情况下识别潜在问题。这些工具可以帮助找到安全漏洞、逻辑错误和可能的性能改进。

好的,那么……我们如何在我们的项目中应用这些测试/分析呢?别担心,这就是 Pre-commit 的用武之地。

2. Pre-commit

pre-commit 是一个用于管理和维护多语言 pre-commit 钩子的框架。我们称之为“钩子”的是一个脚本或一组命令,它们会自动执行。但是,我们什么时候要执行这些测试呢?

这个工具允许我们配置一组质量测试,在运行 git 命令(commit、push 等)之前自动执行。这在某种意义上非常强大,因为每次我们修改 git 仓库时,我们都可以确保添加的代码遵循我们设定的质量规则。

2.1 Pre-commit: 安装

要安装 pre-commit,首先执行以下命令行:

pip install pre-commit

2.2 Pre-commit: 仓库结构

为了配置 pre-commit,我们需要 2 个文件,这些文件必须位于根文件夹中。这些文件是.pre-commit-config.yaml 和 pyproject.toml。

project/
├── src/
├── .pre-commit-config.yaml
└── pyproject.toml

.pre-commit-config.yaml:必需。配置 QA 流水线。它包含要在执行 git 命令之前执行的每个钩子。 pyproject.toml:可选。配置文件,由打包工具以及其他工具(如 linters、类型检查器等)使用。它允许更具体的钩子配置。

2.3 Pre-commit: QA 流水线

现在,让我们看看如何修改这些文件。首先,我们将看到一个简单的.pre-commit-config.yaml 配置示例:

我把这个最好的test wiki全部翻译了一遍 💪

之前给大家分享过这个测试 wiki,https://ray.run/wiki

个人觉得还是非常全面好用的,不过因为是英文的,而且里面的内容不够直观,所以我直接翻译了一遍。最后的效果看这里,一共翻译了 224 个主题,好在是全程自动化,效率还是比较可观的。

具体做法

首先我写了个爬虫把所有的英文内容都爬了下来,这一步不难,毕竟熟练工,三下五除二就搞定了。然后就是调用openai或者是gemini 的 api做全文翻译,但是前者太贵,后者封我号,没办法,只能去打deepl的主意。

不过 deeplx 的翻译接口经常触发限频,没办法了只能另辟蹊径。

无奈之下只能在本地部署了个百川 2 7b模型,调用百川 2 的 api 进行翻译,当然了,翻译时候尝试了很多策略,浪费了大量时间,最终才出来一个相对可用的版本。过程中发现了一些问题

  • 有时候显存不足导致翻译结果为空
  • 如果 baichuan2 翻译不了,那么它会直接返回原文,就会出现中英文混杂的情况

不过简单来说,翻译的结果凑合可用,而且我在 wiki 的详情页也给出了英文原文,也方便大家对照。

爬虫和翻译完成之后就是在 itest 上加个 wiki 模块,把爬下的内容导入到数据库之后,调整一下样式就可以上线了。

总的来说翻译很麻烦,毕竟 openai 和 gemini 的 api 都对我关上了大门,不过好在中文模型可以一战,这才做成了这个勉强可用的版本。

未来计划

  • 有精力的话完善一下翻译
  • 增加 wiki 搜索功能

每个项目都能用上吧:使用Playwright进行图片比较测试

Playwright 做为新一代的浏览器 ui 自动化测试工具,有很多有意思的功能,其中截图对比就是其中一个。

本质上讲 playwright 的图片对比测试其实就是基准测试,其流程大致如下:

  • 先运行一遍测试用例,把代码里定义的需要截图的地方都截图,这些截图就是以后测试的基准了,后面所有的比较都是针对于这次截图进行的
  • 第一遍运行测试用例时候用例会报错,因为之前没有任何截图,不过没关系,再运行一次就可以了
  • 任何时候都可以再次运行用例,此时会拿本次运行时的截图跟第一次保存的截图做像素级的比较,一旦像素有差异用例就会失败,否则用例通过

下面简单介绍一下如何从零开始使用 playwright 进行截图对比测试。

安装 playwright

安装 playwright 之前,大家需要安装 nodejs,这一步可以自行搜索。

这里推荐大家使用Typescript进行代码的编写。主要是因为在入门阶段我们基本上不会接触到复杂的 typescript 语法结构,难度其实跟写 javascript 差不多,心智上的压力其实不算大。最重要的一点是,使用 typescript+vscode+playwright 这套微软组合(三者都是微软出品的),可以在编辑器里非常容易的得到稳定的代码提示,毕竟 ts 可以算得上是静态语言,对于初学者来说代码提示有时候是非常重要的。

因为国内的网络问题,整个安装过程需要用到淘宝 npm 源

打开命令行,敲入下面的命令。不知道怎么使用命令行的同学可以自行搜索弄清楚命令行是怎么回事。

npm install -D @playwright/test  --registry=https://registry.npmmirror.com
npm install -D typescript  --registry=https://registry.npmmirror.com
npx playwright install

mkdir -p tests
touch tests/itest.info.spec.ts

第 1 行是安装 playwright 及测试套件;第 2 行是安装 typescript,第 3 行是安装 playwright 需要调用的浏览器。最后两行则创建了 tests 文件夹并创建了名为itest.info.spec.ts的文件。

第一个用例

itest.info.spec.ts中输入下面的内容。

import { test, expect } from "@playwright/test";

test("Itest.info homepage", async ({ page }) => {
  await page.goto("http://www.itest.info");
  await expect(page).toHaveScreenshot();
});

上面代码的意思是跳转到重定向学院的首页www.itest.info,然后截图,如果截图跟之前保存的像素级别一致,那么用例通过,否则用例失败。