看到一篇关于单元测试最佳实践的文章，简单翻译一下，很多都说到了点子上，不能赞同更多。

单元测试是对软件应用程序中各个单元或组件进行的软件测试。单元测试旨在验证每个软件单元的执行是否符合设计预期。单元测试可以确保代码质量,提高可维护性,方便重构,并提高开发速度。

当谈到最佳实践时,这里有一些应该遵循的:

1. 为每个缺陷编写新测试:当你遇到一个缺陷时,编写一个暴露该缺陷的测试。这也称为回归测试。

2. 保持测试的小而聚焦:一个单元测试应该限制在一个独立的函数或方法中。这使得当测试失败时更容易识别和修复问题。

3. 隔离你的测试:确保每个测试都是相互独立的。这允许你单独运行每个测试,并以任意顺序运行。(划重点了)

4. 按测试类型组织测试:你可以根据它们测试的对象类型或测试类型来组织测试。这使得查找和运行相关测试更容易。

5. 每次测试一条代码路径:每个测试应该验证方法中的一条明确的代码路径。这使得理解被测试的内容以及测试可能失败的原因更容易。

6. 避免在测试中加入逻辑:当你在测试中加入逻辑时,你有引入测试缺陷的风险。保持测试的简单。(重点)

7. 避免在被测试的类中使用静态方法:静态方法不能在子类中重写,这使得它们难以测试。避免在你要测试的类中使用静态方法。

8. 避免测试实现细节:你的测试应该关注代码的行为,而不是它的实现。如果测试实现细节,当你的代码行为保持不变时,测试仍可能中断。

9. 首先为对应用影响最大的方法编写测试:将测试工作集中在对应用影响最大的方法上。这通常包括包含复杂逻辑或与外部资源交互的方法。

10. 使用 AAA 模式:准备测试数据和测试环境(Arrange)、执行(Act)、断言(Assert)是编写单元测试的典型模式。单元测试方法的安排部分初始化对象和传递给被测试方法的数据值。执行部分调用带有 Arrange 参数的被测试方法。断言部分验证被测试方法的行为符合预期。(划重点)

原文如下:

𝗨𝗻𝗶𝘁 𝗧𝗲𝘀𝘁𝗶𝗻𝗴 𝗕𝗲𝘀𝘁 𝗣𝗿𝗮𝗰𝘁𝗶𝗰𝗲𝘀

Unit tests are software testing where individual units or components of a software application are tested. Unit testing aims to validate that each software unit performs as designed. Unit tests ensure code quality, and ease of maintenance, facilitates refactoring, and increase development speed.

When we talk about best practices, here is a list of that one should follow:

测试同学在很多时候都是在沟通问题，复现问题和定位问题。

记得多年前刚入行的时候，我一直对复现问题不够重视，觉得自己是测试人员，主营业务应该是测试，复现问题应该是解决问题的人做的事情。后来尽管岗位分工越来越细，但是测试同学做的事情并没有越来越聚焦，反而整体的工作范围更加的宽泛，其实说白了就是专业性上有提升，但是专注度上的改善其实并不明显。

复现问题其实很多时候是测试人员的痛点，比如我们在测试过程中发现了一个问题，并发给了开发同学，然而，你可能会有下面的经历

• 开发人员表示在自己的环境上是好的呀，这个不讨论，各种梗太多了
• 开发人员表示看不懂 bug 上的描述，这点可以用截图和录屏来解决
• 开发人员表示你帮我复现一下吧，这时候就比较痛苦了，因为复现本质上就是重复

测试的时候一再的重复自己是痛苦且低效的，如果问题是用户上报的，那么除去重复之外，还要加上阅读理解的过程，阅读用户的操作过程，理解他们做了些什么，以及猜测系统或者产品的表现。稍微归纳一下，发现复现基本上都是在做下面的一些事情

