postman以及接口测试bug积累

17. 无法播放某个在线的mp4视频 其他视频可正常播放

报错信息 视频因格式不支持或者服务器或网络的问题无法加载

问题排查：打开开发者工具-网络 找到报错的链接 报错404  把url拷贝到浏览器单独访问报404 Not Found

排查：C:\Windows\System32\drivers\etc\hosts

配置文件查看是否有出问题的域名 经排查发现确实有 注释掉域名解析

Windows中的hosts文件是一个负责IP地址与域名快速解析的文件，‌它允许用户自定义域名和IP地址的对应关系。‌这个文件的作用是，‌当用户在浏览器中输入一个网址时，‌系统会首先自动从hosts文件中寻找对应的IP地址。‌一旦找到，‌系统会立即打开对应网页；‌如果没有找到，‌则系统会将网址提交给DNS域名解析服务器进行IP地址的解析。‌需要注意的是，‌hosts文件配置的映射是静态的，‌即一旦配置好，‌不会自动更新

16. 上线顺序：A模块先上，B等A上完B再上。回滚的话，后上的先回滚，B先回滚，A再回滚 

15. 

八进制转义序列：protobuf转字符串的时候把中文默认这样做

protobuf 八进制转义序列转中文_protobuf 显示中文 java-CSDN博客

发现日志里打印的是数字格式 而不是中文

#!/usr/bin/env python
# -*- coding: utf-8 -*-
########################################################################
#
# Copyright (c) 2020 xx.com, Inc. All Rights Reserved
#
########################################################################

# -*- coding: UTF-8 -*-
import os

def Str8Decode(srt):
    #ret = srt.decode('\345\275\261\350\247\206')
    ret = '\345\275\261\350\247\206'
    print ret

if __name__ == "__main__":
    Str8Decode(str)

---

---

14. 上线上到上海 南京 北京机房，什么是机房 ？

一般一个项目都会部署在多个机房的，不同的项目组申请的机房可能也不一致，保证服务的可靠性，如果某一方的机房出现问题了，其他机房还能扛，就是鸡蛋不放在同一个篮子里。可以根据用户所在地，机房健康状况等等信息，来决定用户请求到哪个机房，如果某个机房挂了，健康检测就会把这个从DNS里面下掉，让请求去访问其他的机房

多机房 一能解决完网络延迟问题，不同区域用户就近选择机房 。二能提高服务可靠性 多活保证 ，极端情况 万一北京机房挂了 其他机房还能提供服务。是部署在不同地区的服务器。多机房需要的架构就很复杂了 比如路由划分 各机房间数据一致性 数据同步 好多问题呢 比较复杂。支付宝不是展示过它的异地多机房容灾 现场把支付宝机房网线还是电源拔了 用户无感知 10S内服务恢复。机房就是布线、放机器，网络连接。一般多机房是提供 容灾用的，如果想加快访问速度 应该直接买CDN服务。

机房是服务器的区域划分，一个机房会有多台服务器，可以理解为集群。不同的机房会接入不同的运营商，联通，电信，移动。可以进行多区域服务部署，提供大规模服务。提高服务的可用性，可靠性，扩展性

---

---

13. postman的Pre-request Script

/*线下*/

var app_key = "";

pm.environment.set("apiUrl","ip:port");

var id = 111111; /*查看服务器日志找*/

var msg = '';

// common

/*

['key' => 3, 'value' => '', 'desc' => '认证成功'],

['key' => 4, 'value' => '', 'desc' => '认证失败'],

*/

var status = 3;

var expireTime = Math.round(new Date().getTime()/1000) + 10;

var actionTime = Math.round(new Date().getTime()/1000);

var applicationId = 100001;

//组装请求sign

var jsonParams = {

"id":id,

"msg":msg,

"status":status,

"actionTime":actionTime,

"applicationId":applicationId,

"expireTime": expireTime

}

function jsonSort(jsonObj) {

let arr = [];

for (var key in jsonObj) {

arr.push(key)

}

arr.sort();

let str = '';

for (var i in arr) {

str += arr[i] + "=" + jsonObj[arr[i]] + "&"

}

return str.substr(0, str.length - 1)

}

var sign = CryptoJS.SHA256(jsonSort(jsonParams)+"@"+app_key).toString();

pm.environment.set("id",id);

pm.environment.set("status",status);

pm.environment.set("msg",msg);

