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

简陋的全自动化测试实践

最近在搜广推项目里做了一些小小的基于数据驱动的测试尝试。

因为项目的特殊性,大部分的测试场景其实相对类似,大体可以分为下面几步

  • 收集数据,整合成 1 个类似宽表的东西。比如在美团上给外卖投放一个关键字广告,那么投放之前需要收集这个商家的门店信息,比如门店名,经纬度;菜品信息,这个商家有哪些菜品,名字分别是什么;品牌信息,这个商家属于哪个品牌,品牌有哪些特殊属性;这些信息其实都分别在不同的业务表里,开发那边有离线数据流去打宽表,但是对于测试来说,如果不使用自动化的方式的话则需要用 sql 去查询,遇到有分表的情况则比较麻烦;
  • 构造数据。还是外卖投关键字广告的例子,因为召回的规则和其他一些业务规则,我们投的关键字最好有相关性,比如商家的店名叫做“永久炸鸡”,那么投“炸鸡”这个关键字可能会比较好。所以通过上一步构造好的数据,从里面自动筛选出一些相关数据并进行构造也是必要的;
  • 执行业务并进行断言。以搜索为例,收集数据阶段我们收集了很多的门店信息和菜品信息,那么使用门店名和菜品名进行搜索的话是需要有结果出来的,由于排序规则是算法团队去实现和测试的,所以我这边只需要数据可以搜出来就好,至于排序是什么样子,测试用例里面是不需要去关注的。

综合考虑了一下,我有一个大胆的想法。

上面这些步骤是不是都可以完全由自动化来实现?

使用爬虫进行数据收集

测试环境和体验环境我是有数据库权限的,所以可以通过 sql 来进行数据查询,逻辑其实很简单,从现有的数据里查一些拥有有效菜品的有效商家就好了,所以问题就简化成了使用脚本去连接数据库,然后进行一系列的连表查询就好了。不过因为菜品进行了分表,所以需要一些额外的逻辑去处理一下,不过总的来说还是不难的。

一切都很顺利,直到业务上线了以后,我发现我需要在线上去收集这些数据。因为安全策略的缘故,开发和测试都是没有线上数据库的访问权限的,因此我在非生产环境里通用的自动化脚本就成了一堆废纸。

后来有一天,我发现项目的本地测试人员都是在业务后台的各个功能模块里做数据的查询和准备,我突然有了使用爬虫去爬取数据的想法。

原理其实很简单,模拟业务后台的请求,通过后端暴露的 api 进行查询,最后想办法把数据组织好存储下来就行了。

后来用代码简单的实现了一下,效果其实还是不错的,而且完全不需要去顾虑分库分表问题,因为管理后台的 api 把这些都实现好了。这也让我开阔了一些思路,其实爬虫除了爬外部数据之外,还可以爬内部其他团队的数据,只要业务有管理后台,一切都好说。

使用 redis 进行数据存储

爬虫拉到数据之后,就需要对数据进行一些处理和存储。得益于业务 api 的杰出工作,之前查 sql 时候需要进行的数据处理现在就变得特别简单,因为业务逻辑都帮我都处理好了,下一步只需要把数据保存起来就好了。

因为数据需要反复使用和在多个场景下使用,所以存储对于我来说是必须的,但对于另一些场景,存储中间数据可能不是必选项。

因为对 redis 相对比较熟悉,所以我这里用 redis 实现了一些类似索引的东西。

  • 用 set 去存储一些实体的主键,比如门店 id 和菜品 id 之类;
  • 用 string 去存储详细信息,比如门店名,菜品的详细信息等;其中门店菜品之类的就直接用的 python dict 序列化成 json string,查询时候通过门店的 id 就可以直接拿到 json string,然后重新反序列化成 python 字典就好了

使用后端 api 进行数据创建

对于搜索来说组装好数据基本就可以测了,不过对于广告来说还需要进行广告的创建。这里我是直接调用 api 做创建,效率高而且不用去页面点。

使用 pytest 进行自动化测试

最后就是用例编写了,这里我直接用 pytest 实现了一些用例,贴一个具体例子。

10大流行的关于软件测试误解

软件测试实际上不像看上去那么容易。为了了解 web 产品测试可能包含的隐藏和意外,我们将分析与此类活动相关的十大最流行的误解。

