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

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

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

• 开发人员表示在自己的环境上是好的呀，这个不讨论，各种梗太多了
• 开发人员表示看不懂 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 积极的方面。另外，它已经了一些版本来支持多种编程语言，社区的反馈也非常积极。简而言之微软的钞能力和干爹属性使其相对其他开源项目来说可能会有更多的持续性。

本文非原创，翻译自https://qahiccupps.blogspot.com/2021/09/693-ok.html

“我们的测试用例中有多少是自动化的？”

这个问题有很多内容，特别是当它是监控测试状态的指标的时候。这也不是我第一次被问到。根据我的经验，当有人提出这个问题时，可能是因为（a）他们听说过它，（b）测试用例的数量是可数的，并且（c）他们的任务是提供一个管理层可以接受的数字，并且每月向大量不会看它的人发邮件做 ppt，然后阐述自动化“测试”的价值。

如果这听起来很愤世嫉俗……好吧，我想是的。

但是，并不意味着我对了解您的需求并试图帮助你获得可以你需求的东西不感兴趣。

我们能谈谈你的追求吗？为什么？

我们可以？太好了！

我会开始。我对这个问题的一些考量是：

• 自动化测试覆盖率似乎被认为是我们测试的一种衡量标准
• 这样的数字不会说明做过的测试的价值
• 测试用例的定义没有实际意义
• …而且，不管它们是什么，测试用例只是我们测试的一部分
• 有一个隐含的假设，即自动化程度越高越好
• …但自动化有其自身的风险
• …而且，无论自动化意味着什么，自动化测试用例只是我们测试自动化的一部分

如果我看看我们的测试方式，以及我们可能称之为测试用例的内容，我现在可以想到三种方式来回答您的问题：

1. 从我认为问题的意图来看，我们没有测试用例。我们所有正在进行的测试都是探索性测试，虽然我们可能会用自动化的方式记录测试结果，测试完成以后我们把现存的用例转换成自动化是没有意义的，我们标记为得分为 0%。
2. 出于练习的目的，我准备将回归测试用例集中的每个断言描述为一个测试用例。因为它们将是我们唯一的测试用例，而且它们都是自动化的。得分 100%！
3. 好的，我们在测试用例管理系统中有一些项目。这些是历史的发布验证记录，（大多数）测试团队以外的人在我们发布之前会进行这些检查。我更喜欢将它们视为检查点，但我很现实，并且知道我的一些同事只是想遵循步骤。相对于“自动化测试用例”的数量，它们很少，但如果我们将它们包括在我们的计算中，我们会将分数降低到 99%。

这些答案对我们中的任何一个来说似乎都不是很令人满意，是吗？

对我来说，这种指标充其量只涵盖了我们所做工作的一小部分，其背后的假设非常值得怀疑。对您而言，该指标的重要性不及某个合理的数字，该数字可以在 ppt 中用来量化测试的最终效果。对此我也有一些想法：

• 对我来说，测试是知识性的工作，因此很难用简单的数字来衡量
• 测试不是独立于其他产品开发活动而存在的
• 如果没有创建测试用例等人工产出物的话我们也可以完成良好的测试
• 没有经过对话交流和正当理由而强加的指标可能会受到怀疑
• 强加的指标可能会有被造假的风险
• 从产出物（bug 列表，用例设计）开始是本末倒置
• … 最好先问你想测量的指标是什么以及为什么

那么，例如，是否希望衡量客户对产品的满意度？是为了衡量测试的贡献吗？是否要查看时间花在了企业想要停止的活动上？是寻找瓶颈吗？或者是其他东西？如果我们同意使用某种指标，我们如何向测试人员保证他们没有受到不公正的评价，并且他们不应该为了使数字看更好而修饰或者歪曲他们的工作实践？

我们需要的不仅仅是花言巧语。想象一下，你被告知你的表现将根据你发送的电子邮件数量来衡量，你会如何反应？你会在讥讽它的同时但还是发送更多的电子邮件吗？您会发送电子邮件而不是进行丁丁或者是企业微信的沟通吗？您会关心对您、他人和企业的潜在不利影响吗？别人怎么能说服你采取不同的行为？最后，您是否真的希望以良好的意图研究合理的指标并根据结果采取行动？如果是这样，那么我将尽我所能帮助获得一些合理的东西，有明确的警告，公平的，透明的，承认其收集涉及的混乱，可以有效地从数据中得出我们有，这在商定的误差范围内，这反映了我们正在做的工作。如果没有，那么我会问你什么样的数字会更好的反映出实际的工作效果？我会简单地告诉你：让我们说 69.3%，好吗？

作者使用的英文没有那么通俗，加上翻译能力有限，所以最后可能需要简单的提炼一下文章的观点

• 自动化测试的覆盖率应该不能作为汇报测试效果的指标
• 测试的目的不是为了产出好看的数据或者指标
• 不合理的指标会造成不合理的结果而忽略了测试工作的实质