测试环境存在的问题：
1、极有可能存在大部分脏数据，因多个项目并行，又不能去删除那部分脏数据
2、存量数据会比线上环境要少，比如在测试一些电商站点的时候会提前插入一些商品信息，类目信息物流信息等
3、动态数据可能不会像线上环境那样真实，比如在测试电商站点的发布商品功能的时候，往往会去创建一些新的商品
解决办法：
1、如果有预发布环境的话，可以尽量保持跟线上数据相当的量级，这样一些测试环境不好测出来的由于数据量导致的问题可以在预发布环境测出来，开发还有时间可以进行修复
如何准备数据：
前提：测试之前对被测业务应该是很熟悉了（需要知道每个字段的取数逻辑）
1、爬虫策略。
如果是新项目/产品的话，线上没有存量数据可以导，那么可能要去友商那里爬一些数据，导到测试环境做测试。比如做一个旅游站点，开始的时候是没有用户的游记的，这时候就要去类似站点爬一点来测试了。
2、定量+脱敏策略。
只上一些线上数据，比如只在线上拉1000个商品，1000个用户信息，然后做脱敏。这里技术实现难度会比较高，毕竟要把关联表理顺
3、全量+脱敏策略。
直接定期把线上的数据做脱敏，导入到测试环境。这里脱敏是必选，数据泄漏导致的问题严重程度往往比普通的线上bug要严重得多
遇到的坑：
1、场景一：渠道人员拓展门店后，满足条件的可以报名一些活动，统计门店的订单信息
开发设计：新增两张表----门店订单表、活动门店订单表
测试过程中都是通过流程生成数据或者跑脚本生成数据来测试，2张表的金额一致，没有发现问题，后来就随意改了门店订单表的金额，发现活动门店的数据在首页展示和详情页展示的不一致，
原因：经查发现两边的取数不一致，首页取的是活动门店订单表的金额，详情页取的是门店订单表的金额
总结：
虽说这种场景非常少见，但测试也要极度重视，开发应保持取值逻辑一致
2、场景二：页面上有3个tab页，展示不同的排名数据，比如本月交易额、今日交易额、上月交易额
结果：测试环境因数据量不够多，未发现响应慢的问题，发到 beta 环境时，因为线上庞大的数据量，导致接口响应时间不可接受
开发处理：修改代码执行顺序，想尽一切办法减少数据规模，保证接口的响应速度
1）SQL 条件中若包含 in 查询，一定要想尽一切办法减少条件数量
2）必须关注 SQL 执行结果的数据规模，若一次性返回大量数据，非常损耗性能
网友评论