测试人员如何快速掌握被测软件业务流程？（2010-1-27）（获奖名单已公布）
测试人员如何快速掌握被测软件业务流程?此话题由会员mihuxu520提供，如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！
获奖名单奖项获奖名单奖励答案链接一等奖shine200150元手机话费充值卡6#
http://bbs.51testing.com/attachments/month_0811/20081125_650d7dccd46be6244f27oXDjE0HoDhyX.gif
相关文章：
业务流程测试总结
QTP测试数据通业务流程分离方法探索和小结
更多内容请点击＞＞＞ 先坐一下，楼下说 1.先大致看一下,业务流程以及业务需求说明书.
2.通过功能测试用例,简单的跑一下被测软件
3.再次温习业务流程及业务需求说明书 顶楼上，首先可以通过文档，比如需求说明书、策划案，有用户手册最好了，用户手册对客户有一个指引作用，可以让我们了解项目的框架以及大概的流程，其次可以通过执行别人写的测试用例，测试用例对于每个流程都应该是写的很清楚 顶楼上
回楼主：你说的应该是新入职测试，或者从其它组借调过来的测试人员吧，
一般情况下测试人员从需求、设计评审就已经介入了，等软件做出来，测试人员对整个软件业务流程就应该已经很熟悉了:) 被测软件的业务流程是开展测试工作的重要准备活动，同时在测试过程中起到十分重要的参考和分析依据作用
这个问题很简单但是又很难。简单是因为软件业务流程可以顺藤摸瓜，难是因为不知从何入手
“被测软件”听起来有点大，被测软件的行业背景、软件的大体作用，总的框架结构这些“大”方面的信息比较容易获取和理解。实际上软件是由众多功能组成的，在实际工作中，功能模块的业务流程对测试起到了直接的指导和参考作用（例如测试用例的编写，测试结果的分析等等），不掌握业务流程则不足以很好的测试
测试人员想要获悉软件功能模块的业务流程，就必然要牵涉到开发人员，也就是要涉及到开发与测试的接口
这个问题想要解决，有很大程度要依赖于测试与开发的合作。开发测试体系是否规范和健全非常影响这一结合点乃至影响整个测试的流程。不同的公司，不同的项目，甚至同一个公司不同的项目组在这个方面都可能存在很大的偏差，这个问题是无法逃避的。
我在论坛中，在QQ群中经常看到某某项目，什么资料都没有，什么会议都没参加，就让我们测试，我们怎么测试啊。偶尔也能看到有的项目从需求、从设计阶段测试人员就介入了进来，从而测试人员测试的时候非常顺畅，流程进展的也比较顺利。
这两种情况简单的总结一下就是测试人员的“知”与“不知”，“早知”与“晚知”
当测试人员遇到“一穷二白”（什么都不知道，什么材料都没有）的情况时，这就是“不知”
如何应对这种情况呢？首先请务必不能抱怨，在你抱怨的同时其实也伤害了你自己。
我常常对新人说，站起来，不要老是坐在位置上。不要依赖于outlook，聊天工具，电话。
请务必现场找到这个软件功能模块涉及的开发人员，最好能够找到一个“头”（也可以由你的头找到他们的头），OK，下面就是真人PK，刚开始这很折磨人，你什么都不知道，但是你必须得问，一定要把某个点弄明白（例如功能模块中的某个程序是做什么的，这个功能模块是谁谁谁负责，这个功能模块涉及到了界面、数据库），找到这个点就可以顺藤摸瓜，把所有涉及的开发人员问个遍（有条件的话，可以所有涉及的人员坐下来探讨一下，对测试人员对开发人员都有好处，要知道负责不同功能的开发人员很可能对项目的其他开发人员负责的部分一窍不通，对整个业务也是糊里糊涂）。沟通的同时要记得互惠互利，你知道的，也要告诉不知道的人，在你以后的沟通交流生涯中，形成一种良性的互惠活动，而非一味的索取答案。
通过良性的循环，使得测试人员从“不知”变为“晚知”
当然“晚知”相对于“早知”花费的气力和代价大很多，但这恰恰是很多人遇到的情况，不得不面对
对于有着良好的开发测试流程体系的团队来说，则要幸福很多，可以“早知”
但是也不要放松自己，因为“早知”不代表你“明知”（正确明白的知道）。
在测试过程中，随着测试的覆盖和深入，必然引发各种问题和疑问，需要去判断和分析。这个时候依然需要测试人员和开发人员协力合作，促成双方对业务流程、功能细节、原始需求等方面的加深理解
当开发与测试团队互相配合，互相信任时，管理和流程上的不足的影响也会被弱化，测试和开发之间的“瓶塞”会被淡化。对于一般的测试人员而言，请不要轻易对种种不完善，不好，不行做出负面评价。因为这对于大家而言没有好处，也无法改变现状，不是吗？！:lol 顶顶LS, 说的很实在。
看需求规范谁都知道，可惜在神奇的土地上，只有少部分公司才有需求规范滴~:) 顶楼上的，要是文档都那么规范，我想提问题的就不用这么头疼了吧。 根据分析文档说明，了解业务流程。或者问业务人员进行了解....
小公司全靠自己领悟，那来个啥子需求文档以及各种说明啊。
小公司全靠自己领悟，那来个啥子需求文档以及各种说明啊。 查看软件流程图 1、看该项目的需求规格说明书；2、询问老员工软件的流程和爱出错的地方；
3、自己实际使用此软件进行流程熟悉。
我总结就这几点，楼下继续阐述！ 树是死的，人是活的
要掌握业务是没有捷径的，唯一的捷径就是勤奋
条件是人创造的，规范是人制定的，过程是人改进的
从无到有离不开刻苦，勤奋，努力，坚持
同样的事情，同样的做法，同样的过程，人与人之间是有差别的
有的人聪明，悟性高，一模一样的做法也会事半功倍
有的人底子弱，一模一样的做法却事倍功半
方法一样，过程一样，有人快有人慢，不可比也
因此，与其说如何快速掌握，不如说如何找到学习方法，如何找到“致富”的路
条件再好（资料，规范，流程齐全）也是人创造的
条件再好也需要人去利用才能发挥条件的价值
以不变（求知，求学，进取的心）应万变，万法归一:lol 阿弥陀佛，一激动，我唐僧了:Q 如果没有较好的文档的话，个人觉得最好的办法就是沟通。多和产品、开发人员聊聊，从他们的嘴中挖些自己想要的东西。 觉得还是沟通重要，运气好的能够遇到一个好的需求，一个好相处的开发，可万一运气不好呢，就不能说不去沟通了吧
另外，参考市场上的同类产品的功能也觉得是个不错的办法哦，有助于理解被测软件的业务流程 目前正在为了更好地明白软件而进行专业方面的学习，所以也就此发表一下自己的看法：
正如楼上各位所说的那样：
1、最好是能得到一个好的测试需求，这样就可以省去你自己做需求的过程，而通过这个好的需求你还可以更好地把握系统本身，为将来的测试提供一个好的帮助；
2、比较明白和细致的开发人员，这个有助于你在遇到问题的时候寻求帮助，减少开发人员和测试人员之间不必要的冲突，因为就像测试与开发之间的关系说的不好听点有些类似于警察与小偷之间的关系，有冲突是必然的，你净找人家的麻烦任何人都不会舒服的，大家说呢？！
3、提供比较完善的用户帮助手册，这样即使是你没有使用过该软件也可通过流程来熟练自己的操作，但是也只是了解和熟练而已。
4、我要说的比较关键的一点就是：必须了解相关的业务。是的，就是相关的业务。
有很多的业务不是简单地用一个流程就可以看明白和操作明白的，他背后有强大的理论支撑，作为一个测试人员，如果单单去根据手册跑完流程是简单的，但是我相信，这样的测试肯定是不完全的，其中可能隐含的原则性问题你肯定也将发现不了，因为你不了解业务，你只能从别人给你的一点点东西中来寻找错误，那么如果所给你的东西本身就是个错误哪，你又会怎么办呢？
举个例子，这个也是我曾经遇到的事情，建设银行的U盾，大家都知道银行的U盾有密码，并且只能在使用的时候一次实验10次，然后就会锁定，大家肯定说这有什么稀奇，但是大家不知道的是，以前建行的U盾在实验10次以后就报废掉，因为它的密码是不能被重置的，这个估计曾经对建行U盾做过测试的人员没有想到的吧，但是这个却是事实，因为这是硬件本身的问题，同时也是软件的问题。
5、所以说要想快速掌握被测试软件业务流程，不能仅仅从上面几个方面来把握，入手可以，但是把握还是不够，我们还必须在长期的工作过程中了解业务流程背后的东西，有了足够的理论作指导，将来在把握起被测试软件的流程上才能更快速，更准确，更全面。
不知道大家是不是这么想的 画流程图 给人讲解
回复 13# 的帖子
顶你 ，说的很好 原帖由 test_fairy 于 2010-1-29 15:14 发表 http://bbs.51testing.com/images/common/back.gif目前正在为了更好地明白软件而进行专业方面的学习，所以也就此发表一下自己的看法：
正如楼上各位所说的那样：
1、最好是能得到一个好的测试需求，这样就可以省去你自己做需求的过程，而通过这个好的需求你还可以更 ...
说的挺不错的
