测试在软件开发中存在的意义

         昨天在我们一个数字化管理平台项目组微信群里讨论的一个问题，引起了我的反思。我在想为什么系统已经上线半年多了才暴露这个问题，是因为时间到了2024年吗？

        首先是产品经理在群里问：“为啥现在XX例会模块23年月份被禁选了，导致23年的信息现在无法查看？”

        紧接着研发负责人反馈：“这个你当时不是说历史月的数据不让点，我们特意禁了的。”

       “你记错了吧，XX例会没有禁选需求，是要每个月份都能看的”产品经理再次说着。

       “之前说的禁过，我都记着呢。要不然我们禁这干啥？”研发负责人反问着。

       产品经理又说： “这是12月的截图，你看下代码，这咋能禁，23年12月看着都正常着呢。”

       研发负责人接着说：“当时2023年有数据  2022年没数据，我记得你当时说是把上年的禁了。”

      “是，但现在23年有数据，也被禁了，得打开对2023年的限制。”产品经理又说。

      “那22年21年是不是也打开？”研发负责人反问了一下。

      产品经理十分肯定的说：“不打开，23年之前都没数据还是保存禁选。”

       问题讨论到这里告一段落了。事情的起因是，之前我们测试的时候发现XX例会模块21年22年没有客户数据，点击时提示信息不友好，于是产品经理就要求研发人员把21年和22年禁选。然后研发人员就理解成了，每一年都不能查看上年数据，每一年都禁选上年数据。半年前，OK的，因为还是2023年，这么处理没有问题。但现在到了2024年了，2023年本身有数据，却也被禁选了，客户反馈这就是一个线上bug了。

       然后我们组长就问了我们这边的测试负责人，之前测试的时候没有考虑到2024年的测试场景吗？测试人员说：“没有，我们测试的时候是23年8月份，确实没想到2024年看不了数据的问题”。组长说：“好，那你们以后测试的时候需要考虑更多的时间场景，这次的这个问题就算是前车之鉴吧。”

       在我看来，这个问题的出现比较有特殊性，从表面上看一方面是开发对代码的处理逻辑识别的不全面，另一方面测试人员也没有想到2024年看2023年数据的问题。

       跳出表面，站在bug之上，我认为这是属于需求设计存在缺陷的问题。源头上从需求设计的时候就应该从正反两个方面去制定规则。2023年对之前没数据年份的处理逻辑是什么？2024及以后年对之前有数据年份的处理逻辑是什么？如果需求写到这么明确，我相信开发人员不会理解再有偏差，测试人员也能充分考虑到这个测试点。