最新文章 更多
​​最近在领英(LinkedIn)上获悉,工作流自动化专家Zapier也加入了MCP的行列,并决定通过MCP的方式提供其所有的集成功能。感谢Angie的及时提醒。这将使AI智能体能够与这些集成功能进行交互,也为像我这样的人(略懂技术但非专业开发者)带来了很多实验机会,让我们能够更多地了解这项不断发展的技术。AngieJones在领英上的帖子,是我第一次听说ZapierMCP服务器。​​以下是我进行
2025-06-14/144 人阅读/0 人点赞

研习提示词工程(资源)已有时日,现结合实践经验整理出一套优化测试任务的提示词列表。以下是精心整理的提示词列表。请注意,这些是为获得详细输出和清晰结果而创建的通用提示词。可以根据项目背景和需求自由调整这些提示词。如果你想学习构建优秀提示词的技巧,请参考《面向测试人员的提示词清单》。📌重要说明:本词库将随实验进展持续更新优化,建议收藏页面获取最新版本。预祝您的测试智能化探索愉快!需求分析1、需求分析
2025-06-14/200 人阅读/0 人点赞

像Lovable.dev这样的AI工具正在改变应用开发模式,它们能通过自然语言提示快速生成原型,让每个人都能轻松创建功能性应用。这些工具的编码速度比传统开发人员快20倍,但也带来了在测试、调试和维护生成代码方面的独特挑战。当团队引入AI时,必须保持警惕。​​我们下面将探讨一些挑战,以及在测试和识别问题时可能遇到的常见场景。如果你希望将这些代码作为项目的基础模板,并在未来扩展产品,请不要在测试之前就
2025-06-14/165 人阅读/0 人点赞

​​学习这件事,似乎真的永无止境。近我还挺享受不断尝试各种新工具的过程,并努力在脑海中梳理它们的逻辑。从战略角度,我希望能清晰阐述AI如何支持质量工程领域,尤其是测试自动化方向。​​以下是我这周尝试的一些工具和体验:1.Anthropic’sClaude:计算机交互实验我重新回顾了最初用Claude进行计算器功能的实验(详见领英动态:链接),并尝试通过其Beta功能深入学习。尽管此前从未在本地使用
2025-06-14/143 人阅读/0 人点赞

在当今节奏飞快的软件开发世界中,系统性能不再是可选项,而是刚需。像JMeter、k6、Gatling和Locust这些工具早已是负载测试的行业标准,但每个工具都有不同的界面、配置方式和学习曲线。管理它们往往既复杂又耗时。现在,FeatherWandAgent解决了这一痛点。这是一个由人工智能驱动的工具包,将这四大性能测试工具整合进一个智能对话式界面,大大简化了测试流程。本文将带你深入了解Feath
2025-06-14/787 人阅读/0 人点赞