1. 创建数据，可以是从 app 上，也可以是从网页上，甚至可以在 admin 后台去创建
2. 收集或查询一些周边数据，比如数据库或者是被测的系统和产品上
3. 结合数据和实际表现去判断产品或者系统的表现是不是正常

所以除了第 3 步之外，前 2 步都是非常适合用自动化脚本的方式去实现的。我就用 python 写了很多的辅助脚本去帮助我重现问题，下面是我的一些经验

用直接调用 api 的方式去创建/查询数据

因为现在大部分产品的管理端都是前后端分离的，所以管理端是可能有纯后台的 api 的；以及移动端 app 都是有 api 的，调用 api 创建各种测试数据其实是可以实现的，只要做好鉴权工作，调 api 去创建和查询的实现成本和维护成本都是可控的。

之前我是用直连数据库的方案去做查询和创建，不过后面逐渐废弃了这种做法，这是因为

• 数据库表结构可能会发生变化，从而导致脚本执行失败，从而降低了脚本执行的稳定性以及提高了维护成本
• 脚本需要去关注分库分表的实现，增加了实现难度，降低了长期的可维护性
• 因为安全审计的关系，数据库的连接和密码会周期性的发生变化，增加了维护成本
• 我们生产环境的数据库只有生产环境的机器才能访问，本地办公网没有办法访问，所以做线上问题复现的时候，直接连数据库就会显得有心无力了
• 直接写数据库可能会绕过后端的数据校验，可能会写入脏数据

所以在做自动化工具的时候一般不推荐直接连数据库进行数据的生成和查询

用爬虫的方式去查询周边数据

很多时候我们需要获取一些周边团队的数据，有时候我们可以通过 api 调用来获取，但也会有获取不到的情况；另外有些祖传的系统可能前后端不分离，后端并没有提供 api 接口，这种情况下我一般用爬虫来做数据的收集。

爬虫的方式有很多好处，但对于一些系统来说可能存在开发难度高，运行效率低的情况，所以如果有更好的方式可以方便的拿到数据的话，爬虫的优先级可以低一点。

用缓存去提高执行效率

收集数据，特别是收集多个页面或者是多个系统的数据往往是比较慢的，这时候可以用 redis 等缓存数据库来保存一下结果，这样可以加速代码的执行。这里不推荐用数据去做，因为收集数据是一项相对来说比较高频且随意的工作，数据结构一般不会特别稳定，如果表结构频繁变更的话，那么开发和维护的成本都非常高。我一般是把数据直接序列化成 json 字符串，然后丢到 redis 的 sting 对象里，简单方便。

另外我的测试数据创建过程一半也是用爬虫加 api 的方式，缓存下来的数据可以帮助我进行更加复杂的测试数据创建工作。

编写 cli 工具，让测试过程更加工程化

有一段时间我积累了相当多的 python 脚本，在实际工作中调用脚本就成了一门学问，一些脚本要这样调，另一些可能要在其他脚本调用后才能调用，记忆的成本很高，文档化的价值又基本没有，后来我发现使用 cli 工具去整合脚本调用，写好每个命令的 help message，这样文档和调用编排都有了。

之前跟大家分享后 chrome 上原生的录制回放功能，今天看到了一款最新的的录制回放工具 jesteer，于是第一时间来了解和试用一下。

主要功能

• 不用写代码，直接可以录制和回放
• 可以录制基本的页面交互
• 自动创建基于 Puppeteer 的脚本
• 回放时的快照检查功能
• 简单舒适的 web ui

安装

jesteer 是一款 chrome 插件，直接去 chrome 商店里所有 jesteer 点击安装既可。

界面

jesterr 的界面很简单，就 3 个按钮

• Record：开始录制
• Take a snapshot：dom 高亮
• Copy to clipboard

简单上手使用

• 点击 Record 开始录制
• 录制过程中点击 Take a snapshot 进行断言
• 点击 Stop Recording 停止录制
• 点击 Copy to clipboard 拷贝生成的代码到剪切板

