财务系统-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

有赞读后感

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

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

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

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

<有赞测试读后感>

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

有赞测试文章读后感

有赞的发布系统为公交车发布系统,我们的发布系统为极品飞车发布系统将来肯定会比他们的牛逼。目前我们的极品飞车系统还在起步阶段,分支发布还在开发过程当中,但整个发布系统功能跟有赞类似,我们的平台将来还要与docker平台,监控系统对接,这是有赞公交车系统所没有的;感觉他们的分支发布好像不是自动编译的,现在我们运维平台实现了自动编译功能,发布项目挺快的;他们的发布流程很长,也不知道他们发布一个项目需要多长时间。

值得借鉴的是他们的整个发布过程已经跟测试打通,整个发布流程相当于是一条龙服务,全程自动化,平台界面展示效果较好。我们的平台现在还没有达到这种地步,但是肯定会的,很看好我们的平台!

有高度,有深度——有赞测试团队介绍读后感

附链接:有赞测试团队介绍

一、有高度:有赞的测试团队基于“提高产品质量”的立场,参与到产品研发流程各个环节:技术评审后的测试方案制定和评审、测试用例编写驱动开发、codeReview、集成测试、多环境测试,并且积累了一系列高效的工具:QA平台、mock服务、安全扫描工具、性能测试平台、持续集成平台、基于测试历史数据分析的工作台。

二、有深度:深入到跟质量相关的各个层面:RPC接口、http接口、线上服务监控等。

他们的测试团队打破了我对测试团队固有的看法:界面点一点、顶多用工具做一下接口测试和压测,他们能基于自己的使命主动出击,做了很多严格意义上讲并不属于测试职能的工作:codeReview、服务监控等,但这些也确实与产品质量和服务质量息息相关。

还有一点,他们的自研能力很强,能基于测试需求开发自己的工具,达到了可持续测试,并且基于测试数据做产品的宏观质量分析。

最大的感触,测试团队也大有可为!

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

有赞测试团队的一个亮点是,他们对平台上的开发和使用。他们的有赞QA平台提供了「构造测试数据」「项目质量报告」「项目日报」「环境健康检查」能力。性能测试平台简化了性能测试的步骤,提高了测试的效率,使得普通测试工程师也能方便地进行性能测试。以及他们正在建设的carmen该平台可以实现测试用例管理,又能够将用例自动化与用例绑定在一起;还有他们的集成测试平台,测试工作台等等,这些平台规范了他们的工作流程,提高了他们的工作效率。

再者从自动化来说越底层的自动化,收益越高,有赞的自动化分布图正是这样的金字塔结构,从而创造最大的效益。一个人的工作量是有一定范围的,自动化测试可以有效的减少单一重复的手工测试,去做更多更有意义的手工测试。

最后,质量不是测试人员一个人的事情,而是所有参与人员的事。

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

读了“有赞测试团队介绍”的这篇知乎分享,确实能感受到有赞测试流程的规范和成熟,有些我们可以借鉴起来;接下来我主要从如下几个方面同时结合公司现状(我刚来公司一周,可能会有些现状了解的不是很透彻,如果有片面或是不全面的欢迎大家指正),发表一下读后感言。
一、流程方面
项目协作
如上图,通过有赞的项目协作流程,个人总结有如下优点:
1、测试人员参与的时间比较早,从需求评审就介入,而且跟踪项目较完整,从需求评审一直到项目上线
2、测试流程很规范,从前期的需求分析,测试方案设计,设计评审,再到测试用例及提测用例的编写;有比较合理的时间去消化需求,落实用例,为后期的测试场景覆盖打下良好基础,避免后期时间紧张,场景考虑不全;
3、对于需求分析比较重视:需求分析后,需要输出对象生命周期图、业务时序图、用例图、待确认的问题、风险点清单。并就相关问题、风险与产品、开发进行多次沟通,直到问题得到明确答复。
这样前期重视需求分析,可以将一些需求不合理或是遗漏问题在前期暴露,在开发阶段就会解决一些问题,避免到后期测试阶段才暴露一些需求或是流程问题;同时能够更合理的评估测试范围,避免一些其他的业务功能兼容遗漏;
4、对于开发质量比较重视,开发阶段增加了单元测试,这样能够进一步保证开发功能的提测质量,把一些问题截止在前面,而不是到后期测试才发现,才去修改;
5、测试用例管理:在测试产出用例的时候会有两份用例,一份是测试用例,一份是提测用例;顾名思义,提测用例,就是开发在提测之前需要保证的流程功能用例,而且在开发流程中也有冒烟测试(个人认为冒烟测试直接执行提测用例即可,实际可能不太清楚是不是一套)和提测报告。这样,就保证了提测之后测试程序的质量,避免测试前期还因为主流程不通等严重影响测试进度的问题出现;
6、对于测试效率提升的重视,引入了测试自动化以及白盒测试,这里可能包括接口、UI等自动化

总结概括:流程比较完善,测试全程介入,提测之前的流程是比较多的,比如需求分析确认问题,设计测试方案,测试用例,单元测试,提测冒烟测试等等,前期介入比较多,可以将部分问题控制在前面解决,毕竟问题越是遗留到后边,修改的成本越高;

