实验简介

本实验主要利用IE和Chrome的F12开发人员工具结合Web前端测试分析相关知识，对常见网站进行基于前端的性能测试分析，本实验将不会使用到测试开发相关技术，而是纯粹意义上的手工测试，但却是很容易找到系统前端性能及设计问题的很重要的测试手段。

实验目的

(1) 发现Web系统中在前端页面的设计上的不足。

(2) 发现Web系统后台服务器在处理前端交互时设计上的不足。

(3) 从前端页面的角度找到Web系统的Bug。

(4) 对Web系统提出各类可能的改进措施，帮助研发团队完善系统。

实验流程

1. WEB前端测试概述

我们知道，WEB系统主要分为客户端和服务器端。客户端的主要载体就是浏览器，相对比较简单，而服务器端则架构要复杂得多，使用到的技术也更加复杂。但是，话说回来，最终用户在使用的时候不就是一直在与浏览器打交道吗，用户才不关心我们的服务器端到底使用了怎么样的技术和架构。那么，做为一个软件测试人员，我们何不站在一个用户的角度来从WEB前端来进行系统测试与分析，辅助找出一些系统的问题，提升用户使用体验呢？

WEB前端测试分析的意义也就在此，可以以相对更小的代价，更快的速度来对系统可能存在的问题进行分析，如果真正能做好前端的分析，对用户体验和性能提升方面会有很大的正面影响。当然，最好是前端分析与后端分析相结合进行，这样才能对系统有一个全面的了解。

2. 对百度首页进行前端分析

先来对百度的首页面进行监控，看看我们通过前端测试分析技术能发现什么有趣的结果。利用IE的开发人员工具监控整个首页而加载的过程，如下图：

从上述监控结果中，我们可以得到如下的初步结论：

(1) 当输入http://www.baidu.com访问百度搜索引擎时，发送了一共15个请求，0个错误，总共传输了75.49KB的数据。

(2) 整个页面共消耗时间1.6秒，页面渲染的时间为877毫秒。此处要注意的是，这里的1.6秒只是每一个请求的响应时间的简单总和，1.82秒的加载时间才是页面的整体响应时间。由于浏览器都是多线程处理的，同时可以处理多个请求，有可能请求A消耗0.5秒，请求B消耗0.8秒，总消耗时间为1.3秒，但是真实的用户能感知到的响应时间有可能是0.9秒。

(3) 消耗时间最大的请求为下载一个JS的脚本，所花时间为1.18秒，当然，经过对时间的排序，我们也可以看到消耗时间最少的等各种情况（注：具体时间视网络状况将有所差异）。一个10KB的JS脚本，怎么会花费1.18秒这么长时间呢？这就需要进行更为具体的分析了，到底这1.18秒都花在了什么地方。后面我们再来介绍详细的分析。

(4) 所有的响应均是2xx和3xx，没有出现异常响应。

3. 对新浪首页进行前端分析

我们能够看到，新浪这个首页监控到的数据很夸张。总共捕获到了693个请求，共传输了5.02MB数据，页面整体加载时间为52.34秒，页面渲染时间为23.2秒。排名前五的请求，都消耗了很长的时间，而其文件大小都是10KB以内。毫无疑问，我们可以初步估计，这些时间要么消耗在了网络传输上，要么消耗在了服务器端处理上。如果消耗在了网络上，那么网络肯定因为产生了堵塞才会导致需要10秒钟来传输一个10KB的文件。后面我们可以继续做深入的分析。

4. 关于页面响应时间

有一个问题我们必须要理解，比如上面的新浪首页的响应时间达到了52.34秒，但是实际上我们访问新浪首页的时候并不会一直等待52秒才会看到页面，而是5秒钟内就可以看到首页了（专业术语叫做First Impression，第一印象），用户体验还不错。这是为什么呢？其实很多门户网站的首页内容是非常多的，我们从滚动条的长短就能看出来，但是页面的加载使用的是局部加载的方式（这得归结于XHTML和渲染引擎的功劳），这样可以保证用户先看到一部分内容，然后再继续加载剩余内容。所以，在进行性能测试的过程中，我们不能武断地将响应时间当成用户体验的关键指标，很多时间用户只关心第一屏内容，只要能快速看到这一部分内容，即使整体响应时间会很长，但是用户体验并不会变差。这一点是我们在进行性能测试时，对响应时间的评估容易出现误判的情况。

5. WEB前端分析之代码压缩

我们不妨来看看百首页的HTML源代码，你有什么发现？原来百度的工程师写的代码都这么烂，我们一直强调的变量命名要规范，代码要有缩进，有适当添加注释…….这些好像在这个源代码里都看不到嘛。

这是为什么呢？按理说不应该呀，百度是一家技术实力很强的公司，那么多大牛们，怎么写个代码还不会呢？这个源代码不就跟天书一样嘛，没法看。看看我们这一节的标题，你也就明白这是为什么了。

由于HTML，Javascript和CSS这些代码都是从服务器端直接下载到客户端，由浏览器来解析的，代码在服务器端不做任何处理。那么这种情况下，如果我们能将传输的代码文件变小一点，比如将空格拿掉，将换行符拿掉，将变量名从规范的currentValue这种变成一个字符a，再将所有的注释去掉，这样是不是就可以减小这个页面文件的大小。文件小了，在带宽一定的情况下，从服务器端传输到客户端也就快了。

目前这种代码压缩工具非常多，比如很多在线压缩工具，或者更强大的webpack等工具，均可以做到这一点。如果我们发现自己的系统的前端部分在这方面并没有特别考虑，那么我们可以建议公司将前端的代码（HTML，CSS，JavaScript）进行压缩，减少带宽的占用，提升传输效率。

6. WEB前端分析之传输压缩

我们知道，HTML，Javascript，CSS都是纯文本形式，也是构成网页的最核心的资源文件。纯文本形式文件的压缩比例是最高的，基本上可以做到75%的压缩比，也就是一个100K的文件被压缩后变成25K。既然是这样，那么为什么我们不将这些文本在服务器端进行压缩后再传输给客户端呢，这样不就可以再次节省带宽，加快传输速度吗？现在的Web服务器正是这么做的，并且现在的浏览器都支持解压缩，这已经成为了WEB系统的标准了。我们前面讲HTTP请求头部的字段Accept-Encoding: gzip, deflate也就是在告诉服务器当前浏览器支持解压缩。