初步了解接口测试

项目进度到了接口测试阶段。
公司遵照日方的开发规范，将接口测试设了个别名，叫做MK3
首次接触MK3，对MK3测试case的作成不解
师傅说一定要从顶层写，我不明白测试一个函数，怎么能保证在顶层就能进入函数的各个路径。
查看一下开发文档，上面说MK3的方法有两种：自顶向下和自下向上，经过不停的讨论和揣摩，我现在的理解是这样的：
接口测试从某种程度上，跟CT即（部件测试）有点相似，只不过现在的模块程度要小得多，接口是提供给内部用户（开发者）使用的。
所以MK3对路径的覆盖度不高，只要能保证接口间正常通信与完整的数据传递即可，效果介于白盒测试和黑盒测试之间。
自顶向下方法比较受用，可能因为作为外包公司，日本那边在接手产品时关心模块的外部接口，倘若从外设角度把各个路径覆盖完全，就能大大降低解析函数的要求，判断一个模块好不好用，从各阶段的测试说明和测试报告可以很快得出结论。自顶向下的测试用例作成方法对不想了解内部逻辑和框架的客户方是比较受欢迎的。
而从书写用例角度来讲，自底向上对程序员，在此指那些熟悉代码结构和具体语句的开发者，是比较受用的。我一开始，在没有了解任何开发资料的情况下，潜意识地按照从最底层函数开始，把每个函数内部的路径抽象出来，设定一些关键数据，我称之为要因吧，然后逐渐向上，可以充分保证路径的完全覆盖（路径覆盖是单元测试的内容），能达到全路径的话，岂不是把所有的测试都保证了？
我现在觉得有个折衷的办法，就是从底层开始写，写到最上层的时候，回顾一下，把那些在外层就测到的要因都提取出来，用一个最外部的接口来测试，不能提取的就是说明最终用户也无法到达，就可以作为白盒测试来做。
对于分工来讲，接口测试需要开发者各和独立的测试员配合，因为我发现作为开发者很难站在上层角度来想一些可能的数据组合。
这是我的一些主观认识，可能不对，但是我要的就是自己的认识和自圆其说，能够和软件工程定义切合，就太好了，还有差距的话，也不介意，总算思考了一下，坚持下去，就会认识到位了。