在AI、云原生、区块链等技术狂潮下，软件系统复杂度指数级攀升。如何让测试不再成为研发流程的“短板”？如何用智能化手段应对千亿级数据校验？如何保障分布式架构下的系统稳定性？种种难题都围绕着软件测试人，时刻刺激他们的神经……直到《现代软件测试技术权威指南》出现。这是一本由20+顶尖专家历时多年打磨的实战宝典，系统覆盖从经典方法论到前沿技术的全场景测试方案，助力测试人成为质量保障领域的“破局者”！3大
在今年3月写过一篇文章：又一次被震惊：从生成和细化需求到应用各种方法设计测试用例，展示了chatGPT生成测试用例，而且可以用不同的方法生成测试用例，在我们的引导下它还能补充测试用例、完善测试用例。半年之后，chatGPT的能力强大许多，而且是多模态的，如下面例子所表现，所以我们更能借助LLM完成从生成验收标准、生成测试计划、生成测试用例、生成测试脚本到生成测试报告等全测试周期所需的交付件。（基于
在本地测试微服务架构很困难。在Nylas，我们使用Minikube和Tilt创建了一个本地开发环境。让我们来看看我们如何在Nylas中启用微服务的本地测试。本地测试微服务架构面临的问题微服务架构是一种很好的设计实践，但在本地测试它非常困难。让我们来看看面临哪些问题。一个简单的微服务架构如下所示：您可以在该架构中看到相关组件：●处理来自客户端的API请求的API服务。●充当消息代理的消息队列。●一些
在团队活动中，反馈是一项非常重要的活动，只有收到反馈，大家才知道事情做到哪里了，做得怎么样了。在敏捷软件开发的核心价值观中，反馈也是核心之一。01反馈指的是：在信息的传播中，接受者对传播者发出信息的反映。反馈得很重要一个属性就是时间滞延。在测试活动中，笔者经常会团队的测试人员一个问题：开发提交了一段代码后，多久能收到质量反馈？是按天？按小时？还是按分钟？再往前一步，产品提供了一个Story，多久能
不懂变异测试，你好意思说自己是测试工程师，今天让我（一个即将秃头的工程师）带你深入浅出理解变异测试的方方面面。从测试覆盖率的局限性谈起很多时候我们会用单元测试执行后的代码覆盖率来衡量测试的充分性和完整性，问题是有了很多测试用例，同时又有很高的白盒覆盖率，是否代码质量真的就高枕无忧了吗？答案显然不是。来看个《软件研发效能提升之美》书里的例子就懂了。比如下面的代码，测试执行后的代码覆盖率可以达到100
话接上回(我眼中的性能测试)，聊了个人对性能测试的一些看法。后来在直播间和老张，CC一起聊了如何构建个人的性能知识体系这个话题，本文做个总结，个人觉得这个话题非常有意义。单纯的碎片化知识很难产生效应，应该学会如何把这些零散知识点串联起来，形成自己的知识体系，才能更好地运用。那么，如何构建自己的性能知识体系呢？1.理解名词背后的原理在性能测试领域，有很多名词（缩略词），像TPS、响应时间、并发数、线
核心观点软件可测试性是实现高质量、高效率交付的基础，关注可测试性可以提升软件质量。可测试性差，会直接增加测试成本，让测试的结果验证变得困难，让测试活动延迟发生。可测试性是设计出来的，提升可测试性可以节省研发成本。可测试性包括可控制性、可观测性、可追踪性与可理解性四个维度。随着云原生技术的加速普及与快速发展，软件系统的规模和复杂性不断水涨船高。与此相对应，在软件研发过程中，为测试而设计（Design
本文从代码提交关联需求任务的功能说起，探讨了其意义、功能扩展以及对研发效能提升带来的收益。记得原来有一次听到一个开发同学抱怨说为啥每次Commit都必须要填写commitmessage呢？他觉得有些浪费时间，因此想出了各种办法来应对，比如输入一个句点或复制粘贴上个commitmessage等。这种一时偷懒的做法，却会给其他合作开发的伙伴带来很多烦恼，这些不知所云的commmitmessage不仅不
大概在五六年前，有一次我在Google美国总部参加一次技术交流，有一个演讲让我印象深刻，让我至今一直记忆犹新的不是其演讲内容，而是演讲开始的第一页PPT：“别人眼中的GoogleVSGoogle人眼中的Google”。我们对Google的软件工程能力可以说是趋之若鹜的，但是Googler对自己的评价确是如此的中肯和朴实。从『农业时代』向『工业时代』进化虽然软件研发过程从一开始就是数字化的，但从某种
本文核心观点：团队的复盘能力有多强，决定了团队的进步空间有多大复杂系统的高网络密度和强耦合性是造成故障无法完全避免的罪魁祸首故障是表象，背后技术和管理上的问题才是根因可以包容失败，但是不允许犯错不“浪费（忽视）”任何一个失误不能以唯一根因为导向来复盘避免将故障归因于外部客观原因在企业业务价值的交付过程中，故障是很难避免的，所以对企业来讲故障复盘是一项关键核心能力，今天我就从研发效能的视角来系统性地
热门文章