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

默默巫

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

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

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

骄阳似火

个人理解：一个项目的需求=行业的需求（该行业一些属性，特殊点等）+用户特别的需求（localization)+软件自身的要求（比如：合适的架构，布署与测试的环境要求....). 如何及怎么样提取用户的有效需求呢？ 详细的回答前面很多行友都作了相关的回答，我只写一个概要的了，如何提取？ 我想在提取前要做些相关的准备的，如对该行业的业务流程及相关注意点的了解，对客户对这项目最终期望的了解及相关软件行业技能知识的了解，，，，有了些前提才能从各种途径收集到的需示来有效提取了（如需求会议文档，项目规划文档，开发的相关文档等）

骄阳似火

学习中，非常好

wangmengdong

回复 31# 默默巫


    我见云老大的帖子，经常有错别字。。一看就是自己一个字一个字打上去的。。哈哈。。

默默巫

提示版主。下次回帖的时候打字不要太细心，有点错别字，就知道是原创啦。。
wangmengdong 发表于 2010-11-24 18:16

囧。。。是不是原创大家可以去搜索索索。

jarystar

本人做了一些通俗总结
1.根据用户需求规格说明书，写出自己的理解
2.根据用户需求规格说明书，提取出功能点所需要实现的功能
3.根据提取出的功能，对复杂功能点进行细分
4.根据提取出的功能，进行拓展各功能点是如何工作的
4.1功能点描述中是否有模糊的字眼
4.2功能点描述中是否有，有别于其他常规描述
4.3功能点描述中是否有关联点
4.4发散性思考，考虑各功能点的异常情况
5根据提取出的功能，进行组合，看看各功能点之间的兼容性
5.1认真阅读需求，思考该功能点实现后的流程，把各小功能点进行组合
5.2 思考该模块是否为一个独立的模块，若不是，需要跟其他模块联合起来测试
5.3 思考各功能点之间是通过什么操作进行连接的？连接结果是否正确
以上仅表个人观点

moonjew

没人管了

wangmengdong

提示版主。下次回帖的时候打字不要太细心，有点错别字，就知道是原创啦。。

NULLTeSt

以下内容出自QC的帮助文件，关于测试需求的工作流，可以参考一下：

1、The Requirements Specification Workflow
You begin the application testing process by specifying testing requirements. Requirements describe in detail what needs to be tested in your application, and provide the test team with the foundation on which the entire testing process is based.

By defining requirements, you can plan and manage tests that are more focused on business needs. Requirements are then associated to tests and defects to provide complete traceability and to aid the decision-making process.

This section describes how you use the Requirements module to specify testing requirements. The requirements specification workflow consists of the following:

  Define Testing -> Create RequireMents ->Detail Requirements -> Analyze Requirements

2、Defining the Testing Scope
The test team begins the testing process by gathering all available documentation on the application under test, such as marketing and business requirements documents, system requirements specifications, and design documents.

Use these documents to obtain a thorough understanding of the application under test and determine your testing scope—test goals, objectives, and strategies.

Ask the following questions when determining your testing scope:
What is the main purpose and direction of the application?
What are the major features of the application?
What is the relative importance of each element in the application functionality?
What are the critical or high-risk functions of the application?
What are your testing priorities?
Do your customers/end-users agree with your testing priorities?
What are your overall quality goals?

2、Creating the Testing Requirements Outline
Quality Assurance managers use the testing scope to determine the overall testing requirements for the application under test. They define requirement topics and assign them to the QA testers in the test team. Each QA tester uses Quality Center to record the requirement topics for which they are responsible.

Requirement topics are recorded in the Requirements module by creating a requirements tree. The requirements tree is a graphical representation of your requirements specification, displaying the hierarchical relationship between different requirements.

For example, consider a flight reservation application that lets you manage flight scheduling, passenger bookings, and ticket sales. The QA manager may define your major testing requirements as: Application Security, Application Client System, Application Usability, Application Performance, Application Reliability, Profile Management, Booking System, Flights Reservation Service and Reservations Management. For the complete example, refer to the QualityCenter_Demo project.

