接口测试点总结

同步异步
    同步调用
        请求的过程
            同步请求信息校验
                
                    一个接口为同步接口，
则首先要校验接口入参数的相关信息正确性。
校验信息的逻辑正确性，和他的长度，类型，特殊字符，非空校验等。
            组装下游请求I型信息
                该接口如果需需要调用其他的接口，
则需要组装信息，
给发送给第三方的信息做准备。
如果接口的调用第三方接口成功，则会去到相应的返回结果，经过处理后，在像等待中的上级进行返回结果。
                接口如果不进行第三方方的调用的话，则会进行内部处理，讲处理结果同步向上返回。
            响应信息处理
                将第三方请求返回的参数进行，响应的处理，在本接口中进行。
            同步向上返回
                返回的信息经过处理后，在向上级的接口进行返回。
        调用接口，可能出现的情况
            同步调用超时
                处理中
                    对于有些交易，如果响应时间过长，
则直接设置为处理中，等待系统相应后，再将系统状态翻转过来。
                降级
                    对于有多种选择的情况，如银行，一种调用不通，
将应该将他下掉，使用别的银进行支付。
                失败
                    如果超过时效时间，系统则立刻标记为失败，进行下一次请求。
但是需要注意，可能出现返回结果两次返回的可能。
            同步调用失败
                同步调用失败，则记录失败，对接口的事物，进行回退处理。
                或者进行失败处理，完成后则进行人工的干预处理。
                失败进行降级处理，让下个请求走下个渠道不走这个渠道了。
            同步重复调用
                幂等操作--即发送同样的报文请求，多次请求接口。
                    幂等请求，系统只能处理第一个请求，后面的请求不能处理。
                并发处理
                    高并发的情况，系统不能报错
        同步调用的总结
            HTTP请求，在掉通接口后，等待系统处理完成后，在断开HTTP请求。
    异步调用
        异步处理
            发送者组装的内容
                调用完成后，接口收到请求，立刻返回结果显示调用成功，
在过后，落状态处理中，调用方进行ob的跑批去被调用方进行查询，
或者被调用方主动调用调用方的相关接口，进行转改变更。
            形式
                调用方去主动获取状态，还是被调用方进行返回的状态。
            正确的解析和消费
                翻译的信息进行正确的解析，然后能达到相关的目的。
        异步重复发送
            重复
                多次使用相同的报文请求，进行接口的请求，不能多次的进行返回结果的返回。
            并发
                对接口进行高并发的请求，接口需要处理的正常。
            幂等
                幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。
        异步发送顺序
            同种Q
                调用了，两个接口，两个接口都会对（调用方）的同一条数据进行操作，如果进行的是同种操作。第二次进行的处理，则会无法变更。
            不同种Q
                如果进行的状态变更不是进行的，相同的，如一个变更为待确认，变为处理中，一个从处理中变更为完成，如果来那个返回信息的结果不同，则会处理结果出错。
        异步比同步快
            异步处理
                异步处理不用等待接口返回处理结果，就立刻的进行了下一次的请求。
            同步处理
                同步处理，必须要等到相应的结果处理完成后，
在进行下一次请求，如果并发量高，则会造成，服务器塔里过大。
        异步同步都返回
            不记得的了
            不记得的了
        异步消息类型用错
            queue
            topic

时间处理
    不同时间段的取值
        创建时间
        更新时间
        下单时间
        最终状态时间
        起息时间
        到账时间
        支付时间
        系统在上下游交互的时候，应该考虑到相关字段的传输，是否符合规格。
    特殊日期
        闰年
        理财成立日到期日
        对公节假日
        募集期结束如在节假日
        2-29的问题问题
            ***开发在写sql时，写的时间为2017-2-2mysql不会报错，但是会将数据存为00-00-00.从而影响程序运行。
    时间一致性
        服务器时间不一致
            程序获取的时间为服务器时间还是本机时间。
        时间格式不正确
        理财各时间
            合同展示时间
            页面展示时间
            计算时间
        日切时间点
        对账时间
        收益时间
        分割时间点的那个时间点属于那里
        跨日交易
            即，在前一日发起交易，但是在第二日完成了支付。
        时间不一致会引发资损。对账不平。