pm.environment.set("actionTime",actionTime);

pm.environment.set("expireTime",expireTime);

pm.environment.set("applicationId",applicationId);

pm.environment.set("sign",sign);

php出core：

php如果运行有错误 比如 内存溢出等问题，就会生成core文件

进程挂了，生成个core文件便于定位分析

部分传参未做非空 value的判断：接口容错性

因为就算传一个空的id给接口，接口也应该要有返回值。一般不会出现id空值情况，如果出现了就是端上或者业务接口出错了，没有为用户创建合适的id，这个时候用户请求了不能给用户空

---

12. 

{"appScene":"xx","appCaller":"-sdk","pz":"30","pid":"64b6847e992c4c45","srid":"0","scene":"xx","aaid":"1b17af263681b2ce96f453293f51449e","keyword":"%E5%88%98%E5%BE%B7%E5%8D%8E%E7%94%B5%E5%BD%B1","utdid":"W8BGHY4y8pADAINY4TmDWKYq","ip":"106.11.41.196","clientTimeStamp":1591880251,"version":"9.0.0.125839","systemInfo":"{\"osVer\":\"13.4.1\",\"zx\":1,\"appPackageKey\":\"xx\",\"ouid\":\"449ddd6411cb1ce3aac8532229870a6c1dd9ddc2\",\"idfa\":\"7CF9D972-8F47-4387-8833-313A846450E1\",\"brand\":\"apple\",\"os\":\"ios\",\"imei\":\"W8BGHY4y8pADAINY4TmDWKYq\",\"ver\":\"9.0.0.125839\",\"guid\":\"449ddd6411cb1ce3aac8532229870a6c1dd9ddc2\",\"network\":\"WIFI\",\"btype\":\"iPhone10,1\",\"pid\":\"64b6847e992c4c45\"}","userType":"guest","device":"IPHONE","xConfuse":"{\"x5-uuid\":\"ca0188a6bf49468ceb01aab706d393bc\",\"x5-credible\":\"\"}","system_info":"{\"osVer\":\"13.4.1\",\"scale\":2,\"zx\":1,\"appPackageKey\":\"com.xx.xx\",\"ouid\":\"449ddd6411cb1ce3aac8532229870a6c1dd9ddc2\",\"young\":0,\"brand\":\"apple\",\"idfa\":\"7CF9D972-8F47-4387-8833-313A846450E1\",\"childGender\":0,\"os\":\"ios\",\"ver\":\"9.0.0.125839\",\"operator\":\"中国电信_46011\",\"network\":\"WIFI\",\"btype\":\"iPhone10,1\",\"pid\":\"64b6847e992c4c45\",\"resolution\":\"1334*750\",\"device\":\"IPHONE\"}","searchFrom":"1","sdkver":"312","trackInfoAppend":"{\"soku_test_ab\":\"a\",\"source_from\":\"home\",\"cn\":\"精选\"}","sourceFrom":"home","userAgent":"MTOPSDK/1.9.3.48 (iOS;13.4.1;Apple;iPhone10,1)","pg":"1","userNumId":0}

从服务器拿到接口json请求，转换为get请求的时候注意\的过滤

curl命令请求不需要过滤\  postman需要

遇到的问题：由于转换完传参带着\，导致接口返回缺少部分字段，需要额外传指定分桶的参数

接口幂等性：客户端传参会上传ononce（随时生成的字符串，唯一性）服务端会校验上传的传参是否一致

服务端存储：悲观锁、乐观锁、分片处理

11. 

接口去重，第二个传参会覆盖第一个传参

传参token=正常值&token=null。返回报错
传参token=null&token=正常值。返回正常信息

接口非必传的判断后端如何做的？

go不存在非必传。。。php python的话在函数声明的时候就可以给个默认值，go是都得传 然后自己判断每个值是否有意义 非必传的话一般就传空，要是纯接口调用 不检验入参的话 就自己内部挨个按key取值 取不到就认为没有 这算非必传

---

10. 当APP端搜索一个query时，加载很慢，应如何分析其原因并解决问题？

客户端

1客户端本身启动慢，客户端没有缓存，手机硬件慢

2请求耗时、页面加载渲染  

3客户端策略问题

4客户端未增加CDN兜底策略

5未命中降级逻辑

6分阶段耗时：

搜索启动总耗时:1490ms

点击到初始化结果页耗时:753ms

网络请求耗时:485ms

