一个良好的测试用例除了可以帮助测试人员阅读，理解，修改之外，也要方便我们去管理它，从而提高测试工作的质量和效率。不同的业务条线或者团队可以根据自己需要制定一些规则，让大家在进行测试用例设计遵守。

随着项目的发展，前端SPA应用的规模不断加大、业务代码耦合、编译慢，导致日常的维护难度日益增加。同时前端技术的发展迅猛，导致功能扩展吃力，重构成本高，稳定性低。因此前端微服务应运而生。

大促备战，最大的隐患项之一就是慢sql，带来的破坏性最大，也是日常工作中经常带来整个应用抖动的最大隐患，而且对sql好坏的评估有一定的技术要求，有一些缺乏经验或者因为不够仔细造成一个坏的sql成功走到了线上，等发现的时候要么是造成了线上影响、报警、或者后置的慢sql采集发现，这时候一般无法快速止损，需要修改代码上线、或者调整数据库索引。

随着业务的不断增长，支撑业务系统的压力也逐渐增加，会面临如系统越来越厚重、逻辑越来复杂、迭代节奏越来越快等繁杂的情况。我们当前并没有做到在每次变化时快速识别出性能风险，检测产品或系统的稳定性、可靠性，而且我们还在不断的投入人力成本在压测这件事情上也是不合理的，所以我们要将性能验证融入到我们日常的工作中，把压测做到常态化，做成平常的一件事。

本文旨在简明扼要说明各回收器调优参数，如有疏漏欢迎指正。1、JDK版本以下所有优化全部基于JDK8版本，强烈建议低版本升级到JDK8，并尽可能使用update191以后版本。2、如何选择垃圾回收器响应优先应用：面向C端对响应时间敏感的应用，堆内存8G以上建

ThreadLocal（TL）、InheritableThreadLocal（ITL）和TransmittableThreadLocal（TTL）在不同场景下有不同用途，本文我们来分析一下

在mysql未支持json数据类型时，我们通常使用varchar、blob或text的数据类型存储json字符串，对mysql来说，用户插入的数据只是序列化后的一个普通的字符串，不会对JSON文档本身的语法合法性做检查，文档的合法性需要用户自己保证。在使用时需要先将整个json对象从数据库读取出来，在内存中完成解析及相应的计算处理，这种方式增加了数据库的网络开销并降低处理效率。

本文从EXPLAIN分析SQL的执行计划开始，进行示例展示，并对输出结果进行解读，同时总结了EXPLAIN可产生额外的扩展信息以及EXPLAIN的估计查询性能，整篇文章基于MySQL8.0编写，理论支持MySQL5.0及更高版本。

说起数据加载的机制，有一个绕不开的话题就是前端性能，很多电商门户的首页其实都会做一些垂直的定制优化，比如让请求在页面最早加载，或者在前一个页面就进行预加载等等。

如果你是商家，当你要进行广告投放的时候，假如平台推送的用户都是你潜在的买家，那你就可以花更少的钱，带来更大的收益。这两者背后都有一项共同的技术支撑，那就是用户画像。