有赞的深度需求功能测试

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

一、熟悉技术方案

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

  • 当前需求,涉及哪些应用的改动,或者我的业务需要改动哪些应用;
  • 了解每个应用在全站系统拓扑结构的节点位置;
  • 我的应用,调用其他应用接口,是强依赖还是弱依赖;
  • 我的应用,所提供的服务,是强依赖还是弱依赖;
  • 有些功能实现,是否有设计模式,还是硬编码;
  • 新老系统的兼容性、App新老版本兼容、不同手机版本的兼容性;
  • 技术方案中的Db变更方案、数据迁移方案、及T+1核对方案;
  • 是否使用缓存,及缓存数据如何保持一致的;
  • 异常情况下的健壮性,技术方案中是如何实现的;

二、测试方案设计

       在充分理解需求及技术方案后,从横向角度,我一般把功能测试三个部分。

2.1 人机交互

       最基本的人与设备间交互。例如小程序设置、在微信上打开有赞商品下单。

2.1.1 前端测试部分

       人机交互测试,有很大工作在页面测试。页面测试用例要写得尽可能详尽,否则,测试时,可能会有遗漏,特别是需要开发自测的用例场景。我们结合有赞前端框架及业务,编写《功能测试.页面测试.基本篇》。

       在实际工作,还需要有实际策略。现在微信小程序将注册开放给了开发者,在有赞也可以直接注册小程序。其中可以设置类目,这是类目怎么测。
       按照微信的要求,不同类目要求提交的证书各不相同。有些类目,可以选择证书类型(如图),有些类目是固定证书,证书也有单个和多个的要求。设计测试方案时,我们深入的开发确定,类目信息是前端硬编码,还是存在有赞后端,或者是从微信端直接读取。

  • 若是硬编码,需要逐个测试小程序200+类目的证书是否正确。
  • 若是存在有赞后台,前端通过设计模式实现,我们只需要验证设计模式无误,在check后端配置数据正确即可。
  • 若是实时读取微信,前端通过设计模式实现,我们只需要验证设计模式无误。
  • 对于读取有赞后台,风险是微信修改了类目证件要求,两方数据如何保持一致。
  • 对于实时读取微信,若微信访问失败,系统提示文案如何确定;也要问下自己,微信的所有类目,我都要支持吗,我的资质是否允许。

2.1.2 后台测试部分

       以大家比较熟悉的交易下单扣库存为例。我们买了某件商品,系统后台就需要扣减商品库存或者锁定库存。
       正常交易,我们买几件商品,从对应的库存中,扣掉几件就可以了。早期,因为是两个系统,两个事务,测试需要考虑如何保证事务的一致性。我们需要考虑:

  • 正常正向交易场景,是否能够正常扣减正确。
  • 正常正向交易场景,商品扣减失败,交易创建失败,商品需要回补。
  • 当商品扣减成功后,因为交易异常,回补前,商家编辑了库存,如何回补。
  • 交易调用库存中心扣减超时了,这时前端会提醒用户系统异常,请重试;对于超时,库存中心并无感知,它有可能已经把库存给扣减成功了。那么,方案中交易是如何告知库存中心,这时一般采用异步消息。
  • 下单过程中,出现请重试,交易系统是新建一个交易单还是复用交易单。
  • 如果复用交易单,对于库存回补,异步回补库存消息到达可能会在本次扣减成功后到达,系统如何确保不会错误回补。
  • 交易作为消息的推送者,如果消息推送失败,是否会重试;即要求消息不能丢失,又要确保回补不会因为消息生产者重试,导致多次回补。

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

2.2 任务

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

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

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

2.3 系统回调

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

  • 我们需要跟执行方确定双方系统幂等验证的条件。
  • 如果涉及跨防火墙通讯,需要考虑验证信息传输的正确性及合法性。
  • 对于回调后,如果存在复杂的业务处理,是不是先存储回调结果,再处理。
  • 对于某些特殊业务,还需要有T+1核对,保证双方系统的一致性。
  • 需要关注对方系统的性能,是否能够支撑相关业务的能力。
  • 同时,考虑其他特殊场景。举个例子,交易下单支付后,请求第三方支付,可能支付成功了,但是一直没有回调,这时交易超时关闭订单,这时回调了,这时系统如何处理。

2.4 系统对象生命周期

       我们在做测试方案设计,处理前面的三点,还会从对象生命周期考虑设计方案。

  • 我们需要知道,每个系统对象存在多少个状态,比如交易订单(如上图)。
  • 每个状态间是否可以正向扭转,逆向扭转,扭转条件是什么。
  • 例如,待支付状态,如果买单下单,不支付走了;这个单子不能一直是待支付,所以系统需要能够发现长期未支付,直接关闭;同时需要支持,买家关闭等。
  • 关闭订单时,系统能直接把单子关闭吗?它有没有可能已支付,只是支付回调还没有回来。
  • 如果因为系统设计,支付未回调之前,被关闭了;回调回来后,系统该怎么做,确保不会出现买家钱付了,单子被关闭了。
  • 对象不同状态的相关方有哪些,每个相关方都有哪些权限或者系统提示文档如何等。

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

关于有赞及加入有赞

关于有赞 https://www.youzan.com/intro/about 加入我们 https://job.youzan.com/

同时,您也可以直接把简历投递到 job@youzan.com   lvguoyong@youzan.com

欢迎关注我们的公众号


Original url: Access
Created at: 2019-09-26 18:05:36
Category: default
Tags: none

请先后发表评论
  • 最新评论
  • 总共0条评论