这几步还是非常简单的，后来我遇到了一个问题，怎么进行用例的回放呢？之前 chrome 自带的 Recorder 是可以录制完成后直接回放的，而 jesteer 则找不到回放按钮。折腾一小会后我终于找到了答案。

把生成的代码粘贴到测试项目中

为了可以运行生成的代码，我决定新建一个 nodejs 项目来进行尝试。

mkdir jesteer_example
cd jesteer_example
npm init
npm install --save-dev jest
npm install --save-dev puppteer
touch example.test.js

修改 package.json

看到一篇文章Is Selenium Dead? Explore the State of Selenium Automation in 2023 !，里面比较详细的描述了 2023 年 selenium 的现状以及竞品分析，感觉还是非常全面的，简单的翻译了一下，供大家参考。

技术世界中，工具和技术以飞快的速度发展，软件测试也不例外。在过去的几年里，涌现出了许多新的测试工具（如 Cypress、Playwright 和 Robot Framework 等），每种工具都有其独特的特性和方法来解决同一个问题：测试自动化。

然而，在测试自动化领域，多年来只有一个框架一直是基石：Selenium。它已经存在并开源了 15 年以上，直到最近，一场激烈的争论浮出水面：Selenium 是否已死？是否存在更好的替代品？它是否在面对新的测试工具和方法时失去了竞争力？

在这篇文章中，我将从自己的角度深入探讨 Selenium 在 2023 年的现状，探索其相对于竞争对手的优势和劣势，以及在快速变化的外部世界中中面临的挑战。

前提条件：

• 成为一名 QA 爱好者 😉

Selenium 的崛起和统治

Selenium 最初由 Jason Huggins 于 2004 年开发，作为一个基于 JavaScript 的自动化工具（名为 JavaScriptTestRunner），用于自动化内部应用程序的测试，该应用程序需要耗费大量的手工工作。多年来，随着他意识到该程序的潜力，它演变成了 Selenium-core 并开源。然后，通过多位贡献者实现了许多功能，例如：

• Selenium IDE：它支持通过录制和回放功能运行自动化测试
• Selenium Grid：一种强大的功能，可以执行并行测试，以将测试执行时间减少到最低限度
• Selenium 2：这是 Selenium 1 和 Webdriver 的合并，形成了我们今天所知道的工具。

自 Selenium 2 以来，它获得了很大的关注度，其受欢迎程度迅速上升，这可以归因于几个关键因素，这些因素改变了游戏规则：

• 开源：Selenium 是开源的，这意味着它可以免费使用，并有一个庞大的社区可以帮助您解决遇到的任何问题，并有许多贡献者和用户。这导致了持续的改进和更新。
• 跨浏览器兼容性：Selenium 支持各种网络浏览器，如 Chrome、Firefox、Safari、Edge 和 Internet Explorer，使其成为网络应用程序测试的通用选择。
• 多种编程语言：Selenium 兼容多种编程语言，包括 Java、Python、C#、Ruby、JavaScript 和最近的 Kotlin。测试自动化工程师可以选择他们喜欢的语言进行测试自动化。
• 广泛采用：许多组织和公司已将 Selenium 纳入其测试自动化套件中，这导致了大量的资源、教程和支持在线可用。（现在，我自己也为我的雇主的公司管理着一个 Selenium 套件 😉）
• 与测试框架的集成：Selenium 可以与流行的测试框架如 TestNG 和 Cucumber 集成，从而实现结构化的测试用例管理和报告。
• 并行性：Selenium 使用 Selenium Grid 支持强大的测试用例并行性，这大大减少了执行时间。

Selenium 在 2023 年的现状：已死还是未死？

www.freecodecamp.org是我密切关注的免费学习编程的网站，里面不定期会有高质量且最新的各种编程以及技术教程，今天偶然在freecodecap看到一篇讲python进行日常自动化的帖子，原文在这里https://www.freecodecamp.org/news/python-automation-scripts/，觉得有点意思，顺便就把里面的内容拿出来分享和评论一下。