3、Defining Requirements
For each requirement topic, a QA tester creates a list of detailed testing requirements in the requirements tree. For example, the requirement topic Application Security may be broken down into the following requirements:

Each requirement in the tree is described in detail and can include any relevant attachments. The QA tester assigns the requirement a priority level which is taken into consideration when the test team creates the test plan.

4、Analyzing your Requirements Specification
QA managers review the requirements, ensuring that they meet the testing scope defined earlier. They assign the requirement a Reviewed status once it is approved.

To help review the requirements, you can generate reports and graphs. For more information, see Generating Reports, and Generating Graphs.

You can then use the requirements as a basis for your test plan. The tests you create during the test plan phase should cover these requirements. For more information on requirements and tests coverage, see Linking Tests to Requirements. These tests are also linked to defects, thereby providing complete traceability throughout the testing process. For more information on linking defects, see Linking Defects.

大雁南飞

想要得到比较完整的测试需求，感觉首先需要搞请获取需求的来源
1、需求规格说明书
   产品功能、UI控制、UI规范、业务规则、效率标准
2、设计规格说明书
   数据库表、数据流程、运行环境、软件部署、性能指标
3、国家政策法规
4、行业标准
5、约定俗成
   操作习惯、行业术语
6、企业应用场景

foxdjxx

好贴

moonjew

看过上面的一些评论了，我再帮助大家补充一些，思路再展开看看
1、测试需求和可测试需求的区别。
可测试需求是产品需求的一部分，与之平行的包括可制造需求、可维护需求等，是为了配合产品整个生命周期而加入到产品需求的部分，是作为产品设计开发的要求列出设计开发计划的内容。
产品需求的内容有很多，很多人都知道$APPEARLS的原则进行需求分析，楼上说的显式需求和隐式需求也是产品需求的一个分类方法。
测试需求不是产品需求，测试需求是对应产品需求、产品规格、产品设计产生的对测试项目起指导作用项目文档。是为了制定测试计划而必须的。

2、测试需求与产品需求的关系
测试需求提取在流程上来说，3楼已经说过了。
从技术手段上来说，测试需求是从产品需求、产品规格中进行提取的。在产品设计中进行补充的，在产品计划中进行调整的。  如果这4个前提准备得非常充分，那么测试需求就没有存在的必要了，直接通过测试计划和用例设计就可以满足质量保证的要求。 所以说，测试需求是为了满足产品质量需求的一个指导书。
测试需求的内容区别于常规的产品需求，强调的是业务应用场景的考虑，是为了让产品用起来的需要。所以我们看到产品需求的功能场景时，在测试需求里要描述其应用场景，什么人、什么能力、什么状态、什么环境、什么常用操作等等。
除了应用场景外，测试需求还要考虑实施交付和维护保证的环节。也就是为测试计划中的测试范围、测试环境、交付要求、可靠性指标等进行的准备。

测试过程依赖于三种角色的角度（开发者、使用者、维护者），也就是这三种角色对产品的质量需求形成了测试需求。

幽灵鱼

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

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

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

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

“三人行，必有我师焉”，多动手，多跑跑，多聊聊，切勿“闭门造车”

greenty

我们的产品现在都没见过需求，产品测试也是完全靠自己对产品的练习学习，从中发现BUG。
现在急需要一个好的方案
是否要根据对产品的了解，以及和研发人员的沟通写需求，然后分析再写用例？？
现在只是通过文字表格的方式把产品的功能点写出来了。如何才能让该产品测试比较规范的执行。
比如：分析功能点的方法，写用例，用例覆盖，执行等。都么有一个好的流程规范。
有好的建议大家提一提。

bazhen

如果需求不够明确，完善，一定要项目经理提供可靠的需求文档，不要只是口说，因为很多测试场景都是从需求中提炼而来的，连需求都不靠谱，设计出来的测试用例覆盖度就可想而知了，不要浪费宝贵时间，明确后再测不迟。

zdlzx

如何提取测试需求

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

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

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

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

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

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

archonwang

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

archonwang

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

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

tengmy

回复 15# zbjie


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

skm2010

挖掘隐形需求