这里是一个比较通用的工程结构目录示例，具体项目会有些许差异，但核心思想是相同的
工程目录结构决定了代码各层级职责和作用关系，推荐面向整体工程目录结构进行全局的case设计，进而梳理哪些模块需要进行测试，哪些需要重点关注进行复杂而周全的用例，哪些可以简单设计等，这里将工程目录划分为两部分：
如上图，函数执行过程从Req开始，经过method层进入，经过logic层复杂的业务逻辑编排，且可能会产生一些中间数据，联动dal、rpc、tcc、mq等原子能力支持，协同完成业务请求，最终通过Resp返回调用方。
简单举例来说，函数执行过程就像一条河道，决定走向（执行顺序）、深浅宽窄（复杂度）、分叉（执行路径）等；函数中的数据像河水，是真实流动的载体（数据），它一定是有源头（入参）的，流动过程中可能因为河道环境的不确定性戛然而止（异常中断），也可能因为其他河道的汇入而混浊（线程不安全），还可能因为一时间的阻塞而缓慢（性能），但它最终且最好的结果是汇入大海（结果）。
一般从函数入口到函数结束，大体经历*接口定义层(method) -> 业务逻辑层(logic) -> 数据访问层(dal)、远程调用层(rpc) *等等，我们可以按照工程结构的分层职责来进行case设计：
函数执行过程中的数据，一般有函数入参、函数出参以及过程中间数据，可以在函数入口对函数入参进行参数有效性校验，比如非空、数量限制等；在函数执行过程中对中间数据一般为临时产生的数据进行校验，中间数据一般作为其他子逻辑的前置条件，所以可以在进入子逻辑模块前进行预期验证，适当增加中间数据的验证可以丰富case设计更加饱满充实，提高逻辑的严谨性；最后是对出参结果的预期验证。