渲染耗时:252ms

解决：端上能做的优化是：本地缓存、较少页面复杂度（依赖于产品和设计）、减少数据条数以及数据复杂度、加载性能优化

QA：性能测试（从发起请求到服务端接口到页面渲染）、增加兜底监控、增加全链路监控、日志排查（请求开始时间、请求结束时间）

网络

1当前网络环境234G WiFi

2带宽打满 网络抖动 CDN（内容分发网络）

3查询结果数据量大，带宽不足

4网管限流

服务端

1机器方面：机器CPU 内存使用率过高 线程 硬盘 网卡IO层面有问题

2服务端业务层面：可能是耗时 可能是技术栈的问。没有用缓存。没用使用并发调用下游，没有使用异步队列。SQL慢查询。并发量高

3nginx负载均衡异常

4依赖的外部服务有没有问题，排查依赖的耗时和成功率，分阶段排查

5技术栈没做CND兜底，容灾处理

定位问题：接口耗时 日志（业务 ng）

解决：设计、压测、日志、增加监控、报警

存储方面

1数据库未命中索引、数据库没有分库分表，数据库没有调优、开启LRU之类的配置

2Redis同上+缓存慢了

总体：

机器问题（网卡，cpu，mem，disk） 
代码问题（没有缓存，算法垃圾，循环sql）
数据库层（慢sql，没用到索引）

启动总耗时:1490ms

点击到初始化结果页耗时:753ms

网络请求耗时:485ms

渲染耗时:252ms

   数据分析：时序图

9. 

pm.test("登录", function () {
pm.expect(pm.response.text()).to.include("0") 
});

tests["Body matches string"] = responseBody.has("15321895668");

// 把responseBody转为json字符串
var jsonData = JSON.parse(responseBody);//获取body中返回的所有参数

// 设置环境变量token，供后面的接口引用
postman.setEnvironmentVariable("token",jsonData.data.token);//把返回参数中的token设置为环境变量

if (jsonData.data.token) {
tests["Body has token"] = true;
postman.setEnvironmentVariable("token", jsonData.data.token);
}
else {
tests["Body has token"] = false;
}

//var timestamp = Date.parse(new Date());
// timestamp = timestamp / 100;
// postman.setEnvironmentVariable("MOBILE", timestamp);

form-data：既可以上传文件等二进制数据，也可以上传表单键值对，只是最后会转化为一条信息

x-www-form-urlencoded 只可以上传键值对 并且键值对间隔分开

raw支持上传text、json、xml、html文本文件

binary只支持上传二进制文件

8. 客户端一个动作，其实就是调用了一个js的方法，这个方法里面可以同时去请求多个接口

接口耗时500ms以内正常，业务一般慢点，一般都是200 ~ 400ms

微服务在50ms左右

php在100-200ms

suggest在1-2ms

7. 测试环境接口响应3秒，但是线上接口响应要30秒左右，如何定位？

可能的原因：可能是某个服务崩了，需要看日志查瓶颈 ；一般就是流量大了之后，某个服务成为瓶颈了。如果部署的环境一样的话，那就是线上并发太多了，带宽打满了，统计线上接口调用次数和耗时。接口逻辑里有个环节变慢了，可能是网络IO，也可能是读写IO，数据库查询，复杂逻辑计算，死锁

经排查：线上环境有个加解密绑定的域名IP变了

6. 为什么接口传token就可以获取到用户信息？token生成规则

token生成一般都是夹杂着自己想要的信息，一般都会有uid 账号等，通过有规则的拼接再加密，而且这个加密是可逆的，所以token过来先解密，再根据规则分割，就拿到了uid。

token是由用户的user_id及其他信息，根据对称式加密/md5/base 64 的方式生成的，所以可以进行加密，解密。所以根据token，可以反解密出 user_id

token就是用户的加密信息，用户登录之后根据他的信息加密生成的 token，然后用户再次调用 api 的时候，服务端解密 token 获取用户信息，没具体规则，一般都是用的对称加密/aes/des之类的

token一般就是把用户ID和其他需要的参数比如过期时间或者token生成时间一起通过加密生成，API拿到后再反解出来

JSON Web Token 入门教程 - 阮一峰的网络日志

API 接口设计中Token设计讨论 - 简书

5. Ø tp99

• 分类

TP50、TP90和TP99等指标常用于系统性能监控场景，指高于50%、90%、99%等百分线的情况

