很久之前给大家介绍过一款性能测试工具 Gatling。该工具有开源版本和企业版本，一般情况下我们只关注开源版本，毕竟企业版还是非常贵的。之前的开源版本中，测试脚本是用 Scala 写的，这门语言有点高阶，写起来不顺手，不过 2024 年的今天，情况有所改变。

Gatling 团队 5 月 23 日宣布，他们已为 Gatling 负载测试新增了 JavaScript 和 TypeScript SDK。这个新的 JavaScript SDK 是 npm 库中第一个企业级负载测试工具，使更多的开发者能够使用他们熟悉的编程语言进行 Gatling 负载测试。

自从 Gatling 推出以来，它一直是一个基于 Java 虚拟机（JVM）的开发工具，专注于负载测试。现在，开发者可以使用 Gatling JavaScript SDK 编写负载测试，并将测试编译在 JVM 上运行。这结合了脚本语言的灵活性和多线程等必要的性能特性。

最重要的是，使用 Gatling 不再局限于 Java 开发者。通过 npm 安装命令设置项目，熟悉的语法使 JavaScript 开发者可以轻松上手，同时拥有 Gatling 引擎的强大功能来运行负载测试。

为什么 Gatling 团队开发了 JavaScript 和 TypeScript SDK？

JavaScript 生态系统的惊人发展是不可否认的。最初，它只是一个前端脚本语言。随着 NodeJS 和 TypeScript 的出现，它现在成为构建现代 Web 应用程序和 API 的全栈、类型安全的语言。根据某些估计，JavaScript 是 98%财富 500 强企业技术栈的一部分。

Java 和 JavaScript 的历史

Java 和 JavaScript 的历史从一开始就紧密相连。两种语言都是在硅谷开发并于 1995 年发布的。JavaScript 最初被称为 Mocha，但 Netscape 将其改名为 JavaScript，以利用 Java 日益增长的人气。

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. 云测试

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

演示动画

具体使用

因为我没有 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函数

事情是这样的，前几天 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 配置示例：

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

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

具体做法

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

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

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

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

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

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

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

未来计划

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