接Web 2.0 浏览器端可靠性测试，第 1 部分: 带你走进 Web 2.0 浏览器端可靠性测试（上）
测试的方法和工具
测试方法
按照测试工具分
按照测试工具来分，测试方法分成手工测试和自动化测试两种。前面我们提到了自动化测试，然而在实际测试中，我们通常会采用手工测试与自动化测试相结合的方法。
1、手工测试
手工测试是指测试人员通过手工操作页面，同时使用监测工具来监测浏览器进程的各计数器数值的变化。在手工测试中，我们经常可以发现一些明显的可靠性问题，比如严重的内存泄漏。由于手工测试比较简单，不需要准备测试脚本，所以，对关键功能点的压力测试，我们通常先进行手工测试，在没有发现明显问题的时候再开始自动化测试。
那么怎样通过手工测试来发现问题呢？
我们在对页面进行操作的同时，使用监测工具来监测浏览器进程内存的变化。记录每次页面操作（点击或拖动）的开始和结束时刻的内存占用，重复多次，就可以得到一组数据，从而看出内存的变化趋势。需要注意的是，对于一个页面操作，我们通常会不计算第一次操作引起的内存增长，因为通常在第一次操作的时候，脚本创建一些对象，从而会导致内存的增长，这种增长属于正常现象，并不是我们常说的内存泄漏。
2、自动化测试
通过自动化测试，我们可以发现更多的问题。比如，一些细微的内存泄漏，只有在经过脚本重复几十次上百次的操作后，积累到一定的程度，才可以被发现。另外，一些响应时间等指标，也是需要操作一定的时间和数量之后才能被发现的。我们也经常能通过自动化测试发现一些更严重的可靠性问题，比如浏览器进程的意外终止。
按照测试场景和时间分
按照测试场景和时间来分，测试方法分为压力测试和长时间测试。
1、压力测试
对于一些关键功能点，我们需要将它们分离出来，进行单独的压力测试。压力测试通常是对某个相对独立的功能点进行重复的页面操作，并观察其对浏览器进程的影响。这样做的目的是为了确保那些基本的、关键的、以及使用频率较高的功能点能够得到充足的测试，从而确保达到最高的可靠性。这样做的好处也很明显，当测试过程发现问题的时候，比较容易进行调试和分析，因为被测功能单一并且相对独立，我们很容易知道是什么样的操作引起的问题。而且，由于功能点的分离，使每一个压力测试都比较短小，一般在 1 到 3 个小时就可以发现问题。
2、长时间测试
在所有的压力测试都完成并且确保没有严重的可靠性问题之后，我们就会进行长时间测试。我们在测试中要覆盖几乎所有已经通过压力测试的功能点。长时间测试一般都会持续较长的时间（比如 24 小时或是更久），所以都是通过自动化工具完成的。测试脚本执行的同时，使用监测工具监测和记录浏览器进程各计数器的变化。根据日志文件和内存增长趋势图来进行分析。
测试工具
对浏览器端进行可靠性测试，我们主要需要两种测试工具。一种是用来模拟页面操作的 GUI 自动化测试工具，一种是用来监测浏览器进程的监测工具。另外，对于测试后的分析工作，我们也需要相应的分析工具。
GUI 自动化测试工具
GUI 自动化测试工具有很多种，我们常用的工具主要是 Rational Functional Tester。
进程监测工具
对于 Windows 操作系统来说，我们通常使用两种工具来进行进程监测：
1、Task Manager，这个工具通常在手工测试中被使用，来监测浏览器进程的内存和 CPU 占用。
2、System Monitor，我们在自动化测试中使用它，通过加入指定的计数器来监测浏览器进程 的内存和 CPU 使用等信息，并保留日志在硬盘上。也可以通过这个工具直接展示各个 计数器的趋势图。
