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

如何优雅的测试cli应用

乙醇发布于 2024-08-03 收录于测试工具软件测试基础

之前写过一篇文章讨论如何去做 hello world 的单元测试，当时想到的一个方法是将 hello world 抽象成 1 个函数，这个函数返回 hello world 字符串，然后测试这个函数的返回值就好了，代码大概如下所示。

def hello_world():
    return "hello world"

前几天看到 rust cli 手册里的一个做法，比上面的方案更加的合理，这里忍不住分享一下。

更优雅的解决方案

测试功能有两种互补的方法:测试构建完整应用程序的小单元,这些称为"单元测试"。还有从"外部"测试最终应用程序,称为"黑盒测试"或"集成测试"。让我们从第一种开始。

为了弄清楚我们应该测试什么,让我们看看我们的程序功能是什么。主要来说,grrs 应该打印出与给定模式匹配的行。因此,让我们为此编写单元测试:我们要确保我们最重要的逻辑能正常工作,并且我们要以一种不依赖于周围任何设置代码(例如处理 CLI 参数)的方式来做到这一点。

回到我们对 grrs 的第一个实现,我们在 main 函数中添加了这段代码:

// ...
for line in content.lines() {
    if line.contains(&args.pattern) {
        println!("{}", line);
    }
}

遗憾的是,这不太容易测试。首先,它在 main 函数中,所以我们不能轻易调用它。这可以通过将这段代码移到一个函数中来轻松解决:

fn find_matches(content: &str, pattern: &str) {
    for line in content.lines() {
        if line.contains(pattern) {
            println!("{}", line);
        }
    }
}

现在我们可以在测试中调用这个函数,看看它的输出是什么:

没想到测试知识库竟然还真有人访问

乙醇发布于 2024-08-01 收录于测试工具软件测试基础

之前翻译了一版我认为是史上最全的测试 wiki，并把内容作为测试知识库放到了 itest.info，也就是重定向学院的网站上面。

一段时间过去了，前几天我偶然看了一下百度统计里的结果，发现这些 wiki 内容竟然已经有自然流量了，尽管翻译的效果不是很好，但有访问就是好事，可以重点去优先那些大家都在搜索的页面了。

我终于肝完了playwright的中文站

乙醇发布于 2024-07-18 收录于测试工具软件测试基础

经过两个星期的努力，我终于肝完了 playwright 中文站的主要内容。

站点地址 playwright.itest.info

后面我会把精力放到 playwright 的原创教程上去，预计也会在这两周发布吧。

这次技术选型的时候遇到了一些问题，肝到快结束才发现 zola 并不支持中文索引的能力，也就是说搜索功能就没办法实现了。

所以我搞了个全部教程的 archive 页面，大家需要搜索的话可以可以在全部教程页面进行搜索。

目前全站应该更新了 90 篇左右的资料，涉及到 playwright 的基础，框架设计，api 测试以及各种最佳实践，技术含量还是不错的。

在整理和翻译教程的过程中，我自己对 playwright 也有了比较深入的了解，对目前正在写的 playwright 教程的帮助很大，一些实现和配置目前基本上手到擒来，所以建站的过程也是一个非常好的学习的过程，付出和收获是对等的。

另外一些文章翻译的质量不是很高，比如有一篇关于 playwright 视觉测试的教程，英文内容本来是很好的，不过翻译过来之后就显得牛头不对马嘴，我自己理解起来都觉得费劲，所以下周我决定抽时间把这篇教程本地化一下，做一个高质量的视频教程。

因为写了很多爬虫的关系，站点的内容应该会持续更新下去的，后面有机会的话看能不能把之前 selenium 的内容也整理出来，做一个 selenium 的中文教程站，毕竟现在对静态网站的制作也是非常得心应手了。

最后

创作内容和维护内容不易，希望这个站点对大家会有所帮助。

我肝了一个playwright的教程及资讯站

乙醇发布于 2024-07-12 收录于测试工具软件测试基础

我花了一周的时间肝了个 playwright 的教程站，域名是 playwright.itest.info，事情的起因还要从 1 个油管视频说起。

我从那个视频上了解到，1 个做 AI 硬件的公司把 playwright 的自动化操作功能跟 AI 硬件结合了起来，融了 2000 万美金。

这让我大受震撼。

首先我没想到这么高大上的产品竟然用的是如此朴实无华的技术，更让我感到惊讶的是这家公司选择的工具是 playwright，而不是自动化届的老大哥 selenium。毕竟如果从纯技术的角度上考虑，selenium 是在原生浏览器上跑的，它的兼容性其实更好。

看来 playwright 确实是有它独到之处的。

这也让我陷入了思考，可能大部分人学习 ui 自动化工具的初衷不是测试，而是赚钱。

毫无疑问，在 2024 年的今天，playwright 是最有钱景的自动化测试工具，当然了，是金钱的钱。

不过我发现 playwright 的中文资料非常有限，所以我和虫师创建了这个站点，希望可以一直维护下去吧。

