? ? ? ? ?昨天在我们之前参与的一个数字化管理平台项目组微信群里讨论的一个问题，引起了我的反思。我在想为什么上线半年多了才暴露了这个问题，就因为到了2024年了吗？
? ? ? ? 首先是产品经理在群里问：“为啥现在XX例会模块23年被禁选了，23年的信息现在无法查看了？”
? ? ? ? 紧接着研发负责人反馈：“这个当时不是说了历史月的数据不让点，我们特意禁了的。”
? ? ? ?“你记错了吧，XX例会没有禁选需求，是要每个月份都能看的”产品经理再次说着。
? ? ? ?“之前说的禁过，我都记着呢。要不然我们禁这干啥？”研发负责人反问着。
? ? ? ?产品经理又说：?“这是12月的截图，你看下代码，这咋能禁，23年12月看着都正常着呢。”
? ? ? ?研发负责人接着说：“当时2023年有数据 ?2022年没数据我记得当时说是把上年的禁了的。”
? ? ? “是，但现在23年有数据，但是也被禁了，得打开限制”产品经理又说。
? ? ? “那22年21年也打开？”研发负责人反问了一下。
? ? ? 产品经理十分肯定的说说“不打开，23年之前都没数据还是禁选。”
? ? ? 问题讨论到这里告一段落了。事情的起因就是，之前我们测试的时候发现XX例会模块21年22年没有客户数据，点击时提示信息不友好，于是产品经理就要求研发人员把21年和22年禁选。然后研发人员就理解成了，每一年都不能查看上年数据，每一年都禁选上年数据。半年前，OK,是2023年这么处理没有问题，现在到了2024年了，2023年之前有数据呢，却也被禁选了，客户反馈了就是一个线上bug了。
? ? ? ?然后我们组长就问了我们这边的测试负责人，之前测试的时候没有考虑到2024年的测试场景吗？测试人员说：“没有，我们测试的时候是23年8月份，确实没想到2024年看不了数据的问题”。组长说：“好，那你们以后测试的时候需要考虑更多的时间场景，这次的这个问题就算是前车之鉴吧。” 在我看来，这个问题的出现比较有特殊性，最主要还是开发对代码的处理逻辑识别的不全面，当然测试人员也没有想到2024年看2023年数据的问题。
? ? ? ?站在bug之上，我认为是需求设计的问题。需求设计的时候就应该从正反两个方面去制定规则。2023年对之前年份的处理逻辑是什么？2024及以后年对之前年份的处理逻辑是什么？如果需求这么明确，我相信开发人员不会理解有偏差，测试人员也能充分考虑到这个测试点。
? ? ??
? ? ??