先测使用时间记录的逻辑，再测累计时间统计的逻辑

做成可配置的？天用秒来代替。一天当成几天用。

你说的这种应该是根据表配置的吧，可以自己改下配置 比如上限时间改长一点或者活动时长改下时间单位，如果不能改配置，就让服务器加个重置的脚本指令，方便测试。如果是做游戏的话 服务器那边应该给你开个分支服务器的，没有的话测关于时间，数值啥的 很难搞的。

活动我之前测试过很多，像你这种测试需求在产品需求就需要提出来的，开发要考虑，通过改脚本来协助测试的。这个真没有啥好办法，你能想到的都算是 BUG，所以，必须要开发协助。

非常感谢各位大佬出谋划策；目前还是多准备了几个测试数据，做跨天测试；然后数据库自己尝试改了下，有效果，但是不知道是否会有影响，所以暂时还是先老实测完这个 feature 再研究研究

有几个点比较难测，跨天，跨月这种。还是配合 code review，然后再用合适的等价类搞定吧

这个虽然可以通过修改配置来让时间缩短到几分钟，但是会忽略一个最危险的测试点！ 就是实际的时间执行或者触发的时候，会不会和公司业务内的其他跑批等脚本 撞到一起，然后互相影响。还有就是边界值问题，每天的正好 24 点这种，算今天还是算明天？修改配置文件测试，很难覆盖到这些特殊边界

嗯嗯现在就是配合开发和服务器一起看看呢

是的，主要还是要覆盖边界值的情况是否会产生异常的数据，涉及这种跨天的 feature 是真的难搞啊

最稳妥的办法还是得部署上正式再验证一下

经常有时效性是天的需求，开发给的方案是用 redis 存储 key 里面带当天年月日，有效性是 24 小时，所以我的测试点变成写入的 redis 缓存 key 是否包含时间信息和 key 有效性

这个一般是找开发配合，让他们做成是可以配置时间的，不然我们不可能测个功能要等好几天吧。3 天，半个小时，累积在线时长 1 个小时。这些只是简单的一个数字，完全可以做成是配置化的。我们要测的是规则，而不是这几个数字。如果开发实在不做成可配置的 直接改库。

个人经验：
1、有配置表最方便，自己改。在代码里就让开发帮着改
2、服务器部署服务仅测试服务，评估不影响其他，直接修改服务器时间
3、让开发把时效代码拿出来，代码 review。真实的进行隔天测试，等价周，月，年无问题

不好测试的功能可以放到最后,然后去数据库自己造数据实现呀,最好是让后端给接口调用接口造数据