如何提取测试需求？（10-11-2）（获奖名单已公布）

默默巫

提取测试需求是软件测试活动中的基础工作，是测试活动展开的前提条件。
那么该如何提取测试需求呢？

如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

获奖名单
奖项	获奖名单	奖励	答案链接
二等奖	tengmy	300论坛积分	3#

luozhijun

1.用户需求
2.行业业务需求（界面提示信息为行业术语，处理和操作模式为行业从业人员习惯模式等）
3.实际使用环境需求（网络带宽，速率，断电数据备份，软件部署设置等）
4.操作使用需求（类似快捷键，紧急关闭，数据恢复保护，回退机制，安装兼容性，语言环境等）
5.用户需求引发的测试需求（按软件测试质量模型进行划分）
6.上下继承性需求（如：软件产品为中间过渡层的产品）

先抛个砖，希望大家多扔点玉，谢谢！

tengmy

继续垒砖..

提取测试需求一般是测试项目的开始。
必要的前提是有足够充分的行业了解和完备的客户需求文档，开发文档和开发&需求关于功能的若干细化解析。
但是实际情况下，介于某些文化氛围和合作者的工作习惯，一般很难这么完美。
那么就只能从你能够拥有的客户资料开始。

首先要知道自己要负责测试的范围（scope）在哪里。
然后要从客户文档里面去寻找相关的功能描述，功能点。以及和其他的功能交叉的点。
根据功能点的初步筛查，做出一张功能清单列表备查。

然后就是一个校对，理顺，清查的过程。
务必保证所有需要测试的功能都包含在你这张清单当中，事无巨细，绝无遗漏。

然后就是研讨的过程，就要跟开发，需求进行核对，确认清单以及功能的完整性。

接着就是需要制作需求说明书以及涉及相关的功能测试框架。
经过评审之后，就可以让相关的测试人员参与，搭建测试环境，准备测试数据和根据测试需求说明书来书写测试用例了。

其实无论功能还是性能测试，需要注意的就是测试范围要划好，相关的监测点/测试场景要设计的真实有效。不要想当然的认为哪些功能是客户会关注的，常用的。因为对于不了解行业信息的人来说，很多时候，你的判断未必是对的。
这个时候，需要向业内人员，最好是用户虚心求教。否则一旦测试重点在一开始就发生了偏移，这个测试项目的结果就可想而知了。
这也是为什么很多项目的参与人觉得自己辛辛苦苦的在项目里面努力，但是到最后却得不到好的评价的一部分原因。
我们需要站在客户的角度上来考虑问题，但是不要把自己想当然的当成客户。或许你以及开发团队认为无足轻重的一个小小的点，足以让影响整个项目的成败。

Jon

这个话题不错！

月夜心

3楼的答案好详细了，大赞。
说一下本人的理解吧。
测试需求提取的开始时间是项目的开始时间。需求的来源：对项目的了解。了解项目的手段或者媒介：项目进行过程中的所有会议，需求文档，与开发产品的交流和使用被测项目。

AwL_1124

针对一个系统进行整体分析，先了解整体功能。做到心中有数
再对每个功能点进行整理、罗列，这样就能知道系统的功能列表。一般的功能点都集中在模块功能，接口功能，数据同步，传输。

刚开努可以先试着自己去整理，用自己的想法来整理，再找高手来帮忙修改。自己就慢慢知道找测试需求的功能点了

rolei

　　测试需求的提取过程是对系统需求和系统设计内容分类、合并、提取的过程。
　　因此，软件测试需求的提取过程也应当遵循需求分析（需求分析内容可以查看相关文档）的过程：测试需求获取、测试需求收集、测试需求分析、测试需求开发。通过对一系统列的需求（产品需求、用户需求、软件需求）的收集、分析、整理，最终提取出按测试人员思路生成的可以测试的测试点、测试项、测试场景，也就是测试需求（不断迭代的过程）。

　　通过对已有系统需求和设计资源的了解，逐步细化为５W1H格式，也就是明确：什么样的系统用户，在什么时间、什么样的环境下、执行了什么样的操作，产生了什么样的结果。而为什么会有这样的测试需求可以在软件需求说明（或是相关的行业标准）中明确的查找到。

　　依据系统评测项（依从性、功能、易用性、效率、可移植性、可靠性、可维护性）将系统需求分类整理为测试需求，从而形成对应的不同类型、不同阶段的测试。

附：需求的分类
１）产品需求：行业标准化和通用化的应用描述
２）用户需求：用户面临的问题和期望
３）软件需求：使用软件工程语言对产品需求和客户需求进行结构化和文档化的整理、描述

FENHUA927

1、提取测试需求的时间
首先根据项目的时间和人力资源确定测试人员参与到提取测试需求的时间。
如果人力资源充足的话当然是尽可能参与到每一场需求讨论中，通过和产品、开发人员开一些需求讨论会确定需求，如果有条件的话客户有代表参与当然更好。如果人力资源不是很充足，那么最好是基本需求确定下来之后测试人员再参与其中，可能是需求文档已经出来的时候，在评审前如前三天测试人员通过阅读文档总结自己发现的问题，通过需求评审或者评审之前其它联系方式和开发、产品确认并解决问题。
2、有需求文档和无需求文档
有些项目有具体的需求文档，而且写的非常详细，这样的提取测试需求需要考虑的就是确定测试范围以及能够执行测试的需求。有些项目并没有具体的需求文档，这就需要测试人员根据现有项目的描述去参考一些相似产品，通过产品人员对需求的描述，最好能够整理一个功能和业务的需求列表，和此项目其它相关人员进行分析确认后归档。
3、不仅仅是业务功能需求，性能、安全性、兼容性等方面的需求也要根据产品特性提取确认
有效的提取需求，还是要提高沟通和理解分析能力，继续向大家学习中……

