白盒测试&&接口测试&&自动化测试

一、白盒测试：一种测试策略，允许我们检查程序的内部结构，对程序的逻辑结构进行检查，从中获取测试数据。白盒测试的对象基本是源程序，所以它又称为结构测试或逻辑驱动测试，白盒测试方法一般分为静态测试和动态测试。

二、如何做白盒测试

1、使用静态代码分析工具：FindBugs先找出一些简单的bug

• 操作空对象；
• 数组访问越界
• 线程安全
• 字符串拼接
• 资源关闭

2、diff评估影响范围，找边界和影响范围

　　往上找，找它的调用链，找测试范围的边界；

　　往下找，找它对下游的影响，找影响范围；

3、做单测，从上往下传

　　不只是对改动方法做单测；

　　还要找到它影响的点，从上到下往下串。

4、单独拉分支，梳理代码逻辑

　　checkpoint：根据checkpoint画出流程图/时序图，后面做接口测试的测试点/检查点；

　　bug：梳理代码时能够确定的问题；

5、接口测试：

　　基于第四步代码梳理的checkpoint来做接口测试；

　　只做白盒测试不做接口测试，无法将代码的整个逻辑理顺；

6、debug：debug执行、

三、接口测试策略

根据接口文档，构造不同的参数组合，各种正常/异常的参数，然后组装请求发送服务端，最后进行返回结果的判断。但是对线上系统会有极大的风险，因为随着业务的越来越复杂，很多测试点是接口文档所描述不到的。

根据代码梳理的结果来画流程图/时序图，然后根据时序图上的各个点来构造各种正常/异常的测试场景进行接口测试，这样才能更为完善的进行接口测试，减小线上的风险。

时序图：序列图、循序图，通过描述对象之间发送消息的时间顺序显示多个对象之间的动态协作，可以直观的传达系统内外的交互过程。我们可以简单的举个例子：

　　程序从入口进来，先做了什么逻辑判断和处理；

　　处理完成后进行入库，入库的数据是什么，关键的状态是什么；

　　入库的数据哪些字段是我们要去检查的，状态是如何变更的；

　　缓存的key是什么，缓存失败的策略又是什么；

如何设计接口测试，微信扫描二维码支付：

 

　　发起支付请求：

　　　　构造相同订单，基于并发或者多线程请求被测服务；

　　　　超时；

　　　　其它异常；

　　微信server回调pay接口生成预支付订单：

　　　　回调多次，是否能保证只生成一笔订单

　　　　回调失败，内部又如何处理

　　　　返回未知异常

　　　　返回已知异常

接口测试一定要先把代码的逻辑梳理清楚。如果只从接口文档的描述来做接口测试，我们对这些后台处理逻辑不清楚，那么这些测试点就会被遗漏，把所有风险都遗留在了线上。

 

四、接口自动化测试：

1、分析功能及接口的优先级别

　　实施前，首先应该明确自动化测试的目标，可以从以下几个维度考虑：

　　功能维度

　　业务维度

　　流量维度

　　风险维度

　　黄金流程维度

我们需要从以上五个方面去考虑需要做接口自动化测试的接口有哪些，然后就能够梳理出各接口及业务的级别（P0、P1、P2）

基于以上分析，我们就定义接口测试的策略，是要做单接口的还是模块级甚至是系统级的接口测试，又或者是三者都要做。

　　场景及--单接口

　　模块级--只在模块内，预下单-提交订单--确认支付

　　系统级--整个业务流程-订单-支付-网关-回调

定义自动化达成目标

　　定义好自动化测试的策略后，然后需要定义自动化测试要达成的目标。例如：

　　核心接口覆盖率50%

　　黄金流程覆盖率normal级别case，场景级40%

框架建设

　　基本诉求：case规范要求、case量级预估、现状：系统变更频繁程度、业务接入的快慢程度、当前资源投入情况、变更的倾向性

　　实现：common_env --工具+环境

　　　　　　dao + client --MySQL、Redis、dubbo、HTTP

　　　　　　Core--测试用例能力扩展、执行前、执行后、参数处理等

　　　　　　gen--自动生成代码

　　　　　　manager--case管理，报告输出等等

case模板：

　　clean db.

　　db init

　　mock client add

　　build request param

　　send request

　　rpc response assert

　　db assert

　　accountDao

　　columnHolder

　　assert.assertEquals

　　accountDaaoassert.assertEquals

　　log assert

　　db clean