并发
    防止并发异常的方式
        悲观锁
            读上锁，其他线程药更改这条记录，则需要去等待，等待上一个数据处理完成，随时操作这条数据的进程只有一个。
            先上锁，在进行更新操作。其他进程等待，最安全的办法，但是效率最低。
            因为对数据是按照独占的方式打开的，那摩只能一个一个处理，效率很低。
            悲观锁的例子：：：：：select  satus 状态 from a where id =‘1000’for update； 查询发送积分。
if{状态  ==‘未领取’}{update a  set 状态=‘已领取’ where  id ==‘1000’\更新领取状态}{执行发积分的是事物}
        乐观锁
            不算是锁，但是起到了了控制的作用。
            select * from satus 状态 from a where id=‘1000\\查询积分发放用户的状态。’
//update a set 状态 =‘已领取’ where id ='1000 and'  状态 ={ 未领取}
if{更新到了数据} 执行发积分事物
else{执行回退操作}
            在进行更新操作的时候去判断用户之前的状态  如果是为发放  则进行更新  如果 不是  则进行回滚操作
        流水号防重
            //唯一值约束，id唯一索引或者
insert init b （id）（），插入一个主键，比如 客户号和  状态，如果重复了，数据库会报异常。
if{insert-count ==1}//更新到了一个记录
if（update_count==1）{执行发积分的事物}  else{执行回退事物}
            插入了一条则说明该用户没有进行发积分，在执行发积分的操作。并且更新状态，完成后执行发积分，否则会进行回退操作。
    一般情况的写法
        select  状态 from 表a where id=‘1000’，//查询用户表中查询发积分信息表
if（状态 ==‘未领取’）{ update a set 状态为==‘已经领取’}
执行发放积分的动作
        问题处在那里呢， 加入出现了高并发的情况  用户点击了两次 ，第一次查询后 未更新前，发生了第二次的查询，这样会更新两次，在冰法的时候会出现问题。

金额的处理
    积分计算
        是否包含手续费
            计算时，是否计算了手续费
            手续费的退款逻辑
            退款时是否包含了手续费
            主商品退款
        不足一个积分处理逻辑
        按照积分兑换汇率 5积分 1分钱 不足一分人民币
        不同币种消费积分计算换算
    优惠活动
        满立减
            限定次数等等
        优惠减
        买赠
        夸店付
        平台优惠券
        本店活动券
        优惠叠加
        满减叠加
    币种
        错填写
        币种不填写
        小币种
            日元
            韩元
            因为汇率的问题可能造成字段超大，数据库落库异常。
        涉及到外币的情况，要考虑币种的因素.
    带%转换
        收益率
        利率
        积分比例
        手续费
        有时候在界面显示中会将百分号忽略掉的,因为数据库中存的数据是
    金额单位
        接口金额
        数据库金额
        文件金额
        对账等,两方的金额必须一致,或者要经过换算的金额.不能有些金额单位是分,有些单位金额是元.
    金额类型
        string
        long
        bigdecimal
        money
    金额计算
        向上取证（进一法）
        向下取整（舍尾法）
        四舍五入（）
    退款,退分等等
        退款
            全额退款
            部分退款
            多个货物，一个订单，只退一个货物
            退款使用的金额应该是用户的付款金额，而不是客户的订单金额。
            退款最后一笔的退款金额，应该等于订单的总金额，减去最后一笔订单的金额。
            多个订单使用一张代金券，只退其中的一个货物，金额如何计算。
        退分
            退积分，应该按照逻辑来来判定，订单退款是否进行退积分 或者退券操作。
    额度
        关注利息 和罚息的计算方式
        关注额度是否实时及时变化
        到期日未还款的处理
        日限额等等
            发起一笔支付，退款后的额度回复

状态机
    状态更新顺序控制
        正向能够更新
            使用后的代金券，
