qq_23150755的博客

了解了语音的基本概念后，接下来来了解语音的产生原理，这其中包括发音器官，语音的产生过程，以及语音的本质。

本章首先介绍语音的基本概念及语音的产生原理，然后介绍什么是人工智能语音、人工智能语音交互和人工智能语音测试，最后阐述人工智能语音测试的目的和意义，引领大家走入人工智能语音测试的世界。

并发30个，响应时间不达标。监控服务器，发现cpu使用率占用一直很高且接近100%，内存使用率基本保持不变；

场景和现象说明：1、并发10个，jmeter执行经常OOM；2、监控服务器，发现cpu使用率显示波峰状且经常达到100%，内存使用率显示波峰状且存在持续增高现象；问题：大部分请求得不到正常响应，报错；监控现象：1、服务器CPU使用率显示波峰状且经常达到100%；2、服务器内存使用率显示波峰状且存在持续增高现象；3、jmeter和服务端都存在大量的OOM；4、full GC频繁；初步原因分析：1、【内存泄漏】存在程序内存未释放，最长的有半小时没有释放到，导致

场景和现象说明：1、观察数据库服务器，cpu使用率在11%左右，看oracle的awr日志，没看到特别慢的sql（有三条sql加起来耗时不到一百毫秒）2、应用服务器，有几台cpu使用率70%左右（几台都是同功能的），频繁fullgc，用的是cms，设置了到70%就回收。堆内存5千兆。这接口慢应该怎么分析。可以通过看日志分析哪里慢吗？问题：接口平均响应时间比较慢，约1.63秒；监控现象：1、full GC频繁；2、应用服务器CPU占比70%左右，略高；3、磁盘写较大，超

性能测试实战分享1—TPS上升后下降场景：30个并发，单台jmeter压测；客户端-Windows系统，服务端-linux系统；问题：TPS上升后下降，且下降为高峰TPS的四分之一左右；原因：压测机tcp连接端口占用过多超2万7千多，且大部分TCP连接都是time_wait状态，顾tcp连接端口不足；解决方案：采用分布式压测，增加端口号；分析思路：*第一步：*分析客户端和服务端的性能，看是否有性能瓶颈（CPU，内存，磁盘，网络）*第二步：*再分析客户端和服务端的端口是否用尽*第三步：*最后分

响应断言—根据变量来断言（每次响应结果不一致）一、断言的场景根据传参的不同，每次响应结果都不一样；二、实现方法1、提取响应结果中断言字段，生成变量；2、断言成功字段生成文本，进行参数化；3、实际响应结果字段和断言成功字段进行对比断言；三、实际操作1、提取响应结果中断言字段，生成变量；2、断言成功字段生成文本，进行参数化；3、实际响应结果字段和断言成功字段进行对比断言；...

监听器jp@gc - Composite Graph： 混合图表一、目的和作用作用：在它的Graphs里面可以设置多少个图表一起展示，它可以同时展示多个图表；目的：将一些图表结合在一起查看性能趋势和走向，有利于对比和结合查看性能情况，最重要分析性能拐点；二、如何添加1、添加jp@gc - Composite Graph添加线程组—>选择监听器jp@gc - Composite Graph；2、如何添加图表（1）先把需要监听的各种监听器添加上（2）运行jmeter脚本（3）查看