性能测试中的一些总结

一、在和历史数据做对比时候，要注意环境的一致性，比如：

• 都是Stage环境
• 服务端是同样多的机器数量
• 客户端的机器的配置，如CPU/memory等
• 测试数据的一致性

二、测试方案的确定--由测试目的确定

• 跑API还是跑workflow？
• 并发用户数10？20？40？并发用户数的梯度？--可根据线上用户的情况确定。
• 跑哪些API？--根据用户的场景及代码的修改

三、测试数据分析-对于代码修改后，或者tomcate升级后评估对系统性能的影响。

• 测试数据的基准是什么？假如去年已经有性能测试的数据，在同样条件下当前数据和历史数据的对比，如果百分比，请求总数差距太大，考虑在当前新跑多轮数据后选择一个新的基准。
• 同一条件下跑出多组数据后，比较这多组数据的差距，如果内部数据差距大，是不考虑外在环境条件需要重跑后再对比。

1. 是不是依赖的三方服务的条件不一致？跑脚本的时候第三方的任务是不都处理完了，比如转换任务
2. 服务器条件不一致导致？CPU、Mermory是否降下来了等
3. 历史产生了更多的脏数据导致？过程中产生了很多model/propsal数据等
4. 网络条件导致？有没有链接VPN，服务器所在区域的影响等

• 不同的用户并发数下，RPS的对比，比如20并发下RPS是10,50并发下RPS也是10左右，这个时候就需要考虑是客户端或者服务端是不是有问题了。

1. 客户端：从发的请求数去分析
2. 服务端：从CPU、memory去分析，处理请求的机器的数量。

 

四、测试案例数据的一致性，否则可能会影响结果，比如对于download 相关的API，文件的大小会对响应时间产生明显的变化，这就需要考虑输入的测试案例的文件一定要是一致。

五、调试某接口的时候，也可以修改其API的比例，或者按照指定tag来跑等。