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

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

　　什么是隐式需求呢？

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

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

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

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

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

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

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

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

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

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

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

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

　　1.用户需求

　　2.行业业务需求（界面提示信息为行业术语，处理和操作模式为行业从业人员习惯模式等）

　　3.实际使用环境需求（网络带宽，速率，断电数据备份，软件部署设置等）

　　4.操作使用需求（类似快捷键，紧急关闭，数据恢复保护，回退机制，安装兼容性，语言环境等）

　　5.用户需求引发的测试需求（按软件测试质量模型进行划分）

　　6.上下继承性需求（如：软件产品为中间过渡层的产品）

　　测试需求

　　1、要求开发人员提供被测软件的测试情况表。

　　这是直接的一个需求，因为我们测试的是开发人员做出的“成果物”，那么他们需要我们测试什么，容易出错误的地点，程序的处理逻辑（需要测试部分）这些都需要在测试申请单上写清楚的。

　　这是一个直接的测试需求来源。

　　这一步，也可以很快的确定你的测试范围。