有赞的深度需求功能测试

转自：https://tech.youzan.com/you-zan-de-shen-du-xu-qiu-gong-neng-ce-shi/?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io

 

序：在《有赞.测试团队介绍(一)》曾经提到过，咱们在测试需求项目时，会把需求逐级拆解，直到最小粒度。而后，各业务线的测试小伙伴把任务领走进行细化，同时，肯定一位主测分来主导复杂项目的测试工做。 
       在面试过程当中，不少小伙伴也会说，咱们会根据需求所描述的功能，进行测试。那做为一位应聘者，如何才能把本身以前工做的能力展现给你的面试官呢。 
       随着有赞SOA服务化的深刻推动，系统拓扑结构愈来愈复杂。咱们也在不断提高测试小伙伴的测试能力及问题思考的能力。 
       咱们的平常测试，通常须要考虑需求功能测试、性能测试、异常测试、安全测试。

1、熟悉技术方案

       有赞如今没有纯粹的测试工程师，不管是经过阅读技术方案文档、或是跟开发 Face to Face 沟通技术方案。从中，测试同窗须要了解一下信息：

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

2、测试方案设计

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

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

 
如无特殊说明，本文版权归 本文做者及有赞技术团队 全部，采用 署名-非商业性使用 4.0 国际许可协议 进行许可。
转载请注明：来自有赞技术团队博客 http://tech.youzan.com/you-zan-de-shen-du-xu-qiu-gong-neng-ce-shi/

欢迎关注有赞技术团队微信公众帐号了解更多，保持联系