一种基于沙箱的动态测试的设想

为什么长期占据我浏览器的一个 tab 页？主要是我作为实用派，一直对单元测试的投入产出比存在疑问，但是自己又没有实际做过单元测试，所以很想知道别人反驳的理由，顺便结合自己的项目，做个取舍。

整篇文章读下来，作者并没有全盘否定单元测试，只是建议只做必要的单元测试，主要反驳的是实际项目中，单元测试至上的思想，至于不做单元测试的部分，作者建议用断言、系统测试以及开发同学的意识来替代。

我很赞成这种想法，但实际落地的可行性仍然存在疑问，之前的单元测试，要么是具备很好质量意识的开发来做，要么是具备很好代码能力的测试来做，现在等于完全倾向于具备很好质量意识的开发了，而国内开发人员的现状，离这个程度还是有一定差距的（开发同学别怼我）。

那我的建议是什么呢？

目前在编码阶段就介入进行质量保证里面比较实用的做法，一个是自动化静态代码检查，一个是人工静态代码 Review。

自动化静态代码检查，可以发现那些比较固定的、有明确检查条件的问题。

人工静态代码 Review，如果碰到负责任的开发，不仅可以发现业务实现上的逻辑问题，还可以发现一些潜在的技术问题。

但是这两种方法都有一个共同的缺点，就是很难发现一些动态执行过程中的问题，比如内存泄露，就是很难确认分配内存和释放内存的匹配操作。那有没有解决方案呢？

也算有吧，一种是针对性代码插桩，对症下药，就是麻烦，一种是安装一些插件，代码编译时自动实现了插桩，但是需要带着插桩的代码进行测试，也是个问题。

所以我突然想到了一种借助沙箱进行动态测试的方案。

所谓沙箱，就是一个完全独立隔离的可执行环境，目前主要应用于安全领域。

说起它的演进过程也挺有意思，很久之前杀软识别病毒都是靠静态特征码（类似我们的静态代码扫描逻辑），后来病毒进化了，没有显著的可以识别的静态特征了，或者有些敏感特征正常软件也会用到，所以杀软就发展出一种行为检测的方法，就是通过检测病毒/木马干了啥来判断是否恶意，而判断木马干了啥，一种方式是等木马干活时抓现行（滞后、被动），另一种则是把木马丢到沙箱里面主动运行起来，这是目前一种非常有效的识别手段。

同理，对于我们静态扫描没法判断的检查点，是不是也可以利用沙箱 + 代码执行 + 行为监控点的方式，去发现那些需要动态执行，并且黑盒测试又不方便验证的点呢？

以上，我好费劲的从敏捷测试引到了沙箱动态检测，不知道你看明白了没有？目前，这个方法还只是个猜想，如果大家有其他的方式，请多赐教，如果针对上面的方案有任何问题和建议，欢迎留言一起讨论。