执行结果如图，这样就完成了对用户行为的模拟以及结果的自动验证。
好，通过自动化测试沙盒，解放了大量测试人力，使得他们可以更专注于版本特性，保证了版本质量。接下来看看代码包超限的问题。
不管是微信小程序，还是支付宝小程序或者其他小程序，代码包大小都是有限制的，拿微信小程序举例，总包上限为8M，主包或单个上限为2M。
代码包超限首先是影响发版进度，不知道你有没有体验过：熬夜加班写完代码，测都测完了，跟别人的分支合并时发现超限了。这显然不是一时半会能解决的，不紧急的可以等下次发版，紧急的就只能推迟发布了。
然后是新增业务，分包大小已经接近上限了，来个新页面，谁来腾空间？这也是个不得不面对的问题。
最后由于代码包太大，启动慢是必然的，太接近包上限，也容易导致小程序内存不足、甚至微信客户端闪退等问题。
怎么办呢，首先是要减小体积。常见的减小体积的方式有这些，前面几种手段相对比较常规，重点讲一下最后一条：找出未使用的文件、函数，删掉。
来看看未使用的文件、函数是怎么形成的。项目初期我们使用 gulp 进行构建，通过规则指定哪些目录需要打包，哪些文件需要剔除等，但久而久之，规则难免有遗漏。随着业务迭代，页面/组件下线，许多公共函数不再被引用，这些靠人工是很难识别的。自然也是需要通过工具化手段来解决。
第一个手段是依赖分析，通过工具在打包时删掉未使用的文件、函数，释放空间。另外一个手段是只能分包，打包时按照算法动态调整 NPM 包到主包或子包，临时调整分包大小。
文件的依赖分析，前面已经讲过了，下面看看函数依赖分析怎么做。
函数依赖分析，或者说 Tree-Shaking，就是识别出未使用的代码并删掉。在 h5 里听得多，相信大家也都有一些实践，小程序如何做呢？
首先，Tree-Shaking 基于 ES6 的模块机制，为此，我们我要统一对小程序代码做了一轮改造，将 commonjs 模块写法全部替换成 ES6 的模块写法，这是前提。
有了这个前提，在 CLI 打包过程中，可以将代码转成 AST，通过 AST 获取各模块的调用关系，删除未使用函数节点，再将 AST 转成代码。
具体实现可以参考这份代码，需要注意的是，一个函数没有被其他模块引用并不代表可以直接删除，还需要考虑模块内的引用情况，同时，写代码时尽量避免副作用。
依赖分析可以删除未使用的文件、函数，释放空间。智能分包则是可以临时调整各分包大小。
看图，左边第一个分包使用了 cookie 和 md5 两个包，第二个分包则只使用了 cookie，通过算法配置，在时可以选择将两个 NPM 包都提到主包，这时主包大，分包小。或者仅将共用的 cookie 提到主包，md5 留在分包，这时主包小，分包大。这样可以大幅度缓解发版时主包或者分包超限导致延期的问题。