如何快速掌握业务需求并进行测试？（09-5-19）（获奖名单已公布）
如何快速掌握业务需求并进行测试？如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！
获奖名单奖项获奖名单奖励答案链接一等奖deanaa当当购物卡50元2#
http://bbs.51testing.com/attachments/month_0811/20081125_650d7dccd46be6244f27oXDjE0HoDhyX.gif
相关文章：
专注于业务需求的自动化测试——Mercury Business Process Testing
使用构架方法来分析、管理和跟踪业务需求
更多内容请点击＞＞＞
注：本期话题延长一周 从公司和项目的角度来讲，首先在人员的安排上，尽量安排有相关业务经验的测试人员，这样能够明显降低学习和上手的时间。如果有经验的测试人员由于各种原因不能全程参与，至少也要保证他们能把需求过一遍，同时需要让他们来审核测试用例，保证测试用例的准确和覆盖率。另一方面，在测试人员的培养上，也要有所侧重，不管是技术，管理还是业务。这样长期的看才能真正提高测试工作的效率和质量。
从测试人员自身来讲，学习能力的培养，业务知识的积累，知识面的拓展，是非常重要的。这几点都是在日常工作中积累起来的，是一个测试人员的真正的价值所在。我们说一个经验丰富的，能力强的测试人员，一个能够在公司中项目里独当一面的测试人员，他一定是在上述三个方面都做得很好的。
具体到一个项目中，当你接手一个功能的时候，首先应该了解需求，这个过程中一定要求甚解，要把需求吃透，甚至要把一个需求点周围的东西都了解清楚。这是一个痛苦的过程，工作量会很大，而且充满挫败感。但是这是一个必须要过的坎，做到这一点，后面写测试用例，执行测试，报bug，这些只会越来越轻松。更重要的是，在这个过程中，你的学习能力得到了提高，业务知识得到了积累。这个学习的过程中，当然有一些提高效率的办法，但是这些都应该是每个人在自己的实践过程中积累起来的，只有自己，才能找到对自己最有效的方法。这个过程是艰难的，但是自私一点的说，这些东西就是你以后加工资，升职，跳槽的资本！ 都被楼上说完了嘛.
当然如果能自己搞定最好,如果真搞不定,可以寻求与开发人员的探讨,加深理解自己不够理解的功能点.
[ 本帖最后由 tiansm 于 2009-5-20 16:41 编辑 ] 测试人员还是要积极调用身边的资源。多问，而且注意问的方式，会收到很好的效果
充当客户的义工，跟客户干上一段时间
你只要用心的跟客户走上一个全流程，也就知道个大概了，做起测试也就不像个纯外行了。积累总结
积累总结 就如一楼所说的,首先你得把需求弄明白,其实在需求这里花的时间会多一些,但是磨刀不误砍柴工,你把需求都明确后,以后的事情都会变得容易.需求--测试之源
毋庸置疑，测试人员对需求的了解是非常非常重要的。目前我就是跟着需求调研人员参与了整个需求调研活动，可以说是获益匪浅。需求是开发之源，也是测试之源。测试人员如果能够更直接的去向客户了解需求，或者跟一两笔业务也是好的。 说说自己的经验：1、业务需求的分析想要做到迅速，快捷，势必要和企业平时在领域内提炼业务元模型相关联。
2、快速测试需求的基础在于依赖解耦以及对于模型的提炼。
3、应用SOA的思想，针对切面进行测试。 举例来说：
一个数据存储的需求。如何快速进入需求测试？
1、首先，是否有相关业务的元模型，即类似的功能不同的实现，但是本质上又是殊途同归的。
2、是否可以立即进行依赖解耦，针对需求的不同层面展开测试，只留下需求中变化的部分。
3、在一个新需求的情况下，是否可以快速进行模型划分，接口隔离，进入依赖解耦阶段，针对接口或层面进行测试？
总之，一切的根源都在于对于需求所对应的模型进行分析，划分层面，去除依赖，针对接口、切面进行测试。
多交流多讨论
与身边的人或客户多交流，多讨论。就可以深入理解需求，一味的自己看效果没有这样明显。 1、如果有需求文档，认真研读需求文档是最重要的。2、自己顺序记录每次变更，因为需求文档也许更新不那么快
并对每次变更做详细批注
3、如果没有需求文档，就应该关心客户，多根客户沟通，获取需求，并作相应记录
4、身边没客户，找开发人员，从整体上了解项目需求。 这个说简单点：就是先在不懂任何业务需求的情况下去随机测试，通过随机测试来了解业务流程，当然肯定会有不明白或不清楚的地方，这时，当在不懂的情况下在去反查需求，这样的一个反复的过程中，你就会更深刻的理解业务需求，并积累了测试的经验 平时多积累测试技术和经验；
多积累计算机相关知识，如网络、数据库等知识；
多与研发人员沟通，学习要测试软件的相关知识；
向经验丰富的人请教；
网络实强大额，上网查询相关资料学习是一个很好的方法；
掌握业务需求从改变思维方式开始
1、掌握业务需求从改变思维方式开始，树立场景的概念，尽快熟悉业务需求场景，进而深刻理解系统需求，从系统需求抽取流程、关键字（验证点）及准备支撑的数据。业务系统的测试无非如此、场景——流程——关键字——数据
2、以上思维方式的锻炼需要深入一个大型复杂系统（比如省集中项目）测试，然后积累的思维经验可以推广及其他行业、其他系统，不会受具体业务系统太大的限制。 如何快速掌握业务需求并进行测试？
1、资深的、有相关业务知识的测试人员进项；有相关经验的测试人员能更快速、更深刻的理解需求。
2、参加各种跟需求相关的会议，实时跟踪开发的需求讲解会议；第一时间把握需求，杜绝需求变动时被开发牵着鼻子走.....
3、认真、仔细研读需求文档，需求有不明或歧义的跟需求调研人员确定；
4、产出“功能点分析”--“测试点”
5、测试内部小组一段时间对产出的“功能点分析”、“测试点”进行内部评审
6、组织学习相关业务知识..... 关键是看公司！
一个追求效率第一的公司，是没办法的，比如我这个公司，成本控制得非常严重，比如要求测试这个系统10天来说，一天让你理解需求，超过了，扣你绩效，我都觉得可笑，或许跟我这个公司不重视测试有关系吧（虽然领导说重视，不过怎么感觉都不重视，测试人员感觉是公司里面的下等工）
怎样更好的理解需求
首先，测试负责人应该是有相关业务经验的人员，能够快速理解需求，并能够提出不合理的地方；其次，测试人员要尽早的进入项目，最好是在需求调研的时候就能够介入。
怎样更多，更好的了解业务需求
1.在没有多的测试任务时，多和开发工程师沟通，了解他们现在在做的项目，主要操作对象是什么，有没有开发文档（前提：测试没有参与项目前期工作）2.若公司比较规范时，项目启动前，主动要求参加需求讨论会（去听听）
3.任何一个功能，要知道做的原因，为什么而做（注意积累）
4.项目结束后，总结系统中的业务流，并形成文档（为下次升级做准备）
如何快速掌握业务需求并进行测试
1.直接与客户交流了解业务需求以及客户的操作习惯。这是我认为最有效最直接也是最快的方法，把握住客户整体的业务需求，了解客户平时的操作习惯，把自己当作客户去用这个软件，才能设身处地的了解客户的真正需求，才能纠正软件中一些非程序bug所致的错误。
2.尽早的阅读业务需求说明书。
在一个功能还未开发之前就应该阅读业务需求说明书，然后可以构思这个功能如何展现出来，最后可以把自己构思的功能和开发人员开发出来的功能进行对比，看哪些功能是不符合操作习惯和业务需求的。
3.多与设计人员、开发人员交流。每个人的想法是不一样的，虽然看的是同一份需求说明书，但是测试和开发人员的想法几乎完全不一样的。
[ 本帖最后由 huguxiang 于 2009-5-31 15:09 编辑 ]
页:
[1]
2
