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

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 阅读器中查看)。从这里开始吧!

没有QA就没有Bug

关于测试左移 shift left 的讨论已经持续了很长一段时间了,前几天刚好看到有外国友人亲身参与了这个过程,结果有点出人意料,所以翻译出来分享了一下。

在 2017 年,成为一名 QA 是一个有趣的时间。但不是搞笑哈哈,是有点点诡异了。每个人都想着测试左移(在合理范围内),但不是为了提高他们的质量,他们会以减少传统的质量保障人员的瓶颈的心态来做,那就是在迭代结束时,测试所有的东西。

我记得几年前,我是一个由 5 个开发人员组成的团队中唯一的 QA,我们没有大量的自动化测试,但左移的思维方式得到了应用,至少是部分应用。我在开发人员做需求时,尽早地帮助他们,这在迭代结束后会得到回报,测试阶段的时间是最少的。充其量,我们会在测试阶段发现一两个问题,并迅速修复它们(或假设该问题到下一个版本)。

公司内部的一个新项目已经开始了,他们想在一开始就应用左移的思维方式,但他们不需要 QA。所有的工作都可以通过自动化测试完成,开发人员将完全承担和拥有这些测试。作为一个 QA 人员,我很好奇,我想看看他们是怎么做的,他们是怎么涵盖这个用例的,或者其他用例的,我想学习并帮助他们。但是我被推到了一边,因为自动化才是王道,不需要 “手动 QA”。

当他们在几个月后找到我的时候,我遇到了 “告诉你 “的时刻,他们在生产中出现了大量的问题。那是一个混乱的局面。这时他们意识到,即使他们写了大量的测试,他们也没有考虑到他们的测试策略。解决方案是在团队中加入一个 “手动 QA”,来处理应用程序的问题,防止生产中出现更多的错误。

快到今天,我意识到他们已经非常接近了。他们拥有自动化测试策略。团队中的任何新开发人员都经历了严格的代码覆盖率、配对编程和细致的提交代码审核过程。他们唯一缺少的是一个好的测试策略,按照测试金字塔的描述进行工作(我知道你们中的一些人鄙视这个,但有时,它真的可以帮助团队分类并专注于正确的事情!),以及在用户体验上多想一点。

那么,你的 QA 团队成员可以在左移的转型或项目中扮演什么角色呢?

  • 在开始 “左移 “时,文档被证明是有用的。通过确保针对现有功能和新功能中最关键的点,它可以更容易地从传统的方法过渡。通常把重点放在用户的关键功能和你的应用程序中常见的脆弱点上。
  • 参加研发的启动会议。帮助提前考虑潜在的问题,用例子来引导这些会议是最好的做法。就我个人而言,我更喜欢在开发人员开始一个需求时以非正式的方式召开这些会议,但你也可以把这些会议变成一个定期会议,类似于你的 scrum 计划和复盘会议。这种做法也被称为 3 amigos(读起来不错)。
  • 学会阅读代码,看看 PR 评论,学习自动化,你的 QA 团队成员越是多才多艺,开发人员就越有信心作为一个团队来交付他们的功能,而不是依赖一个 QA 警察。

如果你的团队没有一个已经在职的 QA,你的团队已经可以开始应用同样的准则。停下来,呼吸,花 15 分钟思考可能的测试用例。不要在功能上走得太深,但思考所有可能的用户行为有很大的帮助。把它们写下来 👏。这将帮助你防止很多 “我没有想到的 “情况。

虽然这不是一个完美的指南,但这是很好的第一步,我称之为 “在 3 天周末前的星期五下午 4 点部署的信心”。但这是另一个故事了。