0%

基金基础服务发版过于频繁的总结

2018-02-03 上周四版本上线,我的服务有几次重复发版,负责人让我总结下原因,感觉一阵蛋疼。

基金基础服务发版过于频繁的总结

原因分析

  1. 思考问题不全面
    • 在编写代码过程中,开发人员想到的场景可能不全。往往都会出现某些条件没有考虑的清形。例如:在飞鱼3.7.1基金终止上市该功能开发中,我只考虑到基金终止和正常上市的情况。而在上线之后,测试人员发现将“转型”过的基金(该基金由终止状态转换为正常上市交易)也设置为终止。导致上线之后需要修复该功能。
    • 测试环境只包含线上很少的基金数据,导致自测和测试都无法发现场景分支。
    • 业务能力不够。对基金业务仍不是非常了解,往往容易出现业务场景思考不足,导致代码容易出bug。
  2. 测试覆盖不全面
    • 自测不到位。测试用例编写不够,很多时候只编写了少部分测试用例,只通过主功能,未考虑边界条件,同时未写测试用例分支也为考虑。
    • 测试人员测试粒度不够。有时代码优化功能,或者以前已经测试过通过的功能,做出优化重构之后未提交给测试,导致测试粒度不够,上线之后才发现bug。
  3. “环境问题”
    • 测试数据与生产环境有一定差距。目前由于一些原因(恒生数据配置原因)导致测试环境数据和生产环境数据还是有很大的差距,会导致“环境问题”(测试环境无bug,生产上有bug,反之)。例如,代销基金列表,测试环境只有80只基金左右,而线上有将近2300只基金。而根据我经验,有时每只基金都可能会出现一种完全不同的情况,所以有时测试也很难测全面。
  4. 兼容性问题(设计缺陷)
    • 由于飞鱼项目在app项目进度不一致,有时容易出现最开始设计的功能已经不再适用app的需求,而在上线之前未评估到这一情况,就会导致在上线之后才发现问题。同时前面设计的功能开发人员认为修修改改就能适用app(或者飞鱼),但实际情况可能不理想。
    • 由于OMS功能比较落后,而我们几个产品有时意见也很难统一,各自都有自己的特色。导致我们的设计很难顾全所有的产品。例如精选基金,app要求即按月份又要同时满足不同客户端的定制需求。而在前期的设计中没考虑不同客户端的问题,故在后期维护中难度较大。容易产生bug,不过后面经过协调产品达成一致。
  5. 代码缺陷
    • 空指针问题。编写代码时非常容易出现的一个问题,代码判断不全面导致
    • 超时问题。接口比较慢导致超时,而未做任何处理,这一般是开发人员无法意料到的问题。恒生接口和巨灵数据库sql查询等容易出现超时。
    • 异常补偿机制。开发人员很多时候对可能出现bug的代码未做异常处理,而有些则是只是做了简单的try catch,没有异常补偿,只能保证前端接口的正常访问,却不能修复数据。例如组合收益率走势图bug等。
    • 数据源问题。数据源的切换没有做更加详细的测试,对源数据未加工,导致界面显示错误。例如货币基金7日年化异常,持仓收益率未计算等bug。

总结(改进)

  1. 加强单元测试,自测。养成编写单元测试的习惯,不仅如此,还要养成对同一个场景编写尽可能全的单元测试用例,各个分支条件要覆盖到,还要对考虑边界条件测试用例的编写。多线程场景条件写的测试用例等。养成自测习惯。再小的功能点都需要编写测试用例。提高对测试用力的重视。
  2. 提高自身意识,需提高对代码上线的严肃态度。目前由于上线流程简单,而微服务往往上线牵涉面比较广,而我们目前用户较少,上线发生的服务中断等用户反馈较少,导致开发人员普遍没有高可用意识,上线比较随意。同时测试或者其他人员催促较急,代码未经过完整的测试就上线,这不利于培养上线严肃的态度。但这需要把控个度。培养以用户为中心的思维习惯,能够提高开发人员对代码上线造成的服务不可用带来的思考。
  3. 加强业务知识,业务理解。
  4. 做好沟通交流。对优化的代码,功能点要及时发聩给测试人员回归测试。开发人员之间也要多保持交流,可以交换大家对业务的理解。也可提高编码能力。
  5. 加强自身编码能力。对于边界条件的思考和复杂场景的处理,要做到尽善尽美。
  6. 代码审查。定期代码审查或者代码(技术)分享能够提高大家能力,减少bug。分享不一定是开会,好的代码或者好的idea都可以分享。