点击文末小卡片免费获取软件测试全套资料资料在手涨薪更快一、什么是白盒测试白盒测试是一种测试策略这种策略允许我们检查程序的内部结构对程序的逻辑结构进行检查从中获取测试数据。白盒测试的对象基本是源程序所以它又称为结构测试或逻辑驱动测试白盒测试方法一般分为静态测试和动态测试。二、如何去做白盒测试网上很多介绍白盒测试的文章会提到白盒测试的方法有代码检查法、静态结构分析法、静态质量度量法、逻辑覆盖法、基本路径测试法、路径覆盖等等。实际工作中的白盒测试并不是一上来就进行代码分析我个人理解白盒测试应该从以下几个步骤来一步一步执行1、使用静态代码分析工具Findbugs先找出一些简单的 bug操作空对象数组访问越界线程安全字符串拼接资源未关闭2、diff评估影响范围找边界和影响范围往上找找它的调用链找测试范围的边界往下找找它对下游的影响找影响范围3、做单测从上往下串不只是对改动方法做单测还要找到它影响的点从上到下往下串4、单独拉分支梳理代码逻辑checkpoint根据checkpoint画出流程图/时序图后面做接口测试的测试点/检查点bug梳理代码时能够确定的问题5、接口测试基于第四步代码梳理的checkpoint来做接口测试只做白盒测试不做接口测试无法将代码的整个逻辑理顺6、debug再做一遍远程debug将整个流程走一遍另外对于接口测试和白盒测试有些公司会引入代码覆盖率工具来衡量测试用例对代码的覆盖率关于这一点我们将在其他文章中做详细介绍。常用的代码覆盖率工具有CoberturaEclEmmaJacoco三、接口测试的策略看过有些介绍接口测试的文档核心思想就是根据接口文档构造不同的参数组合各种正常/异常的参数然后组装请求发送服务端最后进行返回结果的判断。这可能是很多测试同学认知的接口测试我们不能说这么做是错的但是如果我们只是这样来做接口测试对于线上系统来说有着极大的风险因为随着业务的越来越复杂很多测试点是接口文档所描述不到的。在上面描述白盒测试的步骤时我们说到会根据代码梳理的结果来画出流程图/时序图然后根据时序图上的各个点来构造各种正常/异常的测试场景进行接口测试这样才能更为完善的进行接口测试减小线上的风险。什么是时序图时序图Sequence Diagram亦称为序列图、循序图它通过描述对象之间发送消息的时间顺序显示多个对象之间的动态协作可以直观的传达系统内外之间的交互过程。我们可以简单的举个例子程序从入口进来先做了什么逻辑判断和处理处理完成后进行入库入库的数据是什么关键的状态是什么入库的数据哪些字段是我们要去检查的状态是如何变更的缓存的key是什么缓存失败的策略又是什么如何设计接口测试我们以下面这个微信扫描二维码支付为例来说明发起支付请求构造相同订单基于并发或者多线程请求被测服务超时其他异常微信Server回调Pay接口生成预支付订单回调多次是否能保证只生成一笔订单回调失败内部又如何处理返回未知异常返回已知异常调用微信下单接口提交预支付订单调用失败如何处理预支付订单不存在预支付订单过期确认订单密码正确密码不正确返回订单详情订单不存在未收到支付状态查询不到结果查询到支付中/支付成功/支付失败通过以上分析可以看出为什么我们说做接口测试一定要先把代码的逻辑梳理清楚。如果我们只从接口文档的描述来做接口测试我们对这些后台处理逻辑不清楚那么这些测试点就会被遗漏把所有风险都遗留到了线上。四、接口自动化测试1、分析功能及接口的优先级别在谈到自动化测试的时候很多同学上来就说我们使用 Python UnitTest/Java Junit使用了什么什么技术使用了什么什么框架。但是在我们考虑实施之前首先应该明确自动化测试的目标可以从以下几个维度考虑功能维度支付代收代付开户...这些功能包括的接口有哪些条用顺序是什么样的具体的执行流程又是什么样的业务维度核心业务流量维度百万级别千万级别风险维度资金风险出金、入金黄金流程维度核心业务流程我们需要从以上五个方面去考虑需要做接口自动化测试的接口有哪些然后就能够梳理出各接口及业务的的级别P0/P1/P2。2、自动化策略基于以上分析我们就定义接口测试的策略是要做单接口的还是模块级甚至是系统级的接口测试又或者是这三者都要做。场景级 -- 单接口模块级 -- 只在模块内预下单-提交订单-确认支付系统级 -- 整个业务流程-订单-支付-网关-回调3、定义自动化达成目标定义好自动化测试的策略后然后需要定义自动化测试要达成的目标。例如核心接口覆盖率 达到 50%黄金流程覆盖率, normal级别case, 场景级40%, 模块30%,系统 30%出金业务, 100% normal级覆盖入金, 60% normal级覆盖4、框架建设基本诉求case规范要求case量级, 预估, 2000多条.现状: 系统变更频繁程度, 业务接入的快慢程度, 当前资源投入情况. 变更的倾向性实现common env -- 工具 环境dao client -- MySQL、Redis、Dubbo、Httpcore(extension) -- 测试用例能力扩展执行前执行后参数处理等gen -- 自动生成代码manager -- case管理, 报告输出等等case模板1.clean db,2.db init(user_info)| redis init | Hive, Hbase,3.mock client add4.build request param5.send request(Dubbo|Http,Thrift, RPC), RetMsg. 1000,2000,sendRequestForSuccess()6.response assert,(errNo200,)7.db assert|redis assert.AccountDao().of().query(ColumnHolder.of().addColumn(order_id,111))ColumnHolder.getColumn(amount);Assert.assertEquals(ColumnHolder.getColumn(amount),100)AccountDaoAssert.assertEquals(amount,200)8.log assert(weak)9.db clean五、分库分表关注点表的数量2的幂指数字段的选择一般基于单个字段去分也有少数情况是基于多个字段一般基于索引字段能够让请求均分到各张表如按 OrderID 划分比较合理按 MerchID 划分就不太合理会使一个商户的所有数据都在同一张表分库分表后的查询插入和取出逻辑一致关注性能不能比分之前差最后感谢每一个认真阅读我文章的人礼尚往来总是要有的虽然不是什么很值钱的东西如果你用得到的话可以直接拿走这些资料对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库这个仓库也陪伴我走过了最艰难的路程希望也能帮助到你凡事要趁早特别是技术行业一定要提升技术功底。