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

10分钟玩转playwright

playwright 是微软推出的一款自动化测试工具,据说开发小组的核心人员来自 google 的 puppeteer 团队,真是一出生就有了个好爹而且好爹的亲爹也是爹中的战斗机,这就让人非常期待了。

下载与安装

playwright 应该是使用 JavaScript 进行开发的,不过考虑到大部分的测试同学可能对 python 更为熟悉,这里的安装就以 python 版本为例。

在命令行中输入pip install pytest-playwright,等 playwright 安装成功之后再输入命令playwright install,这条命令的作用是安装测试所需要的各种浏览器支持,相比较 selenium 需要先安装浏览器再安装相应版本的 driver,playwright 的初始化工作就显得轻松了很多。

第一个用例

接下来按照官方文档里的例子我们来跑第一个 playwright 用例。

新建一个名为 test_my_app.py 的文件,然后把文档中的例子一字不差的进行拷贝粘贴。

import re
from playwright.sync_api import Page, expect

def test_homepage_has_Playwright_in_title_and_get_started_link_linking_to_the_intro_page(page: Page):
    page.goto("https://playwright.dev/")

    # Expect a title "to contain" a substring.
    expect(page).to_have_title(re.compile("Playwright"))

    # create a locator
    get_started = page.locator("text=Get Started")

    # Expect an attribute "to be strictly equal" to the value.
    expect(get_started).to_have_attribute("href", "/docs/intro")

    # Click the get started link.
    get_started.click()

    # Expects the URL to contain intro.
    expect(page).to_have_url(re.compile(".*intro"))

然后在命令行里输入 pytest,视网速而定,等待个 10 秒钟左右,就可以看运行结果了。

从吴亦凡事件学习安全测试

一般情况下我是不喜欢追热点蹭热度的,不过这两天公安机关警情通报之后,吴亦凡事件发生了各种逆转,这起全员恶人事件非常凑巧的契合了安全测试中的一个概念:也就是中间人攻击。我们在吃瓜之余可以简单了解一下中间人攻击的一些原理,通过例子去学习,印象自然会深刻一些。

什么是中间人攻击?

下面的定义来自维基百科。

中间人攻击(英语:Man-in-the-middle attack,缩写:MITM)在密码学计算机安全领域中是指攻击者与通讯的两端分别创建独立的联系,并交换其所收到的数据,使通讯的两端认为他们正在通过一个私密的连接与对方直接对话,但事实上整个会话都被攻击者完全控制。在中间人攻击中,攻击者可以拦截通讯双方的通话并插入新的内容。在许多情况下这是很简单的(例如,在一个未加密的Wi-Fi 无线接入点的接受范围内的中间人攻击者,可以将自己作为一个中间人插入这个网络)。

一个中间人攻击能成功的前提条件是攻击者能将自己伪装成每一个参与会话的终端,并且不被其他终端识破。中间人攻击是一个(缺乏)相互认证的攻击。大多数的加密协议都专门加入了一些特殊的认证方法以阻止中间人攻击。例如,SSL协议可以验证参与通讯的一方或双方使用的证书是否是由权威的受信任的数字证书认证机构颁发,并且能执行双向身份认证。

举个例子

下面的内容依然来自维基百科。

假设爱丽丝(Alice)希望与鲍伯(Bob)通信。同时,马洛里(Mallory)希望拦截窃会话以进行窃听并可能在某些时候传送给鲍伯一个虚假的消息。

首先,爱丽丝会向鲍伯索取他的公钥。如果 Bob 将他的公钥发送给 Alice,并且此时马洛里能够拦截到这个公钥,就可以实施中间人攻击。马洛里发送给爱丽丝一个伪造的消息,声称自己是鲍伯,并且附上了马洛里自己的公钥(而不是鲍伯的)。

爱丽丝收到公钥后相信这个公钥是鲍伯的,于是爱丽丝将她的消息用马洛里的公钥(爱丽丝以为是鲍伯的)加密,并将加密后的消息回给鲍伯。马洛里再次截获爱丽丝回给鲍伯的消息,并使用马洛里自己的私钥对消息进行解密,如果马洛里愿意,她也可以对消息进行修改,然后马洛里使用鲍伯原先发给爱丽丝的公钥对消息再次加密。当鲍伯收到新加密后的消息时,他会相信这是从爱丽丝那里发来的消息。