自动校对

# Python Proofreading
# pip install lmproof
import lmproof
def proofread(text):
    proofread = lmproof.load("en")
    correction = proofread.proofread(text)
    print("Original: {}".format(text))
    print("Correction: {}".format(correction))

proofread("Your Text")

说实话，似乎用不上。

自动随机播放音乐

import random, os
music_dir = 'E:\\music diretory'
songs = os.listdir(music_dir)

song = random.randint(0,len(songs))

# Prints The Song Name
print(songs[song])

os.startfile(os.path.join(music_dir, songs[0]))

思路很好，不过似乎也用不上。

pdf 转 csv

import tabula

filename = input("Enter File Path: ")
df = tabula.read_pdf(filename, encoding='utf-8', spreadsheet=True, pages='1')

df.to_csv('output.csv')

需要pip install tabula，在做数据处理的时候就很有用了，因为有些站点的收据下载的格式默认就是 pdf 的。

自动压缩照片

import PIL
from PIL import Image
from tkinter.filedialog import *

fl=askopenfilenames()
img = Image.open(fl[0])
img.save("output.jpg", "JPEG", optimize = True, quality = 10)

需要安装 PIL(Python Imaging Library) ，在归档的时候应该有些用处。

playwright 是微软推出的一款 e2e（端到端）测试工具，支持多种语言及浏览器，那么它会成为下一个 selenium 吗？前几天看到外国的一篇文章发表了其观点，这里翻译了一下并夹杂了一点点的私货，希望可以对大家所有帮助。

selenium 作为浏览器自动化项目来说是非常成功的存在。Selenium 现在已经被下载了几百万次，并继续在全球范围内被广泛接受和使用。

Selenium 的成功的原因

1. Selenium 是开源的，支持多种（如 Java、C#、Js、Python、Ruby、Perl 等），支持所有的浏览器（chrome、firefox、edge、ie、safari、opera 等），可以在多种操作系统（Windows、MAC、Linux）上运行。
2. Selenium 功能强大–它可以做 web 测试，也能做跨浏览器兼容性测试。另外 selenium 设计的初衷是浏览器的自动化，所以除了用作测试之外，selenium 还在 web 自动化操作领域有所建树。
3. Selenium 有一个庞大的用户社区，可以帮助你快速入门。
4. 与其他开源工具相比，Selenium 非常稳定，它的实现甚至成了标准的 w3c 协议。
5. 最后，Selenium 社区是充满活力的，定期举行许多活动和研讨会，你可以与志同道合的人讨论最新的工具和技术。

playwright 会成为下一个 selenium 吗？

考虑到现代 Web 应用自动化，Selenium WebDriver 似乎是最受欢迎的工具之一，然而，像 Playwright、Puppeteer、Cypress 这样的替代工具正在出现，并争取在一段长时间之后能对其进行超越。

Playwright 是一个 JavaScript 框架，支持在前端实现 Web 应用程序的自动化。它在后端使用 Node.js，就像 Puppeteer 那样。它扩展了该框架，为用户提供了编写端到端测试或隔离测试应用程序特定部分所需的所有工具。

支持使用包括 Java、Js、C#、Python 在内的语言编写测试用例，并像 Selenium WebDriver 一样在任何浏览器和任何操作系统上运行。它是开源的，很容易使用，支持单兵作战和团队协同。

在 UI 自动化领域，Playwright 能够成为下一个 Selenium 的主要原因有以下七个方面。

• Playwright 得到了微软的支持，其作者来自 Puppeteer（谷歌）团队，因此 playwright 可以吸收 Puppeteer 积极的方面。另外，它已经了一些版本来支持多种编程语言，社区的反馈也非常积极。简而言之微软的钞能力和干爹属性使其相对其他开源项目来说可能会有更多的持续性。