从场景和需求出发，我们了解了功能点和测试范围。

从技术方案中，了解大概逻辑和应用之间的交互，进一步明确了测试点。

从代码实现考虑，我们知道了背后具体的实现机制，能够告诉你数据如何存，错误信息是什么。所以在实际执行功能用例之前，我往往会扒开发代码来看一看。

不同的实现对测试执行有着不同的影响，我理解这背后影响的是可测性：因为遍历各种可能的情况并不划算，所以我们想用尽可能少的用例来更多的覆盖代码逻辑，要做到这点是简单还是难？

根据实现，我们可以判断出之前的功能case的等价类划分是否真的是等价类了；除了功能场景外，针对实现的逻辑还有什么需要重点测试的。

如：

有一个功能是更新库存关系，实现的功能就是增加、删除、修改供货关系以及供货规则和策略，也涉及了各种情况下的校验

从开发的代码实现中，开发是根据传入的列表对需要变更的对象进行了分组，然后对变更的对象和仓库进行了校验，可以看出：

第一.仓库纬度的是否允许变更的规则对于各种修改情况都可以适用，开发也统一由checkWareHourseStatus来处理，所以对于仓库纬度的校验不需要按照之前用例写的每种操作都验证一次，精简了之前的用例

第二.如果是通过数据库数据的校验，确认字段意义准确无误的话，可以直接通过构造数据来代替复杂的真实构造过程，比如过期、停用等等

一些难以构造的就远程debug，然后可以修改数据

第三.操作和检查是否能够正常执行，用的是diff然后分类和分组逻辑，所以需要组合各种情况来验证分组的正确，这是一个比较重要测试的点，需要补充下各种组合的情况

另外通过了解代码实现也会提前发现一些其他问题：

1. 如果用例上有，而开发未实现的场景，属于特性遗漏，需要让开发补上

2. 一些代码逻辑问题，比如字段校验、检查、异常处理等等

如：赋值错误

如：没有return

如：没有抛异常或者检查返回

3. 隔行如隔山，需要再确认下一些相关业务的定义，如判断店铺类型