有赞的深度需求功能测试

吕国用 | 2018 

有赞的深度需求功能测试


       序:在《
有赞.测试团队介绍(一)》曾经提到过,我们在测试需求项目时,会把需求逐级拆解,直到最小粒度。然后,各业务线的测试小伙伴把任务领走进行细化,同时,确定一位主测分来主导复杂项目的测试工作。 
       在面试过程中,很多小伙伴也会说,我们会根据需求所描述的功能,进行测试。那作为一位应聘者,如何才能把自己之前工作的能力展示给你的面试官呢。 
       随着有赞SOA服务化的深入推进,系统拓扑结构越来越复杂。我们也在不断提升测试小伙伴的测试能力及问题思考的能力。 
       我们的日常测试,一般需要考虑需求功能测试、性能测试、异常测试、安全测试。

一、熟悉技术方案

       有赞现在没有纯粹的测试工程师,不论是通过阅读技术方案文档、或是跟开发 Face to Face 沟通技术方案。从中,测试同学需要了解一下信息:

       所以,有赞测试小伙伴,需要对需求、系统实现方案非常了解,掌握系统拓扑结构,掌握自己Owner的业务及其周边业务。

2.2 任务

       不管是在传统行业还是互联网行业,总是会存在任务或者是脚本。有轮询从存储介质获取数据处理,也有接受消息中心处理的任务。 
       举个业务场景,在有赞系统购买会员卡。商家会创建一个会员卡商品,用户购买该商品,然后系统把会员卡发放到买家的账户里。交易下单与发放会员卡,通过消息中心将业务连接在一起,会员中心系统监听交易支付成功消息,然后放卡。
       我们考虑哪些内容:

  • 正常正向业务,我买了某张会员卡商品,我是不是得到这张会员卡。
  • 会员中心接收到消息中心推送的消息后,是先存储,再处理,直接消费掉消息,或者是直接处理,处理成功再消费消息。
  • 对于先存储,再处理,相当于需要在启动一个任务,消费落地在本地的数据。
  • 对于直接处理,处理失败,需要抛会一个异常或者false;让消息中心重新推送。
  • 存在重新推送,那么,执行任务是否符合幂等。
  • 该Topic消息失败重试,是否会有降级策略;例如ABC三个消息,A处理失败,A就不能立即重发,等待5秒,把时间片留给BC;每失败一次时间片+5秒。
  • 消息重试N次,会被抛弃,一旦抛弃,是否可能出现资损;就该场景,我买了会员卡,是必须发到用户手里。所以需要有T+1核对。
  • T+1核对,有业务方或者数据中心,交易日第二天,将会员卡商品的交易明细与会员卡中心发卡明细做核对,对差异数据进行补全或做其他方面的处理。
  • 会员中心作为事件处理方,如果需要多系统协作,需要做到幂等及事务一致性,或者实现断点续传能力;

       我们采用尽可能完备的测试质量规范,尽可能的提高系统的稳定性与可靠性。

2.3 系统回调

       系统回调,也是系统弱依赖的一种表现形式。A系统需要B系统,但是B系统又不能立刻给出成功与否的答复,就会采用回调来实现。例如第三方支付、保险公司出单、购买理财产品交易。        这种场景,依赖方发送Request,执行方会回复说请求已收到。待执行方处理完成后,回复给说执行成功或者失败。就好比我在微信上跟某A说,你帮我办件事,他说好的;某A处理完成后,微信上跟我说,我处理完了,处理结果是这样的。

       本次分享仅写了我们日常工作中在需求功能测试方面的一部分,不同的需求所需要考虑的点各不相同,本文只是很少一部分,留意待续。同时,您在阅读过程中,如认为有待交流沟通。欢迎联系本人邮箱lvguoyong@youzan.com。

关于有赞及加入有赞

关于有赞 https://www.youzan.com/intro/about 加入我们 https://job.youzan.com/
同时,您也可以直接把简历投递到 job@youzan.com   lvguoyong@youzan.com
欢迎关注我们的公众号