%E4%BB%8E%E5%90%B4%E4%BA%A6%E5%87%A1%E4%BA%8B%E4%BB%B6%E5%AD%A6%E4%B9%A0%E5%AE%89%E5%85%A8%E6%B5%8B%E8%AF%95%20f4fcfd1919004bae89ca78e6f0949ed6/Untitled.png

具体展开如下:

1.爱丽丝发送给鲍伯一条消息,却被马洛里截获:

爱丽丝“嗨,鲍伯,我是爱丽丝。给我你的公钥” –>  马洛里   鲍伯

2.马洛里将这条截获的消息转送给鲍伯;此时鲍伯并无法分辨这条消息是否从真的爱丽丝那里发来的:

爱丽丝   马洛里“嗨,鲍伯,我是爱丽丝。给我你的公钥” –>  鲍伯

3.鲍伯回应爱丽丝的消息,并附上了他的公钥:

爱丽丝   马洛里<– [鲍伯的公钥]–  鲍伯

Selenium 4.11 正式发布,支持chrome for testing

Selenium 4.11.0 正式发布了,先来看一下主要特性。

  • Chrome DevTools 支持的版本现在是:v113、v114 和 v115(Firefox 仍然对所有版本使用 v85)
  • 通过 Selenium Manager 支持 Chrome For Testing(CfT)
  • Selenium Manager 现在可以在 PATH 或配置的路径上定位 driver 的二进制文件,检查潜在的不兼容性,并提供更好的警告和错误信息。
  • 每晚都会推送 Ruby 和 Java 的构建版本。对其他语言的支持即将推出。
  • 在查找窗口句柄时忽略进程 ID 匹配 - Edge 上的 IE 模式。

这里最重要的更新是支持了 Chrome For Testing.

Chrome For Testing

这是 chrome 推出的专门针对测试场景使用的浏览器,为了解决下面一些痛点

  • chrome 的自动化更新。自动更新:对用户来说很方便,对开发者来说很痛苦,特别是测试同学,应为我们希望(a)在重复的测试运行中获得一致且可重复的结果,但如果浏览器可执行文件或二进制文件在两次运行之间决定自行更新,这会毁了一切。(b)我们想要固定一个特定的浏览器版本,并将该版本号添加到你的源代码仓库中,这样你就可以检出旧的提交和分支,并重新运行测试,以便使用那个时间点的浏览器二进制文件进行测试。基于上面两个原因,自动更新让人欲除之而后快。

  • 下载不到特定版本的 chrome 浏览器。除了自动更新之外,你可能也发现很难找到特定版本的 Chrome 二进制文件。谷歌故意不提供带有版本号的 Chrome 下载,因为用户不应该关心版本号,他们应该尽快更新到最新版本。这对用户来说很好,但对于需要在旧版本的 Chrome 中重现错误报告的开发人员来说很痛苦。这个问题的一个更具体的例子是当你想要使用 ChromeDriver 进行浏览器自动化时。你不仅需要以某种方式下载 Chrome 二进制文件,还需要一个相应版本的 ChromeDriver 二进制文件,以确保这两个二进制文件是兼容的。

在这样的背景下,chrome for testing 应运而生。官方的说法是

为了解决这些问题,Chrome for Testing 是 Chrome 的一个专用版本,针对测试用例进行了优化,不会自动更新,与 Chrome 发布流程集成,每个 Chrome 版本都可用。这个版本的二进制文件尽可能接近常规的 Chrome,同时不会对测试用例产生负面影响。

2022 年值得测试同学关注的技术趋势

国外有机构展望了 2022 年值得测试和开发同学关注的技术趋势,我在这里简单的给大家介绍一下,路漫漫其修远兮,大家一起求索吧。

混合组织成为常态