• 什么是 tp99 ？

tp99：满足99%的网络请求所需要的最低耗时

• 示例

100个请求里，前98个请求都是1ms，第99个请求是100ms，tp99就是100ms

接口耗时时间长的原因：请求量多、有长尾请求（个别请求响应时间特别长）

Ø avg

请求线上接口(有缓存+无缓存)下接口平均耗时

Ø qps

Query Per Second，QPS衡量吞吐量（Throughput）的一个常用指标，服务器在一秒的时间内处理了多少个请求 

搜索接口耗时200ms  优化后70ms

命中缓存率：25%

缓存失效时间为15min，每5分钟会触发一次动态刷新

4. 登录接口测试：

传参次数测试

token=正常值&token=null。返回报错
token=null&token=正常值。返回正常信息

支付接口测试：

幂等性（连续请求多次）

---

---

3. postman使用遇到的坑

Why this might have happened:

The server couldn't send a response:

Ensure that the backend is working properly

Self-signed SSL certificates are being blocked:

Fix this by turning off 'SSL certificate verification' in Settings > General

Proxy configured incorrectly

Ensure that proxy is configured correctly in Settings > Proxy

Request timeout:

Change request timeout in Settings > General

修改Postman-Preference

postman不会做urlencode，但是浏览器会。参数中间有空格、特殊字符等  浏览器都可以兼容，但是postman有可能就不一定能兼容这些

404分几种情况考虑：1、路径名错误 2、服务器资源不存在 3、代理未配置

2. 正则转义

转义字符_百度百科

1. 一个客户端传参问题的排查：

抓到的传参为json格式，推荐json与GET相互转换-QQE2.COM在线工具网

json与GET相互转换-奇Q工具网

从iPhone端最新包抓包拿到客户端传参请求requestA，服务端responseB不展示XX字段

用A完整参数在postman请求接口，服务端responseC展示XX字段

用A完整参数在curl请求接口，服务端responseD展示XX字段

用服务器日志的客户端请求完整参数requestE，在postman请求接口，服务端responseF不展示XX字段

服务器日志拿到的请求参数如下

origialParam:{"appScene":"mobile_multi","appCaller":"xx-search-sdk","pz":"30","pid":"64b6847e992c4c45","srid":"0","scene":"mobile_multi","aaid":"5f1bbeb12ece1ddfcc65ac0199b6a8a0","keyword":"%E7%B1%BD%E5%B2%B7","utdid":"xx","ip":"42.120.73.167","clientTimeStamp":1584013137,"version":"8.6.0.119228","systemInfo":"{\"osVer\":\"13.3\",\"zx\":1,\"appPackageKey\":\"xxDebug\",\"ouid\":\"800eeea70994bb1419c20d5c3f5571737b16b456\",\"idfa\":\"FFE4379D-E075-49BB-8A1C-8C211DFEE62B\",\"brand\":\"apple\",\"os\":\"ios\",\"imei\":\"xx\",\"ver\":\"8.6.0.119228\",\"guid\":\"800eeea70994bb1419c20d5c3f5571737b16b456\",\"network\":\"WIFI\",\"btype\":\"iPhone11,8\",\"pid\":\"64b6847e992c4c45\"}","userType":"vip","device":"IPHONE","system_info":"{\"osVer\":\"13.3\",\"scale\":2,\"zx\":1,\"appPackageKey\":\"com.xx\",\"ouid\":\"800eeea70994bb1419c20d5c3f5571737b16b456\",\"young\":0,\"brand\":\"apple\",\"idfa\":\"FFE4379D-E075-49BB-8A1C-8C211DFEE62B\",\"childGender\":0,\"os\":\"ios\",\"ver\":\"8.6.0.119228\",\"network\":\"WIFI\",\"btype\":\"iPhone11,8\",\"pid\":\"64b6847e992c4c45\",\"resolution\":\"1792*828\",\"device\":\"IPHONE\"}","searchFrom":"1","sdkver":"308","trackInfoAppend":"{\"soku_test_ab\":\"a\",\"source_from\":\"home\",\"cn\":\"精选\"}","sourceFrom":"home","userAgent":"MTOPSDK/1.9.3.48 (iOS;13.3;Apple;iPhone11,8)","userId":"xx==","pg":"1","userNumId":11111}
 

发现在浏览器里的返回key没有""，如level: 0,  在Charles里key有""，如"level": 0,

待续