在应用程序中，单元是具有一个或多个输入和单个输出的软件中最小可测试部分。单元测试是一种测试软件代码单元的方法，通常包括一个或两个输入，产生一个输出。单元测试主要关注独立模块的功能正确性，目的是确保每个单元都按照预期的方式运行。要进行单元测试，开发人员需要编写测试代码。单元测试有手动和自动化测试两种类型，自动化通常是首选的方法，可以为开发人员节省大量的时间和精力。单元测试是自动化测试金字塔模型中占比
之前本公众号曾经写过几篇和前端性能分析相关的文章。《性能工具之前端工具梳理》《前端分析工具之Charles录制Android/IOS手机的https应用》《性能分析之压力工具是否模拟出了前端的请求》首先这些文章还不够成体系，其次也不够有深度。这一点后面我们要尽量补齐，其实还是和思维逻辑有关。在我写的两个性能专栏中，也没有关于前端的描述。但在我参与过的性能相关的场合，像咨询、培训、讨论等，都会被问到
昨天天去github上的PowerMock项目去看了一下。这个项目上次的commit和发布已经是10个月之前了。还积攒了400个问题和13个PR没有合并。当然，作为一个出道很久的小众Mock工具的项目，本身的活跃度低也是比较正常的。不过，很多Issue其实是关于新JDK兼容性的。从这点上看，维护者已经不是在积极维护这个项目了。而造成这些问题的一个重要因素，其实和JUnit5有关。众所周知，Mock
本文分享一些技术改进类项目（以下简称“技改项目”）的质量保障思路。1.技改项目的质量挑战何为技改项目？即目标是服务于技术改进或架构升级，而非服务于常规的业务功能更新。常见的技改项目有：大规模的前端重构或后端重构、技术架构升级、数据库拆分、数据迁移、系统上云和云迁移、非对客的支撑性项目等。（非对客：不直接面对前端用户的功能，通常是系统的支撑性需求）为什么这类项目的质量保障思路值得单独讨论？区别于常见
前段时间读了一篇文章：“外卖骑手，困在系统里”，引发了我很多的思考，后来有幸和作者有过一次交流更是让我印象深刻。上两周我写了一篇文章“如何用研发效能搞垮一个团队”引起了业界同行大量的讨论与关注，今天想借此继续来聊聊研发效能提升过程中另一个无法回避的的话题：“度量”。历史上度量失败的案例这其实是“窗户税”所引发的不良后果。1696年之前，英国政府对于个人房屋的税收采用的是“壁炉税”，也就是根据屋内的
“转敏捷后，测试经理的话语权没有了，团队更加关注交付速度而不重视质量怎么办？”在跟某转型中的团队进行交流时，一位测试经理表达了这样的担忧。我理解这里的困惑在于两个方面：●传统模式下测试是一个独立的部门，测试经理可以在测试这个阶段严格把关质量，有很强的话语权；在敏捷模式下，测试需要融入开发团队，都由开发团队PM来统一管理，很有可能会更关注交付速度，这种情况下，测试经理的话语权似乎减弱了，该如何发挥价
一、背景随着互联网的发展，我们进入了大数据时代，这个时代也是移动互联网的时代，而且这个时代，大量的线下服务走到线上，随之而来的，比如外卖、叫车……于是，有各种各样的App和设备在收集你的行为和数据。更加海量的数据源源不断的产生，并上传到云平台。这就给云提出了很大的挑战。一方面是极大地消耗有限的网络带宽资源；另一方面对于大数据处理的实时需求越来越成为刚需了，因为，如果不能实时处理、实时响应，那么怎么
前文回顾上期文章《[翻译]代码覆盖率在谷歌中的应用代码覆盖系统的现状及功能架构》介绍了谷歌的代码覆盖率测量计算系统（以下简称代码覆盖系统），主要包括该系统的开发背景，系统中覆盖率的类型和计算范围，以及系统的基础架构。本期将对该系统的每一个组成模块及其功能（如Figure3所示）作具体介绍。模块1：代码覆盖的插桩量化工具（CoverageInstrumentation）谷歌的代码覆盖系统综合采用了多
上篇、中篇分别讨论了5款AI测试工具Applitools、AppvanceIQ、EggPlant、mabl和ReTest。而SauceLab依旧不能访问，那这篇就review最后三个工具：Sealights、Test.AI和Testim。6.Sealights3年前介绍Sealights时，它已是一个基于云的测试平台，能够利用机器学习技术分析SUT的代码以及与之对应的测试，覆盖单元测试、系统的业务
上篇讨论了两款工具Applitools、AppvanceIQ，这篇来介绍三款工具EggPlant、mabl和retest。3.Eggplant在过去三年，Eggplant已启动了一个新的、基于AI的软件测试云平台——EggplantDigitalAutomationIntelligence（DAI）——数字自动化智能，整套工具使用AI和深度学习来从界面上寻找缺陷，能够自动生成测试用例，大幅度提高测
热门文章