接下来通过这段时间与同事沟通以及自己总结,与公司现有情况做一下对比以及一些自己的建议想法:
1、测试人员介入和项目跟踪时间,以及测试流程:
需求评审会有人员参与,但是可能存在项目忙,参与项目需求的人员和实际执行测试的人员不是同一个人;
测试有的时候在项目提测的时候才开始介入项目测试,之前没有时间或是很少时间去充分的分析需求,以及评估测试范围,制定测试方案,有时候都没有时间编写测试用例。
当然以上问题也是测试资源和项目周期紧张,这就需要以后平衡,要想流程规范且质量有一定保证,多少是需要投入一定的时间和前期合理规划的;
2、对于开发质量,及提测质量的重视
缺少开发单元测试和自测的阶段
建议先把提测之前的自测做起来,在提测之前至少保证主流程,提测用例是通过的,后期可以再将单元测试推广;
3、测试效率提升
就如之前的计划,正好把接口测试和UI自动化引入,在提测之前保证接口质量,同时自动化用例也可以同步上线,对线上环境做相应的监控,以及后期其他项目兼容的一种辅助,避免大范围回归;后期大家能力提升之后可以考虑是否引入白盒测试等。
4、项目总结
对于一些优先级比较高或是项目周期比较长的项目,可以考虑要不要加入项目站立会的流程,这样每天或是几天同步一下进度,以及项目问题解决;
项目上线之后可以做定期的总结及复盘,对线上反馈问题进行总结,确认是用例场景考虑不全,还是测试范围评估不准确,还是环境需要完善等等,总结才能有进步。
二、工具建设
QA平台、有赞mock服务、安全扫描工具,性能测试平台,Carmen测试平台,持续集成平台,测试工作台等等;
这里对于工具和平台的构建其实还是需要时间和人力去搭建和维护的,如果前期达不到构建如此规范的平台,可以先重点关注这些平台中主要涉及到的一些内容,或者通过其他方式或是其他已有平台等来进行一些相关内容反馈。。
比如:
  • 有赞QA平台提供了「构造测试数据」「项目质量报告」「项目日报」「环境健康检查」能力;测试报告,包含项目质量报告及项目日报。用于跟踪项目过程质量、进展、风险及最终项目上线的质量。
  • 测试工作台:该工作台的目标是把测试小伙伴平时奋斗的成果展示出来,测试同学参与了哪些项目,项目的提测质量、测试质量、相关报告及风险点
我们可以考虑要不要先发起这些平台中的项目质量报告,项目日报,项目提测质量,测试质量等内容的补充;
三、线上监控
现在开发有线上的监控服务,加上后期的接口及ui自动化测试上线,后期如果通过定期执行,个人认为监控力度还是比较完善的。
四、发布管理
在发布管理上可能需要运维多费心,尽量梳理统一的环境部署规范,使环境部署不会占用太长时间;暂时发现以下一些情况,可能阻碍测试进度:
  • 前期测试环境搭建有时候比较费时间,有的时候提测之后好几天部署不成功;
  • 在有项目并行的时候,有的项目分支代码不完整,导致在分支下测试时候其他功能报错等不能使用,可以讨论是否可以优化;

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

有赞的测试和开发的边界比较模糊的,甚至延伸到了运维,已经有了一套交叉的套路,开发可以做测试工作,测试有开发能力,只是分工不同
同样我们研发人员也应该向外延伸,去多了解测试工作,也必须做好测试工作,简单的单元测试还不够,要做到具体流程测试,测试人员提供测试用例,及进一步验证
各个环节测试是非常耗时耗力的,要让开发人员尽量在提测前发现bug,就需要一个好的套路,这个套路需要各种测试工具和平台做支撑,如有赞的UI自动化、测试工作台、性能测试平台、全链路性能压测等。开发人员在开发的过程中能方便的进行测试,不当减轻了测试人员的工作压力,还可以及时让开发人员对代码进行调整,避免排查bug时耗费大量的精力。
我们曾经上线事故发生概率较高,除了上线规范没有做到位,还有一个就是缺乏一个线上业务级可用性监控。
然而我们目前这块还处于较为初级阶段,开发和测试套路交叉还比较少,还是偏向于测试找bug,开发改bug。要达到开发与测试的边界逐渐模糊,互相默契加深,只是在分工上做事的侧重点不同。我们还需要不断的努力,共同进步。

有赞测试团队介绍读后感

       看了有赞测试团队的分享,让我对优秀的测试团队有了更清晰的认识,一个优秀的测试团队需要具备以下几点:人员分工明确,团队目标一致,相互学习资源互补,有条不紊的测试流程等方面。有赞测试团队的强大不是一朝一夕能够实现的,我们可以吸收他们的长处补充自己的不足,设计出一套适合本公司的一个测试平台,让我们的测试团队更加强大。
       1.对于测试平台的搭建。我们需要探索出适合本公司发展的测试平台,让自动化测试不断的融入我们的测试过程中。对于功能测试,UI测试,安全性测试,性能测试,自动化测试要有一个合适的平台去合理的分工协作。
       2.对于自动化测试,每个测试人员都应有意识的去学习,去探索更好更快更精准的测试方法。自动化是必修课,我们也要学着从接口层、端对端的数据层、端对端的UI层来做自动化建设,尽可能的去朝着自动化 的方向去发展,不能一味的停滞不前,要不断的学习,不断的向自动化测试靠拢,尽可能的减少不必要的人工测试。
       3.对于不同的项目有不同的解决方案。对于标准需求项目或者跨多个业务的项目,一定会有测试投入,并且会有一位PTM来协调测试工作。即哪些业务的功能测试PTM可顺带执行掉,哪些确实需要对应业务线测试同学来完成,以避免一个项目投入过多测试同学。 对于重构改造项目,测试同学要做的就是对新系统进行自动化覆盖。对于小型项目,如果开发的自测场景与测试同学的测试场景基本一致,那开发自行搞定即可;或者测试同学把需要特别关注的或者风险点给开发同学简单介绍。对于有差异的,测试同学把差异点向开发同学描述清楚即可。
        以上几点是我读完有赞测试团队后的感想,一个强大的团队必有它的强大之处,我们要正确的认识自己,去努力追赶超越他们。加油!!!