msnshow

首先还是得了解项目需求

csb821023

回复 8#

你提到在无文档的情况下来做需求分析，我现在就是遇到这样的问题，测试没有任何文档，测试是在开发完成后进行，拿到就是一个可以运行的软件，对于这样的情况如何进行需求分析？我之前就是根据软件的功能和操作点，自己整理了一份文档，但是现在觉得测试的不够深入，更多的感觉是停留在界面的操作上，我该如何做才能更深入的进行测试？

qxhc

提取测试需求，
1、开发小组在对需求文档进行编程阶段时，测试小组也应对需求文档进行分析，提取测试需求，即确定测试范围、归纳测试功能点，理顺思路，对业务逻辑分析清楚。
2、测试需求功能点提取完毕后，需要由产品组和开发组进行评审以确定需求功能点覆盖率

liuqixun

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

什么是隐式需求呢？
从质量保证的定义：产品或服务满足显示或隐含需求能力的功能和特性总和。所以在提取测试需求时，除了关注显式提出的业务需求外，我们也应该关注隐式的需求。这些隐式需求包括：
1、用户隐式的需求。例如：行业规则、业务规则、原来系统已经实现约定俗成的操作或功能等。这些需求设计人员往往认为研发团队会知道这些规则，所以没有在需求中显示描述。这些地方由于没有明确约定，又缺少沟通，往往成为最容易出现缺陷的地方，不容忽视。
2、计算机领域的规范或习惯。这些方面是很难写到业务需求中的，业务需求往往是文字描述，很难准确描述系统展示界面，例如，如果某个输入我有限个元素，则应该用列表框或选择框控件实现，而用编辑框实现则要在输入中做很多判断，不断增加编程工作量，也增加测试工作量，同时给用户带来不便。
3、客户认为我们应该理解或在需求中遗漏的需求。例如，认为我们理解金融行业的会计规则，但是如果不在测试需求明确说明，则由于测试工程师没有金融行业会计方面的测试经验而忘记测试。
4、业务需求编写人员受计算机技术的能力。不知道性能指标如何描述或描述不准确。需要测试团队协助科技人员和业务人员把描述不准确、正确或隐含的性能指标需求显示描述清晰。

通过多个项目上线后的问题反馈来看，原因主要是：
1、对实际业务中可能发生的情况或者说场景考虑不足。
例如：已经到了交易闭市时间，例如5点整闭市，而在柜面在接近5点时发送了一个请求操作，服务器接收到该请求后，把这个操作请求发送到其他系统（交易所系统）请求进行处理，而这个过程中，已经到5点整（实际生产系统中，各服务器系统的时间并非完全同步），而此时服务器已经关闭了交易，造成无法接收请求处理的操作结果，而此时在交易所系统已经做了记录操作成功，但由于银行服务器没有接收到返回，造成产生了单边交易。

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

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




摘自Angela 7点测试论坛
与大家分享一下

老学生

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

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

1~方格子

学习中

zbjie

回复 3# tengmy


   这个不是照着课本上面拷贝过来的吧，版主要不就是很牛人物了，那么多字记得清么。新手发点感慨。

skm2010

挖掘隐形需求

tengmy

回复 15# zbjie


    呵呵~~我不太习惯去copy。写的基本上是我平时工作的流程。
希望有用就好！

archonwang

随便说点什么吧
1。 关于测试需求的提出
测试需求有很多种类，常见的是性能和功能，有时候会有些很特别的要求。需求的提出方一般是测试部门。考虑到有些情况根本没有正式的需求说明，对测试需求的提出要求往往变成了需求整理和细化过程；

2。 提取的手段
最常见的方式是：通过现有的需求规格说明书得到，但是这个方式是有很明确的前提的：必须具备需求规格说明书或类似的文本记录。实际上大多数公司或者需求规格说明书不够明确，要么甚至没有。这样的测试需求提炼非常困难，又回到了第一点，提取测试需求的时候变成了需求整理和进一步细化的过程了。。。
第二种方式，则是通过测试组织或人员的经验来形成，比如来自一些通用的行业规范等等。这种提取方法有很大的不确定性，比较容易遗漏重要的测试项，且个人能力不同，导致的结果千差万别。
第三种方式，通过已实现的系统来获得，这种方式，在工程学角度上是逆反工程——有点亡羊补牢的味道。由于缺乏正规的工程方法，这种方法往往都是形式而无法在实质上改善软件质量。阿门~~

archonwang

3。 对于测试需求提取的几个问题
3.1。 何时提取？这是非常重要的一个问题，与提取什么内容几乎一样重要。要命的是，何时提取受制于提取什么类型的需求以及需求的详细程度。有些需求描述得过于抽象，而仅仅只能作为一个愿景目标而无法单独作为一条需求来处理。
3.2。 采用何种流程对测试需求提取的结果有影响么？
准确的说，采用何种工程方法对需求提取有非常重要的影响。迫于项目周期、资金、人力等方面的原因所导致的工程方法变更是巨大的不确定性，一个变量会引发一场革命。。。。结果不言自明
3.3。 是否一定要有测试需求提取过程？
未必，大中型项目由于管理范围大，不得不这样做以防止遗漏，但是一些小型系统则不一定需要具备这个过程，尤其是测试需求的分析过程。
3.4。 哪些因素会妨碍测试需求的提取
之前说过几种情况：规格说明不明确甚至没有，资源紧张等等。在过程上，如果没有工程化方法的支持，这个过程可能会被认为是多余的浪费成本的行为。。。。

zdlzx

如何提取测试需求

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

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

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

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

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

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