51Testing软件测试论坛

标题: 如何提取测试需求？（10-11-2）（获奖名单已公布） [打印本页]

作者: 默默巫 时间: 2010-11-2 11:10
标题: 如何提取测试需求？（10-11-2）（获奖名单已公布）
提取测试需求是软件测试活动中的基础工作，是测试活动展开的前提条件。
那么该如何提取测试需求呢？

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

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

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

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

作者: tengmy 时间: 2010-11-2 14:54
继续垒砖..

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

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

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

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

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

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

作者: Jon 时间: 2010-11-2 15:40
这个话题不错！

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

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

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

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

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

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

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

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

作者: msnshow 时间: 2010-11-5 22:12
首先还是得了解项目需求

作者: csb821023 时间: 2010-11-7 22:01
回复 8#

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

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

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

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

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

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

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

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

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

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

作者: 1~方格子 时间: 2010-11-11 08:57
学习中

作者: zbjie 时间: 2010-11-11 10:29
回复 3# tengmy

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

作者: skm2010 时间: 2010-11-11 12:49
挖掘隐形需求

作者: tengmy 时间: 2010-11-11 16:58
回复 15# zbjie

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

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

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

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

作者: zdlzx 时间: 2010-11-14 20:00
如何提取测试需求

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

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

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

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

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

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

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

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

作者: 幽灵鱼 时间: 2010-11-18 09:56
需求一般分为显式需求和隐式需求两种

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

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

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

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

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

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

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

作者: foxdjxx 时间: 2010-11-22 17:46
好贴

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

作者: NULLTeSt 时间: 2010-11-23 10:43
以下内容出自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.

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

作者: moonjew 时间: 2010-12-1 10:54
没人管了

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

作者: 默默巫 时间: 2010-12-2 11:39

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

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

作者: wangmengdong 时间: 2010-12-3 11:22
回复 31# 默默巫

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

作者: 骄阳似火 时间: 2010-12-26 09:51
学习中，非常好

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

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)