误解 1:测试很容易

很多 IT 界人士(但不是测试人员)认为,软件测试并不难。它只是在一个图形界面中点击按钮而已。但实际上,一切并不那么简单。首先,QA 工程师必须全面研究一个产品,收集有关它的信息,提出并反驳假设,等等。 仅仅发现缺陷并不能使你成为一名测试人员。要成为一流的 QA 工程师,你必须能够理解软件和测试理论,提出正确的问题,并有效地找到相关信息。

误区 2:软件测试很无聊

有人可能认为测试人员的日常工作很枯燥–点击按钮,将设计与布局相比较。但如果这么简单,就不会有 QA 工程师了–所有这些工作都会由机器完成。 测试人员每天都在与业务和客户的实际需求互动。他们看的是软件内部的工作方式。而且,测试的类型相当多样–从可用性测试到性能测试和网络安全一应俱全,而且值得深入。

误区 3:QA 工程师想黑掉一切

事实上,测试人员不是黑掉程序,而是黑掉开发人员的幻觉。他们不想破坏任何东西;他们只是试图看看一切是如何工作的。有时测试结果与大家的期望完全不一致。

误区 4:完美主义是测试员工作成功的关键

事实上,情况恰恰相反。过度的完美主义只会阻碍正确的测试(就像在任何其他活动领域一样)。一个典型的完美主义者不能准确地意识到何时停止测试。而且,他也很难接受这样一个事实:永远不会有一个没有缺陷的完美的 web 产品。

误区 5:测试人员不需要了解软件的内部实现

实际上,一流的测试人员应该能够理解现代技术和分析软件结构。编程语言的基础知识有助于此。你不必创建你自己的程序代码,只要至少了解一切是如何设置和工作的基础知识。

误区 6:一切都有自动化,人工测试将消失

在任何情况下,你都不应该把 QA 的工作分为自动化和手动测试。自动化和手动测试人员都用他们的头脑工作,他们的工具并不那么重要。当然,你可以(也应该)使用先进的技术,但不要忘记,你不可能完全实现测试自动化,就像你不可能实现研究过程自动化。

误区 7:测试拖慢了开发过程

一些产品公司的员工相当认真地认为测试过程是一个简单的活动。而且他们确信,程序代码中要么没有缺陷,要么其数量微不足道。因此,当开发人员完成他们的前端工作时,他们认为实现 web 产品的大任务已经基本完成。但有时,在这个 “差不多 “的背后隐藏着大量的额外工作。软件测试和其他许多工作一样,是一个创造的过程。这完全取决于要完成的任务和要克服的风险。

误区 8:QA 工程师和开发人员总是缠斗在一起

互联网上有很多关于开发和测试在对方车轮上装上辐条的有趣故事。但在实践中,这并不那么相同。只有当开发部门认为测试人员在控制他们时才会出现问题,或者,当我们用发现的缺陷列表来影响开发部门的绩效时。

误区 9:测试人员对他们发现的每个 bug 都很兴奋

发现错误的兴奋感可能只发生在初级测试人员身上。 但随着时间的推移,它就会过去。熟练的员工会更加沮丧,因为这意味着他们将不得不做额外的工作。而且,这也推迟了任务的开始(部署网站,上架移动应用程序,等等)。质量保证的有效性并不取决于发现的错误的数量。他们工作的结果是一个经过质量测试的产品,一般来说,它能满足感兴趣的用户的需求。

误区 10:如果你写了好的代码,你就不需要测试人员了

这种观点在产品公司中非常普遍,那里盛行写自动测试的理念。但是,软件发展得越快,周围环境的变化越快,测试过程就越有意义。

而这个名单还可以继续下去。但最主要的是,除了测试人员本身,没有人可以成为这个领域的专家。相应地,只有 QA 工程师可以自信地说出什么是事实,什么又不是。

软件测试中7个令人震惊的真相

这是最近看到的一篇比较有意思的文章,原文在这里:https://medium.com/geekculture/seven-unspoken-truths-about-software-tests-4bcf0f720a04,简单的加工翻译了一下,其中()里的内容是我为了帮助大家理解夹带的私货,希望这篇文章会对大家有所启示。

1,当你是一个项目的的测试负责人的时候,你有没有过质问过项目成员为什么没测试出某个具体的 bug,或者因为某人没有测出 bug 而直接责备他?

