如何快速掌握业务需求并进行测试？（09-5-19）（获奖名单已公布）

默默巫

如何快速掌握业务需求并进行测试？

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

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	deanaa	当当购物卡50元	2#

相关文章：

专注于业务需求的自动化测试——Mercury Business Process Testing

使用构架方法来分析、管理和跟踪业务需求

更多内容请点击＞＞＞

注：本期话题延长一周

tails82

好多讨论需求的话题。谁都知道需求重要，可领导就不愿意花时间搞需求。我们讨论的东西，也许只能作为一个衡量标准，告诉我们100分是怎样的。而实际工作中，只能向着100分积极靠拢，永远到不了，可能也就在50到60分之间挣扎吧。

君星

受用

骄傲的公主

  还是很抽象

christine_liu

多提问，认真分析

huihuike

1、反复阅读业务需求说明书，逐步了解；
2、对产生疑问的地方及时做好沟通，要弄的明明白白；
3、在开始测试时会深入理解业务的，同时也会产生更多的疑问，再次进行沟通。（只有实践了才能更深入理解）

我以前就是这么做的，效果还可以哦。

kuailederen

这个问题，是需求管理阶段要解决的问题。
对于我们来说，需求有很多来源，来自市场，来自客户，来自公司的研发或测试，有时候领导一句话就是一个需求。
所以建立一个需求采集的渠道就非常有必要。但这些需求，很多都是原始需求或者是一种需要，要生成测试需求后才能进行测试。
所以我觉得应该有这样一个流程：
需求采集----需求整理----需求评审----生成测试需求----后续测试行为

需求采集就是通过建立的几个渠道，尽可能的收集需求，哪怕是领导或者客户有关的一句话，都要记录确认。
需求整理，是把收集上来的杂乱需求点，有条理的归类。
需求评审，确认需求的有效性和可行性。
生成测试需求，从测试角度去解读需求，把需求分离出一个个的测试点，以便展开后续的测试工作。

我觉得这样的流程是准确的，它是建立在信息流通的基础之上的。如果是单纯的靠自己理解，或者研发人员的讲解，这是不可信的。

beryl_lin

1. 如果你在项目中期加入，可以要早期加入项目的测试人员对整个系统的业务流程做个介绍，然后自己尝试去用系统以最快的速度熟悉系统的业务。
（下面两点适合任何时候加入项目的人）
2. 仔细研究业务分析和设计文档，并且多跟业务分析人员、开发人员沟通，尽可能的掌握需求；在按照自己的理解基础上设计测试用例，然后邀请PM、业务分析人员、开发人员一起评审，看是否对业务需求的理解存在出入；在发现bug的情况下，同样要跟业务和开发沟通，确定需求的理解没有偏差、也没有需求的变动。
3. （如果有可能的话）尽量多跟客户直接沟通，以了解客户使用系统的方式，多以客户的身份去测试系统是最为理想的。

燕子东南飞

大家总结的东西已经很多了，大部分和我想的差不多，我觉得大家都说的很有道理，有些地方我也深有体会，再此我也根据自己的实际工作中遇到的一些问题和大家讨论一下，希望各位大侠给予指点啊！呵呵！

是我刚从事（电子商务）测试工作的第一家公司，到公司后，才知道自己是公司唯一的一位测试人员，而且那个时候刚毕业，经验上几乎是一片空白，领导分配是任务，我一看就傻眼了，怎么办，而且公司没有什么需求文档，当时我真的是无从下手，就直接找开发人员，让他们给我讲业务流程，过了段时间，网站的各个业务流程差不多都了解了，而流程中涉及到功能就比较容易下手了。其他测试经验，大部分都是在网上学习，在工作中借此应用，这样就慢慢的上轨了。我觉得多问，多看，多学习，多积累是必不可少的，搞清楚需求，接下进行测试就比较容易下手了。

namisang

主要看是否有功能遗漏，是否有多余的需求。   
  需求表达是否规范。   
  以上是需求分析人员的工作，用户，开发人员与测试人员只是协助。   
  需求阶段就开始让测试人员进行测试，这恐怕有些概念上的错误。   
  需求结束后可以开始写测试用例，但测试是必须有代码出来后才可以。

