最近开始研究测试需求分析，得到曹老师指点一、二，在雪大嫂、导演等众多测友的大力支持下演绎了如下理论和心得：

　　一、测试需求分析定义：

　　测试需求提供一个测试应用程序所必须的详细的描述。

　　一个测试需求是：

　　有利于开发和测试

　　帮助定义测试对象和测试范围

　　设置明确的团队目标

　　发现需求中不完善和不足地方，进行完善以节省时间和投入

　　便于需求基线化和跟踪业务需求变更

　　一条有用的测试需求总是：

　　惟一的

　　精确的

　　有边界的

　　可测试的

　　举例：

　　系统主要事务的响应时间满足系统要求，为不符合要求的测试需求；

　　测试需求：在1G内存和1.73兆主频的计算机上在25个并发用户执行插入、更新和删除操作时端到端的响应时间在3秒时间内。

　　系统功能测试需求分类

　　1、 业务功能测试需求

　　2、 可靠性测试需求

　　3、 安全性测试需求

　　4、 易用性测试需求

　　5、 可移植性测试需求

　　6、 可维护性测试需求

　　上面对于测试需求的分类是依据软件质量模型而定的，对于效率我们放在性能测试需求中，而其他5种特性都应归入功能测试范畴。在这里，我们把安全性单独提出来，目的是强调安全性测试的重要性。尤其对于金融行业系统，其安全性是至关重要的。

　　二、提取测试需求

　　测试工作的依据首先是业务需求规格说明书，所以应该首先提取测试需求，把需求从业务需求中提取出来，再把业务需求分解为测试需求，每个业务需求对应一个或多个测试需求。

　　在分析测试需求和设计测试用例时，以需求规格说明书为依据，以业务功能为中心，以质量模型中的各子特性为出发点，同时深刻理解业务规则和隐式需求，通过与客户深入沟通，明确测试范围和质量目标，达到测试分析和设计全面、无遗漏。

　　什么是隐式需求呢？

　　从质量保证的定义：产品或服务满足显示或隐含需求能力的功能和特性总和。所以在提取测试需求时，除了关注显式提出的业务需求外，我们也应该关注隐式的需求。这些隐式需求包括：

　　1、用户隐式的需求。例如：行业规则、业务规则、原来系统已经实现约定俗成的操作或功能等。这些需求设计人员往往认为研发团队会知道这些规则，所以没有在需求中显示描述。这些地方由于没有明确约定，又缺少沟通，往往成为最容易出现缺陷的地方，不容忽视。

　　2、计算机领域的规范或习惯。这些方面是很难写到业务需求中的，业务需求往往是文字描述，很难准确描述系统展示界面，例如，如果某个输入我有限个元素，则应该用列表框或选择框控件实现，而用编辑框实现则要在输入中做很多判断，不断增加编程工作量，也增加测试工作量，同时给用户带来不便。

　　3、客户认为我们应该理解或在需求中遗漏的需求。例如，认为我们理解金融行业的会计规则，但是如果不在测试需求明确说明，则由于测试工程师没有金融行业会计方面的测试经验而忘记测试。

　　4、业务需求编写人员受计算机技术的能力。不知道性能指标如何描述或描述不准确。需要测试团队协助科技人员和业务人员把描述不准确、正确或隐含的性能指标需求显示描述清晰。