2022 年很明显,有些人不会返回办公室,至少不会一直返回办公室。病毒大流行开始时最大的挑战之一就是远程工作的弱点和新机遇。 人们远程工作面临的最大困难是深陷工作无法自拔。另一方面,人们承认他们在在线交流和协作方面遇到的困难较少。全球 CIO 调查显示,截至 2021 年 3 月,31% 的受访者预计将继续永久远程工作。据另一项调查显示,73%的雇员要求更灵活的工作选择。

对测试人员意味着什么

由于远程管理的困难降低使得原本对外包保持警惕的公司放弃了一些担忧。外包 QA 团队是内部团队的延伸。如果正确的设置流程,管理外包并不具有挑战性。更多的公司可能会开始使用外包的 QA 资源。

对通讯工具的需求不断增长

2020 年 3 月,在线会议软件的使用量猛增。Zoom 打破下载记录,股价上涨超过 100%,Google Hangouts 提供半年免费使用高级计划,Microsoft Teams 一个月赢得了 1200 万用户。这样的故事在 2021 年听起来并不令人震惊。我们已经加入了用户行列,成为统计数据的一部分。 组织仍在不断寻找可靠的通信和合作软件工具。远程办公不应限制工作活动。

反过来,科技公司的目标是增强他们的通信工具,加入更多功能,以提供更大的灵活性。 例如,Slack 推出了 Huddles——一种轻量级的音频优先通信功能,允许用户在不安排面对面或视频会议的情况下接听电话。此外,现在用户可以发送音频和视频消息,这对许多人来说也是一个很大的好处。

对测试人员意味着什么

各种规模和各行各业的公司都在使用通信工具,市场广阔,现有工具还有改进空间。随着新功能的添加,QA 部门将忙于进行功能、集成和回归测试。 喜欢使用定制解决方案的公司可能会决定升级其内部平台。例如,添加与 Zoom、Skype、Meet 或其他一些工具的集成将能够更快地访问视频通话功能。这些改进总是伴随着 API 和回归测试。

企业可能对更复杂的产品感兴趣,例如具有多客户端功能的内网视频平台、媒体资产管理等。在这种情况下,提供商应该准备好提供具有高级定制功能的产品。从头开始创建这样的平台需要仔细的市场分析,然后进行广泛而细致的测试。

吸引眼球,拉拢更多的用户

人们越来越意识到社交网络和品牌可以如何操控他们的思想。此外,2021 年的数据表明,用户对新奇产品保持兴奋的程度是有限的,比如 clubhouse。新媒体专家用多篇文章总结了这些事件,一些人在新社交网络的早期就预测到了 clubhouse 这样的结果,以及总结了该产品的失败原因。

  • 显然,创作者没有看到长期的潜力,逐渐停止为平台增值。
  • 实时性的功能(例如只能进行直播而无法进行广播录制)营造了一种怀旧/复古的氛围,然而大房间的访问受限和人数限制导致了激怒和两极分化。
  • 算法和用户体验都远非完美。Clubhouse 围绕最初的炒作发展,而不是专注于平台改进 。

令人惊讶的是,TikTok 仍然是派对之王,逐渐吸引了更多不同的受众。当然,Instagram 也不容忽视,其通过推出 Reels 做出了回应。无论是良好的实现还是熟悉的平台,用户似乎都对它感到满意。

对测试人员意味着什么

把用户牢牢的绑在平台上,对用户忠诚度甚至注意力的竞争变得更加激烈。 这意味着软件开发团队现在应该更加关注最终用户体验。当然,很大程度上决定开发新应用或功能的人并非技术专家。然而,软件开发人员是实现这些想法的人,而软件测试人员是接触结果的人。功能、UI 和兼容性测试将非常重要。 最后,在流程中涉及业务分析师的团队将更好地了解市场契合度、商业机会和规模。仔细的分析和精心编写的文档有助于避免逻辑空白和不适合市场/需求。

纠正两个常见的错误观念。端到端测试自动化是 简单而容易 还是 复杂而不可能

当前市场上各种端到端的测试工具层出不穷,工具市场很繁荣,但真正成功的项目实践却很少见。今天看到了一篇很有意思的文章,我愿称作者为典型的 selenium 原教旨主义者, 他的一些观点尽管看上去非常的 old school,不过总的来说是很有道理的,这里简单的分享一下他的观点。

