记一次时间推移业务测试

测试总结-时间推移

测试背景

	由于项目机制,用户的操作数据以及后续数据都与时间相关,时间推移的决策就显得非常重要.时间前移还是后移影响着整个测试流程.由于用户的操作也随时间影响,显然时间往后推移是比较服务预期逻辑的.

测试目标

​ 通过模拟时间推移,观察用户数据并校验其正确性

测试方案

前置条件:测试代码和db(docker)都是在测试宿主机上

在本次时间推移测试中,有两种测试方案(前置条件:)

测试方案1: 修改系统时间

修改系统时间的方法可以参考[附录1-修改系统时间]

优点:

1. 这种方法是最直接的, 代码中获取的时间就是修改后的系统时间,db亦是如此.

缺点:

1. 前置条件是需要关闭系统时间自动同步.

   2. 在没有脚本的帮助下,每次需要在命令终端通过命令修改时间.
      3. 在有随着时间变化的业务情况下(比如,每日用户数据情况),需要而外的脚本调用支持

适用场景推荐:

1. 比较适合观察随时间变化的业务数据,比如电站的单价,年化
2. 在会写脚本的情况下,[缺点3]不再是问题,很大程度上可以提高测试效率

测试方案2: 修改业务代码中获取当前时间的方法

方案2需要将业务代码中获取当前时间相关代码都通过一个工具类公有方法获取(比如new Date(), System.currentTimeMillis()). 这里以new Date() 获取当前时间为例.DateUtil中提供获取当前Date数据接口

public static int dateAdd = 4; // 增加天数

public static Date getCurrentDate() {
    Date date = new Date();  // 获取系统时间

    return addTimes(date, dateAdd, CalendarTimeType.DAY); // 系统时间往后加dateAdd天
}

优点:

1. 方便大范围时间推移
2. 对于[有随着时间变化的业务],能够通过编写代码友好的支持

缺点:

1. 该方法只能修改业务代码运行时通过指定接口获取到的时间(比如DateUtil.getCurrentDate())
2. 对于db中自动时间不能友好的支持,除非业务代码在执行响应sql语句时作为参数传过来.

适用场景:

​ 在大规模时间推移的情况下,以及有随着时间变化的业务情况下能够友好的支持.

本次测试对于今后开发的帮助

​ 在今后的开发过程中,在可预知有时间推移的情况下,我们可以将业务代码中的关于时间的代码建议参考方案2,以方便日后的时间推移测试.

附录1: 修改系统时间(Ubuntu)

开启/关闭系统时间同步

# 开启时间同步
timedatectl set-ntp true
# 关闭时间同步
timedatectl set-ntp false

设置时间

# date 方式
date -s "2019-06-19 17:50:05"