标签：
被测软件的业务流程是开展测试工作的重要准备活动，同时在测试过程中起到十分重要的参考和分析依据作用。
这个问题很简单但是又很难。简单是因为软件业务流程可以顺藤摸瓜，难是因为不知从何入手。
“被测软件”听起来有点大，被测软件的行业背景、软件的大体作用，总的框架结构这些“大”方面的信息比较容易获取和理解。实际上软件是由众多功能组成的，在实际工作中，功能模块的业务流程对测试起到了直接的指导和参考作用（例如测试用例的编写，测试结果的分析等等），不掌握业务流程则不足以很好的测试。
测试人员想要获悉软件功能模块的业务流程，就必然要牵涉到开发人员，也就是要涉及到开发与测试的接口。
这个问题想要解决，有很大程度要依赖于测试与开发的合作。开发测试体系是否规范和健全非常影响这一结合点乃至影响整个测试的流程。
请务必现场找到这个软件功能模块涉及的开发人员，最好能够找到一个“头”（也可以由你的头找到他们的头），OK，下面就是真人PK，刚开始这很折磨人，你什么都不知道，但是你必须得问，一定要把某个点弄明白（例如功能模块中的某个程序是做什么的，这个功能模块是谁谁谁负责，这个功能模块涉及到了界面、数据库），找到这个点就可以顺藤摸瓜，把所有涉及的开发人员问个遍（有条件的话，可以所有涉及的人员坐下来探讨一下，对测试人员对开发人员都有好处，要知道负责不同功能的开发人员很可能对项目的其他开发人员负责的部分一窍不通，对整个业务也是糊里糊涂）。沟通的同时要记得互惠互利，你知道的，也要告诉不知道的人，在你以后的沟通交流生涯中，形成一种良性的互惠活动，而非一味的索取答案。
通过良性的循环，使得测试人员从“不知”变为“晚知”。
当然“晚知”相对于“早知”花费的气力和代价大很多，但这恰恰是很多人遇到的情况，不得不面对。
对于有着良好的开发测试流程体系的团队来说，则要幸福很多，可以“早知”。
但是也不要放松自己，因为“早知”不代表你“明知”（正确明白的知道）。
在测试过程中，随着测试的覆盖和深入，必然引发各种问题和疑问，需要去判断和分析。这个时候依然需要测试人员和开发人员协力合作，促成双方对业务流程、功能细节、原始需求等方面的加深理解
要如何才能掌握好业务流程呢？有以下几点比较重要：
一、了解主体的业务框架，不必追求分支细节。先对总体业务有一个印象，知道一些概念性的东西，混个面熟；
二、了解为什么要有这个业务，最原始的需求来自于哪里。可以跳出当前的这个业务流程思维，考虑下最源头的业务驱动，原本这个业务是解决一个或者一类什么问题的。这样也算是有的放矢了。
三、站在用户或业务需求本身的角度来理解分支细节。这个时候可以充分发挥我们的想象力去理解这些东东，也可以找一个熟悉这块业务或类似业务的同事来聊聊，或许会有很多意外的收获。
四、将分支和主干全部都串起来，一体化思考整个业务流程。重新梳理你对整个业务流程的理解，如果还有不通的地方，可以再次去求证。这个时候你对业务可能就不再仅仅是理解，或许你还可以发现其中不合理的地方，一切皆有可能。
另外，不要把自己限制在测试人员的角色里，在熟悉和理解业务的时候，需要从多个维度去思考问题，比如：从需求方的角度去考虑业务本身的价值走向；从开发的角度去推断业务的逻辑构架；从测试的角度去分析业务的合理和完整性；从用户的角度去体验业务的易用性。
1、在需求文档，设计文档等相当的规范的情况下，当然是先拿到文档后熟悉业务流程，一般在业务流程比较了解的情况下，公司会有开发做产品和技术的介绍，这样可以比较深入的了解开发的背景，以及一些技术的特点，也可以了解到测试的侧重点等等……
2、在没有详细的需求文档时，一般有2中情况，一种是有设计文档，看以先看看设计文档，熟悉业务的流程图，这样的话测试人员要花比较多的时间在流程上，希望在开发讲解产品和技术介绍之前，能够补上没有需求文档带来的业务不熟悉……
第2种情况是既没有需求文档也没有设计的详细文档，那个人建议多和开发沟通，不懂，不清楚的都只有找开发口传需求了，这样估计效率不叫低。
3、需求一直变？ 那最好的办法是多和开发，需求设计人员沟通吧，沟通在没有详细的文档的时候是最有效的了 。
4、开发不好沟通……事情不好做哦
标签：
原文地址：http://www.cnblogs.com/dayiran1222/p/4876255.html