关于目前的进度

目前上线的版本有大概 24 篇左右的原创加翻译的资料。

我写了个爬虫去关注 playwright 的最新进展，也爬了 120 多篇非常优秀的英文教程。后面我会持续更新，这样一来资料会更加丰富一些。

除了翻译，我目前主要的精力是放在了原创教程上。在 playwright 可以找到的资料里，大部分的内容都是和自动化测试相关的，这些内容很好，不过我想如果我的教程把关注的重点放在爬虫和自动操作上，那么是不是受众会更广泛一些。

爬虫可以获取数据，在 AI 大行其道的今天，数据是各种大语言模型的基础。

自动化操作可以提升工作效率，在提效这个赛道上，永远是有商机可以挖掘的。

所以我开始肝一套 playwright 的中文教程，可以写的素材相当的丰富，既然要写很多，那么不如就写一本书吧。

目前书籍的进度大概是这样的，typescript 版本应该完成了有 50%了，等肝完 ts 的版本，再花点时间把 python 版本结束掉。

关于网站内容的质量，翻译的文章，我尽量翻译的通俗易通，然而水平毕竟有限，一些翻译的资料中会出现比较神奇的表达，希望大家可以多多指正。

原创的文章我会尽量做到深入浅出，让大家容易理解。

另外 playwright 的 api 变化很快，之前已经过期的内容我这边会人肉过滤掉，尽量保证呈现出的内容是最新的，一些翻译文章里我会加入自己的看法，明目张胆的夹带私货了。

结束掉文本资料的部分后，我会根据教程的内容录制一套 playwright 的视频教程，也会把重点放在爬虫和自动化操作上。

我怎么可能在每次迭代中测试所有内容？

乙醇发布于 2024-07-05 收录于测试工具软件测试基础

这是一个常见的经典问题，答案见仁见智，下面是一种比较普遍的观点。

这取决于你对“所有内容”的定义。

你可能指的是对整个应用程序进行全面的回归测试，包括所有功能、负面路径、边缘情况等。你说得对——除了一些非常小的产品外，你不可能在每次迭代中做所有这些事情。

但事实是：你不应该在每次迭代中进行这种全面的测试，你不应该觉得有必要这样做，也不应该被要求这样做。

迭代是敏捷软件开发中的概念——在软件长期开发并在最后一次性交付的模式中，“迭代”这个词没有意义。

迭代开发软件的全部意义在于引入小而有价值的变更并将其交付给用户。由于变更很小，产品的大部分与之前相同，因此不需要再次进行全面验证。假定它在过去已经被测试过了。

但也许变更的范围比看起来更广，或者它们在程序的其他部分引入了意想不到的后果。

这些都是合理的担忧。然而，开发人员引入的大多数变更并不影响整个系统，你不应该默认认为它们可能会这样。

值得补充的是，如果团队经常发现自己处于变更波及整个系统并需要全面测试的情况，那就是存在更深层次问题需要解决的迹象。

这可能意味着系统架构有问题，团队应该认真考虑偿还技术债务。 或者也许软件更像是一个原型、概念验证，而不是解决方案。在这种情况下，在团队更好地理解需求和利益相关者可以批准一种方法之前，可能不需要全面测试。许多测试人员在这种环境中工作时感到困难。他们将自己的角色视为可能存在缺陷的软件与用户之间的最后一道防线。他们对用户可能得到未经全面测试和验证的软件感到不安。

如果你是其中之一，你需要理解这种风险是经过计算的，也是重视短迭代和频繁交付的软件开发模式固有的。这些想法相互强化。产品没有经过全面测试，这意味着可能存在用户遇到前未被发现的错误、失误和问题。但正因为产品没有经过全面测试，它可以更快地发布。当团队了解到软件中的问题时，他们可以修复并进行新的发布。

如果这个论点不能说服你，我建议你尝试一下。承认你个人并不认同这种方法，但如果这是团队想做的，就不要阻止它。在几次发布中保留你的保留意见，看看会发生什么。你可能会发现产品的质量实际上并没有明显低于以前。如果结果显示质量确实下降了，那么你将有坚实的经验数据向团队展示。大多数人会同意这些结果是不理想的，需要某种改变。

最后，你不应该被要求在每次迭代中进行全面测试。

就我个人而言，我在这方面没有太多经验——我从未在试图这样做的团队中工作过。虽然我不能说在这种情况下什么方法可能有效，但我猜想首先要做的是理解这种要求背后的立场。也许需要教导利益相关者迭代的权衡；或者也许团队需要采用更谨慎的软件开发模式，以牺牲速度为代价。

我还没有提到自动化，它对以上所有观点都有贡献。作为测试人员，你的工作应该得到自动化的支持，至少每天运行一次，并提供关于产品状态的最新可靠信息。虽然自动化有限制，不能检查所有内容，但它可以检查一些行为。

你应该了解在你的项目中自动化能做什么和不能做什么，这样你就可以对哪些功能和路径不需要花费太多时间做出明智的决定。你应该对自动化结果有信心。当有人要求你反复执行特定测试时，你可以将其视为讨论花些时间改进自动化的机会。

