最近工作时发现，每当业务提了新需求，我们的开发大佬就开始扑哧扑哧的建表开发代码，我这个测试呢，就开始利用难得的清闲时光，撸起了代码，学习测试开发技术。这样做呢，也会产生个问题，往往等开发大佬开发1周了，我这边还对业务在代码中的实际运行不慎清楚。
针对以上问题，如何快速的了解业务逻辑，代码逻辑就成了关键。分析下，这个阶段，接口文档一般没有，只有需求文档（吐槽一下，需求文档定稿了，还经常有改动，原因：领导为了支持业务发展，不管IT死活~~），表结构文档。此时答案就很简单了，通过需求文档了解业务基本逻辑，根据数据库表结构文档 脑补开发流程，推敲代码大致的逻辑，有不对劲的地方就直接问开发大佬。 经过这样一套流程，针对业务的功能测试点基本就清楚了， 能么一期一月的话，2天就基本能把测试案例大致写出来了（当然是精简版），后头的时间就是常规测试，加探索发现式测试了。
最后说下，这样做的好处， 毫无疑问的可以节省一部分的案例编写时间，让测试人员有更多的时间学习，充实自己，最终功能手工测试进化成 自动化测试，性能测试，乃至测试开发。其实笔者觉得，不管工作多忙，多累，也得留出时间去学习新的测试思想，测试技术，只有这样才能不被行业所淘汰。