2.1.3　过程实战

在进行业务梳理的时候，我们不仅要站在用户的角度去考量，而且要站在全局的角度，从系统设计出发，了解每一次需求改动会对全局产生什么样的影响，并评估出影响的范围。如果单纯地站在用户的角度去测试，那么我们将很难发现更深层次的问题，从而很容易出现漏测问题。

所以，我们需要对业务由表及里、由系统到服务、由服务到架构、由架构到逻辑进行梳理。业务梳理的具体策略说明如下。

（1）业务层面

“里”主要强调的是业务与服务之间的关系、服务与模块之间的关系，这样做的好处是能将服务与模块串联起来，让各个领域都能知道自己的服务里包含了哪些模块和功能。部分业务梳理效果图如图2-2所示。

图2-2　部分业务梳理效果图

（2）服务层面

整理测试需求或者进行技术评审的时候，我们必须清楚地知道所涉及的业务服务在系统中的位置、产品对外提供了哪些服务、需要依赖其他服务的哪些功能来完成业务交互，以及外界服务需要依赖哪些服务功能来完成哪些业务交互。简单地讲就是，如果换成我们自己，那么我们需要知道自己的能力边界在哪里？自己的核心竞争力是什么？如果换成服务层就是，它的服务能力是什么？它的能力边界在哪里？中间的交互层核心是什么？不论是对于QA团队还是研发团队，清楚地了解上述内容是对系统执行任何任务（task）的底线（baseline）。如图2-3所示的是服务层梳理效果图。

图2-3　服务层梳理效果

（3）数据流

用户一旦开始操作，数据就产生了：经过了哪些中间态，有哪些服务和逻辑可以改变数据状态，最后又是通过哪些服务的处理流转到数据库中的，中间的过程是如何消费的。也就是说，我们要知其然并知其所以然，不仅要了解表面的业务功能，还要知道数据流转过程中经过了哪些服务和处理逻辑，以及中间态的每个停留点的服务和数据最后落地的数据库。如图2-4所示的是数据流转梳理效果图。

图2-4　数据流转梳理效果

（4）特殊逻辑时序图

经验告诉我们，QA人员最容易遗漏如下两种测试点：一种是由特殊逻辑的盲区所导致的测试点，另一种是未考虑到的由各种异常所导致的测试点，比如ToB方面的测试，针对不同的企业，我们需要定制很多不同的逻辑。从登录、支付到消息推送等都会存在特殊的定制逻辑，所以我们需要对这些特殊的定制逻辑进行梳理，了解其上下交互点，以便后面的业务在涉及这些定制的功能点时，能够特别留心，从而避免漏测。如图2-5所示的是逻辑时序梳理效果图。

图2-5　逻辑时序梳理效果

当我们接触一个陌生的领域时，从业务到服务，从服务到上下游，再到具体的架构、逻辑处理、数据流转、所涉及的数据库（DB）等，我们要由表及里、快速地对整个业务有一个大致的了解，从而形成战斗力，并且能够高效地切换到另外一个领域，成为业务的顶梁柱。