在这篇文章的开头，我说过答案取决于“所有内容”的含义。它可能意味着全面测试，这是我到目前为止关注的重点。但它也可能意味着迭代期间发生变化的所有内容。

确实会发生开发人员完成了如此多的工作，以至于团队中的测试人员应接不暇的情况。不久前我就遇到过这种情况，对我们有效的方法是推动整个团队的所有权。大多数开发任务不需要专门的测试人员来测试或验证——它们只需要由没有编写代码的人来测试。在我们的案例中，我们所要做的就是在站会上表明问题，团队其他成员很快就想出了解决方案——一些开发人员应该停止接受新工作，而是专注于测试已经完成的内容。为每个任务明确列出完成的定义和验收标准肯定会有所帮助。

然而，处理这个问题的最好方法是主动避免它。总的来说，作为测试人员，尽量尽快测试变更。不要等到迭代结束。如果团队实践基于 PR 的工作流程，你可以尝试在代码合并之前测试创建的开发版本。让 CI 系统为每个 PR 构建工件会有所帮助，但另一种选择是在你自己的机器上设置构建环境。对于特别大的功能，在代码编写之前给开发人员反馈，并鼓励早期分享代码和想法。每日站会（如果有的话）是表达这种对话愿望的好机会。你也可以考虑主动联系开发人员并私下讨论。

可能会发生尽管使用了上述所有建议，测试人员在冲刺结束时仍然常常工作过载的情况。根据我的经验，这种情况更有可能发生在试图严格遵循僵化的 Scrum 结构的团队中，迭代周期为一到两周。由于工作在冲刺开始时分配，会有一段时间开发人员专注于他们的工作，而测试人员没有太多事情可做。这种动态在冲刺结束时会发生变化。在这种情况下，我强烈建议在回顾会议上提出这个问题。大多数人会同意这是一个长期不可持续的系统性问题。像往常一样，对于自组织团队来说，由团队自己想出解决方案。只要记住监控情况，保留数据，如果没有明显改善，就再次提出这个话题。

人人都要会的工具之--curl

乙醇发布于 2024-06-30 收录于测试工具软件测试基础

想象一下，你需要在 CI/CD 流水线中进行一些 API 调用，以进行身份验证、获取数据、发送简单请求或从网络 URI 下载文件。

你会选择哪些工具？

答案可能是使用像 Postman 这样的著名 API 测试工具。

不过一般情况下只需要用 curl 就够了。而且很多年之前 curl 就已经跨平台了，我记得 windows 上也是可以使用的。

所以我认为，写一篇关于 CURL 的文章是值得的。

我将这篇文章的范围缩小到 HTTP/HTTPS，因为写一篇关于 curl 全部功能的文章会花费好几天。你很快就会明白我为什么这么说。

curl 是做什么的？

Curl，全称为“Client URL”，是一种命令行工具，用于通过 URL 传输数据。curl 还用于汽车、电视机、路由器、打印机、音频设备、手机、平板电脑、医疗设备、机顶盒、电脑游戏、媒体播放器等。

Curl 是超过二百亿个软件应用程序中的互联网传输引擎。

几乎每个使用互联网的人每天都会使用 Curl。

你能想象它支持多少协议吗？

DICT、FILE、FTP、FTPS、GOPHER、GOPHERS、HTTP、HTTPS、IMAP、IMAPS、LDAP、LDAPS、MQTT、POP3、POP3S、RTMP、RTMPS、RTSP、SCP、SFTP、SMB、SMBS、SMTP、SMTPS、TELNET、TFTP、WS 和 WSS。curl 支持 TLS 证书、HTTP POST、HTTP PUT、FTP 上传、基于 HTTP 表单的上传、代理（SOCKS4、SOCKS5、HTTP 和 HTTPS）、HTTP/2、HTTP/3、cookie、用户+密码认证（Basic、Plain、Digest、CRAM-MD5、SCRAM-SHA、NTLM、Negotiate、Kerberos、Bearer tokens 和 AWS Sigv4）、文件传输恢复、代理隧道、HSTS、Alt-Svc、unix 域套接字、HTTP 压缩（gzip、brotli 和 zstd）、etags、并行传输、DNS-over-HTTPS，等等。

为什么选择 Curl？因为它简单、无处不在且灵活！

简单易用：Curl 就像 API 测试的瑞士军刀。它简单、直接，不需要编程博士学位就能使用。只需输入几个命令，按下回车键，瞧，你就像专业人士一样发送或测试 API！
随处可用：无论你是在 Mac、PC 还是 Linux 机器上，Curl 都能为你服务。不需要为不同平台使用不同的工具，Curl 与每个人都相处得很好。

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

如何优雅的测试cli应用

更优雅的解决方案

没想到测试知识库竟然还真有人访问

热门内容

测试规范(测试规格说明书)

故障注入测试

基准测试

背靠背测试