梧州建设厅官方网站,建设网站经验,wordpress 加斜杠,柳州市网站建设公司一、什么是白盒测试
白盒测试是一种测试策略#xff0c;这种策略允许我们检查程序的内部结构#xff0c;对程序的逻辑结构进行检查#xff0c;从中获取测试数据。白盒测试的对象基本是源程序#xff0c;所以它又称为结构测试或逻辑驱动测试#xff0c;白盒测试方法一般分…一、什么是白盒测试
白盒测试是一种测试策略这种策略允许我们检查程序的内部结构对程序的逻辑结构进行检查从中获取测试数据。白盒测试的对象基本是源程序所以它又称为结构测试或逻辑驱动测试白盒测试方法一般分为静态测试和动态测试。
二、如何去做白盒测试
网上很多介绍白盒测试的文章会提到白盒测试的方法有代码检查法、静态结构分析法、静态质量度量法、逻辑覆盖法、基本路径测试法、路径覆盖等等。实际工作中的白盒测试并不是一上来就进行代码分析我个人理解白盒测试应该从以下几个步骤来一步一步执行
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 add 4.build request param 5.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 划分就不太合理会使一个商户的所有数据都在同一张表
分库分表后的查询插入和取出逻辑一致
关注性能不能比分之前差
感谢每一个认真阅读我文章的人礼尚往来总是要有的虽然不是什么很值钱的东西如果你用得到的话可以直接拿走 这些资料对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库这个仓库也陪伴我走过了最艰难的路程希望也能帮助到你凡事要趁早特别是技术行业一定要提升技术功底。
