本篇文章主要讲述软件测试技术之有赞的深度需求功能测试，希望阅读本篇文章以后大家有所收获，帮助大家对相关内容的理解更加深入。

　　一、熟悉技术方案

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

　　1.当前需求，涉及哪些应用的改动，或者我的业务需要改动哪些应用；

　　2.了解每个应用在全站系统拓扑结构的节点位置；

　　3.我的应用，调用其他应用接口，是强依赖还是弱依赖；

　　4.我的应用，所提供的服务，是强依赖还是弱依赖；

　　5.有些功能实现，是否有设计模式，还是硬编码；

　　6.新老系统的兼容性、App新老版本兼容、不同手机版本的兼容性；

　　7.技术方案中的Db变更方案、数据迁移方案、及T+1核对方案；

　　8.是否使用缓存，及缓存数据如何保持一致的；

　　9.异常情况下的健壮性，技术方案中是如何实现的；

　　二、测试方案设计

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

　　2.1 人机交互

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

　　2.1.1 前端测试部分

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

　　在实际工作，还需要有实际策略。现在微信小程序将注册开放给了开发者，在有赞也可以直接注册小程序。其中可以设置类目,这是类目怎么测。

　　按照微信的要求，不同类目要求提交的证书各不相同。有些类目，可以选择证书类型(如图)，有些类目是固定证书，证书也有单个和多个的要求。设计测试方案时，我们深入的开发确定，类目信息是前端硬编码，还是存在有赞后端，或者是从微信端直接读取。

　　若是硬编码，需要逐个测试小程序200+类目的证书是否正确。

　　若是存在有赞后台，前端通过设计模式实现，我们只需要验证设计模式无误，在check后端配置数据正确即可。

　　若是实时读取微信，前端通过设计模式实现，我们只需要验证设计模式无误。

　　对于读取有赞后台，风险是微信修改了类目证件要求，两方数据如何保持一致。

　　对于实时读取微信，若微信访问失败，系统提示文案如何确定；也要问下自己，微信的所有类目，我都要支持吗，我的资质是否允许。

　　2.1.2 后台测试部分

　　以大家比较熟悉的交易下单扣库存为例。我们买了某件商品，系统后台就需要扣减商品库存或者锁定库存。

本文由职坐标整理发布，学习更多的相关知识，请关注职坐标IT知识库！