APP性能测试诊断与优化--通过现象猜本质

        这段时间忙着帮北京某城商行做移动端性能测试，因移动端IPD、手机等都是无线设备，而且该客户是面临全国各地用户提供移动**P支持，为了更真实的模拟测试，我跟该项目的项目经理沟通直接在厦门本地通过无线网借用LR工具模拟并发压力测试。很感谢移动架构组的技术专家肖工的帮忙，让我顺利的在本地搭建了模拟机，并跟该项目经理要了生产环境的APK工程包部署后，并根据项目组提供的业务操作手册学习业务知识，后使用LR开发脚本进行压力测试。51Testing软件测试网Mum$nP
       因地域距离关系，而且是直接在生产环境压力测试，生产环境在北京，压力测试机器在厦门，通过无线压测，所以测试过程对服务器资源使用监控成为一大问题，只能在每次压力测试时通过微信交流，在碰到响应时间等相对比较长或者TPS不稳定时，让项目经理协助监控，拍照截图我分析，还好自己这十几年到出差支持项目做性能故障分析优化，对各类问题通过LR前端能猜测出后端是数据库问题还是应用问题，虽然没办法做到真正的知微见著，但是还能通过现象了解本质问题，并提供优化建议，这主要是因为工作走心，也有事物去总结积累的效果。51Testing软件测试网*p_PC,u:~M
      刚开始压测时因是默认部署后默认配置等问题导致响应时间偏高，TPS低，经项目经理反馈应用CPU 都82%以上如下图：51Testing软件测试网'_[RekB:j
51Testing软件测试网:txU1Wl V|

Q'v%L:m6S"X5||T0      测试了四五支交易发现都有共性问题，响应时间都是六秒以上，手机端响应时间一般是258原则，超过5秒使用者都会烦躁直接关闭，一般建议都是3秒以下，因此指标没办法满足。
!n#w8O%No-Qg)^0       猜测应该是应用服务器配置不合理导致的，因为登录退出、页面连接等也有共性问题，大概测算下后，给项目经理提供相关的配置优化意见后，竟然真的解决了，主要是tomcat相对好优化，然后通过再压测响应时间都在1秒以下。51Testing软件测试网uy
~#jv"G*e
51Testing软件测试网'v
]"F7Z(t
51Testing软件测试网k7|S#AEL
         一般银行的APP移动端的应用逻辑也不会太复杂，代码写法问题相对比较少，而且是胖客户端的，数据传输虽单机业务数据量少，但是并发大，在测试过程中如果发现性能问题，一般是网络带宽问题或者后端处理逻辑问题。假如测试过程中如果大部分交易有问题，一般是软硬环境配置不合理居多，如果有时偶尔一两支查询交易响应比较慢，一般是SQL写法问题引起的，建议先看SQL语法执行路径如何，是走全表扫描，全索引扫描？是否因多表关联等写法导致的，这时在根据实际业务情况进行优化。--当然问题原因很多还是多监控诊断分析，性能监控数据说话才更真实和权威。51Testing软件测试网!O~F7CVlM2_ P
51Testing软件测试网v"E.Z `C

9H#B.X,}mm"N0