程序尽量不要转化为未使用
        反向不能够更新
            已使用，无法转化为未使用
        状态变更前最好做校验，做成了乐观锁
    异常情况的处理
        空指针
        rpc异常
        ······
        程序报异常的时候，
是否有异常处理，回滚数据库等等操作。
系统需要一定的容错性，不能遇到了错误直接宕机、
    未知状态处理
        未约定
        进行状态变更前，进行状态变更的校验，
如果状态不符合的话，则不进行变更，报错误、
    状态位理解一致性
        上下游系统，通过接口连接，
返回的接口，进行查询或者字段变更的时候，上下游约定的，状态含义应该一致。
        不能出现了，上下游系统对字段所得理解不一致。
    状态未更新
        正常交易状态更新
            正常交易，如果状态未进行变更，该如何处理。
        调单状态更新新
            订单出现异常时间，系统该怎样处理
        人工状态更新
            人工干预系统时间，状态字段该如何处理
    状态重复处理
        同步成功。异步成功
        异步成功收到多次
    并发更新状态
        对状态变更进行更新 这个操作进行并发处理，看是否出错。--短时间连续点点点

资金流向
    新旧业务迁移
        新老替换
            新业务系统，接替老业务系统，两个系统只之间的接口定义，以流程上的定义，应该与之前的老系统一致.
        业务的连续性
            相关业务不能因为,新老业务的切换,则使有的功能不能进行操作,或者某些业务不能进行了.
    内部户的使用
        有进有出
        不进不出
    手续费的收取
        用户手续费
        商户佣金手续费
    主子账户的使用
        一账通
            子账户出入按社会自规则运行
            主子账户余额保持一致
            主子账户权限
            角色一致
        非一账通
            子账户出入按社会自规则运行
            主子账户余额可能不一致
            主子账户权限
            金额划转流动
    资金流闭环
        正常闭环
            资金可以形成资金流,资金进入,消费,流出都能完成.商户流出,个人流出,均能完成.
        业务特殊流程
            冲退转代发
                用户退款,转为代发,相当用户退款进行 转账操作
            冲退退余额
                用户进行了退款,将前推回到了自己的余额中标
    逆向交易唯一
        冲证
            冲正只能进行一次
        撤销
            撤销操作只能进行一次
        退款
            退款操作只能进行一次
        反向的操作只能进行一次,退款,冲正,撤销等操作只能进行一次.
    业务信息流一致
        信息
            资金流携带的相关信息不能变更
        金额
            资金流的金额不能变更

返回码
    返回失败
        通讯失败
            http请求没有通过接口传送到目标服务器
        交易失败
            TTTP请求到了，对方服务器，
但是请求报文的内容参数有问题
致使交易有问题
    未知返回码
        处理中
            返回的返回码汇中，出现了未知的返回码，应该讲状态填写为处理中。
        透传
            对未知的状态码，进行向上的透传，传到上一级别的接口。
    异常情况
        无返回码
            某个值没有返回码应该正常处理
        返回码为空
            返回码为空值，系统该如何处理
        系统异常
            系统出现异常该如何处理的
    返回码为成功
        通讯成功
            http请求请求到对方系统后返回来的，请求成功的指令。
        交易成功
            返回的成功后的指令。
    返回码为非终态
        处理中
            返回的状态码不是最终的状态，认定为处理中。继续进行处理。
            订单丢失，则需要继续进行的处理为，重新吊起订单。
        掉单
            数据的处理结果，没有被返回，则需要进行，返回的信息，从发起调用方，在进行调用，重新拉起订单。
    增加新的返回码
        增加新的返回码
            需要上下游系统，都要对新的返回码做兼容处理。
                上下游系统，都要支持新的返回码，不能上游返回一个新的返回码
下游系统则进行了，无返回码处理、
            需要联调。
                上下游系统需要进行新的返回码的联调。
        添加映射关系
            需要在上下游系统中建立新的对应映射关系、
            需要让系统指导响应码和相应信息的对应关系。

批处理
    批次的内存处理
        文件太大
            文件太大会导致，
