如何提取测试需求

如何提取测试需求

测试工作的依据首先是业务需求规格说明书，所以应该首先提取测试需求，把需求从业务需求中提取出来，再把业务需求分解为测试需求，每个业务需求对应一个或多个测试需求。
    在分析测试需求和设计测试用例时，以需求规格说明书为依据，以业务功能为中心，以质量模型中的各子特性为出发点，同时深刻理解业务规则和隐式需求，通过与客户深入沟通，明确测试范围和质量目标，达到测试分析和设计全面、无遗漏。

什么是隐式需求呢？
从质量保证的定义：产品或服务满足显示或隐含需求能力的功能和特性总和。所以在提取测试需求时，除了关注显式提出的业务需求外，我们也应该关注隐式的需求。这些隐式需求包括：
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、要求开发人员提供被测软件的测试情况表。
   这是最直接的一个需求，因为我们测试的是开发人员做出的“成果物”，那么他们需要我们测试什么，容易出错误的地点，程序的处理逻辑（需要测试部分）这些都需要在测试申请单上写清楚的。
    这是一个最直接的测试需求来源。
    这一步，也可以很快的确定你的测试范围。
2、文档
    从已有项目文档中提取有价值的内容。结合《测试申请单》的内容，在用户原始需求资料、需求文档、设计文档中寻找有价值资料。记住用户原始资料的重要性，当发现疑问时，有可能需求文档或设计文档出现了歧义，可以在用户提供资料中提取信息。
3、自身业务知识
    第三点就是凭借自己对软件的了解，对业务知识的了解，甄别需求完整性，正确性，加以补充。
——————————以上为需求来源——————————
4、确定测试需求范围
   n多项需求，在经过前三步后，确定本次测试点需求范围。以及各个需求点具体内容。
5、画个流程图
   可以根据需求要点，画业务流程图，方便梳理自己的思绪。
——————————以上为处理需求方法————————
6、用户确认，或者跟开发人员或者有经验的同事确认
   辛苦的整理完这些东西，最好跟用户或者开发人员有个沟通，让他们帮你判断本次测试需求你了解的准确性，并且可以提出意见。及时将反馈意见补充到你的测试需求文档中。
——————————以上为测试需求文档确认——————

需求确认完毕，开始测试。


——————————————————————————————————————————————————————————————————————————————————

如何提取测试需求

一、与需求相关的
1、直接来自需求
测试需求的绝大部分直接来自需求。工作中其实容易混淆什么是真正的需求,什么是需求的解决方案,什么是设计和实现带来的约束。什么是需求呢？如果不这样就不行的，才是需求。例如，作为一个银行系统，客户需要能够查询余额。不能查询余额的系统银行不会为这个系统而买单。所以，这是需求。那么，需要密码才能查询余额是不是需求呢？这不是需求。因为我可以通过指纹识别来查询余额吧，为什么一定要用密码呢？那么要设定一个6位数字当作密码是不是需求呢？当然也不是。这只是为了达到保密目的而做的一个设计上的限制。6位密码其实完全可以是8位或者别的身份标志。所以，先弄清什么是真正的需求，然后提取出来作为测试需求。

2、补充需求
需求并不完美，所以你还可以补充一些需求。具体包括：遗漏（如：分支流程、对特殊数据的支持和处理。。。）；隐性的需求（如：对某些人或特定领域来说的常识；行业规范；UI标准；停留在需求分析人员脑中的隐含需求）；竞争对手的类似系统的功能等。

3、挖掘需求
通过提问的方式可以挖掘一些需求。例如，通常比较难以得到高质量的非功能需求。因为用户只是需要越快越好，他也无法告诉你多快才是他能接受你又可行的。这时，通常相应的性能测试需求可以通过Q&A的形式以具体的问题去启发或者得到。还有一些需求，虽然一直存在，但用户长期以来已经习惯了忍受。你不从某个角度去问，他也不会当作需求提给你。

二、不会出现在需求中的
某些测试需求不会出现在需求中，因此需要测试人员补充。
1、反向测试用例
你最常需要补充的测试需求中很重要的一块是反向测试用例，即需求要求这样做了。那么需求上没有要求做的是否系统没有做。

2、设计和实现约束
前面“直接来自需求”中提到的需求的解决方案或者设计/实现的约束，在其进一步确认后需要逐步补充到测试需求中来。

3、可测试性的需求
最后一点常容易被人忽视：测试人员还需要补充为了提高系统可测试性而提的测试需求。例如，某个系统依赖于多个其他系统的接口。为了在对方没有提供可测试的环境或者版本的时候可以先测试我方对接口的正常处理，需要系统提供一个功能，模拟生成对方的数据，也可以查看我方发给对方数据包的具体内容。
——————————————————————————————————————————————————————————————————————————————————

需求一般分为显式需求和隐式需求两种

一、显式需求提取参照需求说明书：
1、逐个罗列出功能点，功能描述
2、考虑交叉功能点
3、画出业务流程图

二、对于隐式需求
1、针对行业知识，向客户（提需求的人）和项目组内熟悉产品的人请教。切记，“闻道有先后，术业有专攻”，在这方面很多人需要习惯并且擅长向他人学习，你就要问的他都烦。
2、针对用户实际需求，要问清楚他想解决的问题和以后的期望值，做到“未雨绸缪”，想客户之所想。期望值虽然暂时达不到，但一定会为你了解产品有非常大的帮助。
3、软件实际需求，在了解用户需求的基础上，向技术人员请教，了解当前产品所能达到的目标。

综上，把所有需求功能点罗列在一张表格里，找对应人员确认，查缺补漏
——————————————————————————————————————————————————————————————————————————————————