摘要：
一、熟悉技术方案 有赞现在没有纯粹的测试工程师，不论是通过阅读技术方案文档、或是跟开发 Face to Face 沟通技术方案。从中，测试同学需要了解一下信息： 1... 一、熟悉方案
有赞现在没有纯粹的工程师，不论是通过阅读技术方案文档、或是跟开发 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 后台测试部分
以大家比较熟悉的交易下单扣库存为例。我们买了某件商品，系统后台就需要扣减商品库存或者锁定库存。
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
21/212>