内存一次读入，造成内存的崩溃。
        失败回滚
            特意要注意，失败的时候可能储存到临时表，
但是，要考虑临时表的大小，不能写错误信息，造成信息的错误。 
    批次划分处理
        话分批次错误
            对信息要进行分批处理，上下批次进行的时候，要对分批处理的一句校验
不能出现，一条数据，被分批划分了好多次，这次在这个批次汇中，下次在下一个和批次汇中。
            一次分批次过大，造成数据处理过程中，出现了内存问题。
            单次处理过大的信息量，造成了系统崩溃。
    文件的批处理
        分批
        失败回退
        还需要注意接口的时效性，
一个接口传输数据不能超过30分钟，1800秒。
    批的事物处理
        失败混滚
            失败回滚
            事物处理失败，完成后需要你进行回滚操作

服务器端，兼容性
    新老版本并行兼容
        数据库老板板的处理
            分支合并，新的系统的数据，
对老系统进行迁移，需要支持，他们的互相迁移
        老数据新版本的处理
            老的数据，新的系统需要支持的。
    数据兼容
        存量数据
            新的版本需要对数据库中的存量数据进行兼容，需要支持他们的处理，不能出现问题的。
            在一个，新的程序需要支持，存量数据的数量级，意思就是说，新的代码需要支持的搜索数量级，至少等于现在系统设计的存量数据级别。
        迁移过来的数据
            数据迁移，外来的数据，迁移过来，需要考虑到新的数据，新系统是否支持他们的数据格式（长度，非空等等校验），在一个需要考虑冲到他们的数量级。
    缓存兼容
        有缓存
        无缓存
        缓存雪崩
            缓存数据的过期时间设置随机，防止同一时间大量数据过期现象发生。
            如果缓存数据库是分布式部署，将热点数据均匀分布在不同搞得缓存数据库中。
            设置热点数据永远不过期。
        缓存击穿
            设置热点数据永远不过期。
            加互斥锁
    db兼容
        字段长度变更
        字段类型的变更
        是否有必必填变更
        db配置内容变更
    并行击穿
        如果同行来那个版本并行会出问题的。
            解决方案
                
从缓存取不到的数据，在数据库中也没有取到，这时也可以将key-value对写为key-null，缓存有效时间可以设置短点，如30秒（设置太长会导致正常情况也没法使用）。这样可以防止攻击用户反复用同一个id暴力攻击

                接口层增加校验，如用户鉴权校验，id做基础校验，id<=0的直接拦截；
        扣减库存的逻辑
            老版本：下单时，减库存。
            新版本,支付时扣减库存。

传参校验
     业务分支
        不同版本分支
        不同渠道分支
        不同产品线
    字段
        字段长度
        必填
        sql注入
            SQL注入攻击1
                原理：
                    因为拼接SQL语句，导致输入内容被当作SQL语句执行。
                    SQL语句注释符号：--在oracle和mssql都可用，mysql可以用# /**/。
                判断方法：
                    and/or 1=1 及 and/or 1=2 注入判断大法：
当参数为2 and 1=1去查询时，由于1=1为true所以能够正常的返回查询结果；
当传入参数2 and 1=2时查询结果是不存在的，所以没有显示任何结果。
                    order by 字段判断大法: 
执行order by 4正常显示数据
order by 5错误说明查询的字段数是4
                防范方法：
                    PreparedStatement实现防注入：
SQL语句被预编译并存储在PreparedStatement对象中，
然后可以使用此对象多次高效地执行该语句。
                    http://zone.wooyun.org/content/2448
                Web项目中/WEB-INF/lib下和对应容器的lib下有MySQL等数据库连接驱动包，那么就能够连接相应数据库。
                Web当中最容易出现SQL注入的地方：
1、常见的文章显示、分类展示。
2、用户注册、用户登录处。
3、关键字搜索、文件下载处。
4、数据统计处（订单查询、上传下载统计等）经典的如select下拉框注入。
5、逻辑略复杂处(密码找回以及跟安全相关的)。
        类型
        非必填
    返回值