我倾向于将功能看成是系统面向用户的业务需求，这个问题可能隐含着一个前置问题是如何识别出每一个有效的业务场景？
要识别出有效的业务场景，你可以通过对对业务需求做Tasking，来梳理你对需求的理解，并做到结果可视化，方便你跟业务人员沟通确认。在ThoughtWorks敏捷交付团队中，通常开发人员面对的直接业务方是团队内部的BA，所以你可以直接去跟BA去确认需求细节，如果说BA自己也不清楚，就需要去跟客户方的PO去做需求澄清了。当然，如果PO也不清楚，那就弹尽粮绝了。真实项目中，还真会遇到PO也不清楚需求的情况，此时，我更愿意说你是在做需求快的速验证，建议你就先不要写测试了。假如这种状况持续时间较长，建议你先休假几天，如果一直是这样子，你可以考虑离职了~
还是回到需求都相对确定的情况下，当你通过Tasking、沟通确认后，框定了业务需求的Scope，下一步针就可以针对业务需求Tasking的结果编写测试用例了，我强烈推荐你采用TDD。
随着任务列表的推进，测试用例的增多，你也积累了更多的经验和业务知识，你会发现最开始Tasking也有未考虑到的场景或考虑有偏差的场景，遇到这种你不要惊讶、心生疑虑，敏捷本身就提倡从实践中获得反馈并做出及时的调整，一开始不需要十全十美的设计，在过程中获得有效反馈后（确认需求细节无误），调整更新Tasking结果即可，然后再回到你原有的开发节奏中。
铺垫了这么久，回到问题本身，即便你在需求确认和Tasking下了很多功夫，也不能100%保证你的功能可测试，但已经能帮助你避免80%以上不可测试 或 难以测试的场景。采用TDD方式编写的代码，为什么更加可测试？推荐阅读 测试如何驱动设计？
155-2731-8020