0.前言
这篇论文是通过神经网络等方法生成JavaScript代码监测其Engines是否同具有一致性错误。
1.介绍
首先我们先来聊一下JavaScript，这个语言通常用于网络浏览器以及一些嵌入式应用中，而JavaScript Engines则是用于执行处理JavaScript脚本的虚拟机。我们都知道编程语言都有一份公认的标准，所有的执行器都需要能够按照这个标准去执行语言，否则就会给开发者带来困扰。但是由于编写engine的工作过为庞大，其中难免会出现错误，而想要人工去检测这些错误因其工作量也是不大可行的，那怎么办的，本文作者给出的方法是，让计算机自己去产生测试代码来检测一致性错误。看起来思想比较简单是吧，那么之前有没有人想过这么做呢，当然是有的，但是问题在哪呢，问题在于原先的测试代码通常是通过生成(Generative)或者突变(mutational )方法产生的,都需要人来构建语法规则或者构建语料库，这将会随着JS语言的进化而变得越来越复杂。那么作者是怎么做的呢，万物皆可机器学习。除此之外，只有代码是不够的，有些问题需要在特定的输入情况下才可以展现出来，因此我们还需要构建数据，然而，JS是弱类型语言，使得随机生成输入数据的成本变高，作者通过语言标准手册ECMA-262来生成输入数据，从而降低测试的成本。现有的数据生成技术使用输入生成技术将随机值赋值给变量，由于担心上下文的缘故并不会随意的将一些特殊值(undefine)赋给变量.但是我并没有看出作者是如何解决这个问题的，作者只是说使用ECMA-262去指导输入的生成具有很好的效果。
2.COMFORT
接下来就是正题了，作者为了解决上面所提出的问题，提出了一个项目叫做COMFORT，那么他是如何工作的呢，上图!
当然，光看这张图肯定是不够的，其目的只在于让你对其有一个结构性的了解，下面我们来分块介绍一下。
1. 提取ECMA-262标准特性
首先这个ECMA-262标准特性是啥呢，我的理解是对于语言标准的一种表述，比方c11之类(话说我其实连c11是个啥都说不上来 ==)，作者说其大概就是如下这样，即对于API的一些描述
这一步的工作是由ECMA Script Parser完成的，其通过一个内容分析库以及作者团队写的正则表达式完成对于其中元数据的提取，提取结果得到一颗抽象语法树，然后再将其以JSON形式存放在数据库中。至于为什么要先得到一颗抽象语法树，我并不是很清楚，或许是因为技术原因?
注意看，其提取的结果中包含了边界条件等，这为之后输入数据的生成提供了基础，但是我依然有两个问题没想明白，value是怎么得到的，scope是什么东西。
带着迷迷糊糊地理解，我们来到了下一部分
2.测试程序生成
测试程序生成模型是通过对GPT-2模型用Github上的JS项目代码进行微调(fine-tuning)训练得到的。其首先需要将输入代码转化成一个数值序列，即将每个指令，常数，变量都映射成词汇表中的一个整数，词汇表采用Byte Pair Encoding tokenization方法进行构建，这一步的主要目的是通过重用有限的token(即那个数值)来表示具有很多单词的JS程序，我觉着大概这样可以降低工作量。其次就是通过这些数据对模型进行微调，方法是重训练最后两个全连接层，对其他层的参数保持不变。
得到模型后，下一步就是生成测试程序了，这一步首先要求提供一个seed generation header，这个seed generation header类似于一个函数头，比如说"var a = function(assert) {"就是一个程序头然会将该程序头放入模型，模型计算出10个最有可能的下一个单词(或者说是数字更为贴切)，然后随机挑选一个，如此反复，直到达到停止条件。然后对得到的代码进行语法检查，作者说其保留了20%语法有错误的测试样例，以期更好的监测其一致性。
3.测试数据生成
有了测试代码，就还需要测试数据，测试数据的生成就是基于我们前面说的对于ECMA-262的提取结果，包括测试数据的边界结果与随机取值。对于数据的改变，还涉及到了遍历代码寻找定义并改变的过程，即line8
通过以上的方法为每个测试程序生成了多组测试样例。
4.差分监测及一些优化
有了数据和程序，我们怎么进行一致性检测呢，机器并不能像人一样对代码有一个直观的了解，他怎么知道执行结果与预期是否一致呢。作者提出了采用差分测试的方法，即通过比较多个engine的执行结果是否一致 。
上图是?作者给出的关于测试的一个流程图及七种可能出现的情况，比较好理解，唯一有点疑问的是Consistent Parsing Result和Valid Parsing Result这两个阶段，我的理解是这并不是两个操作，只是先判断所有解析结果一不一致，若一致，在判断是否valid。
然后我们再讲一下优化，有哪些地方可以优化呢:
1.茫茫代码中你去哪里找出错的那一块呢，总不能每次对着几千行的代码分析吧。
2.有些代码有可能发现的是已经发现的bug，那么怎么去掉那些重复的bug以提高人工分辨的效率呢？
对于第一个问题，作者利用的抽象语法树(就是前面说的那个，这东西好像在JS中还比较重要，但是我没咋看懂)，通过对树中结点的删除执行来找到出错的位置，这样就得到了出错的那一部分代码。
第二个问题呢，作者构建了一个树形的知识库，记录了那些历史测试中的错误种类
?对于一个新的错误，根据JS Engines和API Function以及Error Message去在这棵树中寻找，若有相同的节点，那么我们就认为该错误之前被触发过。
3.后记
由于时间关系，后面的内容我就着重看了一下那些bug例子，一个很有意思的事情就是我不太明白用DL真的可以做出这么些代码么，就感觉很神奇，可能做出代码之后语法检查的过程就是类似我之前用的Android Studio的补全恢复那种感觉?