2,当你提升了测试覆盖率的时候你有没有发现产品的 bug 数量其实没有发生变化?

3,你有没有在发布之前花费了大量的时间去进行测试却最终发现一无所获,而发布之后 bug 却不期而至?

4,开发可以测试他们自己的代码吗?

5,bug 真的是发现的越晚修复成本就越高吗?

6,你有没有过以不按套路出牌的方式来进行软件的测试,并称之为“探索性测试”?

7,你是否需要通过 QA 活动来提升产品质量?

真相 1:测试并不能找出所有的 bug

很不幸这是真的,没有任何一种测试方式可以保证找出所有的 bug。

一些测试活动跟直接上手点点点相比确实效率要低一些,所以我们可以不用那么关注测试的类型,相反我们要做的是选择合适的测试类型并综合使用,从而以最少的工作量打到较好的效果。(比如 ui 的自动化测试如果要做到非常复杂那么将花费相当大的开发和维护成本,但没有 ui 的自动化,每轮测试都靠人肉点来点去也不现实,所以比较合适的做法是一些稳定的核心路径可以用 ui 自动化去实现,平衡投入产出比,用较少的工作量达到效率最大化)

当有人抱怨为什么测试没有发现某些问题的时候麻烦提醒他们:测试确实没有办法保证一定会发现某些特定的缺陷。

我们会经常复盘测试的漏测情况,很不幸,这是落后的想法,这就像是在魔术揭秘了之后再马后炮的说其实这个戏法很简单,很容易被识破一样。事后做漏测复盘并不是一个有效的分析手段。

永远不要责备测试工程师,他们并没有写出 bug,相反,他们一直在努力找出开发过程中引入的缺陷。没有什么是完美的,测试同学在接受现实的同时也需要记住千万别立 flag,因为测试不可能发现所有的 bug。

真相 2:测试覆盖率与测试的效果几乎没有相关性

是的,你没有看错。我们已经有足够的科学证据表明,增加单元测试覆盖率不一定会提高我们测试套件发现 bug 的效率!也许是时候关注与测试相关的内容而不是正在测试的代码量了。(这里作者的原话是 We already have enough scientific evidence to say that increasing unit test coverage may not necessarily increase your test suite effectiveness in finding defects!直译过来就是单元覆盖率的提升并不会提升测试套件发现缺陷的效率,说实话,我觉得单元测试覆盖率跟测试中发现 bug 的效率本来就没有什么关系,覆盖率代表的是代码被测试的程度,而发现 bug 的效率指的是时间和产出的关系,发现 bug 的效率高并不代表着产品的质量就好,反之亦然。不过看下文引用资料时的描述,我们可以看到作者的举证基本上都透露了一个信息,那就是单元测试覆盖率与 bug 的数量之前没有太多的关联,换句话说就是并不是单元测试覆盖率越高,产品的质量就越好,因为产品的质量好一般意味着可被观察到的 bug 相对少,而 bug 又跟单元测试覆盖率无关。这里为了严谨,作者的引用我就不做翻译了。)

Selenium 4.9.0 发布

我们非常高兴地宣布支持 Java、.NET、Ruby、Python 和 Javascript 及 Grid 和 Internet Explorer Driver 的 Selenium 4.9.0 版本发布。所有内容的链接可以在我们的下载页面找到。

重点如下:

  • Chrome DevTools 支持现在是:v110、v111 和 v112(Firefox 仍然对所有版本使用 v85)
  • Java 绑定的 Maven BOM。
  • 通过 Selenium Grid 现在可以远程下载文件。
  • 首先, Firefox 开始逐步废除 CDP,并用双向实现 (BiDi implementation) 替代它。
  • InvalidSelectorException 现在继承自 WebDriverException 而不是 NoSuchElementException。
  • 发布了 Selenium Manager, 这个工具可以使用浏览器选项中设置的信息来获取正确的浏览器 driver。
  • 在 Selenium Grid 中可以设置子路径,以获得自定义的 Grid URL。
  • 在 Java 版本和 Grid 中完全移除 Json Wire Protocol 支持。

情感驱动测试

看到一篇非常有意思的女性测试从业者的技术分享,忍不住翻译了一下,角度非常感性,引人深思,测试的世界其实特别多元,也希望以后有机会能遇到各种有意思的观点。

