你遇到过的测试难题(3)实时数据流测试,数据库和Redis测试
- 业务背景
- 测试计划
- 测试准备
- 测试关注点
- SQL语句梳理
- SQL常用语句
- Redis 查询key整理
- Redis 常见命令
- 测试总结
业务背景
对于用户的浏览信息,进行数据整理,统计,聚合,前期已经有一系列的埋点工作,目前计划将埋点数进行,实时分析、统计、计算,其实埋点这个东西,早在10年前tb一早就已经在使用了,就是后台会收集每个用户的行为系习惯,比如地区,语言,兴趣爱好等一系列的信息,当时也有一个名字叫做‘千人千面’算法。
但对于刚刚起步的公司来说,通过大数据算法去分析客户,发掘客户,精准推荐的算法来说还是比较新颖的,前、后端、架构、BI去规划和定制。
前期项目涉及的测点有,数据库,Redis,埋点数据,日志、MQ等,根据技术设计架构有关。
测试计划
开发人员:2个(技术栈,框架搭建,业务编写)
开发时间:1周左右
测试时间:2周左右(包括测试环境,集成环境,线上环境)
测试人员:1人(流程畅通,业务畅通,场景合理,逻辑合理)
测试准备
- 新数据(跟进自己行业去指定)我是电商的~
不要有脏数据,所有的SKU SPU都要造全新的,并对要测试的几个商品名称记录号,或者将商品id记录好,方便后期在数据库中查找数据
商品名称 | 商品id |
A商品 | 001 |
- 测试环境,集成环境,线上环境 的数据库和redis
确认好,库名,表名
环境 | 库名 | 表名 |
测试 | testData | test_evn |
- 对于数据库,Redis,所有的字段和key
版本 | 维度指标 | 测试场景描述 | 数据来源 | 生成数据 | 预期结果 | 实际结果 |
V1.0 | 商品维度指标 | 商品销量 | 这里一般是SQL语句 | redis查询的结果 | 数据库、Redis均为正确 | 通过 |
测试关注点
- 数据库的数据
- Redis的数据
- SQL查询的语句(业务与逻辑)
- 数据的新增和更新(根据行业,比如买东西,退东西,看数据变化)
SQL语句梳理
- 根据自己习惯,简单说怎样方便就怎样写,我的SQL就是有中文的,因为除了给自己看,还给别人看,所有写得详细点,有点帮助
- 区分好每个条SQL的作用是什么,查什么的,考虑后面是否需要赋用
-- 查询某个商品,当天的销量
SELECT
g商品表.goods_id AS `商品ID`,
SUM(og订单商品id.quantity) AS `(求和)销售量`
FROM
`order` AS `o订单表`
LEFT JOIN order_goods AS `og订单商品id` ON o订单表.order_id = og订单商品id.order_id
AND og订单商品id.state = 1
LEFT JOIN goods_spec AS `gs商品规格` ON og订单商品id.goods_spec_id = gs商品规格.goods_spec_id
AND gs商品规格.state = 1
LEFT JOIN goods AS `g商品表` ON gs商品规格.goods_id = g商品表.goods_id
AND g商品表.state = 1
WHERE
o订单表.state = 1
AND o订单表.order_state = 8
AND o订单表.add_time BETWEEN 1612627200000 AND 1612713599000
AND g商品表.goods_id = 236261
ORDER BY
o订单表.add_time DESC
LIMIT 0, 100;
SQL常用语句
方法 | 作用 |
SUM | 聚合函数,求和 |
LEFT JOIN | 左连接 |
BETWEEN AND | 两个值直接的范围具有连贯性的 |
Redis 查询key整理
维度指标 | 测试场景描述 | redis | key |
商品维度指标 | 商品销量 | zrange | shareRecord:shopCount |
Redis 常见命令
命令 | 用法 |
zrange | zrange KEY 0 -1 withscores |
pfcount | pfcount KEY |
get | get KEY |
测试总结
- 测试点内容全通过
- 整理好SQL
- Redis查询KEY整理好
其实所谓难点,就是一开始并没有接触过,我们会学方法就好了,一般测试都离不开输入输出结果,也是当年入行测试第一句真理!
总的来说,不就是看数据嘛,确实啊,当然后续还会依赖第一期的数据进行复杂计算查询,SQL嵌套,SQL子查询,甚至涉及MongoDB的数据应用,和后台日志查看,这都是的后话,用方法战胜难点,其次多思考。