Progress Report 2018.09.09
阅读Xue Han， Tingting Yu在ASE18的文章：
本文工作是从bugreport中提取信息，借助软件文档信息，生成性能测试的测试样例。作者说“this is the first work that automatically generates test frames from bug reports written in natural language.”
Motivation：当前的性能测试主要是通过提高输入的规模来进行的，但是只考虑规模是不行的，软件的输入还有维度（即文题Frame）。所谓维度：例如，配置a算一个维度，配置b算第二个维度，输入参数c算第三个维度，输入命令cmd1算第四个维度……当前研究没有考虑“维度（Frame）”层面的事情（仅有一篇相似，在本文中与其进行了对比）。但是如果测试时考虑所有的维度，就会有很多的维度（配置项有很多，每个配置项都是一个维度）。那么该测哪些维度，就是本文所研究的。本文希望能够大大缩减维度，在小的维度范围内开展各种测试（如增大负载、增大参数、增大配置等），以此来暴露性能问题。
我觉得这个故事说的比较好，有拔高。他实际做的事情与前人的区别就是以前方法没考虑配置，他的方法考虑了配置。而且其实作者的工作并不是完全实现一个完整考虑配置的测试技术，而是对已有方法的加强。--“. It aims to improve the efficiency of testing by focusing on selecting commands and input parameters that are more likely to expose performance bugs.”
300个性能bug（apache、mysql、firefox各100） 89%-92%的bug都不止设计一个维度的输入（配置、参数等） 41%的性能bug和配置有关 只有23%的性能bug和负载有关（需要特定的负载）
从历史bugreport中生成test frame的方法： 从report中利用自然语言处理+信息获取方法（tfidf、nlp、pattern匹配等。为了pattern匹配，作者还总结了一些用户用自然语言表达命令的方法。），得到提交者提到的复现bug的命令、命令中的参数、配置、是否与负载有关。类似下图这种东西：
然后再进行排列组合，得到下面这种东西：
这就是test frame，注意，会生成多个test frame。生成完毕后，作者还会生成真正的test case，就是给每个维度赋值，过程中还要满足一些软件自带的各个维度之间的约束，例如配置约束等。最终得到一堆测试样例，理想情况下，这些test case里面会有真正复现当前这个bug的测试样例。
实验1：评估提取关键信息（配置、参数、命令）的准确度
数据集：来自apache、mysql、firefox的共300个真实bug（各100） 标签数据：两个学生，分别人工提取这300个bug的复现命令、参数、必要的配置。如果两人达成一致，则继续，否则反复讨论。 对比：本文用了各种nlp和信息获取方法，为评估方法有效性，与朴素的关键字匹配法进行比较 结果
光看准确率，工具的确比较高，但是这仅仅是从report中提取的命令，能不能真的复现还是未知的。从提取命令到复现中间，还有一道坎。
实验2：评估生成出来的测试样例的效果 这里作者设计的试验比较有技巧，是通过回答下面的假设来验证效果的：frame elements frequently appeared in historical bug reports can be used to generate test frame for testing future versions of the programs.
试验方法是从每个软件的100个bug中，分别选前90个（按时间顺序）。然后分别用90个bug的report进行test frame的生成，直到生成出剩下的10个report中的test frame，或超过24h时限或生成了多余1w个frames。如果最终生成了10个report对应的frame，且生成的多余的frmae数量（下图纵轴）比较少，说明有效性强。结果如下图：
PL也就是每个软件左边的部分，是作者工具，全部生成成功。CT是前人（motivation中提到的）工具，也是唯一在测试中考虑配置的工作。前人工具用的是基因算法，基本完全就是随机生成frame，全部因超限而失败。试验证明了工具的有效性。
证明有效性的同时，我认为这也是一点发现：即容易导致性能问题的输入、配置都具有局部性特征。但是其实就是配置具有局部性特征，因为作者这个工作里定义的输入的维度很小，每个软件就10个左右，例如mysql中就是（update、insert。。。）这些，真正具有局部性的是配置（几百个配置里就少数容易引发配置故障），如下图所示。这就更佳说明了我们的工作就应该针对某些配置进行。
实验3: 检验生成的测试样例是不是真的能检测bug
作者首先复现了10个bug（不在研究的300个里），然后分别用前人的方法（CT）和自己的方法进行检测。发现前人方法一个bug都检测不出来，而作者方法可以检测出7个（生成可复现的testcase）
这个试验非常简略，我感觉其实与试验2差不多，只不过试验2只是生成正确的frame，3是必须要复现。
ASE2018 这组的boss是 Xin Liu，来自University of California, Davis Davis。她本人主要是研究机器学习、神经网络算法的，发了一些ICML会议的文章，本篇是为数不多涉及软工。
本文在Lushan那篇配置自适应调整文章（Understanding and Auto-Adjusting Performance-Related Configurations）之后发表，但奇怪的是本文全文没提到lushan的工作。而且其实lushan这篇文章在2017的CoRR上发表过。而本文的工作与lushan那篇的的工作又极为相似，所以我感到比较奇怪。
本文主要工作就是固定负载下调节配置使性能最优。
motivation：前人的同类工作有以下缺陷：1.在有限时间内，采样数有限（用一组配置测试的到一个性能），用这有限的采样构建出健壮的性能模型比较困难。2.在高维空间（配置多->维度大）内搜索最小值点也是比较困难的。这两点其实就是在说：配置调优的工作，应该着眼的不是构建一个更精确的性能预测模型然后在这个模型中找使性能最好的点，而是只需要找到这个性能最好的点即可，并不需要很好的模型。
方法：本文既然提出不需要构建模型，那么其核心思想就是随机生成很多组配置（采样），然后优化这个采样过程，使得工具能够更大的概率采样到性能好的一组配置。工具一开始，会完全随机地生成很多组配置，对他们分别测固定的负载，得到每一组的性能（本文研究的一类软件用吞吐量来衡量）。然后两两对比这些组配置，得到哪些配置影响力大，哪些小。哪些正相关哪些负相关。每个配置项都有一个参数用于表示上述影响力。然后重新采样，采样时以大概率采样性能好的配置。（例如一开始知道了配置A对性能影响大，且越小越好。那么再下次采样时，就会大概率采样配置A值较小的一组配置）然后重新计算配置对性能的影响力。迭代这个过程。中间记录性能最好的一组配置。直到超时。
注意到，其实本文也构建了性能模型，但是十分简单、粗糙的线性模型（就是配置对性能影响力的参数），构建的目的是指导随机采样。
试验：本文从两个角度评估本文效果。 试验一：随机产生150组配置，100组训练，50组验证，看工具能否迭代地找到50组验证配置中的最优配置组。结果证明，当训练集和为20，30，...100时，本文方法都可以找到最优配置组，但前人方法只在6种训练集中找到最优配置。
实验二（重点）：本文找到的最优配置，比其他工作找到的最优配置更优。作者设计kafka了软件8个不同的负载，然后用前人方法和自己方法对默认配置进行调优，在有限时间内，本文方法得到的配置组性能是默认的3倍多，而前人工作只能调优到不到2倍。可以看到对已有方法的一个巨大提升。这也是本篇文章最大的贡献。
开始了hadoop家族软件的调研，结果已更新： # 调研结果 # 密码:22nk 我发现hadoop这些软件里面的配置相关的性能bug比以前那些软件相对多一些。而且我认为把一些和性能相关的常量变为配置（张元良工作）也可以算是性能问题，如果真的进行性能测试，可能也可以得到一些有特征的分布。因此我也拿了他的数据，并列入调研。