解码器测试流程
测试流程
传送prop_list=1参数给decoder
发送请求时，需要配置prop_list传1，prop_list传成功的话，解码器的日志里会打印 "set active branch:"字样
性能测试
对解码器的性能测试可以使用测试脚本v2_performence.sh
一般这个脚本的所在目录在client/negative/decoder,可以从机器上找到存有client的文件里面的negative找到此脚本
打开脚本，可看到如下
1.funs字段
其中262400代表不开启提前返回
262401代表开启提前返回
什么是提前返回？？？？？
提前返回就是当你在给小度说话的时候如果你说话大喘气，在你喘气的时候，由于系统没有检测到声音（静默期time超过一定时间时），就会停止服务返回你说的大喘气前的结果，如果在百度app里就是停止识别（如果你说「今天天气怎么样<喘气>去上地怎么走」）在你说完「今天天气怎么样」之后就已经给你搜索出来了，后面的你说的他就不管了，因为识别的过程是流式的所以会一边识别一边返回结果<但这并不是提前返回，这两个概念不要混淆>
2. thread_nums字段
并发数，多线程，指的是分别同时有30 40 50 60 70个用户访问语音识别服务
3.ts_log字段
设置为你ts-ex的log所在的路径（脚本需要log里的数据从而计算新配置的bin的性能）
4服务器监控地址
User为audio 登录为ssh audio@加host
Host 为RD所给你的测试机器
file为你所生成的监控文件所在路径
des表示当前目录
password登录RD所给机器所需要的密码
*一般密码为audiotest如果密码不对，联系RD帮你初始化密码
file这里面需要你替换成运行decoder的机器，在提测的时候RD会给你一台配好环境的机器，就在这台机器上启动decoder，所用监控器文件名为process_monitor,需要将这个文件复制到你所测的bin的文件夹里，监控文件所在路径为
/home/audio/dynamic-wfst.online/bin/process_monitor/data/monitor_data.txt(online代表线上bin，为旧bin根据实际情况更改)
拷贝完后，先启动decoder
启动命令
nohup ./bin/dynamic-wfst -d conf -f dynamic-wfst.conf &
（有可能RD会给，应为所用conf文件名及路径有可能会不一样）
*nohup & 为后台启动，关闭secureCRT还会继续运行
启动后需要检查是否启动成功
用ps -ef | grep dynamic-wfst.conf
Netstat -nlp | grep dynamic-wfst.conf
检查，看是否有你所设的端口号
有的话还需要查看此端口号的进程号是否运行在你的文件目录下
用ll -ht /proc/端口号查询
解码器启动成功后，接着启动process_monitor
启动方式，先cd到process_monitor的bin下
执行nohup ./process_monitor /home/audio/dynamic-wfst.new/bin dynamic-wfst &
表示监控在/home/audio/dynamic-wfst.new/bin下的dynamic-wfst并在后台运行
如何判断监控成功？？？？？？
a. 能生成process_monitor/data/monitor_data.txt
b. tailf monitor_data.txt 能看到每5s生成一条性能数据
用tailf monitor_data.txt这个命令，能够看到数据滚动
自此，decoder，process_monitor 都已经启动了，我们可以注意力转向前端了，启动v2_performance.sh脚本
启动方法
nohup sh v2_performence.sh > result/new.262400.1.40 &
启动用sh命令 ，> 为将结果保存在result目录下的new.262400.1.40文件中（有的话覆盖文件没有的话创建文件写入数据）
Tips： 在性能调试过程中，如果中途kill v2_performence.sh的时候，也要校验一下client是否也被kill了，因为脚本就是执行命令，有可能他刚执行启动client的命令，就被你kill了，但client才刚刚运行，所以你也要把client给kill了。
回归测试
对解码器的回归测试，我们有自动化测试脚本，
路径为asr_negative.conf.ime 
这是其中的一个case
在使用之前需要更改几个参数
Tips：
V2架构需要两条tcp链接,一条上行链接，一条下行链接，上行链接用于将语音信息传送给解码器，下行链接用于将解码信息传送给client。
（这两条链接怎么建立的？？？？
首先在三次握手的时候，client会随机选择两个端口，如36576，36577，分别以这两个为source port，请求nginx的tcp链接，但这时nginx是只有一个port在监听）
一般测试环境为本地的话，就设置为本地IP地址，Port和nginx的一致即可，这个Port时destination port，不是source port，不要混淆
这个选择相应的语音文件格式就好
采样率一般为8000或者16000
分包大小，这个有规定
16k
PCM 5120kb
BV 640kb
8K的话以上数值除以2
Wait_time 一般为160
PID根据你要测的产品，一般可以在ts-ex的conf里面有一个product
.conf查看，且key和app都有
CUID一个过滤字段，在处理请求的时候如果是测试请求，会做特殊处理，依据情况而定
那这么多case，我咋一下全部改完？？？？？？？
比如我要将PID改为996的话
在进入vim或者vi之后shift + ： ，输入
1代表第一行，$代表最后一行，/A/B/,三个斜杠表示将A替换成B
所有为10010的pattern全部变成996了
同理其他也一样
解码器的回归测试就是分别用新bin和旧bin跑一遍，对比两者之间的case是否fail都一样，若一样回归测试通过，反之亦然。
压力测试
第一件事，找到配置文件asr_perform.conf，位置*你使用的机器名及你的文件夹名*/client/conf
然后，将
改为0或者一个很大的数
如果没有启动监听，依据我上面写的，启动process_monitor,都启动之后
正常启动client，命令nohup ./client conf client.conf &
创建监控任务，输入机器名，路径就可以监听你所测的那个程序了，在测压力前，启动解码器前，输入命令ulimit -c unlimited 来生成core文件，当程序出core的时候，用来记录哪里出core了，然后再启动解码器。全部启动后，可以没事就看看，有没有崩溃，是不是稳定之类的，压测一般在48小时以上，所以，一般是周五启动，周一检查，撰写报告