财务系统-axxBank和marginCall项目上线小总结

财务对账一期,在各方势力催促下,匆匆忙忙上线了,上线之后,第一天cat监控显示有4个接口超过了300ms,最高请求能达到1秒多,爆炸!

微信截图_20170930155822
接下来,查找原因,4个接口4条业务线逐一排查,首先走Debug先从sql入手,对于新增的表 没有及时建立索引的,增加索引保证sql最优化,接下来走单元测试打印运行时间,看代码块响应时间,优化代码 !
这次调优印象最深的有两点:

1、有个业务方法,在for循环中加了sql查询,这个错误太明显,

微信图片_20170930155009
二话不说修复代码将所需3张表的数据一次性加载到内存中,在内存中进行各项封装,时间从180ms优化到6ms,鼓掌!~\(≧▽≦)/~
2、另一个错误是在频繁使用一个三级分类查询中,使用了google guava缓存,有一个方法未写正确,导致每次都重新查询加载到缓存中,怎么避免这种失误很简单,debug断点看是否第一次加载进去,第二次从缓存中直接取到,还是不能太相信自己,直接测试功能就认为没问题
经过一些修改之后,使用勇勇的gatling压测,4个接口平均响应时间已经低于40ms

本次小总结:

1、sql优化,养成每个sql在写代码阶段就自己进行性能调优监控的习惯
2、单元测试,不能只是简单的测试功能是否正常,打印出响应时间,好坏立刻见效
3、上述两条只是基本的编程习惯,有了上述两个之后,适当地使用缓存,上线之前进行压测,都是避免不必要问题的措施啦~

江湖路远,下期再见~

微信图片_20170930155456

接口测试考虑事项

在集成测试中首先是确定需要测试模块,集成是将多个模块集合在一起工作,模块与模块之间肯定有工作的接口,你就需要研究一个模块输入输出,研究多个模块的输入输出,构造你如何测试这多个模块输入输出的关系。——-查找各模块的输入输出及关系,编写用例

接口测试主要考虑的问题:

1.各个模块连接集成起来的时候,穿越模块接口的数据会不会丢失; —–确定数据完整

2.各个子功能组合起来,能否达到预期要求的父功能; ——集合后,达到需求目标

3.一个模块的功能是否对另一个模块的功能产生不利影响; ——集成后,不影响相关模块功能

4.全局数据结构是否有问题; ——集成后,保证系统数据的正确性

5.单个模块的误差积累起来,是否会放大,从而达到不可接受的程度。 ——-集成后,确保误差不影响系统功能及性能

Service层接口测试,大致有三种测试类型:接口逻辑测试、出错测试、路径测试

接口逻辑测试,对开发人员输写的JavaDoc进行测试,后根据JavaDoc来编写测试用例(一般情况下JavaDoc需要包含前提条件,业务逻辑,输入参数,输出值的描述),在接口逻辑测试中主要是根据所描述的业务逻辑,进行用例的设计,主要目标是测试在正常输入的情况下能得出正确的结果,测试用例的设计方法跟黑盒测试差不多,主要运用等价类,边界值两种方法。

出错测试,做了接口逻辑测试后,可以正常使用了。为了保证数据的安全,及程序在异常情况的逻辑正确性,因此需要测试出错测试。出错测试主要考虑:空值输入(如当传入一个对象参数时,需进行NULL值的参数)、参数属性的测试(如输入一个未赋值参数)、异常的测试(制造一些异常的测试场景,测试的异常描述是否清晰)

路径测试,经过了上述处理后,单个的接口服务已经得到了保证,但是在业务流中是否满足了业务需求其实还是没有得到保证,路径测试的目的就是设计尽可能少的用例,来保证各种业务场景下数据是安全可操作的。

优测网的手机测试环境搭建

U测环境搭建前,需要保证本地的开发adb环境是搭建好的,即在命令窗口输入adb可以显示以下信息。(adb环境搭建第一篇博客已经介绍过)地址:
http://tech.dev.aixuexi.com/?p=740 有介绍过,成功的标志如下。
图片1
1.进入优测网:
2.登录优测网账号,点击进入云真机-设备分享,点击页面上的使用指南按钮,如图:
图片2
3.进入使用指南页面,如下,按照页面上的操作一步步操作
图片3
4.下载客户端,点击页面上的下载按钮;安装客户端。
图片4
5.安装完成之后,启动UTestClient客户端,输入登录UTest官网的账号。手机连接PC后,打开手机的USB调试模式。客户端命令行提示“手机上报成功”并显示手机基本信息时,连接设备成功。
图片5
6.分享设备在云真机 > 设备分享 > 我的设备中找到正在连接的设备,分享给指定的人或指定的组。
   以上是我们做U测手机测试的环境搭建的步骤,有兴趣的可以按照上面的步骤进行操作。

Fiddler模拟弱网测试

Fiddler模拟弱网

