学习这件事，似乎真的永无止境。近我还挺享受不断尝试各种新工具的过程，并努力在脑海中梳理它们的逻辑。从战略角度，我希望能清晰阐述AI如何支持质量工程领域，尤其是测试自动化方向。以下是我这周尝试的一些工具和体验：1.Anthropic’sClaude：计算机交互实验我重新回顾了最初用Claude进行计算器功能的实验（详见领英动态：链接），并尝试通过其Beta功能深入学习。尽管此前从未在本地使用
在当今节奏飞快的软件开发世界中，系统性能不再是可选项，而是刚需。像JMeter、k6、Gatling和Locust这些工具早已是负载测试的行业标准，但每个工具都有不同的界面、配置方式和学习曲线。管理它们往往既复杂又耗时。现在，FeatherWandAgent解决了这一痛点。这是一个由人工智能驱动的工具包，将这四大性能测试工具整合进一个智能对话式界面，大大简化了测试流程。本文将带你深入了解Feath
我相信博客文章应由人类撰写，所以这篇“不够完美”的技术随笔完全出自我手，而不是AI所为。另外，我不会接受任何新工具的评测请求，只会写我感兴趣的内容，请不要联系我！在上一篇文章中，我介绍了自己最近亲自尝试的一些AI工具。特别是Napkin.ai，这是一个我已经多次回访、节省时间的应用，未来我可能还会继续使用它。这周，我的注意力被一些其他工具吸引了：Cursor：一个以AI为核心的集成开发环境（I
如今的人工智能，尤其是那些超级强大的模型，如GPT-4、Claude和Gemini，早已不仅仅是玩玩游戏、写写诗了。它们正快速进入社会中最关键的位置。想象一下：AI正在帮助医生诊断疾病，协助银行判断谁可以贷款，协助平台识别假新闻，参与企业招聘，甚至操控自动驾驶车辆。它带来的潜力巨大——超高速分析、一致性决策、甚至可能超越人类固有偏见。它可以在几秒内查阅成千上万份病历，或识别出人类可能忽视的金融
为何测试驱动的设计自然带来更优代码在我多年的培训经验中，我发现了一个有趣的现象：当开发人员以测试性为设计考量时，他们往往能打造出更优质的代码架构，即便他们并未刻意遵循特定的设计模式。提及软件测试，许多开发人员常常流露出无奈之情，尤其是单元测试，似乎只是被迫完成的任务。然而，在培训众多工程师后，我观察到，当我们将测试性融入代码设计时，不仅测试工作变得轻松，代码本身的质量也会显著提升。这并非偶然巧
在移动应用的质量保证（QA）自动化测试中，大多数测试人员主要关注验证功能——但应用的外观呢？视觉截图对比是一种强大但常被忽视的技术，可以发现不同设备和屏幕尺寸下的细微用户界面不一致问题。在本文中，我们将探讨为什么视觉对比对移动应用至关重要，如何使用Python、Appium和Pillow简单实现，以及分享现实案例中它如何发挥关键作用。为什么视觉对比对移动测试特别有价值（设备碎片化）移动应用测试
测试糟糕应用的乐趣先来坦白一下：我喜欢测试糟糕的应用。在笨拙的用户界面中导航、点击无效的按钮、填写填写到一半就崩溃的表单，这些事情有一种奇怪的满足感。这就像是在玩一个以破坏一切为目标的电子游戏——只不过你还能因此获得报酬。但问题是：没有任何人工智能或自动化测试能够感受到测试糟糕应用时的沮丧。当按钮无效时，它们不会感到烦恼；当页面加载缓慢时，它们也不会烦躁不安。当应用在一小时内第五次崩溃时，它们不会
你是否曾对测试领导岗位的“真相”心生疑惑？你踏入质量保障（QA）领域，历经无尽的回归测试周期，或许曾在压力下崩溃数次。若命运垂青（或者你只是成为最后剩下的测试人员），突然间，你就戴上了闪亮的“测试工程师主管”帽子。听起来仿佛是职业的跃迁，宛如发现通往质量启蒙的隐秘通道，那里有高管级决策与战略愿景制定在等待着你。然而，残酷的现实是：你刚刚主动请缨，成为质量的“私人清洁工”，并且拥有独家清理他人实现灾
我们大家都见过测试金字塔，这一图表告诉我们，从比例上讲，我们应该减少大型测试的数量，转而增加小型测试。然而，我们看到许多团队仍然主要依赖大型的端到端测试，这是为什么呢？更重要的是，这是否是个问题？端到端测试是什么？端到端测试是我们用来检查整个代码库是否能够协同工作的一种方式，字面意思就是从一端到另一端。这些测试通常以用户旅程的形式编写，模拟最终用户可能在应用中执行的操作，一路锻炼不同的代码部分。
在性能测试的世界里，我们常常把大量精力放在工具、框架和执行策略上。然而，有一个基础真理凌驾于这一切之上：性能测试的有效性仅取决于其所依据的需求的质量。无论你的测试脚本多么稳健，测试工具多么先进，如果性能测试需求模糊、过时或与实际使用情况脱节，测试结果都无法反映现实。而在最糟糕的情况下，这会导致生产环境中的性能问题——加载时间慢、系统崩溃、收入损失以及用户不满。那么，什么样的性能测试需求才是良好
热门文章