huguxiang

1.直接与客户交流了解业务需求以及客户的操作习惯。
这是我认为最有效最直接也是最快的方法，把握住客户整体的业务需求，了解客户平时的操作习惯，把自己当作客户去用这个软件，才能设身处地的了解客户的真正需求，才能纠正软件中一些非程序bug所致的错误。
2.尽早的阅读业务需求说明书。
在一个功能还未开发之前就应该阅读业务需求说明书，然后可以构思这个功能如何展现出来，最后可以把自己构思的功能和开发人员开发出来的功能进行对比，看哪些功能是不符合操作习惯和业务需求的。
3.多与设计人员、开发人员交流。每个人的想法是不一样的，虽然看的是同一份需求说明书，但是测试和开发人员的想法几乎完全不一样的。

[ 本帖最后由 huguxiang 于 2009-5-31 15:09 编辑 ]

guanxiaoqin

1.在没有多的测试任务时，多和开发工程师沟通，了解他们现在在做的项目，主要操作对象是什么，有没有开发文档（前提：测试没有参与项目前期工作）
2.若公司比较规范时，项目启动前，主动要求参加需求讨论会（去听听）
3.任何一个功能，要知道做的原因，为什么而做（注意积累）
4.项目结束后，总结系统中的业务流，并形成文档（为下次升级做准备）

blsp

首先，测试负责人应该是有相关业务经验的人员，能够快速理解需求，并能够提出不合理的地方；
其次，测试人员要尽早的进入项目，最好是在需求调研的时候就能够介入。

鹭岛

关键是看公司！
一个追求效率第一的公司，是没办法的，比如我这个公司，成本控制得非常严重，比如要求测试这个系统10天来说，一天让你理解需求，超过了，扣你绩效，我都觉得可笑，或许跟我这个公司不重视测试有关系吧（虽然领导说重视，不过怎么感觉都不重视，测试人员感觉是公司里面的下等工）

fei.ge

如何快速掌握业务需求并进行测试？

1、资深的、有相关业务知识的测试人员进项；有相关经验的测试人员能更快速、更深刻的理解需求。
2、参加各种跟需求相关的会议，实时跟踪开发的需求讲解会议；第一时间把握需求，杜绝需求变动时被开发牵着鼻子走.....
3、认真、仔细研读需求文档，需求有不明或歧义的跟需求调研人员确定；
4、产出“功能点分析”--“测试点”
5、测试内部小组一段时间对产出的“功能点分析”、“测试点”进行内部评审
6、组织学习相关业务知识.....

unisoft

1、掌握业务需求从改变思维方式开始，树立场景的概念，尽快熟悉业务需求场景，进而深刻理解系统需求，从系统需求抽取流程、关键字（验证点）及准备支撑的数据。业务系统的测试无非如此、
场景——流程——关键字——数据
2、以上思维方式的锻炼需要深入一个大型复杂系统（比如省集中项目）测试，然后积累的思维经验可以推广及其他行业、其他系统，不会受具体业务系统太大的限制。

cagemm

平时多积累测试技术和经验；
多积累计算机相关知识，如网络、数据库等知识；
多与研发人员沟通，学习要测试软件的相关知识；
向经验丰富的人请教；
网络实强大额，上网查询相关资料学习是一个很好的方法；

colume

这个说简单点：就是先在不懂任何业务需求的情况下去随机测试，通过随机测试来了解业务流程，当然肯定会有不明白或不清楚的地方，这时，当在不懂的情况下在去反查需求，这样的一个反复的过程中，你就会更深刻的理解业务需求，并积累了测试的经验

konglingzhen

1、如果有需求文档，认真研读需求文档是最重要的。
2、自己顺序记录每次变更，因为需求文档也许更新不那么快
并对每次变更做详细批注

3、如果没有需求文档，就应该关心客户，多根客户沟通，获取需求，并作相应记录
4、身边没客户，找开发人员，从整体上了解项目需求。

bonitayang

与身边的人或客户多交流，多讨论。就可以深入理解需求，一味的自己看效果没有这样明显。