后台回复「MTSC」，领取大会 PPT
阅读本文大概需要 5 分钟。
一、从一个 Bug 说起
最近在使用一个 IM 时，突然发现一个有趣的秘密。
话说这个 IM 有一个发起问卷的功能，这个功能支持匿名答卷，效果图如下：
有一次在使用时，我好奇的点了点几个入口，突然发现匿名的内容和实名确认名单，可以通过时间线进行关联，我简直惊呆了。
到底怎么关联的呢？别着急，听我慢慢说。
上图中应该能看到发起问卷的时间是3/14 21:38，记好这个时间，我们再打开确认人列表如下图：
从图中可以看到每个人确认后面（前面被打码掉的是实名的确认人信息），会有一个确认时间的记录，这个记录中左边是用户实名，右边是时间线。
接着我们返回到第一个图的问卷主页，点击问卷中某个问题的回答，会打开新的问卷结果查看页面，如下图：
看到没？每个匿名回答后面也有个时间，这个时间减去问卷发起的时间，恰好等于实名确认记录页面那个时间线（并且，它已经给做好了排序，实名确认记录的顺序和回答的顺序刚好相反，然后就完全一一对应了）。
我的天，原来这个匿名只是把实名和回答放到两个页面显示而已，吓得我一身汗。
二、我想说什么
今天不讨论这个 bug 的发现和定位，我想继续说说需求的合理性验证。
需求相关的话题，我之前有写过三篇文章了，可以点击如下链接回顾：
《测试人员参与需求评审的价值是什么》
《需求评审之实战演练》
《需求评审之隐性需求》
其中在第二篇文章中，我有提到测试人员在需求评审过程中，应该考虑需求的合理性。
按理说这种事情应该是产品来考虑的，但经常会发现产品对产品使用的路径考虑的没有测试周全。
比如上面这个例子，如果从每个功能单独来看，什么毛病都没有，说不定当时还测试出时间线显示不准确的问题呢。
但是把三个时间点一结合，就出现问题了，而这个问题又不是功能性问题，只是没有达到需求预期的「匿名问卷」的效果，所以这个效果应该也是我们一个重要的测试点。
如果是在需求评审阶段，评审合理性的时候就需要考虑设计是否满足了需求，如果是在测试阶段，就需要优先验证是否满足了需求的最终效果，而不是只是验证功能实现了正确的结果。
三、我们怎么做
其实谁也不希望出问题，但是真出现了问题也还是很无奈，比如上面这个例子，现在这个现状就是，之前做的那么多铺垫全白费了，满足了表面上的需求，却没有实现真正需要的需求，而且使用者可能都以为是真正的匿名呢，反而会造成一些使用上的隐患。
如果要规避这种问题，产品经理考虑问题的角度当然是需要更周全，特别是提供的设计方案稿，不能仅仅是满足了表面需求，但是说起来容易，做起来难呀。
如果是从测试角度看的话，我们需要固化测试人员对需求的关注度，同时要时刻记住需求合理性和需求全面性这两个关注点，时刻从这两个角度进行需求确认，只有这两个角度都经过验证通过后，才开始真正的功能测试。
又或者说把这两点当作方法论一样去应用和实践，借助方法论从而更有目的的指导实践。
今天重新聊这个话题，是因为发现这样的 bug 真的很无语，就算功能测试做的再怎么天衣无缝，结果反而事与愿违，甚至悲哀。
以上，记录了一个发现的奇葩 bug，基于此，建议大家在项目过程中都要关注需求的合理性，从而尽可能早地避免问题，不知道你是否同意我的观点，欢迎留言说说你的意见。
当然，如果你觉得自己有所收获，欢迎分享文章到朋友圈 点个「在看」让更多人看到，谢谢。
