后台回复「加群」，一起进群学习
阅读本文大概需要 5 分钟。
最近朱老师新开了一门敏捷测试的线上课，我也在跟着学，其实很早就听说过敏捷的概念，但一直没有用心去研究。
一方面是因为工作太忙（懒），另一方面是觉得这些新思想（别争，你就认为是新的好了），让老师们先去研究，我们多花点时间专注实际的业务，等老师们研究透了，我们直接把成果进行落地 ，这样既发挥了各自的专长，还能起到互补的效果，岂不美哉。
现在刚好有成果输出了，赶紧学习下，目前讲到第 6 讲，要说我的收获，一是知道了朱老师对于敏捷测试的定义，二是知道了朱老师定义的敏捷测试八大原则，三是知道了敏捷测试强调全流程测试（持续测试）。
说到全流程测试，就不得不提很多人关心的「单元测试」，而说到单元测试，我又自然的想到了在我浏览器中长期占据一个 tab 页的文章《为什么大多数单元测试是浪费》（后台回复「浪费」获取 URL 地址）。
为什么长期占据我浏览器的一个 tab 页？主要是我作为实用派，一直对单元测试的投入产出比存在疑问，但是自己又没有实际做过单元测试，所以很想知道别人反驳的理由，顺便结合自己的项目，做个取舍。
整篇文章读下来，作者并没有全盘否定单元测试，只是建议只做必要的单元测试，主要反驳的是实际项目中，单元测试至上的思想，至于不做单元测试的部分，作者建议用断言、系统测试以及开发同学的意识来替代。
我很赞成这种想法，但实际落地的可行性仍然存在疑问，之前的单元测试，要么是具备很好质量意识的开发来做，要么是具备很好代码能力的测试来做，现在等于完全倾向于具备很好质量意识的开发了，而国内开发人员的现状，离这个程度还是有一定差距的（开发同学别怼我）。
那我的建议是什么呢？
目前在编码阶段就介入进行质量保证里面比较实用的做法，一个是自动化静态代码检查，一个是人工静态代码 Review。
自动化静态代码检查，可以发现那些比较固定的、有明确检查条件的问题。
人工静态代码 Review，如果碰到负责任的开发，不仅可以发现业务实现上的逻辑问题，还可以发现一些潜在的技术问题。
但是这两种方法都有一个共同的缺点，就是很难发现一些动态执行过程中的问题，比如内存泄露，就是很难确认分配内存和释放内存的匹配操作。那有没有解决方案呢？
也算有吧，一种是针对性代码插桩，对症下药，就是麻烦，一种是安装一些插件，代码编译时自动实现了插桩，但是需要带着插桩的代码进行测试，也是个问题。
所以我突然想到了一种借助沙箱进行动态测试的方案。
所谓沙箱，就是一个完全独立隔离的可执行环境，目前主要应用于安全领域。
说起它的演进过程也挺有意思，很久之前杀软识别病毒都是靠静态特征码（类似我们的静态代码扫描逻辑），后来病毒进化了，没有显著的可以识别的静态特征了，或者有些敏感特征正常软件也会用到，所以杀软就发展出一种行为检测的方法，就是通过检测病毒/木马干了啥来判断是否恶意，而判断木马干了啥，一种方式是等木马干活时抓现行（滞后、被动），另一种则是把木马丢到沙箱里面主动运行起来，这是目前一种非常有效的识别手段。
同理，对于我们静态扫描没法判断的检查点，是不是也可以利用沙箱 + 代码执行 + 行为监控点的方式，去发现那些需要动态执行，并且黑盒测试又不方便验证的点呢？
以上，我好费劲的从敏捷测试引到了沙箱动态检测，不知道你看明白了没有？目前，这个方法还只是个猜想，如果大家有其他的方式，请多赐教，如果针对上面的方案有任何问题和建议，欢迎留言一起讨论。
当然， 如果对我的观点感兴趣，欢迎分享文章到朋友圈 + 点个「在看」让更多人看到，谢谢。
为了感谢大家的支持，我准备了一个抽奖，在 3 月 5 号上午 8 点 15 分自动开奖。
感谢你的阅读、在看和转发，点我抽奖，祝你好运！
推荐阅读：
4822
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
