需求，毋庸置疑，是软件设计与测试的来源，但是需求除了终端用户的功能需求外，还有设计性需求、可制造性需求、可测试性需求等。而这些需求，对于测试工作而言，最后都需转化为测试需求。本章从测试需求的介绍开始，与读者分享如何超越于需求文档之外，收集更多、更全面的需求，然后如何分析这些需求，特别是一些隐含需求的识别，从而提取方向性的顶层测试对象。接着为提取到的测试对象部署测试策略，重点介绍了各种测试技术的裁剪与合理应用的方法。主要体现在以黑盒功能测试为主，适当采用白盒测试，活用灰盒测试，部分功能或模块采用自动化测试的方法上。同时要着眼于专项测试，以突破某特性的测试模式，以使测试对项目软件质量在可靠性与稳定性方面做出更多的贡献。测试的计划与整个测试过程的跟踪、控制方法也是策略中需考虑的主要内容，在本章也做了介绍。最后就测试策略中需考虑但容易被忽略的其他因素进行了一番介绍，以飨读者。
从测试需求开始
需求一词，对于从事软件行业的测试朋友来说，已是再熟悉不过了。然而笔者对它的理解提升，却是在一次偶然的活动中。一次，在公司部门组织的一次春游活动中，而导游小姐的一句服务语让我久久难忘。当时车内每人都发了1瓶水，最后还余一些。在半途中时，导游小姐热情地询问：“尊敬的旅客们，我这边还余5瓶水，请问哪些贵宾尚有加水的需求。”话语一出，就听到一群人异口同声地欢呼：“太专业了！”需求，在软件开发过程中，有特别的含义。远离办公室，在大家心情放松的车上能听到如此熟悉的专业术语，大家感到特别亲切，但又隐含着新意。服务源于需求，这是再正常不过的商业规则。测试是一种服务性的商业活动，测试需求的识别是后续测试工作的基础，也是起点。
测试需求主要来源于用户的业务需求，那么，该如何开始了解产品的业务，为测试任务迈开重要的一步呢？首先，要能识别测试需求，接着是分析此测试需求，最后确定并提取出测试对象，如图5-1所示。
图5-1 提取测试需求路线示意图
提取出了测试对象后，接下来需要确定对每一对象如何进行测试，拿出具体的方法及措施出来，这便是测试策略制定的问题。
多管齐下溯需求
料想测试朋友们，也曾遭遇过由于需求的频繁变化给后续开发、测试工作所带来的困扰，小则更改，大则原来的开发、测试工作被废弃。其中有需求管理的问题，也有市场压力问题，等等。总之，现实中需求就是有这种爱变的特性。话又说回来，爱变的需求，它是符合事物的发展规律的，如果不是这样，在我们工作生活的周围，又怎么会到处都充满着日新月异的新鲜事物？
需求，是开发工作的来源（输入），当然也是测试工作的来源。需求，要开发实现后才能变为产品，开发出来的产品是否符合用户的需求，需要测试来验证。无论是哪方面的需求，实现后都需要测试的验证。对测试需求的识别，也就是对需求的识别。针对爱变的需求，识别测试需求，对于测试工作来说至关重要的。对于这些变化了的需求（需求变更）或新增需求，如何及时获取正确且全面的信息，直接关系到测试的充分性与全面性。当然这与公司的需求管理有很大关系，在没有规范的开发流程支持或执行有偏离的情况下，测试人员的主观能动性发挥起着重要作用。
尽管有专门的需求文档，如产品需求或叫软件需求，对要做的产品功能有集中的需求定义。但是对于测试来说，不能只关注产品的功能需求，还要关注设计需求、非功能需求，如可靠性需求、可维护性需求等。如图5-2所示的需求类别，其中功能需求所占比例最大，约为80%左右，接着分别是设计需求与可靠性需求。图中的比例关系在不同行业的软件中要求会有不同，测试重点也就不同。
图5-2 需求类别
无论是哪一类需求，在产品研发的过程中一直都会有变化，而这些变化常可能是体现在专家评审的会议纪要或邮件中，或QQ的即时讨论中等。按理来说，需求分析人员需转换需求到专门的文档中，但实际运作中，常会出现需求转换慢，或根本就漏掉了。但是测试不能漏，测试是软件质量的最后把关者。在这种情况下，我们需要把关注范围放大，以多管齐下的方式关注需求的入口，如图5-3所示。从各种可能的渠道及时获知需求信息，作为工作的来源，同时反推需求，要求把零散的需求文档化或纳入需求库，正式地给出测试的依据。从而使“测试尽早介入，开展测试相关工作成为事实”，并使测试影响着需求、开发成为可能（这与测试人员对系统及项目的熟悉程度，是否能给需求、开发一些合理或有建设性的建议有关）。
图5-3 多管齐下的测试需求
注：图中正式需求的来源用粗线表示，非正式需求来源用虚线表示
质疑精神，是我们测试人员需要的气质，在提取测试需求、追溯需求的来源、实现背景过程中大可充分发挥，这对我们是否能真正理解用户场景需求很有用，见下面案例。有时需求分析人员未必能给你满意的回答，没关系，我们可以再往前溯，直接与市场，甚至是一线用服或用户直接交流，直到弄明白真相为止。这也是我们突破开发内部交流，把目光看得更远的机会。
【案例】MP4的日历提醒事件丢失了
某公司生产MP4电子产品，其中的应用软件是自主研发的，日历行程便是其中一款应用程序。卓A是软件测试部负责此日历行程的测试工程师，在做日程提醒事件测试时，他发现如果MP4电力不足（不足于开机），而这段时间正好有提醒事件发生，则在下次开机后不会再提醒，即发生在没电池时段内的提醒事件会丢失。而对于这种特殊情况，需求并未有明确定义（需求只定义了到达约定的时间便进行响铃提醒，并弹出事件窗口）。于是卓A找到需求、开发讨论关于这种特殊情况的处理，开发认为，电力不足的情况下，本来就不可能开机，提醒事件也就不可能弹出来，目前的处理是合理的。需求设计人员认为，如果在不能开机的情况下，提醒事件需在下次开机后进行积累提醒，如果用户一个月没用此机，事务每天又多的话，再次开机后的消息太多了，光关闭这些事件窗口都不是一件易事，用户未必欢迎。最后这个问题就此搁浅（挂起）了。
无独有偶，当该产品上线约一年后，从市场返回一张更改申请单，上面反映“成都客户陈女士于某年某月某日购买的一款M680型号的高档MP4，一天晚上，取出机子的电池在机外充电。后来由于忙于其他事情，3天后才再次打开MP4来使用后发现，这3天内的提醒事件一个都没有，导致她把提前3天预订飞机票的事给忘了，误了她的一桩大事。后来打电话到某公司当地办事处进行投诉。
相关链接：
好钢用在刀刃上：测试技术应用之合适设计
测试设计不只是测试设计工程师的事
软件测试流程改进设计案例分享
认识测试流程
测试管理中的隐形指挥棒：测试组织模式的设计（3）
测试管理中的隐形指挥棒：测试组织模式的设计（2）
测试管理中的隐形指挥棒：测试组织模式的设计（1）
解读测试设计
测试设计景观