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

一、测试需求分析定义：

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

一个测试需求是：

有利于开发和测试

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

设置明确的团队目标

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

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

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

惟一的

精确的

有边界的

可测试的

举例：

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

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

系统功能测试需求分类

1、 业务功能测试需求

2、 可靠性测试需求

3、 安全性测试需求

4、 易用性测试需求

5、 可移植性测试需求

6、 可维护性测试需求

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

二、提取测试需求

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

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

什么是隐式需求呢？

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

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

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

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

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

通过多个项目上线后的问题反馈来看，原因主要是：

1、对实际业务中可能发生的情况或者说场景考虑不足。

例如：已经到了交易闭市时间，例如5点整闭市，而在柜面在接近5点时发送了一个请求操作，服务器接收到该请求后，把这个操作请求发送到其他系统（交易所系统）请求进行处理，而这个过程中，已经到5点整（实际生产系统中，各服务器系统的时间并非完全同步），而此时服务器已经关闭了交易，造成无法接收请求处理的操作结果，而此时在交易所系统已经做了记录操作成功，但由于银行服务器没有接收到返回，造成产生了单边交易。

2、用户违反操作规则或业务规则操作。

虽然在测试中测试人员会考虑很多异常操作和违反业务规则的情况，但往往在测试阶段由于各种各样的原因没有进行测试（例如：缺少测试设备，在测试中没有使用POS机，而通过软件界面输入到系统与通过POS机设备输入可能存在差。）违反规则的例子：更换银行卡问题。某客户在北京分行开户，后在上海办理了一个新的银行卡，用户要把交易帐户关联的交易帐户转到上海卡上，在交易中出现问题，而系统需求中说明只能是在本分行管辖区域内更换银行卡，而不能跨地域更换。

3、意识上的问题或沟通不足导致的问题。

有时，我们测试人员会认为某些事情应该是这样，应该已经处理了，应该是客户成熟的东西等等，实际上并不是这样。在测试中，柜面和网银上输入借记卡卡号为11位，而实际上网银输入应该为18位。测试中，客户提供我们的卡号也都是从核心系统中搜索到的，也都是11位。实际上借记卡应该有18位，前面6位为银行固定号码，最后一位为检验位，中间11位才是银行卡号。举一个意识问题导致的缺陷，对于银行网银上的密码加密，因为客户的网银早就有系统在运营，而被测试系统部署已经运营的网银中，测试人员往往认为网银密码加密这些应该是客户使用的是成熟的算法，不用再测试。测试实际上不是这样。

测试需求的表示

测试需求可以保存在任何文档中，但是我们在项目中往往是通过测试管理工具进行管理，这样便于进行跟踪管理。下面我们本文结合目前最流行的测试管理工具HP Quality Center （后面简称QC）工具进行讲解。

因为在QC中直接编辑测试需求不是太方便，在Excel中编写在修改、复制、评审时比较方便，所以我们使用了通过Excel导入功能。业务需求和测试需求首先在Excel中进行编写，但是要完全符合导入QC的规则和字段要求（QC中字段可以定制）。

1、为了使用导入功能，需要首先安装QC中导入Excel文件的插件；

2、在Excel文件中做好模板，按照模板编写；

另外，在使用QC等测试管理时，一定要注意QC库的备份以及对用户权限的控制，防止误删除数据库，造成测试成果丢失。

测试需求在QC中的组织层次，测试需求一共包括三层，形成三层的测试需求树：

对业务模块进行统一编号，例如，01-风险控制模块，02-个人网银业务

业务模块下的业务功能需求标识为0201-个人网银入金，表示个人网银业务模块中的第一条功能需求。

在业务功能需求下，添加测试需求，例如0201001-个人入金金额检查，表示个人网银入金的第一条测试需求。

解释：

02表示第2个模块功能，是系统中按照模块功能划分。依次增加。

0203表示第2个模块下的第3个子功能，是在模块功能下面的每个子功能；按照子功能依次增加。

0203001表示为第2个模块下的第3个子功能下的第一个测试需求，为测试需求，测试需求分为3种，以表示第3层的第一位标识。注意有些用例可以专为数据移植后测试的测试用例。

0101001：表示第一条正常功能测试业务需求

0101002：表示第二条正常功能测试业务需求

0101101：表示第一条容错功能测试需求

0101102：表示第二条容错功能测试需求

0101201：表示第一条GUI测试需求

0101301：表示第二条GUI测试需求

整个列表中序号是连续的。可以通过剪切、粘贴为兄弟等操作移动测试需求，保持顺序。

QC中的图为例：略

测试需求组织顺序：

先正常功能测试用例，接着是容错测试用例，最后是界面功能测试用例。

金融行业系统测试以正常业务功能测试为主，以容错测试为次之。

我们一定要树立这样一个观念，以测试各种业务情况为主，界面的容错功能为次的测试需求提取和测试用例设计的观念。

如果是升级项目，所以在测试需求中，首先以新增加的业务为主，以修改的业务为辅，不修改的部分，优先级最低，仅仅设计正常业务功能测试用例即可。

业务需求+测试方法+测试视角=测试需求

通过分析测试需求，可以帮助业务人员完善业务需求。

有了测试需求，就直接可以写测试用例了。

对的，测试需求是和业务需求对应的，一条业务需求可能对应几条测试需求。

有利于开发和测试， 开发需要参考测试需求吗？？但开发会参考需求说明书啊，不应该参考业务需求啊？不明白，觉得完善的是系统分析呢。

但是大部分开发，把需求说明书和业务需求，需求规格说明书做成一个文档。

这样啊。测试比开发先行。

n 惟一的

n 精确的

n 有边界的

n 可测试的

同需求中描述的需求一致。

测试需求分析和提取是在在业务需求形成的后期、设计测试用例的前期进行的工作。

很多公司这步也是省略的，和用例放在一起分析了。

我们也有一个测试设计的过程，比如针对一个功能需求，包括测试范围、测试策略，逐步细化得出一套测试思路，最后得出测试用例列表。好像和上面说的测试需求差不多？要求要在测试设计文档上体现你的设计思路，而不仅仅是最后的一堆用例；范围、重点是什么，要从哪些角度进行测试，测试的策略，然后应用什么用例设计方法，最后形成一个用例列表；对用例的评审基本上也是针对测试设计而言，没有具体去评审用例了。

OH，其实是个用例的框架，但没有步骤。如用等价类法，就说明分成几个等价类，有哪几个，就可以了，是这样吗？

1.1. 测试范围

根据测试准备阶段的相关信息（如开发类型、开发策略、时间要求等），确定测试范围。

可以结合本规范第一章列出的测试类型，选择必要的测试类型。对测试范围的分类有助于确认测试重点。

1.2. 测试策略

针对功能实现原理和测试范围、测试类型，有针对性的制定测试重点和测试策略、迭代策略。

1.3. 测试设计

根据测试计划阶段的测试范围、测试重点、测试策略，进行测试用例的设计（包括测试的关注点）

1.4. 测试列表

该列表可以按实际需要变化，用例名称一般就是该用例的测试目的，测试要点是该用例覆盖到的测试要点，是基于2.3 测试设计而来，用例ID是对应另一份测试用例文档的用例ID。

得到以上真理和讨论精华，心里逐渐明白三分，放于此，以便以后学习之用。