业务流
业务流
曾经一段时间，同事们把做得好的测试人员分为两种，一种是“业务流”，精通软件需求业务，对功能的业务逻辑进行深入研究，提的bug大多是与业务实现息息相关的，只是更多的关注操作流程，每一步操作顺序倒来倒去的，就常常出现了致命的bug，其实这些bug也正是客户和市场人员最在乎的；一种是“操作流”，在我们组内大多是计算机专业毕业，动手能力较强，常常能经过复杂或者诡异的操作来发现一个bug，并没有经过什么仔细的分析业务，由“操作流”发现的bug，在业务上没有太多深度，一般都是系统崩溃、报错、或者发生较功严重功能错误，往往市场人员和用户不是很注重这种bug，甚至有人说，谁会去做这种变态又复杂的操作呢？
两种测试方式都是必不可少的，业务与实现既要很好的分离开来，也不能单独的存在，只能说侧重点不同罢了。
业务流的测试如何在测试用例中体现？
1、一个功能会有很多的入口。比如下订单，可以从采购单下订单，也可以从历史订单中下订单等。如果我按照功能划分写测试用例的时候，那是不是要把每种入口作为一个测试用例写呢？
2、不同角色处理订单会有不同的流程，比如采购商和供应商在订单处理中是不一样，采购商主要是查看订单配送情况以及取消订单等操作，而供应商是负责配送订单等。
那如果写测试用例的时候，该如何体现这种业务的流转。感觉按照每个页面写的用例，都是静态页面似的。但我们实际测试的时候肯定会先按招业务流程执行的。
1、首先需要明确，你无论从那个入口进入，是否都是调用的同一模块；如果每个入口都是调用的同一模块，我认为没有写每个入口的测试用例，只是需要写初每个入口是否能够调用订单模块的测试用例。如果是不同模块，毫无疑问的需要写不同的测试用例。
2、不同角色处理订单会有不同的流程，这个根据场景法写，重点放在不通角色的处理流程是不是正确。
简单来说就是：
1、一个入口一个测试用例
2、一个角色一个测试用例
最关键是设计基于业务场景的用例，这里的用例不是我们通常意义上的测试用例，它是业务场景，但是在设计这些场景时，要考虑业务的各种组合情况，通过业务流程、公式、数据流把业务链接起来，形成一个一个的业务流，将来这些业务流就是我们功能测试中的一个个执行流程，这些流程将把测试设计工程师设计的测试用例贯穿下来，在测试用例中不写测试数据，而在业务场景中设计测试数据，这样能够让测试用例得到最大的复用，也就是不同的业务流可能使用同一个测试用例。
但是目前，在设计中也出现了一些问题，例如，在设计这些场景时，还是需要花费大量的时间，因为场景非常多，只能先设计典型业务场景，再考虑特殊情况。
该方法是我根据银行项目的特点以及对质量的要求设计的，以求达到对业务功能的覆盖。