无论是哪一类需求，在产品研发的过程中一直都会有变化，而这些变化常可能是体现在专家评审的会议纪要或邮件中，或QQ的即时讨论中等。按理来说，需求分析人员需转换需求到专门的文档中，但实际运作中，常会出现需求转换慢，或根本就漏掉了。但是测试不能漏，测试是软件质量的最后把关者。在这种情况下，我们需要把关注范围放大，以多管齐下的方式关注需求的入口，如图5-3所示。从各种可能的渠道及时获知需求信息，作为工作的来源，同时反推需求，要求把零散的需求文档化或纳入需求库，正式地给出测试的依据。从而使“测试尽早介入，开展测试相关工作成为事实”，并使测试影响着需求、开发成为可能（这与测试人员对系统及项目的熟悉程度，是否能给需求、开发一些合理或有建设性的建议有关）。
图5-3 多管齐下的测试需求
注：图中正式需求的来源用粗线表示，非正式需求来源用虚线表示
质疑精神，是我们测试人员需要的气质，在提取测试需求、追溯需求的来源、实现背景过程中大可充分发挥，这对我们是否能真正理解用户场景需求很有用，见下面案例。有时需求分析人员未必能给你满意的回答，没关系，我们可以再往前溯，直接与市场，甚至是一线用服或用户直接交流，直到弄明白真相为止。这也是我们突破开发内部交流，把目光看得更远的机会。
【案例】MP4的日历提醒事件丢失了
某公司生产MP4电子产品，其中的应用软件是自主研发的，日历行程便是其中一款应用程序。卓A是软件测试部负责此日历行程的测试工程师，在做日程提醒事件测试时，他发现如果MP4电力不足（不足于开机），而这段时间正好有提醒事件发生，则在下次开机后不会再提醒，即发生在没电池时段内的提醒事件会丢失。而对于这种特殊情况，需求并未有明确定义（需求只定义了到达约定的时间便进行响铃提醒，并弹出事件窗口）。于是卓A找到需求、开发讨论关于这种特殊情况的处理，开发认为，电力不足的情况下，本来就不可能开机，提醒事件也就不可能弹出来，目前的处理是合理的。需求设计人员认为，如果在不能开机的情况下，提醒事件需在下次开机后进行积累提醒，如果用户一个月没用此机，事务每天又多的话，再次开机后的消息太多了，光关闭这些事件窗口都不是一件易事，用户未必欢迎。最后这个问题就此搁浅（挂起）了。
无独有偶，当该产品上线约一年后，从市场返回一张更改申请单，上面反映“成都客户陈女士于某年某月某日购买的一款M680型号的高档MP4，一天晚上，取出机子的电池在机外充电。后来由于忙于其他事情，3天后才再次打开MP4来使用后发现，这3天内的提醒事件一个都没有，导致她把提前3天预订飞机票的事给忘了，误了她的一桩大事。后来打电话到某公司当地办事处进行投诉。
相关链接：
