Progress Report 2018.08.26
下面这篇文章是Hanxue看了我的想法后，想到这篇文章和我的工作是有关系的：
ISSTA'13
这篇文章主要解决了一个问题：很多性能问题是需要大负载才会暴露的，但是多大算“大”，本文给出了一种计算方式。方式是：测试人员给出一组测试输入，工具可以迅速估计出这组输入会让程序运行大约多久时间。从而，可以得知当输入规模具体多大时，可能会引发性能问题。
历史地位：传统的性能测试方法或使用黑盒测试，或使用人工构造输入样例的方法。无论哪种，都无法构造出足够大规模的测试样例。Lushan在ICSE12的研究表明，41/109的性能bug都是因为开发者对负载的估计不当导致。可见就算是人也不能很好的设计出足够大的测试样例。此外，执行程序单次并进行profile的方法可以找到在当下工作负载下耗时最多的代码在哪里，但是无法得知当负载变化时，其他的代码会不会变为耗时最多的。
本文方法：通过多次执行变化的负载（轻负载、中负载、重负载），建立一个复杂度模型：通过拟合的方法，确定每个函数再随着负载增加时，是以怎样的形式增加的（一次、二次、指数……）。实际上就是确定每个函数中循环迭代次数与负载之间的关系。再执行过程中，因为进行了profile，所以也就知道了每个函数中的循环迭代一次大概用时多少。这样一来，就可以在给定一个负载时，通过模型预测出每个函数大约会执行多久。当发现某个函数“在负载提升了10倍后，也提升了10倍”时，认为这个函数就是一个performance bottleneck。
下图为我所理解的用图来表示的本文的方法。曲线就是所建出来的模型：
上面提到的“10倍……10倍”这种oracle只是一个例子，文章没有定义什么算是oracle。只是提供了一种估计的方法。
评估：作者用这个方法测试出了notepad++，7zip这两个GUI软件的共10个性能bug。作者首先评估误报率：
图示含义为预测出来有bug的函数的真实执行时间，占总真实执行时间的百分比。横坐标是负载的大小。可以看出，当大负载下，预测出得函数消耗了绝大部分执行时间。从这点来说，误报率是低的。
然后作者评估预测的准确性：对于7zip这个软件，预测时间与真实时间相差2%-4%。对于notpad++这个软件，相差14%-36%（复杂越大，误差越大）
不足：只对两个简单的软件进行了评估，负载简单（其实是确定输入，只通过填几数值来控制workload的变化）、所研究的软件的代码很少。但是对于测试时该构造多大的负载进行了量化的估计，这种方法对于我进行性能分布测试值得借鉴。对于性能分布实验的负载究竟取多大，我目前的思路是一般商用网站数据库有多大我就构造多大，这样感觉感觉发现异常点的能力不如本文好。
上面的文章只没有考虑配置，如果考虑配置，并且换成数据库软件（更复杂），进行测试，如何找到配置（尤其是数值型）和输入同时如何取值，可以更大概率触发性能bug，是一个可以做的，而且这样的工作目前我没有看到过。