需求，毋庸置疑，是软件设计与测试的来源，但是需求除了终端用户的功能需求外，还有设计性需求、可制造性需求、可测试性需求等。而这些需求，对于测试工作而言，最后都需转化为测试需求。本章从测试需求的介绍开始，与读者分享如何超越于需求文档之外，收集更多、更全面的需求，然后如何分析这些需求，特别是一些隐含需求的识别，从而提取方向性的顶层测试对象。接着为提取到的测试对象部署测试策略，重点介绍了各种测试技术的裁剪与合理应用的方法。主要体现在以黑盒功能测试为主，适当采用白盒测试，活用灰盒测试，部分功能或模块采用自动化测试的方法上。同时要着眼于专项测试，以突破某特性的测试模式，以使测试对项目软件质量在可靠性与稳定性方面做出更多的贡献。测试的计划与整个测试过程的跟踪、控制方法也是策略中需考虑的主要内容，在本章也做了介绍。最后就测试策略中需考虑但容易被忽略的其他因素进行了一番介绍，以飨读者。

　　从测试需求开始

　　需求一词，对于从事软件行业的测试朋友来说，已是再熟悉不过了。然而笔者对它的理解提升，却是在一次偶然的活动中。一次，在公司部门组织的一次春游活动中，而导游小姐的一句服务语让我久久难忘。当时车内每人都发了1瓶水，最后还余一些。在半途中时，导游小姐热情地询问：“尊敬的旅客们，我这边还余5瓶水，请问哪些贵宾尚有加水的需求。”话语一出，就听到一群人异口同声地欢呼：“太专业了！”需求，在软件开发过程中，有特别的含义。远离办公室，在大家心情放松的车上能听到如此熟悉的专业术语，大家感到特别亲切，但又隐含着新意。服务源于需求，这是再正常不过的商业规则。测试是一种服务性的商业活动，测试需求的识别是后续测试工作的基础，也是起点。

　　测试需求主要来源于用户的业务需求，那么，该如何开始了解产品的业务，为测试任务迈开重要的一步呢？首先，要能识别测试需求，接着是分析此测试需求，最后确定并提取出测试对象，如图5-1所示。

图5-1  提取测试需求路线示意图

　　提取出了测试对象后，接下来需要确定对每一对象如何进行测试，拿出具体的方法及措施出来，这便是测试策略制定的问题。

　　多管齐下溯需求

　　料想测试朋友们，也曾遭遇过由于需求的频繁变化给后续开发、测试工作所带来的困扰，小则更改，大则原来的开发、测试工作被废弃。其中有需求管理的问题，也有市场压力问题，等等。总之，现实中需求就是有这种爱变的特性。话又说回来，爱变的需求，它是符合事物的发展规律的，如果不是这样，在我们工作生活的周围，又怎么会到处都充满着日新月异的新鲜事物？

　　需求，是开发工作的来源（输入），当然也是测试工作的来源。需求，要开发实现后才能变为产品，开发出来的产品是否符合用户的需求，需要测试来验证。无论是哪方面的需求，实现后都需要测试的验证。对测试需求的识别，也就是对需求的识别。针对爱变的需求，识别测试需求，对于测试工作来说至关重要的。对于这些变化了的需求（需求变更）或新增需求，如何及时获取正确且全面的信息，直接关系到测试的充分性与全面性。当然这与公司的需求管理有很大关系，在没有规范的开发流程支持或执行有偏离的情况下，测试人员的主观能动性发挥起着重要作用。

　　尽管有专门的需求文档，如产品需求或叫软件需求，对要做的产品功能有集中的需求定义。但是对于测试来说，不能只关注产品的功能需求，还要关注设计需求、非功能需求，如可靠性需求、可维护性需求等。如图5-2所示的需求类别，其中功能需求所占比例最大，约为80%左右，接着分别是设计需求与可靠性需求。图中的比例关系在不同行业的软件中要求会有不同，测试重点也就不同。

图5-2  需求类别