51Testing软件测试论坛

标题: 如何快速掌握业务需求并进行测试？（09-5-19）（获奖名单已公布） [打印本页]

作者: 默默巫 时间: 2009-5-19 16:15
标题: 如何快速掌握业务需求并进行测试？（09-5-19）（获奖名单已公布）
如何快速掌握业务需求并进行测试？

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

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

作者: deanaa 时间: 2009-5-20 10:15
从公司和项目的角度来讲，首先在人员的安排上，尽量安排有相关业务经验的测试人员，这样能够明显降低学习和上手的时间。如果有经验的测试人员由于各种原因不能全程参与，至少也要保证他们能把需求过一遍，同时需要让他们来审核测试用例，保证测试用例的准确和覆盖率。另一方面，在测试人员的培养上，也要有所侧重，不管是技术，管理还是业务。这样长期的看才能真正提高测试工作的效率和质量。

从测试人员自身来讲，学习能力的培养，业务知识的积累，知识面的拓展，是非常重要的。这几点都是在日常工作中积累起来的，是一个测试人员的真正的价值所在。我们说一个经验丰富的，能力强的测试人员，一个能够在公司中项目里独当一面的测试人员，他一定是在上述三个方面都做得很好的。
具体到一个项目中，当你接手一个功能的时候，首先应该了解需求，这个过程中一定要求甚解，要把需求吃透，甚至要把一个需求点周围的东西都了解清楚。这是一个痛苦的过程，工作量会很大，而且充满挫败感。但是这是一个必须要过的坎，做到这一点，后面写测试用例，执行测试，报bug，这些只会越来越轻松。更重要的是，在这个过程中，你的学习能力得到了提高，业务知识得到了积累。这个学习的过程中，当然有一些提高效率的办法，但是这些都应该是每个人在自己的实践过程中积累起来的，只有自己，才能找到对自己最有效的方法。这个过程是艰难的，但是自私一点的说，这些东西就是你以后加工资，升职，跳槽的资本！

作者: tiansm 时间: 2009-5-20 16:39
都被楼上说完了嘛.
当然如果能自己搞定最好,如果真搞不定,可以寻求与开发人员的探讨,加深理解自己不够理解的功能点.

[ 本帖最后由 tiansm 于 2009-5-20 16:41 编辑 ]

作者: zhiyun181 时间: 2009-5-20 21:06
测试人员还是要积极调用身边的资源。多问，而且注意问的方式，会收到很好的效果

作者: rolei 时间: 2009-5-21 10:13
标题: 充当客户的义工，跟客户干上一段时间
你只要用心的跟客户走上一个全流程，也就知道个大概了，做起测试也就不像个纯外行了。

作者: xiaoping_725 时间: 2009-5-21 13:06
标题: 积累总结
积累总结

作者: chenmonanhai 时间: 2009-5-21 16:55
就如一楼所说的,首先你得把需求弄明白,其实在需求这里花的时间会多一些,但是磨刀不误砍柴工,你把需求都明确后,以后的事情都会变得容易.

作者: ganhuiping 时间: 2009-5-21 17:05
标题: 需求--测试之源
毋庸置疑，测试人员对需求的了解是非常非常重要的。目前我就是跟着需求调研人员参与了整个需求调研活动，可以说是获益匪浅。需求是开发之源，也是测试之源。测试人员如果能够更直接的去向客户了解需求，或者跟一两笔业务也是好的。

作者: lanbiers 时间: 2009-5-21 17:24
说说自己的经验：

1、业务需求的分析想要做到迅速，快捷，势必要和企业平时在领域内提炼业务元模型相关联。

2、快速测试需求的基础在于依赖解耦以及对于模型的提炼。

3、应用SOA的思想，针对切面进行测试。

作者: lanbiers 时间: 2009-5-21 17:27
举例来说：

一个数据存储的需求。如何快速进入需求测试？

1、首先，是否有相关业务的元模型，即类似的功能不同的实现，但是本质上又是殊途同归的。

2、是否可以立即进行依赖解耦，针对需求的不同层面展开测试，只留下需求中变化的部分。

3、在一个新需求的情况下，是否可以快速进行模型划分，接口隔离，进入依赖解耦阶段，针对接口或层面进行测试？

总之，一切的根源都在于对于需求所对应的模型进行分析，划分层面，去除依赖，针对接口、切面进行测试。

作者: bonitayang 时间: 2009-5-22 11:21
标题: 多交流多讨论
与身边的人或客户多交流，多讨论。就可以深入理解需求，一味的自己看效果没有这样明显。

作者: konglingzhen 时间: 2009-5-22 11:42
1、如果有需求文档，认真研读需求文档是最重要的。
2、自己顺序记录每次变更，因为需求文档也许更新不那么快
并对每次变更做详细批注

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

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

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

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

作者: fei.ge 时间: 2009-5-25 16:37
如何快速掌握业务需求并进行测试？

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

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

作者: blsp 时间: 2009-5-27 11:14
标题: 怎样更好的理解需求
首先，测试负责人应该是有相关业务经验的人员，能够快速理解需求，并能够提出不合理的地方；
其次，测试人员要尽早的进入项目，最好是在需求调研的时候就能够介入。

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

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

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

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

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

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

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

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

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

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

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

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

作者: christine_liu 时间: 2009-6-4 11:50
多提问，认真分析

作者: 骄傲的公主 时间: 2009-6-4 14:49
标题: 不懂啊

还是很抽象

作者: 君星 时间: 2009-6-5 19:45
标题: 受用
受用

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

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