上节通过两个典型案例介绍了需求分析过程中遇到的问题，案例是笔者工作实践中曾发生过的实际场景，相信对读者会有启发。需求要如何分析，在网上可找到一些资料，如先准备好需求审核Checklist是一个通用的方法，但是对需求的理解（或分析）是一个复杂的脑力思维过程，与分析人员的经验、技术等关系密切。需求分析的目的是为了提取测试对象，正如需求可分为不同的层级一样，测试对象也可从粗到细，逐步细分。

　　提取测试架构设计模型中的测试对象，需要确定顶层方向性的测试对象，也可理解为测试业务涉及的测试类别，以使测试人员能针对不同的测试类别考虑对应的测试策略。不同的测试类别，需要不同的测试方法，会涉及不同的测试资源，这在项目开始之初，需在测试计划中规划好。如图5-7所示是常见的一些测试类别，图中的比例仅作为示意，不同行业的软件可能会有不同的比例。

图5-7  测试类别及其测试工作量比重示意图

　　1、功能测试

　　业务功能是软件产品的基础，与用户最贴近的也是这些基本功能。功能测试恐怕也是测试任何产品的重点，没有功能的产品相当于不能用，也不叫产品。而功能是多种多样的，这一块的测试需求基本上会占75%以上。一个软件系统通常由若干个子系统组成，每个子系统又由若干模块组成。对于每一个子系统或功能模块，它们在系统中充当的角色及复杂度不同，在测试框架设计阶段，可只列出子系统及功能模块测试大项，接下来在进行测试方案的设计时，再对模块及下面的测试项（功能点）进行分析。

　　2、性能测试

　　软件是否需考虑性能测试，测试什么？笔者认为这是任何软件产品都需要考虑的，只是被测软件不同，性能要求的关注点也会不同。如所测试软件是通过后台SQL 2005数据库来存储数据的，那么对数据库的访问速度，如查询速度是性能测试需考虑的，以及数据库的容量限置也需考虑。对于嵌入式软件，实时性要求较高，除了产品需求中明确定义的一些性能指标外，一些潜规则中与性能有关的特点，如软件界面的刷新速度、界面切换的速度等，都会影响用户的满意度，也可作为性能测试的关注点。这里的潜规则，指的是并未在需求中有明确定义，但它又是一些常识性的问题。例如，嵌入式产品中常有自带的RTC时钟，时钟的准确性就是一个潜规则的性能问题。笔者曾遇到过嵌入式产品上的时钟过了3天后，系统时间变慢了约1分钟，一周后，变慢了约5分钟的案例。

　　小贴士：

　　性能测试是一个较大的范畴，包括负载测试、压力测试和容量测试。其中负载测试是为了检验系统在给定负载下是否能达到预期的性能指标；压力测试是通过不断向被测系统施加“压力”，检验测试系统在压力情况下的性能表现；容量测试针对数据库而言，是在数据库中有较大数量的数据记录情况下对系统进行的测试。

　　3、接口测试

　　这里的接口测试并不是软件内部模块与模块之间的接口（这种接口测试在功能测试中可考虑），这里指的是软件与硬件、机械等其他专业之间的接口测试。正由于接口测试跨专业，涉及的人与事多且杂，常需要我们主动收集或参与项目接口专业组的方案讨论，主动多请教他们，例如组织相关专业组对测试同事进行设计宣讲，针对某技术点进行培训也是不错的做法。多了解产品的实现原理，并记录相关信息，作为测试需求的提取源。甚至有时主动分析其他软件接口专业的需求变更，以了解其对测试的影响。例如设备的驱动便是一种典型的测试对象，驱动程序是沟通软硬件之间协同工作的桥梁，驱动测试发现的问题有时不仅仅是软件的问题，还可能是硬件设计的问题。对于测试，在这方面的作用显得特别重要，如能发现这方面接口的问题，是对软件测试仅发现软件问题的常规要求的突破。发现的接口问题在项目经理眼里，你的贡献远远大于你发现一个纯软件的问题，因为它的影响远比纯软件的问题影响面广，对产品的质量意义更大。

　　小贴士：

　　驱动程序（Device Driver）全称为“设备驱动程序”，是一种可以使计算机和设备通信的特殊程序。它提供了硬件到操作系统的一个接口，协调了二者之间的关系，可以说相当于硬件的接口，操作系统只能通过这个接口，才能控制硬件设备的工作。人们都称“驱动程序是硬件的灵魂”、“硬件的主宰”，同时驱动程序也被形象的称为“硬件和系统之间的桥梁”。