原文地址: https://fishouthebox.medium.com/the-power-of-emotion-driven-testing-280a944d352b

昨晚,我在 Ministry of Testing 的 TestBash World 做了一个演讲,其中有一部分是关于情感的。其中有一部分我分享了 10 条情感路径,你可以用来指导你的测试。来源于 Gojko Adzi, David Evans 和 Tom Roden 的《改善我们测试的五十个快速想法》一书。

我把这个写在博客上是出于 Gwen Diagram 的一个建议,以文字的形式来分享这个内容会很有用。因此,我们开始吧。

  • 可怕的路径–对你的利益相关者来说,什么会真正烧毁你的房子?可能是品牌效应?安全风险?
  • 快乐的路径–每次都能通过的道路。
  • 愤怒的路径 - 试图让应用程序做出糟糕的反应。如验证错误、不良输入和逻辑区域。
  • 疏忽的路径 - 考虑需要测试的安全风险,如认证、授权、权限、数据保密性。
  • 尴尬的路径–会造成巨大尴尬的事情,如主页上的拼写错误。
  • 荒凉的路径–为应用程序或组件提供暗淡的东西。例如 nulls、blanks 或缺失的数据。
  • 遗忘之路–填满内存和 CPU 容量,使应用程序没有地方可以存储任何东西。看看它变得多么健忘,是否开始丢失数据,要么是已经存储的东西,要么是它正在持有的东西。
  • 犹豫不决的路径–打开和关闭一些东西,点击浏览器上的返回按钮等。
  • 贪婪的路径–选择一切,勾选每一个方框,选择每一个选项。
  • 紧张的路径–找到功能和组件的突破点。负载/性能测试的考虑。

by 乙醇:情绪相关的分类方式更加感性一些,相比于我们理性的测试用例和测试场景来说,这里没有对错之分,只要考虑的全面,用任何分类方式都是合理的。

2024年如何学习python

这几天 hack news 上比较热烈的讨论是这一套 python 教程:https://github.com/dabeaz-course/python-mastery。

作者是 Dabeaz, David Beazley 的别名,他是一位计算机科学家、教育家和研究员,拥有超过 35 年的经验。Dave 在 Python 社区中非常活跃,他创建了多个软件包,参加了会议演讲和教程,并且以《Python Distilled》(Addison-Wesley)、《Python Essential Reference》(Addison-Wesley)和《Python Cookbook》(O’Reilly Media)的作者而闻名。他通过提供各种高级计算机科学和编程课程来支持这些工作。

来头很大的,毕竟是《Python Cookbook》 的作者,所以专业性上是有背书的。

简单的把项目的 readme 文件翻译了一下,这个项目的核心学习理念就是手动操作,完成课程练习,多写代码总是有收获的。

简介

这是一门高级 Python 编程的练习驱动课程,经过十多年的企业培训实战验证数百次。由 David Beazley 撰写,他是《Python Cookbook, 3rd Edition》(O’Reilly)和《Python Distilled》(Addison-Wesley)的作者。课程采用了知识共享许可协议,无广告、无追踪、无弹窗、无新闻通讯和 AI。

目标受众

这门课程适合希望进一步提高 Python 编程水平,从编写简短脚本转向编写更复杂程序的 Python 程序员。课程主要关注常用库和框架中使用的编程技巧。主要目标是更好地理解 Python 语言本身,以便理解他人的代码,并将新学到的知识应用于自己的项目中。

先决条件

你已经掌握一些 Python 知识。这不是一门面向初学者的课程。如果你需要更多入门材料,你可以考虑参加 Practical Python Programming(https://dabeaz-course.github.io/practical-python)课程。

如何参加课程

首先,你应该将 GitHub 仓库 fork 或克隆到自己的机器上。

我们假设你在本地有一个合适的 Python 开发环境。这意味着你已经正确安装了 Python,有一个编辑器/集成开发环境和其他常用于 Python 开发的工具。由于课程使用了多个文件和模块导入,不推荐使用 Notebooks。

PythonMastery.pdf 文件包含了详细的演示幻灯片。课程练习和建议的时间安排都有清楚的标示。你应该将它放在身边(我建议你下载并在本地 PDF 阅读器中查看)。从这里开始吧!