今天忙了一整天，处理了很多问题，成就感爆棚。碰巧有一个测试用例评审，我想着去放松一下吧，没想到在会上我们吵起来了…

测试同学坚持分模块组织用例，这样有利于复用；而产品和开发更关心业务流程，觉得测试用例需要把流程描述清楚，而不是东一块西一块的讲。大家吵的不可开交，谁都说服不了谁，连我都气的数不出来话了😂。

其实问题的本质很简单，就是大家视角不一样，对用例的预期不一致而已。

矛盾分析

产品/开发的流程视角

产品/开发同学希望测试用例要像需求评审一样，能够把整个业务流程讲清楚，并把产品各个细节逻辑补充清楚。这样产品可以确保自己的需求自洽没有遗漏，技术可以对照者看自己开发的内容是否有缺失。

测试的功能视角

所有公司都存在一个共性的问题“测试用例复用度很低”。为了一个大需求好不容易梳理完的完整的用例，随着不断地迭代，原有用例慢慢就不适用了，而且在迭代的过程中很难持续的把一个单体的大用例维护到最新的状态。所以我们的测试同学坚持分模块维护，这样可以降低用例的复杂度、降低用例的维护成本，以此提高用例的复用度。

那么矛盾就来了，测试同学把用例按模块拆分的太过分散，评审的时候没有任何组织的讲着自己分解好的各个模块，而产品/开发完全看不到任何的需求流程，听的是一头雾水。测试同学在被持续的挑战过程中，想尝试按业务流程讲自己的用例，可是因为我们的业务太复杂了，结果效果更糟糕。（当前公司的业务复杂度，比我以往经历过的最复杂的业务还要复杂10倍，后面有机会详细讲一下）

如何解决

测试用例虽然主要是给测试用的，但是测试用例评审是需要给产品/开发讲清楚自己的用例的，所以用例评审需要做到把流程和功能两者兼容，达到“结构化流程用例”的效果。

所以解决方案很简单，测试同学只需要在原有用例的基础上，针对本次需求范围再附带一个流程化的用例。这个流程化用例需要把本次需求涉及到的主要业务流程画清楚，用例评审的时候就以流程化用例为引导，当讲到不同节点的时候再去过该节点各个模块的细节用例。

最后，祝研发、测试、产品一家亲~