1. Fiddler>Rules>Customize Rules…

1

2.搜索m_SimulateModem, 修改以下参数,并保存

oSession[“request-trickle-delay” ] = “300”;(每上传1KB延迟300ms)

oSession[“response-trickle-delay” ] = “150”;(每下载1KB延迟150ms)

2

3. Save后,之前勾选的Simulate Modem Speeds会被取消勾选,需要重新再勾选回来

3

总结:

千里之行始于足下 !

有赞.测试团队介绍 读后感

有赞.测试团队介绍 读后感

读完这篇文章给我最深的三点印象
第一是 测试,运维和开发在工作之中配合更紧密,这一点我们做的还不够,我们运维在工作很少涉及到跟其他团队之间合作,在以后的工作中也会更加注重这一点
第二点是 无论是测试还是运维都需要具备一定的编码能力,否则在工作中只能有心无力
第三点应用性能监控与发布系统相结合,项目发布完毕自动调用接口进行多节点检查,这一点也是我们要学习借鉴的,运维与测试配合对各个应用进行深层次的监控

<<有赞测试读后感>>

有赞测试读后感:
直接步入正题,说下我个人理解,和他们的差距:

1.高效的协作(PTM角色),全程跟踪:

项目协作
2.产品质量总结以及制定产品质量考核:
监控产品质量,从时间控制的角度来说,开发新功能和修bug是一个平衡。开发得太快就可能把交付给下一个阶段一个问题较多的版本,从而使得后面的问题更难处理。我们如何知晓每个阶段软件质量怎么样?具体的方法很多,回归测试,代码覆盖、压力测试等等。但是这些信息谁来收集和分析,怎么分析,能得出什么样的结论,怎样对RD的质量进行考核?

3.自动化覆盖率以及自动化工具:

有赞的自动化测试,从文章看来,在深度和广度都有一定的积累,比如UI、http接口、MOCK接口自动化覆盖率,深度上,他们有一套较为完整的测试工程(部分自研),广度上,在功能测试,性能测试,安全测试都有一定的体现。

4.监控系统:

随着系统网络拓扑与业务场景越来越复杂,发布频率越来越高,我们需要知道当前系统中核心业务场景的健康情况,目前我们OP开始设计并实施进程级别的监控告警,以及应用程序级别的ERROR监控。
4.定期组织业务分享,提高测试、开发人员的业务全局观及跨业务耦合与风险评估能力
5.提供《异常测试基本场景》指导测试人员如何考虑异常。

有赞读后感

一个成熟的运维团队,流程化、平台化是必不可少的。需要根据相应的流程去准备相应的平台,才能让一个团队的工作效率大大的提升。

对于运维来说,我们更多关注的是线上服务器的运行状态,线上服务的运行状态,发布上线的快速化、简单化,能够更高效率的解决开发或者测试在环境问题中遇到的瓶颈。

对于现在的我们需要做的,监控的完善,自动化平台的完善,虚拟化(docker)的完善,自动化平台对接监控+虚拟化。

现在的我们,流程化的东西正在逐渐的完善,平台化的东西我们也已经开始在做,尤其是我们第一版的自动化发布平台已经正式上线,这也就意味着我们已经成功了一多半,我们离一个成熟的团队也越来越近。

读有赞测试团队之读后感言

        之前对有赞不是很了解,看完过他们团队介绍,感觉这个测试团队做的很全面,监控到主网站到机器到每个接口,测试工作很全面而且是自动化,合并发布很厉害,每天能发布十几至二十几个代码分支,持续集成发布,值得为之点赞!

        我主要谈一下有赞的监控给我们的启发.随着系统网络拓扑的变大,业务场景越来越复杂,有赞这边专门开发了监控系统,监控主机状态,并模拟真实场景操作进行监控,一但某个环节有异常,及时告警之测试及开发,这样能第一时间了解问题,及时去处理.这也是我们所需要的,运维平台目前正在加入监控,目前完成所有项目运行状态的监控,异常及时告警.同时我们正在完成通过elk的api接口查询异常日志,反馈开发更好的完善我们的服务. 以后我们也要对每个接口监控,不论哪个点出现问题,我们都及时扫除这些异常.相信我们会越来越完善!

<有赞测试读后感>

看完有赞测试团队的介绍,从中获取了很多启发。
一.首先就是项目测试,分为三类:
1.标注需求项目或者跨多个业务项目
2.技术重构项目
3.小型项目
我们瑞恩3期就属于重构项目,所以测试可以借鉴他们的经验,设计测试方案并完成测试用例落地即可,用例有开发完成,测试需要自动化覆盖。
二.还有一点新颖的地方就在于,有赞测试他们关注了线上服务的性能和稳定性,通过他们自己开发的工具监控线上服务的健康性,以及及时的告警。
三.开发分支管理,有赞大巴的管理模式,由测试来管理分支。
四.各种工具的建设,极大提升了测试团队的效率。