​​我相信博客文章应由人类撰写,所以这篇“不够完美”的技术随笔完全出自我手,而不是AI所为。另外,我不会接受任何新工具的评测请求,只会写我感兴趣的内容,请不要联系我!在上一篇文章中,我介绍了自己最近亲自尝试的一些AI工具。特别是Napkin.ai,这是一个我已经多次回访、节省时间的应用,未来我可能还会继续使用它。这周,我的注意力被一些其他工具吸引了:Cursor:一个以AI为核心的集成开发环境(I
2025-06-14/160 人阅读/0 人点赞

​​如今的人工智能,尤其是那些超级强大的模型,如GPT-4、Claude和Gemini,早已不仅仅是玩玩游戏、写写诗了。它们正快速进入社会中最关键的位置。想象一下:AI正在帮助医生诊断疾病,协助银行判断谁可以贷款,协助平台识别假新闻,参与企业招聘,甚至操控自动驾驶车辆。它带来的潜力巨大——超高速分析、一致性决策、甚至可能超越人类固有偏见。它可以在几秒内查阅成千上万份病历,或识别出人类可能忽视的金融
2025-06-14/268 人阅读/0 人点赞

为何测试驱动的设计自然带来更优代码​​在我多年的培训经验中,我发现了一个有趣的现象:当开发人员以测试性为设计考量时,他们往往能打造出更优质的代码架构,即便他们并未刻意遵循特定的设计模式。提及软件测试,许多开发人员常常流露出无奈之情,尤其是单元测试,似乎只是被迫完成的任务。然而,在培训众多工程师后,我观察到,当我们将测试性融入代码设计时,不仅测试工作变得轻松,代码本身的质量也会显著提升。这并非偶然巧
2025-06-14/129 人阅读/0 人点赞

​​在移动应用的质量保证(QA)自动化测试中,大多数测试人员主要关注验证功能——但应用的外观呢?视觉截图对比是一种强大但常被忽视的技术,可以发现不同设备和屏幕尺寸下的细微用户界面不一致问题。在本文中,我们将探讨为什么视觉对比对移动应用至关重要,如何使用Python、Appium和Pillow简单实现,以及分享现实案例中它如何发挥关键作用。为什么视觉对比对移动测试特别有价值(设备碎片化)移动应用测试
2025-06-14/149 人阅读/0 人点赞

测试糟糕应用的乐趣先来坦白一下:我喜欢测试糟糕的应用。在笨拙的用户界面中导航、点击无效的按钮、填写填写到一半就崩溃的表单,这些事情有一种奇怪的满足感。这就像是在玩一个以破坏一切为目标的电子游戏——只不过你还能因此获得报酬。但问题是:没有任何人工智能或自动化测试能够感受到测试糟糕应用时的沮丧。当按钮无效时,它们不会感到烦恼;当页面加载缓慢时,它们也不会烦躁不安。当应用在一小时内第五次崩溃时,它们不会
2025-06-14/134 人阅读/0 人点赞

推荐博客 更多

大家好,我是陈哥。当下,国产化替代稳步推进,不少企事业单位对工作中所用的到信创产品提出了更高的要求。硬件、操作系统和数据库等产品的国产化替代受到了一定的重视,但底层框架的国产化同样不容忽视。正如华为创始人任正非所说:“核心技术是买不来的,只有自主创新才能立于不败之地。”这与禅道的观点不谋而合,我们一直在不断探索和优化软件的架构。在《国产化替代是个伪命题?被误解多年的开源软件,如今怎么样了?

47° /470 人阅读/0 人点赞/0 条评论


《聊聊其他“Ops”(一)》中跟大家简单介绍了DevOps,以及与其概念相近的NoOps、DevSecOps和GitOps。“Ops家族”还包含其他形式,但归根结底,DevOps之所以更为流行,是因为其提供了改进工作流程的最全面的方法,因而被广泛应用。一、DevOpsvs.ITOps接下来,我们将更仔细地了解一下ITOps。许多开发人员将ITOps视为DevOps更传统的版本,但实际上它不止

100° /1003 人阅读/0 人点赞/0 条评论


大家好,我是陈哥,今天想和大家聊聊敏捷团队项目的准时交付~敏捷方法和硬性期限看似是两个不相容的概念。提到“敏捷”,我们通常会想到灵活性、适应性、迭代和持续改进,而“期限”往往与固定日期、最终性和时间压力有关。实际上,敏捷与期限并非完全对立,它们之间可以找到一个合适的平衡点,使得项目既能保持灵活性,又能遵守时间节点。正如知名敏捷教练玛丽·波彭迪克(MaryPoppendieck)所说:准时交

147° /1473 人阅读/0 人点赞/0 条评论


大家好,我是陈哥,今天想和大家聊聊Git合并冲突解决~背景前几天,我正好收到了一位读者的留言:又又又又遇到了Git合并冲突,解决冲突比写代码还费劲,突然想起SVN的好。该怎么避免Git冲突啊?我想,比如这样?在我看来,Git合并冲突是不可避免的。在本文,我想和大家简单分享一下遇到Git冲突该如何解决,希望对大家有所帮助。在此之前,我们先来了解一下Git的合并冲突是什么以及合并冲突的类型有哪

241° /2414 人阅读/295 人点赞/0 条评论


大家好,我是陈哥,今天聊聊禅道的代码提交规范~背景在《还不知道这个原则的程序员,要小心了》的文章中,我提到了禅道的代码提交规范。简单来说,我们将工具融入到禅道团队的日常代码提交过程中,利用工具对流程、行为进行规范和约束。接下来,我将从编码规范、测试规范等方面,和大家简单分享一下禅道团队的代码提交规范。为了方便大家了解和学习,大家可以发送【代码提交规范】,免费领取禅道团队的代码提交规范。

275° /2754 人阅读/293 人点赞/0 条评论


一位读者在看过我的《理解这八大优势,才算精通单元测试》后,问我:知道单元测试有好处,但实在没空写。看完文章后又想重新落实一下,有没有啥写好单元测试的技巧?这位读者绝对不是第一个和我抱怨单元测试的人。这很好理解,中国互联网公司太多太卷,想要抢夺市场就要推出不同功能,而这些压力一部分落在了程序员身上,拼命赶需求。单元测试这种费力不讨好的事情,自然而然就没有人做。就我多年的经验来看,写单元测试其实不

301° /3012 人阅读/293 人点赞/0 条评论


在准备将软件上线到生产环境之前需要进行测试。随着软件测试方式日趋成熟,软件开发团队的测试也在取代大量手动测试,逐渐实现自动化测试。通过自动化测试,开发团队可以在短短几分钟内就了解到软件是否存在问题,而不需要等待几天的时间。自动化测试大大地缩短了反馈周期,与敏捷开发、持续集成和DevOps文化密切相关。本文将分为上、下篇来探讨如何构建一个高响应、可靠并且可维护的测试组合,无论是针对微服务架构、移动

426° /4265 人阅读/292 人点赞/0 条评论


作为开发人员,我们应该遵守这样一句话:“质量不是来自检查,而是来自生产过程的改进。”——爱德华·戴明 “测试即代码。”太多的组织将任何未编码的东西视为一次性的。很明显,测试是必不可少的,但我们一次又一次地发现,团队将测试自动化和相关材料视为二等公民。测试是用户行为的文档,与产品组织产生的需求密不可分,并在虚拟层面与用于创建功能的代码相连。 如果它提供了价值,就应该对它进行版本化、维护、照顾和尊重,

450° /4502 人阅读/189 人点赞/0 条评论


技术性债务在DevOps到底意味着什么?从本质上讲,这是小的开发缺陷的积累,需要不断地返工。它可能由多种原因引起,例如快速交付新功能的压力,这可能会导致团队不得不牺牲代码的整洁和完善。但这些不完整的小代码,如经济上的债务一样,随着时间的推移会产生“利息”,在软件工程里就表现为修改的挑战或添加新功能的困难。 一、技术债务的原因技术债务的主要原因之一是组织的开发方和业务方之间的脱节。开发团队经常会感到

388° /3887 人阅读/270 人点赞/0 条评论


在《TDD、BDD、ATDD都是什么、有什么区别?(上)》一文中,探讨了探讨TDD、BDD和ATDD的概念。虽然TDD、BDD和ATDD都是软件开发中使用的测试方法,但它们在方法和重点上有所不同。TDD、BDD和ATDD之间的主要区别在于关注点、抽象层级和协作。1、关注点TDD侧重于测试代码并确保它满足需求。BDD关注软件的行为,并确保它满足业务需求。ATDD关注于验收标准,并确保软件满足业务

428° /4280 人阅读/184 人点赞/0 条评论