他的这篇文章叫做 Correct two Common Misconceptions: End-to-End Test Automation is “Simple and Easy” or “Complex and Impossible”,翻译过来就是纠正两个常见的错误观念。端到端测试自动化是 “简单而容易 “还是 “复杂而不可能”, 原文的地址是https://zhiminzhan.medium.com/correct-two-common-misconceptions-end-to-end-test-automation-is-simple-and-easy-or-complex-and-ad559ade982a。

一切都开始于这样的一个观点:

事实:大多数测试自动化的尝试都失败了

“根据我在这个领域 17 年的经验,我同意图片中描述的主要概念,即大多数测试自动化的努力往往是失败的。” - 作者

端到端测试自动化是简单还是复杂?

答案取决于你问谁。在过去的 30 年里,测试自动化供应商,如惠普,一直在推销 “记录/回放 “和 “对象识别工具 “的概念。尽管这些方法已经被证明是无效的,但一些供应商仍然坚持使用这些方法。

在一个典型的软件团队中,众多的软件工程师和经理可能认为 “测试自动化 “是一个简单的任务,尽管没有人见过测试自动化的成功实施(也就是说,团队完全依靠手工测试)。作为证据,许多招聘广告要求申请人有 “创建测试自动化框架 “的经验,这似乎很荒谬。

所以,端到端的测试自动化可能并不像许多人想象的那样简单和容易。

“根据我的经验,优秀的开发人员不一定能成为优秀的测试人员,但优秀的测试人员(同时具有很强的设计能力)可以成为优秀的开发人员。这是一种心态和一种激情。…他们是黄金”。

  • 谷歌副总裁帕特里克-科普兰,在一次采访中(2010 年)

“95%的时间,95%的测试工程师会写出糟糕的 GUI 自动化,只是因为它是一件非常难做的事情。

  • 这篇来自微软测试大师 Alan Page 的采访(2015 年)

“测试比开发更难。如果你想有好的测试,你需要把你最好的人放在测试中”。

  • Gerald Weinberg,在一个播客中(2018 年)。

考虑到事实和上述知名专家的引言,似乎完成端到端的测试自动化是一个无法克服的挑战。

我的答案是 “它可以很简单,但往往是人为的错误使它变得不必要的困难。”

许多人做出了明显的错误的决定

我见过错误的决定,往往不止一个,在失败的测试自动化尝试中。

两周内录完selenium教程是一种什么样的体验?

2021 年其实立过 flag,但最终事情太多,没有完成既定的目标。2022 年初的时候,想到很久都没有做过教程和视频了,于是兴冲冲的录了一些 selenium 的全套教程,目录如下:

  • 环境搭建
  • 跑个脚本先
  • 第 1 个自动化用例
  • 前进和后退
  • 搞定被测项目
  • 使用 id 定位
  • 使用 name 定位
  • 使用 xpath 定位:定位王者 xpath
  • 使用 tag name 定位
  • 使用 class name 定位
  • 使用 css 选择器定位
  • 往文本框里输入内容
  • 执行 js 脚本
  • 滑动到页面的最底部
  • 各种表单元素的操作
  • 显示等待
  • page object
  • 常见问题答疑

做的不足的地方

因为录制的时间比较短,所以影片的编辑和准备其实是不够充分的,教程应该能看,不过节奏感不好,毕竟年纪大了,有时候会显得啰嗦了一些。

另外 selenium 的一些新特性其实并没有涉及,后面有时间可以重点补充一节。

亮点

当然,教程也是有一些亮点的。

  • 脉络基于官方文档,整体的思路还是清楚的;
  • 修正了一些官方文档的不足;
  • 使用本地文件进行演示,不依赖网络,脚本的稳定性还是比较高的

发布节奏

目前 b 站和微信公众号都在同步更新,每周更新 4-5 集,目前录了 18 集,应该 1 个月就能更新完吧。

后续计划

准备专门弄一个软件测试视频教程分享站点,代码还没写,不过大致的思路有了,啥时候不忙了就可以开工了。