背景说明

　　手机应用越来越广，其中使用手机浏览互联网是需求量较大的一类。手机浏览器因为手机资源的限制，处理能力还达不到PC版本，因此一些大的网站会有移动互联网专门的页面。而大部分网站只提供html代码的页面。为了可以在手机上也能够方便地看到网站，提供了一个从html代码到xhtml代码转换的系统，帮助手机用户浏览互联网资源。本次测试是针对其中一个子系统进行性能优化测试。

　　测试目的

　　无线页面转换系统的抓取子系统，可以简单的描述为2个程序，一个类似于调度功能的程序（简称为sf），完成接收上游模块下发的抓取具体url任务，将该真正抓取任务下发给下游模块（简称bc），sf程序还要提取url对应html代码中的外链（比如图片、css等），发起二次抓取。bc程序主要功能是实际抓取页面，抓取任务来源由sf模块下发。上线之后，随着业务量的增加，抓取子系统不能满足线上的要求。但不能确定性能瓶颈是在sf，还是bc。这次测试目的要对比出性能瓶颈是在sf还是在bc，如果在bc，还需要定位一下具体的问题。

　　测试指标

　　性能测试指标的确定是和测试目的相关的，针对本次测试目的，是为了对比sf和bc的性能，并找出可能存在性能差的原因。

　　对比性能差，哪个指标能代表这两个程序的性能值呢？线上给人的感官是速度慢，也是抓取速度慢，代表抓取速度的指标是每秒抓取网页数量。本次关注指标是每秒抓取网页数量。为了消除页面大小对结果的干扰，测试用的页面大小取线上平均页面大小。

　　测试分析

　　定位性能差的位置：

　　页面cache：线上使用2层cache策略，但该cache使用3层会更有效。cache使用方式可能会是导致性能差原因。作为本次测试关注点。

　　配置项：长短连接、词表、线程数等，和线上保持一致。这个成为性能差的可能性很小，如果是通过一些配置项修改应该能改善。配置项不作为测试关注点。

　　处理逻辑：程序在处理抓取流程上存在问题，从而影响性能。但这个太广泛，还无法在进一步细化原因。如果问题定位在这里，则需要另行分析。网络模型的问题，也归到此类。

　　网络环境：抓取速度也依赖于网络状况，这个在线上不是程序能控制的。本次测试不作为关注点。

　　测试环境与数据

　　网络环境：为了降低网络环境对测试结果的影响，抓取的页面置于内网环境。

　　压力词表：压力url中只含有一条url。之所以考虑用1条url，是因为cache的查找使用hash方式，随着cache容量的增长，查找速度不会变长。得出的性能结果与实际结果不会发生偏差。

　　总结

　　明确测试目的。测试目的发生偏差，会使测试内容发生偏差，从而导致终测试结果不能达到要求，性能测试结果被质疑，测试目的分析不准确也是原因之一。

　　通过对内部结构的抽象，得出性能测试的基础模型，针对模型产生用例，并且直接能够定位性能问题。

　　“在测试之前可以确定测试执行次数，做性能测试中有一个经常被测试工程师提及的问题是性能测试执行的次数太多，

　　反反复复的在做，也不清楚该做多少次。通过这个分析图可以看出来，在本次测试过程中，多只做3次执行。

　　而且任何一个判断条件为yes的时候，都可以停止继续测试。”