安装 EclEmma 插件

安装 EclEmma 插件的过程和大部分 Eclipse 插件相同，我们既可以通过 Eclipse 标准的 Update 机制来远程安装 EclEmma 插件（图 1），也可以从站点下载 zip 文件并解压到 eclipse 所在的目录中。

添加 EclEmma 更新站点

不管采用何种方式来安装 EclEmma，安装完成并重新启动 Eclipse 之后，工具栏上应该出现一个新的按钮：

新增的覆盖测试按钮

到此安装就已经完成了，下面就可以使用此功能了。

使用 EclEmma 测试 Java 程序

为了实验 EclEmma 的特性，我们首先在 Eclipse 的 Workspace 中建立一个名称为 test.emma 的新 Java 项目。接下来，我们在其中建立一个 HelloWorld 类，其代码如下所示：

package test.emma;

public class HelloWorld {

/**
* @param args
*/
public static void main(String[] args) {
int rand = (int) (Math.random()*100);
if(rand%2==0){
System.out.println( "Hello, world! 0");
}
else
System.out.println("Hello, world! 1");

int result = rand%2==0? rand+rand:rand*rand;
System.out.println(result);
}
}

接下来，我们通过 EclEmma 运行 HelloWorld.main() 函数。

图 3 对 Java 应用程序进行覆盖测试

执行完毕之后，我们正在编辑 HelloWorld.java 的窗口将会变成如下所示：

图 4 进行覆盖测试的结果

在 Java 编辑器中，EclEmma 用不同的色彩标示了源代码的测试情况。其中，绿色的行表示该行代码被完整的执行，红色部分表示该行代码根本没有被执行，而黄色的行表明该行代码部分被执行。黄色的行通常出现在单行代码包含分支的情况，例如上图中的 16 行就显示为黄色。由于程序中有一个随机确定的分支，因此读者的窗口可能与这里稍有不同（11 行或者 14 行中有且只有一个红色的行）。

除了在源代码编辑窗口直接进行着色之外，EclEmma 还提供了一个单独的视图来统计程序的覆盖测试率。

图 5 察看程序的覆盖测试率

EclEmma 提供的 Coverage 视图能够分层的显示代码的覆盖测试率，上图中的信息表明我们对 HelloWorld 的一次运行覆盖了大约 68.6% 的代码。

想在一次运行中覆盖所有的代码通常比较困难，如果能把多次测试的覆盖数据综合起来进行察看，那么我们就能更方便的掌握多次测试的测试效果。EclEmma 提供了这样的功能。现在，让我们重复数次对 HelloWorld 的覆盖测试。我们注意到 Coverage 视图总是显示最新完成的一次覆盖测试。事实上，EclEmma 为我们保存了所有的测试结果。接下来，我们将通过 Coverage 视图的工具按钮来结合多次覆盖测试的结果。

图 6 用于结合多次覆盖测试结果的工具栏按钮

当我们多次运行 Coverage 之后，我们可以单击上图所示工具栏按钮。之后，一个对话框将被弹出以供用户选择需要合并的覆盖测试。

图 7 选择需要合并的覆盖测试结果

在合并完成之后，我们可以观察到 Java 编辑器和 Coverage 视图中都显示了合并之后的结果：

图 8 察看合并后的覆盖测试结果

从上图中，我们可以看到，通过多次运行覆盖测试，最终我们的代码达到了 91.4% 的测试覆盖率。有趣的是，图中第三行代码被标记为红色，而此行代码实际上是不可执行的。奥妙在于，我们没有生成任何 HelloWorld 类的实例，因此缺省构造函数没有被调用，而 EclEmma 将这个特殊代码的覆盖状态标记在类声明的第一行。

EclEmma 的高级特性

如果 EclEmma 只能测试 Java Application 的测试覆盖率，那么它相对命令行版本的 Emma 来说，提供的增强就不多了。相反，EclEmma 提供了很多与 Eclipse 紧密结合的功能。它不仅能测试 Java Application，还能计算 JUnit 单元测试，对 Eclipse 插件测试的覆盖率。从下图中我们可以看到 EclEmma 目前支持四种类型的程序。

图 9 EclEmma 的配置页面

为了了解 EclEmma 是如何获得覆盖测试数据的，我们需要先对 Emma 有初步的了解。通常代码覆盖测试工具都需要对被执行的代码进行修改。而 Emma 提供了两种方式来完成这件事。

1. 预插入模式：对程序进行测量之前，需要采用 Emma 提供的工具对 class 文件或者 jar 文件进行修改。修改完成之后的代码可以立刻被执行。覆盖测试的结果将会被存放到指定的文件中。
2. 即时插入模式：即时插入模式不需要事先对代码进行修改。相反，对代码的修改是通过一个 Emma 定制的 Class loader（类载入器）进行的。这种方式的优点很明显，我们不需要对 class 或者 jar 文件进行任何修改。缺点是我们为了获得测试的结果，需要用 Emma 提供的命令 emmarun 来执行 Java 应用程序。

使用即时插入模式的优点很明显：class 文件和 jar 文件不会被修改。而预插入模式的应用范围更为广泛，对于某些需要嵌入到框架中运行的代码来说（例如 EJB），我们只能使用预插入模式。EclEmma 仅仅使用了 Emma 的预插入模式来工作，不过 EclEmma 缺省会在临时目录中创建 class 文件和 jar 文件的副本来进行修改，因此在 workspace 中 class 和 jar 文件仍然保持原样。虽然听上去很好，但是由于需要修改 classpath 来使用修改过的 class 和 jar 文件，对于不能修改 classpath 的应用（例如 Eclipse RCP 和 JUnit Plugin Test）来说，我们还是只能选择修改 workspace 中的 class 文件和 jar 文件。对于 Java Application 和 JUnit 类型的覆盖测试，我们可以在配置对话框中选中“In-place instrumentation”项来指定直接修改 Workspace 中的 .class 文件和 .jar 文件。

结论

本文通过一个简单的例子介绍了使用 EclEmma 进行覆盖测试的基本过程。EclEmma 允许软件工程师/测试工程师方便的考察测试的覆盖率，并能将测试结果以直观、简洁的方式展现给开发人员。

1. 你如何在pocket pc 上TEST 你的程序. 你考虑了哪些方面.

2. 如果将你的程序的语言扩展到非英语,例如中文, 你如何测试.

3. 给你一个COCAN, 你如何测试(解释说就是罐装的可口可乐).

4. 当你的程序遇到BUG的时候，你选择怎样处理.

5. 你如何isolation 你程序里的BUG.

6. 给你一个产品有10个functionality,如果时间紧迫, 只能测其中的5个, 你如何选择.



其它相关：

如果别人问我这些题目，我想我会大致这样回答，各位从事软件测试的同志们帮我看看回答的怎么样。

01. 为什么要在一个团队中开展软件测试工作？

答：软件测试在整个一个团队中占有非常重要的地位，具体来说就是测试是一个发现软件错误的过程，执行软件测试会以最少的人力和时间，系统的找到软件存在的缺陷和错误，建立起开发人员和使用者对软件的信心。

02. 您是否了解以往所工作的企业的软件测试过程？如果了解，请试述在这个过程中都有哪些工作要做？分别由哪些不同的角色来完成这些工作？

答：软件测试部门配合系统分析人员软件需求分析讨论，并根据需求说明书制定《项目测试计划》，编写测试用例，建立测试环境。
软件测试人员负责软件开发部门的新产品测试及原有产品的升级测试，负责软件问题解决过程跟踪，负责软件开发文档开发工作的规范化及管理开发部门的产品文档，制作用户手册及操作手册，负责产品的上线测试，监督软件开发过程的执行，提高产品质量。

03. 您是否了解以往所工作的企业的软件开发过程？如果了解，请试述一个完整的开发过程需要完成哪些工作？分别由哪些不同的角色来完成这些工作？（对于软件测试部分，可以简述）
答： 需求人员连同系统分析人员&测试人员开会讨论需求。系统分析人员写出需求分析说明，并连同系统分析人员&测试人员&需求人员开会 讨论可行性。系统分析人员写出详细设计说明书，程式人员编码，给出系统流程图。交与测试人员，测试人员给出Bug统计表。

04. 您在以往的测试工作中都曾经具体从事过哪些工作？其中最擅长哪部分工作？
答：从事过write test plan，creation of test case，进行功能测试，性能测试，编写测试工具，文档的管理等，比较擅长与写测试用例和进行功能测试。

05. 您所熟悉的软件测试类型都有哪些？请试着分别比较这些不同的测试类型的区别与联系（如功能测试、性能测试……）
答：有功能测试，性能测试，可靠性测试，安全性测试，负载测试，压力测试，安装/卸载测试，启动/停止测试，兼容性测试，互连测试，文档测试，恢复测试，回归测试，可使用性测试，容量测试。
功能测试只对软件的功能是否满足用户需求来做测试。性能测试需要和压力和负载测试联合起来。

06. 请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系。

黑盒测试：把测试对象当成一个黑盒子，测试人员完全不考虑逻辑结构和内部特性，只依据程式的需求说明书来检查程式的功能是否满足它的功能说明。
白盒测试：把测试对象当成一个透明的盒子，允许测试人员利用程序内部逻辑结构及相关信息，设计或选择测试用例，对程式所有逻辑路径进行测试。
单元测试：白盒测试的一种，对软件设计中的单元模块进行测试。
集成测试：在单元测试的基础上，对单元模块之间的连接和组装进行测试。
系统测试：在所有都考虑的情况下，对系统进行测试。
验收测试：第三方进行的确认软件满足需求的测试。

07. 测试计划工作的目的是什么？测试计划工作的内容都包括什么？其中哪些是最重要的？
答：测试计划工作是对测试工作内容的一个有效的组织和规划，能保证测试工作有效的展开。测试计划工作包括测试目标，测试范围的定义，测试方法的选择，测试进度里程碑，测试资源的有效配置和管理。
测试计划工作也称为测试策略，主要描述测试工程的总体方法和目标，描述目前在进行那一阶段的测试（单元测试，集成测试，系统测试）以及每一阶段内进行的测试种类（功能测试，性能测试等）确定测试范围，生成测试数据等。
其中软件计划中的测试目标最重要，他的软件测试的所需要达成的最终结果。

08. 您认为做好测试计划工作的关键是什么？
答：1. 明确测试的目标，增强测试计划的实用性
2. 坚持“5W”规则，明确内容与过程，'what''why''when''where''how'
3. 采用评审和更新机制，保证测试计划满足实际需求
4. 分别创建测试计划与测试详细规格、测试用例

09. 您所熟悉的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。
答：有黑盒和白盒两种测试种类，黑盒有等价类划分法，边界分析法，因果图法和错误猜测法。白盒有逻辑覆盖法，循环测试路径选择，基本路径测试。
例子：在一次输入多个条件的完整性查询中。利用等价类划分法则和边界分析法则，首先利用等价类划分法，可以一个或多个结果是OK的测试用例，然后确认多个NG的测试用例，然后利用边界值分析法，可以对结果分别是OK和NG的测试用例进行扩展和补充。

10. 您认为做好测试用例设计工作的关键是什么？

答：测试用例设计工作的关键是对可行的和不可行的都要考虑。
1，输入 2，详细的操作步骤 3，预期输出 4，实际输出。

11. 请以您以往的实际工作为例，详细的描述一次测试用例设计的完整的过程。

12. 您以往的工作中是否曾开展过测试用例的评审工作？如果有，请描述测试用例评审的过程和评审的内容。

13. 您以往是否曾经从事过性能测试工作？如果有，请尽可能的详细描述您以往的性能测试工作的完整过程。

14. 您在从事性能测试工作时，是否使用过一些测试工具？如果有，请试述该工具的工作原理，并以一个具体的工作中的例子描述该工具是如何在实际工作中应用的。
答：有使用过LoadRunner,该工具能够录制测试人员的操作步骤，然后对这个操作步骤模拟出多个用户来播放出来。
1。Visural User Genertor创建脚本，选择协议，录制操作，编辑操作。
2。中央控制器（Controller）调度虚拟用户。创建场景，选择脚本，建立虚拟用户，设计shedual，设置ip spoofer。
3。运行脚本。分析shedual。
4。分析测试结果。

15. 您认为性能测试工作的目的是什么？做好性能测试工作的关键是什么？
答：性能测试工作的目的是检查系统是否满足在需求说明书中规定的性能，性能测试常常需要和强度测试结合起来，并常常要求同时进行软件和硬件的检测。
性能测试主要的关注对象是响应时间，吞吐量，占用内存大小（辅助存储区），处理精度等。

16. 在您以往的工作中，一条软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？
答：检测时间，系统环境，硬体环境，严重程度，程式版本，确认人，功能模块，问题描述，详细操作步骤，是否会重现。
问题描述和详细操作步骤要尽可能的详细。Bug应该尽量用书面语，对与严重程度比较高的缺陷要在相同环境下在测试一遍。

在C/S模式下，如果条件满足可以使用替换法来确认是client端的问题还是server端的问题。

书上的目录很难说明书中的内容，由于知识点很多，所以专门做了这个思维导图，来帮助大家更好的理解和回顾这本书中的知识点。

性能测试兵法

    在大多数的性能测试工作中，我们可以看出很多内容都是互相关联的。这就给我们提供了一个思路：性能测试的很多内容可以经过一定的组织统一来进行。统一开展性能测试的巨大好处是可以由浅入深按照层次对系统进行测试，进而减少不必要的工作量，以实现节约测试成本的目的。为此，本文提出了“全面性能测试模型”的概念。

　　“全面性能测试模型”提出的主要依据就是一种类型的性能测试可以在某些条件下转化成为另外一种类型的性能测试，而这些类型的测试实施也是很类似的。例如：针对一个网站进行测试，模拟10到50个用户就是在进行常规性能测试，用户增加到1000乃至上万就变成了压力/负载测试。如果同时对系统进行大量的数据查询操作，就包含了强度测试。

1 全面性能测试模型

　　在“全面性能测试模型”中，把Web性能测试分为八个类别。下面首先介绍八个性能测试类别的主要内容。

　　（1）预期指标的性能测试：系统在需求分析和设计阶段都会提出一些性能指标，这些指标是性能测试要完成的首要工作之一，本模型把预先确定的一些性能指标的测试称为预期指标的性能测试。

　　这些指标主要是指诸如“系统可以支持并发用户1000”、“系统响应时间不得高于10秒”等在产品说明书等文档中中十分明确的内容，对这种预先承诺的性能要求，测试小组应该“首当其冲”完成这类测试。

　　（2）独立业务性能测试：独立业务主要是指一些核心业务模块，这些模块通常具有功能比较复杂、使用比较频繁、属于核心业务等特点。这类特殊的、功能比较独立的业务模块始终都是性能测试重点。我们通常不但要测试这类模块的一些和性能相关的算法，还要测试这类模块对并发用户的响应情况。

　　核心业务模块在需求阶段就可以确定，在系统测试阶段开始单独测试其性能。如果是系统类软件或者特殊应用的软件，通常从单元测试阶段就开始进行测试，在后继的集成测试、系统测试、验收测试中进一步进行测试，以保证核心业务模块的性能稳定。

　　用户并发测试是核心业务模块的重点测试内容，“并发”的主要内容是模拟一定数量的用户同时使用某一核心模块的“相同”或者“不同”的功能，并且持续一段时间。对“相同”的功能进行并发测试分为两种类型，一类是在同一时刻进行完全一样的操作，例如打开同一条数据记录进行查看；另外一类是在同一时刻使用完全一样的功能，例如同时提交数据进行保存。可以看出后者是包含前前者的，后者是前者的特例，这种并发测试都要持续一定的时间。

　　从微观角度讲，同时使用某一核心模块“不同”的功能，也是一种组合业务性能测试，只不过这种组合的相关业务大分类是一致的。

　　（3）组合业务性能测试：通常不会所有的用户只使用一个或者几个核心业务模块，每个功能模块都可能被使用到，所以Web性能测试既要模拟多用户的“相同”操作(这里的“相同”指很多用户使用同一功能)，又要模拟多用户的“不同”操作(这里的“不同”指很多用户同时对一个或者多个模块的不同功能进行操作)，对多个业务进行组合性能测试。组合业务测试是最接近用户实际使用情况的测试，因而是性能测试的核心内容。我们通常按照用户的实际使用情况来模拟使用各个模板的人数比例。

　　由于组合业务测试是最反映用户使用系统情况的测试，因而组合测试往往和服务器（操作系统、Web服务器、数据库服务器）性能测试结合起来，在通过工具模拟用户行为的同时，还通过测试工具的监控功能采集服务器的计数器信息，进而全面分析系统的瓶颈，为改进系统提供有利的依据。

　　用户并发测试是组合业务测试的核心内容。“组合”并发的突出特点是分成不同的用户组进行并发，每组的用户比例要根据实际情况来进行匹配。组合业务测试可以理解为包含了“核心业务模块并发”和“非核心业务模块并发”同时进行的并发用户测试。

　　（4）疲劳强度性能测试：疲劳强度测试是在系统稳定运行下模拟较大的用户数量、并长时间运行系统的测试，通过综合分析执行指标和资源监控来确定系统处理最大业务量时的性能，主要目的是为了测试系统的稳定性。

　　（5）大数据量性能测试：大数据量测试分为两种：一种是针对某些系统存储、传输、统计查询等业务进行大数据量的测试,主要是测试数据增多时的性能情况，这类一般都是针对某些特殊的核心业务或者一些日常比较常用的组合业务的测试。

　　第二种是极限状态下的数据测试，主要是指系统数据量达到一定程度时，通过性能测试来评估系统的响应情况，测试的对象也是某些核心业务或者日常常用的组合业务。例如系统的数据每年只备份转移一次，可分别选择一个季度、半年、一年作为参考，模拟输入各个时间段的预计数据量，然后测试系统的性能，进而预估系统的性能走向。

　　由于大数据量仍然是为了测试系统的业务处理能力，因此大数据量性能测试可以独立进行，也可以和前面的独立、组合业务测试结合起来进行，主要由性能测试策略来决定。由于大数据量测试一般在投产环境进行，因此把它单独独立出来，和疲劳强度测试放在一起，在整个性能测试的后期进行。大数据量测试可以理解为特定条件下的核心业务或者组合业务测试。

　　（6）网络性能测试：网络性能测试主要是为了准确展示带宽、延迟、负载和端口的变化是如何影响用户的响应时间的。在实际的软件项目中，主要是测试应用系统的用户数目与网络带宽的关系。

　　（7）服务器性能测试（操作系统、Web服务器、数据库服务器）：服务器性能测试分为初级和高级两种形式。“初级服务器性能测试”主要是指在业务系统工作或者进行前面其它种类性能测试的时候，监控服务器的一些计数器信息，通过这些数据对服务器进行综合性能分析，找出系统瓶颈，为调优或者提高性能提供依据。“高级服务器性能测试”一般不由测试人员进行，由专门的系统管理员来进行，例如数据库服务器由专门的DBA来进行测试和调优。本文主要讨论在测试中常用到的“初级服务器性能测试”，既通过工具对服务器资源进行监控的性能测试。

　　（8）一些特殊测试：主要是指配置测试、内存泄漏测试一些特殊的Web性能测试。这类性能测试或者和前面的测试结合起来进行，或者在一些特殊情况下会独立进行，本文重点来讨论前一种情况，因为后一种情况往往通过特有的工具、较大投入的进行，可以不作为性能测试的范畴来研究。

2性能测试通用策略

2.1性能测试策略通用方法

　　本节主要介绍一下通用的性能测试策略制定方法。性能测试策略一般从需求设计阶段开始讨论制定，策略的内容决定着性能测试工作投入多少资源、什么时间开始实施等后继工作如何安排。其制定的主要依据是“软件自身特点”和“用户对性能的关注程度”两个因素，其中软件的自身特点起决定作用。

　　软件按照用途的不同分为两大类：系统类软件和应用类软件。系统类软件对性能一般要求比较高，因此性能测试应该尽早介入。应用类软件分为特殊类应用和一般类应用，特殊类应用主要指银行、电信、电力、保险、医疗、安全等领域类的软件，这类软件使用比较频繁，用户较多，一般也要较早进行性能测试；一般类应用主要指一些普通应用，例如办公自动化软件、MIS系统等，一般应用类软件多根据实际情况决定性能测试策略，比如OA系统，可以早开始、也可以最后进行性能测试，这类软件受用户因素影响比较大。

　　用户一般可以分为四类：即对性能特别关注、中等重视、一般关注、不怎么关注四类。这里这么划分并不意味着用户不关注性能测试人员就可以忽略性能测试。不过，用户如果特别关注性能，测试人员也应该特别重视性能测试。表1列出了性能测试策略制定的基本原则。（注意：这里的用户是广义范围的用户，包括所有和我们的产品有利害关系的群体。因而不单单指最终使用产品的用户，这些用户既可以是为我们提出需求的产品部，也可以是公司的董事会，甚至是我们研发人员自己。）

　　软件的特点决定性能测试策略另外一个重要原因就是“一般应用类软件”通常耗费资源较少，因此可以通过提高硬件配置，进而改善运行环境来提高“一般应用类软件”的性能。从硬件方面解决性能问题往往更容易做到，同时可以降低我们的开发成本，不过也不能过分让用户进行较大的硬件投入，否则会降低我们的“客户满意度”。我们调整性能最好的办法还是软硬件相结合。

　　用户对待系统性能的态度影响性能测试策略，但不起决定作用的根本原因是我们最终要把产品交付给用户来使用，而不是做出来给用户欣赏。因此不管用户是否重视性能测试，即使根本不关心，对于性能要求高的软件产品我们都应该按照测试上面的策略进行合理的安排。同时，如果我们的上帝——用户如果特别重视，这意味着我们需要进行更多的性能测试方面的投入，因为我们有义务使我们的用户满意。

3 Web性能测试模型使用方法

　　“全面性能测试模型”是针对Web性能测试而提出的一种方法，主要目的是为了比较全面的开展性能测试，使Web性能测试更容易组织和开展。本模型包含了测试策略制定的通用方法和测试用例设计通用方案，测试用例的设计覆盖了应用软件、服务器、操作系统多方面的内容，按照由浅入深的顺利对性能测试进行了合理的组织。

　　“全面性能测试模型”是一种经很多性能测试项目抽象出来的方法论，主要用来指导测试，它一般不适合具体的性能测试项目，因为任何一个项目都会有它的特定背景。要想通过“Web全面性能测试模型”做好性能测试工作，首先要制定好性能测试策略，同时还要按照一些基本指导原则来使用“Web性能测试用例设计模型”的内容。这些原则主要包括如下的内容：

　　测试策略遵从最低成本原则。Web性能测试本身是一种高投入的测试，而实际中国内公司通常在测试上进行较低的投入，Web性能测试只是全部测试工作的一部分，很多项目只能进行一些重要的性能内容，这就决定测试经理制定性能测试策略时在资源投入方面一定要遵从最低成本化原则。最低成本的衡量标准主要指“投入的测试成本能否使系统满足预先确定的性能测试目标”，只要我们经过反复的“测试——系统调优——测试”后，系统符合性能需求并有一定的扩展空间，就可以认为性能测试工作是成功的。反之，如果系统经过测试后不满足性能需求或者满足性能需求后仍然投入资源，都可以认为是不合理的。

　　策略为中心原则。本原则不但对性能测试工作有效，对其他类型的测试工作都具有同样的指导意义。测试策略不但决定了我们测试用例设计时的主要内容，还决定着我们实施测试工作时如何根据项目的实际情况进行处理，例如：如果项目时间比较紧张，我们完全可以按照测试用例的优先级只执行一部分性能测试用例。因此，性能测试策略应该贯穿整个性能测试过程。

　　适当裁剪原则。裁剪原则主要是针对性能用例设计而言。Web性能测试用例设计模型主要是针对电信、银行级的应用而提出的，包含的测试内容比较全面，而这类项目的性能测试一般周期较长、投入较大，作者曾亲身经历过测试周期为一年的银行项目。要想性能测试用例设计模型在大多数测试项目中使用，必须对测试用例模型包含的内容进行合理的裁剪，这样做的主要目的是为了适合特定项目的测试需求，进而节约测试成本。

　　裁减的主要依据是性能测试策略，我们根据策略制定方法制定出测试策略，然后依据策略从“五类性能测试用例”中选择适当的内容来编写测试用例。例如有些要求不高的静态门户网站，用户也没有提出性能方面的要求，我们完全可以只测试一下用户并发情况作为系统性能的参考。

　　完善模型原则。本模型只是作者的工作经验总结，由于不同的性能测试任务都有自己的项目背景，因而需要对模型内容进行不断的调整、补充、完善，才能使之适合更多的性能测试工作。不断完善具体来说就是要在工作中不断总结自己的经验，形成自己的“Web全面性能测试模型”。只有“自己的”测试模型，才是最符合自己需要的模型。

　　模型具体化原则。模型具体化主要是指把本模型运用到具体的项目中，是前面所有原则的目标。如果只记住模型的这些条条框框，然后生搬硬套框架来设计测试，只能得到适得其反的结果。要想使模型在Web性能工作中发挥作用，只有根据实际项目的特点制定合理的性能测试策略、编写适当的性能测试用例，并在测试实施中灵活的执行测试方案。

　　综合上面的分析，可以看出模型使用完全可以概括成两个字——“活用”。要想真正做好性能测试工作，最有效的办法就是在掌握基本理论和方法后，在工作中不断的去探索和总结，不断的完善该模型，形成自己的“Web全面性能测试模型”。

　　“全面性能测试模型”是一种很有效的做Web性能测试的“兵法”，这正是本篇命名为“兵法篇”的目的。“兵法”是“将帅”们“打仗”的必备知识，学会了兵法才可以指挥战争，但是兵法毕竟不能代替具体的“战术”，它只是“打胜仗”的前提条件，具体的“仗”怎么去“打”，仍然要根据具体的战场情况来指挥。因此，具体的Web性能测试工作仍然按照项目的自身特点去组织和实施。

一、利用excel生成批处理脚本

excel数据生成sql插入数据库语句
excel表格有A、B、C三列数据，希望导入到数据库users表中，对应的字段分别是name,sex,age

在你的excel表格中增加一列，利用excel的公式自动生成sql语句，方法如下：

1、增加一列（D列）

2、在第一行的D列，就是D1中输入公式： =CONCATENATE("insert into users (name,sex,age) values ('",A1,"','",B1,"','",C1,"');")

3、此时D1已经生成了如下的sql语句： insert into users (name,sex,age) values ('ls','女','24');

4、将D1的公式复制到所有行的D列（就是用鼠标点住D1单元格的右下角一直拖拽下去啦）

5、此时D列已经生成了所有的sql语句

6、把D列复制到一个纯文本文件中。

二、在PL/SQL中编写存储过程

 

declare  
  i   number:=1;  
  begin  
  for   i   in   1..1000000   loop  
  insert   into   table_name   values(i       ,     a   ,             b   );  
  if   mod(i,500)=0   then  
  commit;  
  end   if;  
  end   if; 

（以下是已经调试通过的存储过程）

DECLARE
    i  int;
BEGIN
 --循环游标
 --for   i   in   1..10  loop  
  insert  into  xtgl_jd (select i,i,JD_MC,JD_JC,JDJC_BM,SJJD_BM,XZQY_BM,YB,DZ,GDDH,CZ,LXR,YX_BZ from xtgl_jd jd where jd.jd_bm='000000001');
  --END loop;
EXCEPTION
    WHEN OTHERS THEN
        DBMS_OUTPUT.PUT_LINE('Exception occurs during registering and starting job...');

三、利用PL/SQL插入数据 

用存储过程实现向下表中 插入数据，其中id 是主键。
NSERT INTO  WATAB (id
,NAME
,YEAR
,MEMO
VALUE(
object_id,
'XZW',
'XZW',
'XZW'
)

insert into watab(id,name,year,memo)
select rownum,'xzw','xzw',xzw'
from dual
connect by rownum<=10000;

软件测试是指使用人工或者自动的手段来运行或测定某个软件产品系统的过程，其目的是在于检验是否满足规定的需求或者弄清预期的结果与实际结果的区别。本文主要描述软件测试的类型。

1 数据和数据库完整性测试

数据与数据库完整测试是指测试关系型数据库完整性原则以及数据合理性测试。

数据库完整性原即：

主码完整性：主码不能为空；

外码完整性：外码必须等于对应的主码或者为空。

数据合理性指数据在数据库中的类型，长度，索引等是否建的比较合理。

在项目名称中，数据库和数据库进程应作为一个子系统来进行测试。在测试这些子系统时，不应将测试对象的用户界面用作数据的接口。对于数据库管理系统 (DBMS)，还需要进行深入的研究，以确定可以支1持测试的工具和技术。

比如，有两张表：部门和员工。部门中有部门编号，部门名称，部门经理等字段，主码为部门编号；员工表中有员工编号，员工所属部门编号，员工名称，员工类型等字段，主码为员工编号，外码为员工所属部门编号，对应部门表。如果在某条部门记录中部门编号或员工记录员工编号为空，他就违反主码完整性原则。如果某个员工所属部门的编号为##，但是##在部门编号中确找不到，这就违反外码完整性原则。

员工类型如下定义：0：职工，1：职员，2：实习生。但数据类型为Int，我们都知道Int占有4个字节，如果定义成char(1).就比原来节约空间。

2 白盒测试

白盒测试是基于代码的测试，测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件的质量，一般黑盒测试由项目经理在程序员开发中来实现。白盒测试分为动态白盒测试和静态白盒测试

2.1 静态白盒测试

利用眼睛，浏览代码，凭借经验，找出代码中的错误或者代码中不符合书写规范的地方。比如，代码规范中规定，函数必须为动宾结构。而黑盒测试发现一个函数定义如下：

Function NameGet(){

….

}

这是属于不符合开发规范的错误。

有这样一段代码:

if (i<0) & (i>=0)

…

这段代码交集为整个数轴，IF语句没有必要

I=0;

while(I>100){

J=J+100;

T=J*PI;

}

在循环体内没有I的增加,bug产生。

2.2 动态白盒测试

利用开发工具中的调式工具进行测试。比如一段代码有4个分支，输入4组不同的测试数据使4组分支都可以走通而且结果必须正确。

看一段代码

if(I<0){

P1

}else{

P2

}

在调试中输入I=-1,P1程序段通过， P2程序段未通过，属于动态黑盒测试的缺陷

3.功能测试

功能测试指测试软件各个功能模块是否正确，逻辑是否正确。

对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确，以及业务规则的实施是否恰当。此类测试基于黑盒技术，该技术通过图形用户界面 (GUI) 与应用程序进行交互，并对交互的输出或结果进行分析，以此来核实应用程序及其内部进程。功能测试的主要参考为类似于功能说明书之类的文档。

比如一个对电子商务系统，前台用户浏览商品-放入购物车-进入结账台，后台处理订单，配货，付款，发货，这一系列流程必须正确无误的走通，不能存在任何的错误。

4.UI测试

UI测试指测试用户界面的风格是否满足客户要求，文字是否正确，页面美工是否好看，文字，图片组合是否完美，背景是否美观，操作是否友好等等

用户界面 (UI) 测试用于核实用户与软件之间的交互。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外，UI 测试还可确保 UI 中的对象按照预期的方式运行，并符合公司或行业的标准。包括用户友好性，人性化，易操作性测试。UI测试比较主观，与测试人员的喜好有关

比如：页面基调颜色刺眼；用户登入页面比较难于找到，文字中出现错别字，页面图片范围太广等都属于UI测试中的缺陷，但是这些缺陷都不太严重。

5.性能测试

性能测试主要测试软件测试的性能，包括负载测试，强度测试，数据库容量测试，基准测试以及基准测试

5.1负载测试

负载测试是一种性能测试指数据在超负荷环境中运行，程序是否能够承担。

在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。

比如，在B/S结构中用户并发量测试就是属于负载测试的用户，可以使用webload工具，模拟上百人客户同时访问网站，看系统响应时间，处理速度如何？

5.2强度测试

强度测试是一种性能测试，他在系统资源特别低的情况下软件系统运行情况。这类测试往往可以书写系统要求的软硬件水平要求。

实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足，测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源（如数据库锁或网络带宽）而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。

比如：一个系统在内存366M下可以正常运行，但是降低到258M下不可以运行，告诉内存不足，这个系统对内存的要求就是366M。

5.3数据库容量测试

数据库容量测试指通过存储过程往数据库表中插入一定数量的数据，看看相关页面是否能够及时显示数据。

数据库容量测试使测试对象处理大量的数据，以确定是否达到了将使软件发生故障的极限。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。例如，如果测试对象正在为生成一份报表而处理一组数据库记录，那么容量测试就会使用一个大型的测试数据库，检验该软件是否正常运行并生成了正确的报表。做这种测试通常通过书写存储过程向数据库某个表中插入一定数量的记录，计算相关页面的调用时间。

比如，在电子商务系统中，通过insert customer 往user表中插入10 000数据，看其是否可以正常显示顾客信息列表页面，如果要求达到最多可以处理100 000个客户，但是顾客信息列表页面不能够在规定的时间内显示出来，就需要调整程序中的SQL查询语句；如果在规定的时间内显示出来，可以将用户数分别提高到20 000 , 50 000, 100 000进行测试。

5.4基准测试

基准测试与已知现有的系统进行比较，主要检验是否与类似的产品具有竞争性的一种测试。

如果你要开发一套财务系统软件并且你已经获得用友财务系统的性能等数据，你可以测试你这套系统，看看哪些地方比用友财务系统好，哪些地方差？以便改进自己的系统，也可为产品广告提供数据。

5.5竞争测试

软件竞争使用各种资源（数据纪录，内存等），看他与其他相关系统对资源的争夺能力。比如：一台机器上即安装您的财务系统，又安装用友财务系统。当CPU占有率下降后，看看是否能够强过用友财务系统，而是自己的系统能够正常运行？

6. 安全性和访问控制测试

安全性和访问控制测试侧重于安全性的两个关键方面：

应用程序级别的安全性，包括对数据或业务功能的访问

系统级别的安全性，包括对系统的登录或远程访问。

6.1应用程序级别的安全性

可确保：在预期的安全性情况下，主角只能访问特定的功能或用例，或者只能访问有限的数据。例如，可能会允许所有人输入数据，创建新账户，但只有管理员才能删除这些数据或账户。如果具有数据级别的安全性，测试就可确保“用户类型一”能够看到所有客户消息（包括财务数据），而“用户二”只能看见同一客户的统计数据。

比如B/S系统，不通过登入页面，直接输入URL,看其是否能够进入系统？

6.2系统级别的安全性

可确保只有具备系统访问权限的用户才能访问应用程序，而且只能通过相应的网关来访问。

比如输入管理员账户，检查其密码是否容易猜取，或者可以从数据库中获得？

7.故障转移和恢复测试

故障转移和恢复测试指当主机软硬件发生灾难时候，备份机器是否能够正常启动，使系统是否可以正常运行，这对于电信，银行等领域的软件是十分重要的。

故障转移和恢复测试可确保测试对象能成功完成故障转移，并能从导致意外数据损失或数据完整性破坏的各种硬件、软件或网络故障中恢复。

故障转移测试可确保：对于必须持续运行的系统，一旦发生故障，备用系统就将不失时机地“顶替”发生故障的系统，以避免丢失任何数据或事务。

恢复测试是一种对抗性的测试过程。在这种测试中，将把应用程序或系统置于极端的条件下（或者是模拟的极端条件下），以产生故障（例如设备输入/输出 (I/O) 故障或无效的数据库指针和关健字）。然后调用恢复进程并监测和检查应用程序和系统，核实应用程序或系统和数据已得到了正确的恢复。一定要注意主备定时备份

比如电信系统，突然主机程序发生死机，备份机器是否能够启动，使系统能够正常运行，从而不影响用户打电话？

8.配置测试

又叫兼容性测试。配置测试核实测试对象在不同的软件和硬件配置中的运行情况。在大多数生产环境中，客户机工作站、网络连接和数据库服务器的具体硬件规格会有所不同。客户机工作站可能会安装不同的软件例如，应用程序、驱动程序等而且在任何时候，都可能运行许多不同的软件组合，从而占用不同的资源。（如浏览器版本，操作系统版本等）

下面列出主要配置测试

8.1浏览器兼容性

测试软件在不同产商的浏览器下是否能够正确显示与运行；

比如测试IE，Natscape浏览器下是否可以运行这套软件？

8.2操作系统兼容性

测试软件在不同操作系统下是否能够正确显示与运行；

比如测试WINDOWS98,WINDOWS 2000,WINDOWS XP,LINU, UNIX下是否可以运行这套软件？

8.3硬件兼容性

测试与硬件密切相关的软件产品与其他硬件产品的兼容性，比如该软件是少在并口设备中的，测试同时使用其他并口设备，系统是否可以正确使用.

比如在INTER,舒龙CPU芯片下系统是否能够正常运行？

这样的测试必须建立测试实验室，在各种环境下进行测试。

9.安装测试

安装测试有两个目的。第一个目的是确保该软件在正常情况和异常情况的不同条件下: 例如，进行首次安装、升级、完整的或自定义的安装_都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。第二个目的是核实软件在安装后可立即正常运行。这通常是指运行大量为功能测试制定的测试。

安装测试包括测试安装代码以及安装手册。安装手册提供如何进行安装，安装代码提供安装一些程序能够运行的基础数据。

10.多语种测试

又称本地化测试，是指为各个地方开发产品的测试，如英文版，中文版等等，包括程序是否能够正常运行，界面是否符合当地习俗，快捷键是否正常起作用等等，特别测试在A语言环境下运行B语言软件（比如在英文win98下试图运行中文版的程序），出现现象是否正常。

本地化测试还要考虑：

l 当语言从A翻译到B，字符长度变化是否影响页面效果。比如中文软件中有个按键叫“看广告”，翻译到英文版本中为 “View advertisement”可能影响页面的美观程度

l 要考虑同一单词在各个国家的不同意思，比如football在英文中为足球，而美国人使用中可能理解为美式橄榄球。

l 要考虑各个国家的民族习惯，比如龙个美国中被理解邪恶的象征，但翻译到中国，中国人认为为吉祥的象征。

11.文字测试

文字测试测试软件中是否拼写正确，是否易懂，不存在二义性，没有语法错误；文字与内容是否有出入等等，包括图片文字。

比如：“比如，请输入正确的证件号码！”何谓正确的证件号码，证件可以为身份证，驾驶证，也可为军官证，如果改为“请输入正确的身份证号码！”用户就比较容易理解了。

12.分辨率测试

测试在不同分辨率下，界面的美观程度,分为800*600，1024*768，1152*864，1280*768，1280*1024，1200*1600大小字体下测试。一个好的软件要有一个极佳的分辨率，而在其他分辨率下也都能可以运行。

13发布测试

主要在产品发布前对一些附带产品，比如说明书，广告稿等进行测试

13.1说明书测试

主要为语言检查，功能检查，图片检查

语言检查：检查说明书语言是否正确，用词是否易于理解；

功能检查：功能是否描述完全，或者描述了并没有的功能等；

图片检查:：检查图片是否正确

13.2宣传材料测试

主要测试产品中的附带的宣传材料中的语言，描述功能，图片

13.3帮助文件测试

帮助文件是否正确，易懂，是否人性化。最好能够提供检索功能。

13.4广告用语

产品出公司前的广告材料文字，功能，图片，人性化的检查

14 文档审核测试

文档审核测试目前越来越引起人们的重视，软件质量不是检查出来的，而是融进软件开发中来。前置软件测试发越来越受到重视。请看一个资料：

文档审核测试主要包括需求文档测试，设计文档测试，为前置软件测试测试中的一部分。

14.1需求文档测试

主要测试需求中是否存在逻辑矛盾以及需求在技术上是否可以实现；

14.2设计文档测试

测试设计是否符合全部需求以及设计是否合理。

总结

据美国软件质量安全中心2000年对美国一百家知名的软件厂商统计，得出这样一个结论：软件缺陷在开发前期发现比在开发后期发现资金，人力上节约90%；软件缺陷在推向市场前发现比在推出后发现资金，人力上节约90%。所以说软件的缺陷应该尽早发现。不是所有的软件都要进行任何类型的软件测试的，可以根据产品的具体情况进行组装测试不同的类型。

软件测试从不同的角度出发会派生出两种不同的测试原则，从用户的角度出发，就是希望通过软件测试能充分暴露软件中存在的问题和缺陷，从而考虑是否可以接受该产品，从开发者的角度出发，就是希望测试能表明软件产品不存在错误，已经正确地实现了用户的需求，确立人们对软件质量的信心。

　　中国软件评测中心的测试原则就是从用户和开发者的角度出发进行软件产品测试的，通过我们的测试，可以为用户提供放心的产品，并对优秀的产品进行认证。

　　为了达到上述的原则，那么需要注意以下几点：

　　1．应当把“尽早和不断的测试”作为开发者的座右铭

　　2．程序员应该避免检查自己的程序，测试工作应该由独立的专业的软件测试机构来完成。

　　3．设计测试用例时应该考虑到合法的输入和不合法的输入以及各种边界条件，特殊情况下要制造极端状态和意外状态，比如网络异常中断、电源断电等情况。

　　4．一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系。

　　5．对测试错误结果一定要有一个确认的过程，一般有A测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析。

　　6．制定严格的测试计划，并把测试时间安排的尽量宽松，不要希望在极短的时间内完成一个高水平的测试。

　　7．回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多的错误出现的现象并不少见。

　　8．妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档。

                                          来源:中国软件评测中心

WEB性能测试用例设计 

性能测试用例主要分为预期目标用户测试，用户并发测试，疲劳强度与大数据量测试，网络性能测试，服务器性能测试五大部分，具体编写测试用例时要根据实际情况进行裁减，在项目应用中遵守低成本，策略为中心，裁减，完善模型，具体化等原则；

一、WEB 全面性能测试模型
 Web 性能测试模型提出的主要依据是：一种类型的性能测试可以在某些条件下转化成为另外一种类型的性能测试，这些类型的性能测试的实施是有着相似之处的；

1.       预期指标的性能测试：
系统在需求分析和设计阶段都会提出一些性能指标，完成这些指标的相关的测试是性能测试的首要工作之一，这些指标主要诸于“系统可以支持并发用户200个；”系统响应时间不得超过20秒等，对这种预先承诺的性能要求，需要首先进行测试验证； 

2.       独立业务性能测试；
     独立业务实际是指一些核心业务模块对应的业务，这些模块通常具有功能比较复杂，使用比较频繁，属于核心业务等特点。

用户并发测试是核心业务模块的重点测试内容，并发的主要内容是指模拟一定数量的用户同时使用某一核心的相同或者不同的功能，并且持续一段时间。对相同的功能进行并发测试分为两种类型，一类是在同一时刻进行完全一样的操作。另外一类是在同一时刻使用完全一样的功能。

3.       组合业务性能测试；
通常不会所有的用户只使用一个或者几个核心业务模块，一个应用系统的每个功能模块都可能被使用到；所以WEB性能测试既要模拟多用户的相同操作，又要模拟多用户的不同操作；组合业务性能测试是最接近用户实际使用情况的测试，也是性能测试的核心内容。通常按照用户的实际使用人数比例来模拟各个模版的组合并发情况；组合性能测试是最能反映用户使用情况的测试往往和服务器性能测试结合起来，在通过工具模拟用户操作的同时，还通过测试工具的监控功能采集服务器的计数器信息进而全面分析系统瓶颈。

用户并发测试是组合业务性能测试的核心内容。组合并发的突出特点是根据用户使用系统的情况分成不同的用户组进行并发，每组的用户比例要根据实际情况来匹配；

4.       疲劳强度性能测试；
疲劳强度测试是指在系统稳定运行的情况下，以一定的负载压力来长时间运行系统的测试，其主要目的是确定系统长时间处理较大业务量时的性能，通过疲劳强度测试基本可以判定系统运行一段时间后是否稳定；

5.       大数据量性能测试；
一种是针对某些系统存储，传输，统计查询等业务进行大数据量时的性能测试，主要针对某些特殊的核心业务或者日常比较常用的组合业务的测试；

第二种是极限状态下的数据测试，主要是指系统数据量达到一定程度时，通过性能测试来评估系统的响应情况，测试的对象也是某些核心业务或者常用的组合业务。

第三种大数据量测试结合了前面两种的测试，两种测试同时运行产生较大数据量的系统性能测试；

大数据量测试通常在投产环境下进行，并独立出来和疲劳强度测试放在一起，在整个性能测试的后期进行；大数据量的测试可以理解为特定条件下的核心业务或者组合业务测试；

6.       网络性能测试；
     主要是为了准确展示带宽，延迟，负载和端口的变化是如何影响用户的响应时间的，在实际的软件项目中

主要是测试应用系统的用户数目与网络带宽的关系。网络测试的任务通常由系统集成人员完成；

7.       服务器（操作系统，WEB服务器，数据库服务器）性能测试；
初级服务器性能测试主要是指在业务系统工作或者进行前面其他种类性能测试的时候，监控服务器的一些计数器信息，通过这些计数器对服务器进行综合性能分析，为调优或提高系统性能提供依据；

高级服务器性能测试一般由专门的系统管理员来进行如数据库服务器由专门的DBA来进行测试和调优；

8.       一些特殊的测试；
  主要是指配置测试，内存泄露测试的一些特殊的WEB性能测试；

二、WEB 性能测试策略
性能测试策略一般从需求设计阶段开始讨论如何定制，它决定着性能测试工作要投入多少资源，什么时间开始实施等后续工作的安排；其制定的主要依据是软件自身的特点和用户对性能的关注程度，其中软件自身的特点起决定性的作用；

软件按照用途的不同可以分为两大类，系统类软件和应用类软件。系统类软件通常对性能要求较高，因此性能测试应该尽早介入；应用类软件分为特殊类应用和一般类应用，特殊类应用主要有银行，电信，电力，保险，医疗，安全等领域软件，这类软件使用频繁，用户较多，也需要较早进行性能测试；一般类主要是指一些普通类应用如OA，MIS 等一般类软件根据实际情况制定性能测试策略，受用户因素影响较大；

1.       系统类软件；
 从设计阶段就开始针对系统架构，数据库设计等方面进行讨论，从根源来提高性能，系统类软件一般从单元测试阶段开始性能测试实施工作，主要是测试一些和性能相关的算法和模块；

2.       应用类软件；
特殊应用：从设计阶段就开始针对系统架构，数据库设计等方面进行讨论，从根源来提高性能，系统类软件一般从单元测试阶段开始性能测试实施工作，主要是测试一些和性能相关的算法和模块；

一般应用：与使用用户的重视程度有关，用户高度重视时 ，设计阶段开始进行一些讨论工作，主要在系统测试阶段开始进行性能测试实施；用户一般重视时，可以在系统测试阶段的功能测试结束后进行性能测试；用户不怎么重视时，可以在软件发布前进行性能测试，提交测试报告即可；

三、WEB性能测试用例设计模型
性能测试用例设计通常不会一次设计到位，是一个不断迭代完善的过程，即使在使用过程中，也不是完全按照设计好的测试用例来执行，需要根据需求的变化进行调整和修改； WEB性能测试用例设计模型是一个内容全面比较容易组织和调整的模型架构。

3.       预期性能指标测试用例；
指一些十分明确的，在系统需求设计阶段预先提出的，期望系统达到的，或者向用户保证的性能指标，针对每个指标都要编写一个或者多个测试用例来验证系统是否达到要求，预期性能指标测试用例主要参考需求和设计文档，把里面十分明确的性能要求提取出来，指标中通常以单用户为主；

如：对于普通的客户端，系统上传5MB以内的文件，速度不低于2MB/S；

输入动作：选择1-5 MB的文件并上传，用秒表计时；

期望的性能：上传的时间小于等于2.5S

实际性能: 上传的时间2.29秒;

这类用例通常以手工的方式执行;

4.       用户并发性能测试用例；
     用户并发测试主要通过逐渐增加用户数量来加重系统负担,并通过测试工具对应用系统,各种服务器资源进

监控,用户并发测试可以是正常数量用户和特殊数量用户进行并发, 用户并发测试是系统性能测试的核心部分,涉及压力测试,负载测试,强度测试等多方面的内容.独立业务性能测试实际就是核心业务模块的某一业务的并发性能测试,可以理解为单元性能测试;组合业务的性能测试是一个或者多个模块的多个业务同时进行并发性能测试,可以理解为集成性能测试,单元性能测试和集成性能测试两者紧密相连合并称为用户并发性能测试;用户并发测试要求选择有代表性的关键的业务来设计测试用例,以便更有效的评测系统性能;其测试用例设计文档的基本的编写思想是按照系统的体系结构进行编写.

1.       独立核心模块用户并发性能的测试用例设计

 完全一样功能的并发测试:主要检查系统的健壮性,从技术角度讲就是检查程序对同一时刻并发操作的处理.

 完全一样操作的并发测试:基本要求是在同一时刻进行完全一样的操作,这类测试的目的是验证核心模块在

大量用户使用同一功能时是否正常工作;

相同/不同功能的子功能并发:每个不同的子功能都模拟一定的用户数量,通过工具来控制并发情况;

如发送与接收邮件模块的一个测试用例,

功能:当在线用户达到高峰时,发送和接收普通邮件正常,保证2000个以内用户可以同时访问邮件系统,能够正常发送和接收邮件;

目的:测试系统2000个以内的用户同时在线时能否正常发送邮件;

方法:采用LOADRUNNER的录制工具录制一个邮件发送过程测试,要监视数据库服务器和WEB服务器的性能,其中发送的邮件为普通邮件,附件大小不超过1MB.

并发用户数与事务执行情况:并发用户数,事务平均响应时间,事务最大响应时间,平均每秒处理事务数,事务成功率,每秒点击率,平均流量;

并发用户数与数据库主机:并发用户数,CPU利用率,MEM利用率,磁盘I/O参数,DB参数;

并发用户数与应用服务器的关系表:并发用户数,CPU利用率,MEM利用率,磁盘I/O参数;

2.       组合模块用户并发性能测试的用例设计

组合模块的性能测试是最能反映用户实际使用情况的测试，它把前面系统中具有耦合关系的模块组合起来进行测试，可以理解为集成性能测试，组合模块并发测试可以真实反映用户使用系统的情况，可以从需求，设计文档；现场调查，系统采集数据获取用户场景；

具有耦合关系的核心模块进行组合并发测试：主要测试在多用户并发条件下，一些存在耦合关系或者数据接口的模块是否正常运行；

彼此独立的，内部具有耦合关系的核心模块组的并发测试：这类测试的对象是多个模块组，每个组相关的模块具有一定的耦合关系，组与组之间关系相互独立，主要站在用户的角度考虑问题；

基于用户场景的并发测试：选择用户的一些典型场景进行测试，测试对象不限制于核心模块或非核心模块；

组合模块用户并发性能测试的前两种类型仍然是针对核心模块的同时也关注用户场景，这样做的原因是大多数的性能问题都是由用户经常使用的核心模块一起的；可以看出，组合模块的用户并发性能测试既关注功能测试，也关注性能测试，通过发现一些接口和综合性能方面的问题，使系统更加稳定的运行。

如下某OA系统组合模块的一个测试用例：

功能：在线用户数达到高峰时，用户可以正常使用系统，目标是满足500个以内用户同时在线使用系统；

目的：测试500个以内用户同时在线时能否使用比较常见的模块：公文系统，电子公告，网上论坛；

方法：采用LOADRUNNER 的录制工具录制三项业务；业务1，在公文系统内进行打开，修改等操作；业务2，在电子公告系统内，察看发布公告； 业务3 ，在网上论坛系统内发布帖子，查看文章；每项业务分配一定数量的用户，利用LOADRUNNER来完成；

并发用户数与事务执行情况：业务1，业务2，业务3事务平均响应时间；业务1，业务2，业务3事务最大响应时间；业务1，业务2，业务3平均每秒事务数；业务1，业务2，业务3平均成功率；每秒点击率；平均流量；

并发用户数与数据库主机：CPU利用率；MEM利用率；磁盘I/O情况；DB参数；

并发用户数与应用服务器的关系：CPU利用率，MEM利用率；磁盘I/O情况；

5.       疲劳强度与大数据量测试；
疲劳强度测试：主要特点是长时间对目标测试系统加压，目的是测试系统的稳定性，持续时间一般在1小时以上；疲劳强度测试属于用户并发测试的延续，因此核心内容仍然是核心模块用户并发和组合模块用户并发，在编写测试用例时需要编写不同参数或者负载条件下的多个测试用例，可以参考用户并发性能测试用例的设计内容，通常修改相应的参数就可实现所需要的测试场景；如下疲劳强度测试用例：

极限名称：200个用户同时使用系统的3个模块；

前提条件：测试客户端要有足够的资源；

运行时间：连续运行16小时；

测试方法：采用LOADRUNNER录制3个任务，然后开始对系统加压；

输入动作：任务1，任务2，任务3 ；持续时间, 任务20小时， 任务2，21小时，任务3，16小时；用户数量；现象；

大数据量测试：主要针对对数据库有特殊要求的系统进行的测试，如电信业务系统的手机短信业务；可以分为实时大数据量，主要目的是测试用户较多或者某些业务产生较大数据量时，系统能否稳定运行；极限状态下的测试，测试系统使用一段时间即系统累计一点量的数据时能否正常的运行业务；前面两种的结合，测试系统已经累计了较大数据量时，一些实时产生较大数据量的模块能否稳定工作；如下大数量测试用例：

功能：数据库中的短信息表可以保存所有不能及时发送的短信息，用户上线后又能及时发送已经保存的信息；

目的：

方法：

并发用户数与事务执行情况：输入说明； 事务平均响应时间；事务最大响应时间；平均每秒处理事务数，事务成功率；每秒点击率；平均流量；

6.       网络性能测试；
     基于硬件的测试：主要是通过各种软件工具，仪器等测试整个系统的网络运行环境，一般由系统集成人员负责 ；

     基于应用系统的测试：主要测试用户数目与网络带宽的关系，通过测试工具准确展示带宽，延迟，负载和端口的变化是如何影响用户响应时间的；

网络性能测试的用例设计主要针对后一种类型，可以独立进行测试，也可以和用户并发性能测试，疲劳强度与大数据量测试结合起来，在原有的基础上采用工具来调整网络设置，从而达到监视网络性能的目的；如下网络性能测试用例；

目的： 测试系统运行在不同网络带宽条件下的性能情况，以及与并发用户数量的关系；

方法：在不同的广域网带宽下使用LOADRUNNNER录制邮件系统得相关事务操作脚本，然后以不同的带宽和并发用户数进行压力测试，并记录在各种用户条件下各种事务的响应情况，同时记录路由器端口的流量和其他数据；

运行时间：

并发用户数与事务响应时间：

7.       服务器性能测试；
服务器性能测试主要是对数据库，WEB服务器，操作系统的测试，目的是通过性能测试找出服务器的瓶颈，为系统扩展，优化提供相关的依据；分为：

高级服务器性能测试：在特定的硬件条件下，由数据库，WEB服务器，操作系统相应领域的专家进行的性能测试；

初级服务器性能测试：在系统运行前面的性能测试时，通过测试工具对数据库，WEB服务器，操作系统的使用情况进行监控，然后进行综合分析，找出系统瓶颈；性能测试的主要目的是在软件功能良好的前提下，发现系统瓶颈并解决，而软件和服务器是产生瓶颈的两大来源，因此服务器测试一定要和前面的测试结合起来进行；在进行用户并发性能测试，疲劳强度与大数据量性能测试时，可以完成对服务器的监控并对服务器性能进行评估；这类部分的测试用例一般不必单独编写；

四、WEB性能测试用例设计
WEB 性能测试用例设计模型是设计性能测试用例的一个框架，在实际项目中，需要对其进行适当的剪裁，从而确定性能测试用例的范围和类别，裁减的依据是性能测试策略和测试范围；在测试用例主要框架确定后，接下来就要如何设计各类性能测试用例中具体数据。

基于用户的测试多在用户现场进行，而为了测试目的而进行的测试多在开发环境即开发团队的内部进行；为了测试目的而设计的测试用例场景主要根据测试设计人员的经验来进行，但是仍要参考用户的实际场景，用户实际使用场景是设计所有测试用例的依据，性能测试用例设计首先要分析出用户现实中的典型场景，然后参照典型场景进行设计。比较常见的用户场景有如下三种：一天内不同时段的使用场景；系统运行不同时期的场景；不同业务模式下的场景；各类测试用例设计的细节：

1.       确定用户使用系统情况的方法；
确定用户对系统的使用情况是设计用例具体数据的基础，后面并发用户数据设计，疲劳强度设计以及各种场景设计都要依赖对用户使用系统情况的分析，分析用户使用情况经常采用现场调查和分析系统日志两种方法；

用户现场调查：通过和用户进行沟通，可以确定用户的人员组成情况；这类方法适用于用户群体固定且目标测试系统没有投产前的情况；

分析系统日志：当用户比较分散，现场调查比较困难时，可以采用对系统日志进行分析的方法，作为对用户现场调查的补充；

2.       并发用户数量设计；
     设计并发用户数量前，首先要了解确定系统最大并发用户数量的方法；可以根据系统的最大使用人数或者最大在线数量来评估最大并发用户数量的方法；

     极限法：取最大在线用户数作为最大并发数，这种方法适用于系统已经投产目标用户群体不确定的门户网站，可以通过分析日志来进行测试；也可以使用系统已经注册的用户数量作为系统的用户数量，按照经验公式来估算最大用户数量；

     用户趋势分析：对软件生存周期内的用户未来走势进行分析，预测系统可能达到的最大使用用户数目，从而估算系统的最大并发用户数目，这种方法多用于用户数目逐渐增多的情况；

    经验评估法：多用于系统的使用用户数目相对稳定而且比较明确的系统；

并发用户数量的设计基本是按照最大并发用户的数量的百分比来设计的，对于某一特定的用例，需要注意：

一按照各类用户同时递增的方式来设计用户数量，是为了按照由浅入深的方法来发现系统的瓶颈；二并发用户的最大值一般不会超过前面计算的最大并发用户数量的20% ，除非是为了测试系统能支持的最大并发用户数量；三设计用户数量时要考虑成本，因为每组用户数都意味着至少执行一次测试；

3.       系统不同时间段场景的设计；
不同时间段的场景更接近用户使用情况，它也是设计核心模块和组合模块并发性能测试用例的基础，不同时间段场景分析的数据主要是前面的需求分析和日志分析结果；不同时间段场景的设计基本原则有两个：一是选择典型的场景进行测试；尤其要选择场景中并发用户数目较大的场景；二是要覆盖全面，设计出的用例要覆盖到压力可能较大的时间段；用户场景的设计一般与后面的业务模式结合起来进行；

4.       业务模式的设计；
     业务模式的设计是不同时间段场景设计的特例，也是设计核心模块和组合模块并发性能测试用例的基础，设计业务模式的目的是专注于某些功能模块的组合，按时间段来设计场景通常会涉及很多模块，如果系统存在的由应用软件引起的瓶颈则很难定位，所以才抽象一些特定的业务模式来进行用例的设计；

按照业务模式和时间段的场景来设计性能测试用例时，会涉及到如何设计每个模块并发用户数目的问题，通常会取各个相关模块在24小时内最大的并发用户数目进行组合；

5.       大数据量测试用例的设计；
历史数据相关的大数据量测试设计与并发用户的测试设计很类似，首先要确定系统数据的最长迁移周期，确定了系统的最大数据量后，接下来选择一些前面的核心模块或者组合模块的并发用户测试用例作为其主要内容即可；

运行时大数据量测试主要根据模拟系统运行时可能产生的大数据量来进行测试，这类测试用例通常根据实际情况去分析设计；

6.       一些特定测试用例的设计；
疲劳强度测试，最大用户测试，容量测试等一些特殊的测试用例设计，根据用户的需求进行，这类用例的相关要求通常十分明确；

性能测试用例最重要的是注意用例间的关系，孤立的设计各类用例只能增加测试成本，浪费人力。性能测试用例设计人员应该追求设计既能覆盖性能测试需求，又能以较低的成本来执行测试用例；

五、WEB性能测试用例设计总结
1.       测试用例可用性总结
对于一个比较完善的性能测试项目，经常会有一些测试用例不能执行，，因此测试完成后应该分析哪些用例不能执行以及不能执行的原因，这样可以为下次测试打好基础。

2.       用例执行效果分析
通过对用例执行效果进行分析，可以为升级或者开发新的性能测试用例提供有利的参考，不是所有的用例都能导致系统瓶颈的出现，因此应该分析哪些用例能够发现系统问题，哪些用例执行时没有太大效果。分析那些设计好的用例不但有助于以后设计用例，还可以为再次执行提供参考：当下次测试进度压力较大时可以先执行重要的用例，跳过那些尝试性的，不容易发现问题的用例；

3.       用例执行时间分析；
分析用例的执行时间是为下次规划性能测试提供参考，由于很多用例执行时间不是特别确定，导致性能测试计划也具有一定的不确定性。通过分析用例的执行时间可以为以后的制定测试计划提供参考；

 

总之，性能测试用例的设计是需要通过不断分析总结才能做好，不但要分析性能测试用例的可用性，执行效果，执行时间，还应该分析用例的设计方法，设计思路等。

大家在编写测试用例的时候往往把输入数据、操作步骤、输出、结果、以及一些过程信息等都包含很全，但是往往忽略掉对执行该测试的检查点，这些检查点往往是测试用例设计和编写的人的经验或对被测对象的深入的理解基础上，很多检查内容参加我写的测试检查点的文章。

因此我建议在描述操作步骤的时候还要把检查点列上去，如下：

VP即时Verifacation Point: 

VP1（重点检查点）：每个列表列出的人员、机构信息是正确的，没有重复、不缺少用户

VP2: 组合这两部分的接收者，比如：用户user1在机构1 user2属于本公司人员
    选择user1、无群组： user1能收到刚才发布的文件，user2没有
    选择user1、本公司人员：user1、user2都能接收到刚才发布的文件
    选择user3、本公司人员：user1不能接收到，user2能收到
VP3：坚持非空域，标题、时间必须为非空等
VP4：附件，测试各种格式，如doc、gif、xls、ppt、pdf格式的文件，文件大小分别为100k、1M、5M、10M
VP5：添加图片，浏览gif、tif、jpg、bmp格式的图片，查看现实上传是否正确。
VP6：检查文件状态，如暂存文件显示 “审核中“，发布文件显示”已审核“。

作者是从事项目组内测试的，这是作者个人的测试经验总结，点滴文章，仅供大家参考，强烈欢迎大家提意见：）
一，测试人员应该从需求跟进（或者更早，从调研跟进），和开发人员交流，甚至参与和客户交流。学习各类文档，要求必要的培训，从而了解、学习项目，为以后测试工作的开展打下很好的基础。
二，测试人员参与开发文档的审核，审核文档的可测性、明确性、正确性、完整性、一致性，同时审核的过程是学习。审核文档既要从大处有整体思考，又要从小处细致斟酌。
三，在了解、学习项目之后，就可以明确测试目的。根据测试目的制定测试计划（含测试用例），而且测试目的和测试计划都可以细化。测试目的和测试计划的内容也是有优先级的。测试文档一定要规范化。
四，测试计划要经过项目组评审。评审人员包括项目经理、测试人员、开发人员，以便于吸收不同的人不同的角度的意见。
五，在了解、学习项目的基础上，根据测试目的和测试计划，搭建测试环境，生成测试数据。测试数据最好是从客户方得来的真实数据。得到真实数据的途径可以通过项目经理和客户方沟通。
六，测试工作的开展要有优先级，要有取舍。
七，建立良好的版本控制系统；测试人员要明确测试的是最新版本的程序，建议使用ant系统。
八，建立bug管理系统，测试工作中发现的bug严格的按照bug管理流程进行提交、修改、测试。Bug管理系统的运用很重要：1，避免检查出来的bug被遗忘；2，有利于明确bug的优先级； 3，有利于监督bug解决的过程，解决完的bug要及时进行回归测试并且及时关闭；4，有利于统计，有利于确定测试重点；
九，测试人员要多和项目经理、开发人员进行沟通。测试是项目经理控制项目进度和质量的重要手段。
十，和同事保持良好的私人管理，对工作的顺利开展很有帮助。
十一，在时间允许的情况下，和项目经理、开发人员沟通，尽量推动开发人员对程序的单元测试工作。
十二，集成测试前先不要把新开发的未经过测试的部分提交到配置管理库，应该先从库中把其它部分下载到本地结合新开发的部分进行集成测试。
十三，项目后期安排对项目了解很少或者不了的人员根据使用、维护手册和测试计划对项目进行测试。
十四，项目组内部的测试始终是要服务于项目的整体进展和需要。

『转载』Loadrunner关于页面检查的几个函数详解

2008-09-24 10:05:21 / 个人分类：LoadRunner

关于插入文本检查点的问题

操作步骤：LR指南手册：

1 打开内容检查向导。

确保显示任务窗格（如果没有，请单击“任务”按钮）。在任务窗格的增强功能

标题下，单击“内容检查”。

将打开内容检查向导，显示脚本中每个步骤的缩略图。

选择右窗格中的“页面视图”选项卡以显示缩略图的快照。

2 选择包含要检查文本的页面

单击第一个名为 MercuryWebTours 的缩略图。

3 选择要检查的文本

突出显示快照内的文字欢迎使用。选中该文字后，右键单击并选择“添加文本检

查 (web-reg-find)”

4 查看新步骤

在树视图（“视图” > “树视图”）中，您将看到 VuGen 在脚本中插入了一个新

步骤服务: 注册查找。此步骤将注册文本检查棗LoadRunner 将在运行步骤后检

查文本。回放期间， VuGen 将查找文本欢迎使用并在回放日志中指示是否找到。

问题：按照此步骤出现了问题:

在第一步右键点击‘添加文本检查点’时报错。

按照提示内容为：文本检查不能以这种方式创建，要创建文本检查，切换到服务响应视图，展开主节点，右键再点击想检查的文本然后进行操作

分析：在树视图中有三种视图类型，page view（页面视图），client request（客户端请求视图），server response（服务器端响应视图）

那么在这三个视图中只有page view是可以看到截屏的，也意味着如果按照上述的提示操作是不可能实现的（既在页面中找到需要检查的文本这个操作只能在page view中实现）

解决方法：选择你所要检查的页面，操作 插入->新步骤->web checks->text check

进入“文本检查属性”页面，在search for栏输入你所要检查的文本，也可以在“之前”“之后”两栏选择你所要检查的文本内容。

注意在运行文本检查和图像检查的时候，一般未开启“启用图像和文本检查”，因为对图像的检查将耗费大量的内存。

应该要开启Vuser->run-time settings

然后选中preferences中的“启用图像和文本检查”。

Loadrunner 检查点函数总结

最近项目比较紧，一直没有写博客，再一个发现之前写的一些文章被其它网站任意使用，也不注明出处，实在心寒，也罢谁让当今社会就是这样呢！！！还是继续做我想做的事！

今天我来总结一下Loadrunner中的检查点函数，主要介绍两个函数：web_find()和web_reg_find()

转载请注明出处：http://www.51testing.com/?41972

这两个函数均用于内容的查找，但两者也有本质的区别，具体介绍如下：

一、web_find（）函数

该函数的作用是“在页面中查找相应的内容”，常用参数及含义如下：

       web_find("web_find",    //定义该查找函数的名称
              "RightOf=a",       //定义查找字符的右边界

              "LeftOf=b",        //定义查找字符的左边界

              "What=name",      //定义查找内容

              LAST);

使用该函数注意以下事项：

1、  位置

该函数在页面内容显示出来以后，在页面中进行查找，所以只能写在要查找内容之后

2、  录制模式

该函数只能在基于HTML模式录制的脚本中进行查找

3、  必须启用内容检查选项

在runtime setting->Preferences里面，把Enable image and text check选中，否则不执行该查找函数

4、  在VB和JAVA语法中不支持该函数

该函数有以下一个缺点：

1、  执行效率较低

2、  不返回查找结果情况，如想在执行该函数后根据查找结果做进一步操作时，没有返回值可以依据

例如：

在页面中查找“登录成功”的字符串，如果找到该字符串在日志中输出“登录成功”，如果找不到该字符串，则在日志中输出“登录失败”，此时使用该函数没有依据来做此判断，但使用web_reg_find()函数，使用它其中的SaveCount可以进行判断，具体方法我们下面介绍。

转载请注明出处：http://www.51testing.com/?41972

二、web_reg_find（）函数

该函数的作用是“在缓存中查找相应的内容”，常用参数及含义如下：

           web_reg_find("Search=Body",   //定义查找范围

              "SaveCount=ddd",             //定义查找计数变量名称

              "Text=aaaa",                  //定义查找内容

              LAST);

使用该函数注意以下事项：

1、  位置

该函数写在要查找内容的请求之前，通常情况下写在如下六个函数之前：

Web_castom_request();web_image();web_link();web_submit_data();web_submit_form();web_url()

2、  使用技巧

在该函数的参数中有个“SaveCount”，该参数可以记录在缓存中查找内容出现的次数，我们可以使用该值，来判断要查找的内容是否被找到，下面举个例子来说明：（引用LR的帮助中的例子）

  // Run the Web Tours sample

       web_url("MercuryWebTours",

              "URL=http://localhost/MercuryWebTours/",

              "Resource=0",

              "RecContentType=text/html",

              "Referer=",

              "Snapshot=t1.inf",

              "Mode=HTML",

              LAST);

// Set up check for successful login by looking for "Welcome"

       web_reg_find("Text=Welcome",

              "SaveCount=Welcome_Count",

              LAST);

// Now log in

       web_submit_form("login.pl",

              "Snapshot=t2.inf",

              ITEMDATA,

              "Name=username", "Value=jojo", ENDITEM,

              "Name=password", "Value=bean", ENDITEM,

              "Name=login.x", "Value=35", ENDITEM,

              "Name=login.y", "Value=14", ENDITEM,

              LAST);

// Check result

       if (atoi(lr_eval_string("{Welcome_Count}")) > 0){    //判断如果Welcome字符串出现次数大于0

              lr_output_message("Log on successful.");  }//在日志中输出Log on successful

        else{ //如果出现次数小于等于

              lr_error_message("Log on failed"); //在日志中输出Log on failed

              return(0);         }

我觉得这个方法非常有用，我们可以举一反三，应用到我们实际的项目中

转载请注明出处：http://www.51testing.com/?41972

三、插入函数的方法

1、  手工写入，在需要插入函数的位置手工写入该函数

2、  光标停留在要插入函数的位置，在INSERT菜单中，选择new step，在列表中选择或查找要插入的函数，根据提示填写必要的参数

3、  在tree view模式下，在树状菜单中选中要插入函数的位置，右键，选择insert after或insert before，根据提示填写必要的参数

四、总结

1、  这两个函数函数类型不同，WEB_FIND是普通函数，WEB_REG_FIND是注册函数

2、  WEB_FIND使用时必须开启内容检查选项，而WEB_REG_FIND则不没有此限制

3、  WEB_FIND只能只用在基于HTML模式录制的脚本中，而WEB_REG_FIND没有此限制

4、  WEB_FIND是在返回的页面中进行内容查找，WEB_REG_FIND是在缓存中进行查找

5、  WEB_FIND在执行效率上不如WEB_REG_FIND

转载请注明出处：http://www.51testing.com/?41972

摘要

　　虽然Java虚拟机(JVM)及其垃圾收集器(garbage collector，GC)负责管理大多数的内存任务，Java软件程序中还是有可能出现内存泄漏。实际上，这在大型项目中是一个常见的问题。避免内存泄漏的第一步是要弄清楚它是如何发生的。本文介绍了编写Java代码的一些常见的内存泄漏陷阱，以及编写不泄漏代码的一些最佳实践。一旦发生了内存泄漏，要指出造成泄漏的代码是非常困难的。因此本文还介绍了一种新工具，用来诊断泄漏并指出根本原因。该工具的开销非常小，因此可以使用它来寻找处于生产中的系统的内存泄漏。

垃圾收集器的作用

　　虽然垃圾收集器处理了大多数内存管理问题，从而使编程人员的生活变得更轻松了，但是编程人员还是可能犯错而导致出现内存问题。简单地说，GC循环地跟踪所有来自“根”对象（堆栈对象、静态对象、JNI句柄指向的对象，诸如此类）的引用，并将所有它所能到达的对象标记为活动的。程序只可以操纵这些对象；其他的对象都被删除了。因为GC使程序不可能到达已被删除的对象，这么做就是安全的。

　　虽然内存管理可以说是自动化的，但是这并不能使编程人员免受思考内存管理问题之苦。例如，分配（以及释放）内存总会有开销，虽然这种开销对编程人员来说是不可见的。创建了太多对象的程序将会比完成同样的功能而创建的对象却比较少的程序更慢一些（在其他条件相同的情况下）。

　　而且，与本文更为密切相关的是，如果忘记“释放”先前分配的内存，就可能造成内存泄漏。如果程序保留对永远不再使用的对象的引用，这些对象将会占用并耗尽内存，这是因为自动化的垃圾收集器无法证明这些对象将不再使用。正如我们先前所说的，如果存在一个对对象的引用，对象就被定义为活动的，因此不能删除。为了确保能回收对象占用的内存，编程人员必须确保该对象不能到达。这通常是通过将对象字段设置为null或者从集合(collection)中移除对象而完成的。但是，注意，当局部变量不再使用时，没有必要将其显式地设置为null。对这些变量的引用将随着方法的退出而自动清除。

　　概括地说，这就是内存托管语言中的内存泄漏产生的主要原因：保留下来却永远不再使用的对象引用。

典型泄漏

　　既然我们知道了在Java中确实有可能发生内存泄漏，就让我们来看一些典型的内存泄漏及其原因。

全局集合

　　在大的应用程序中有某种全局的数据储存库是很常见的，例如一个JNDI树或一个会话表。在这些情况下，必须注意管理储存库的大小。必须有某种机制从储存库中移除不再需要的数据。

　　这可能有多种方法，但是最常见的一种是周期性运行的某种清除任务。该任务将验证储存库中的数据，并移除任何不再需要的数据。

　　另一种管理储存库的方法是使用反向链接(referrer)计数。然后集合负责统计集合中每个入口的反向链接的数目。这要求反向链接告诉集合何时会退出入口。当反向链接数目为零时，该元素就可以从集合中移除了。

缓存

　　缓存是一种数据结构，用于快速查找已经执行的操作的结果。因此，如果一个操作执行起来很慢，对于常用的输入数据，就可以将操作的结果缓存，并在下次调用该操作时使用缓存的数据。

　　缓存通常都是以动态方式实现的，其中新的结果是在执行时添加到缓存中的。典型的算法是：

• 检查结果是否在缓存中，如果在，就返回结果。
• 如果结果不在缓存中，就进行计算。
• 将计算出来的结果添加到缓存中，以便以后对该操作的调用可以使用。

　　该算法的问题（或者说是潜在的内存泄漏）出在最后一步。如果调用该操作时有相当多的不同输入，就将有相当多的结果存储在缓存中。很明显这不是正确的方法。

　　为了预防这种具有潜在破坏性的设计，程序必须确保对于缓存所使用的内存容量有一个上限。因此，更好的算法是：

• 检查结果是否在缓存中，如果在，就返回结果。
• 如果结果不在缓存中，就进行计算。
• 如果缓存所占的空间过大，就移除缓存最久的结果。
• 将计算出来的结果添加到缓存中，以便以后对该操作的调用可以使用。

　　通过始终移除缓存最久的结果，我们实际上进行了这样的假设：在将来，比起缓存最久的数据，最近输入的数据更有可能用到。这通常是一个不错的假设。

　　新算法将确保缓存的容量处于预定义的内存范围之内。确切的范围可能很难计算，因为缓存中的对象在不断变化，而且它们的引用包罗万象。为缓存设置正确的大小是一项非常复杂的任务，需要将所使用的内存容量与检索数据的速度加以平衡。

　　解决这个问题的另一种方法是使用java.lang.ref.SoftReference类跟踪缓存中的对象。这种方法保证这些引用能够被移除，如果虚拟机的内存用尽而需要更多堆的话。

ClassLoader

　　Java ClassLoader结构的使用为内存泄漏提供了许多可乘之机。正是该结构本身的复杂性使ClassLoader在内存泄漏方面存在如此多的问题。ClassLoader的特别之处在于它不仅涉及“常规”的对象引用，还涉及元对象引用，比如：字段、方法和类。这意味着只要有对字段、方法、类或ClassLoader的对象的引用，ClassLoader就会驻留在JVM中。因为ClassLoader本身可以关联许多类及其静态字段，所以就有许多内存被泄漏了。

确定泄漏的位置

　　通常发生内存泄漏的第一个迹象是：在应用程序中出现了OutOfMemoryError。这通常发生在您最不愿意它发生的生产环境中，此时几乎不能进行调试。有可能是因为测试环境运行应用程序的方式与生产系统不完全相同，因而导致泄漏只出现在生产中。在这种情况下，需要使用一些开销较低的工具来监控和查找内存泄漏。还需要能够无需重启系统或修改代码就可以将这些工具连接到正在运行的系统上。可能最重要的是，当进行分析时，需要能够断开工具而保持系统不受干扰。

　　虽然OutOfMemoryError通常都是内存泄漏的信号，但是也有可能应用程序确实正在使用这么多的内存；对于后者，或者必须增加JVM可用的堆的数量，或者对应用程序进行某种更改，使它使用较少的内存。但是，在许多情况下，OutOfMemoryError都是内存泄漏的信号。一种查明方法是不间断地监控GC的活动，确定内存使用量是否随着时间增加。如果确实如此，就可能发生了内存泄漏。

详细输出

　　有许多监控垃圾收集器活动的方法。而其中使用最广泛的可能是使用-Xverbose:gc选项启动JVM，并观察输出。

[memory ] 10.109-10.235: GC 65536K->16788K (65536K), 126.000 ms

　箭头后面的值（本例中是16788K）是垃圾收集所使用的堆的容量。

控制台

　　查看连续不断的GC的详细统计信息的输出将是非常乏味的。幸好有这方面的工具。JRockit Management Console可以显示堆使用量的图示。借助于该图，可以很容易地看出堆使用量是否随时间增加。

图1. JRockit Management Console

　　甚至可以配置该管理控制台，以便如果发生堆使用量过大的情况（或基于其他的事件），控制台能够向您发送电子邮件。这明显使内存泄漏的查看变得更容易了。

内存泄漏检测工具

　　还有其他的专门进行内存泄漏检测的工具。JRockit Memory Leak Detector可以用来查看内存泄漏，并可以更深入地查出泄漏的根源。这个强大的工具是紧密集成到JRockit JVM中的，其开销非常小，对虚拟机的堆的访问也很容易。

专业工具的优点

　　一旦知道确实发生了内存泄漏，就需要更专业的工具来查明为什么会发生泄漏。JVM自己是不会告诉您的。这些专业工具从JVM获得内存系统信息的方法基本上有两种：JVMTI和字节码技术(byte code instrumentation)。Java虚拟机工具接口(Java Virtual Machine Tools Interface，JVMTI)及其前身Java虚拟机监视程序接口(Java Virtual Machine Profiling Interface，JVMPI)是外部工具与JVM通信并从JVM收集信息的标准化接口。字节码技术是指使用探测器处理字节码以获得工具所需的信息的技术。

　　对于内存泄漏检测来说，这两种技术有两个缺点，这使它们不太适合用于生产环境。首先，它们在内存占用和性能降低方面的开销不可忽略。有关堆使用量的信息必须以某种方式从JVM导出，并收集到工具中进行处理。这意味着要为工具分配内存。信息的导出也影响了JVM的性能。例如，当收集信息时，垃圾收集器将运行得比较慢。另外一个缺点是需要始终将工具连在JVM上。这是不可能的：将工具连在一个已经启动的JVM上，进行分析，断开工具，并保持JVM运行。

　　因为JRockit Memory Leak Detector是集成到JVM中的，就没有这两个缺点了。首先，许多处理和分析工作是在JVM内部进行的，所以没有必要转换或重新创建任何数据。处理还可以背负(piggyback)在垃圾收集器本身上而进行，这意味着提高了速度。其次，只要JVM是使用-Xmanagement选项（允许通过远程JMX接口监控和管理JVM）启动的，Memory Leak Detector就可以与运行中的JVM进行连接或断开。当该工具断开时，没有任何东西遗留在JVM中，JVM又将以全速运行代码，正如工具连接之前一样。

趋势分析

　　让我们深入地研究一下该工具以及它是如何用来跟踪内存泄漏的。在知道发生内存泄漏之后，第一步是要弄清楚泄漏了什么数据--哪个类的对象引起了泄漏？JRockit Memory Leak Detector是通过在每次垃圾收集时计算每个类的现有对象的数目来实现这一步的。如果特定类的对象数目随时间而增长（“增长率”），就可能发生了内存泄漏。

图2. Memory Leak Detector的趋势分析视图

　　因为泄漏可能像细流一样非常小，所以趋势分析必须运行很长一段时间。在短时间内，可能会发生一些类的局部增长，而之后它们又会跌落。但是趋势分析的开销很小（最大开销也不过是在每次垃圾收集时将数据包由JRockit发送到Memory Leak Detector）。开销不应该成为任何系统的问题——即使是一个全速运行的生产中的系统。

　　起初数目会跳跃不停，但是一段时间之后它们就会稳定下来，并显示出哪些类的数目在增长。

找出根本原因

　　有时候知道是哪些类的对象在泄漏就足以说明问题了。这些类可能只用于代码中的非常有限的部分，对代码进行一次快速检查就可以显示出问题所在。遗憾地是，很有可能只有这类信息还并不够。例如，常见到泄漏出在类java.lang.String的对象上，但是因为字符串在整个程序中都使用，所以这并没有多大帮助。

　　我们想知道的是，另外还有哪些对象与泄漏对象关联？在本例中是String。为什么泄漏的对象还存在？哪些对象保留了对这些对象的引用？但是能列出的所有保留对String的引用的对象将会非常多，以至于没有什么实际用处。为了限制数据的数量，可以将数据按类分组，以便可以看出其他哪些对象的类与泄漏对象(String)关联。例如，String在Hashtable中是很常见的，因此我们可能会看到与String关联的Hashtable数据项对象。由Hashtable数据项倒推，我们最终可以找到与这些数据项有关的Hashtable对象以及String（如图3所示）。

图3. 在工具中看到的类型图的示例视图

倒推

　　因为我们仍然是以类的对象而不是单独的对象来看待对象，所以我们不知道是哪个Hashtable在泄漏。如果我们可以弄清楚系统中所有的Hashtable都有多大，我们就可以假定最大的Hashtable就是正在泄漏的那一个（因为随着时间的流逝它会累积泄漏而增长得相当大）。因此，一份有关所有Hashtable对象以及它们引用了多少数据的列表，将会帮助我们指出造成泄漏的确切Hashtabl。

图4. 界面：Hashtable对象以及它们所引用数据的数量的列表

　　对对象引用数据数目的计算开销非常大（需要以该对象作为根遍历引用图），如果必须对许多对象都这么做，将会花很多时间。如果了解一点Hashtable的内部实现原理就可以找到一条捷径。Hashtable的内部有一个Hashtable数据项的数组。该数组随着Hashtable中对象数目的增长而增长。因此，为找出最大的Hashtable，我们只需找出引用Hashtable数据项的最大数组。这样要快很多。

图5. 界面：最大的Hashtable数据项数组及其大小的清单

更进一步

　　当找到发生泄漏的Hashtable实例时，我们可以看到其他哪些实例在引用该Hashtable，并倒推回去看看是哪个Hashtable在泄漏。

图 6. 这就是工具中的实例图

　　例如，该Hashtable可能是由MyServer类型的对象在名为activeSessions的字段中引用的。这种信息通常就足以查找源代码以定位问题所在了。

图7. 检查对象以及它对其他对象的引用

找出分配位置

　　当跟踪内存泄漏问题时，查看对象分配到哪里是很有用的。只知道它们如何与其他对象相关联（即哪些对象引用了它们）是不够的，关于它们在何处创建的信息也很有用。当然了，您并不想创建应用程序的辅助构件，以打印每次分配的堆栈跟踪(stack trace)。您也不想仅仅为了跟踪内存泄漏而在运行应用程序时将一个分析程序连接到生产环境中。

　　借助于JRockit Memory Leak Detector，应用程序中的代码可以在分配时进行动态添加，以创建堆栈跟踪。这些堆栈跟踪可以在工具中进行累积和分析。只要不启用就不会因该功能而产生成本，这意味着随时可以进行分配跟踪。当请求分配跟踪时，JRockit 编译器动态插入代码以监控分配，但是只针对所请求的特定类。更好的是，在进行数据分析时，添加的代码全部被移除，代码中没有留下任何会引起应用程序性能降低的更改。

图8. 示例程序执行期间String的分配的堆栈跟踪

结束语

　　内存泄漏是难以发现的。本文重点介绍了几种避免内存泄漏的最佳实践，包括要始终记住在数据结构中所放置的内容，以及密切监控内存使用量以发现突然的增长。

　　我们都已经看到了JRockit Memory Leak Detector是如何用于生产中的系统以跟踪内存泄漏的。该工具使用一种三步式的方法来找出泄漏。首先，进行趋势分析，找出是哪个类的对象在泄漏。接下来，看看有哪些其他的类与泄漏的类的对象相关联。最后，进一步研究单个对象，看看它们是如何互相关联的。也有可能对系统中所有对象分配进行动态的堆栈跟踪。这些功能以及该工具紧密集成到JVM中的特性使您可以以一种安全而强大的方式跟踪内存泄漏并进行修复。

参考资料

• JRockit工具下载
• BEA JRockit 5.0说明文档
• JRockit 5.0中的新功能和新工具
• BEA JRockit DevCenter

在大多数的性能测试工作中，我们可以看出很多内容都是互相关联的。这就给我们提供了一思路：性能测试的很多内容可以经过一定的组织统一来进行。统一开展性能测试的巨大好处是可以由浅入深按照层次对系统进行测试，进而减少不必要的工作量，以实现节约测试成本的目的。为此，本文提出了“全面性能测试模型”的概念。 “全面性能测试模型”提出的主要依据就是一种类型的性能测试可以在某些条件下转化成为另外一种类型的性能测试，而这些类型的测试实施也是很类似的。例如：针对一个网站进行测试，模拟10到50个用户
就是在进行常规性能测试，用户增加到1000乃至上万就变成了压力/负载测试。如果同时对系统进行大量的数据查询操作，就包含了强度测试。
1．全面性能测试模型在“全面性能测试模型”中，把Web性能测试分为八个类别。
下面首先介绍八个性能测试类别的主要内容。
（1）预期指标的性能测试 系统在需求分析和设计阶段都会提出一些性能指标，这些指标是性能测试要完成的首要工作之一，本模型把预先确定的一些性能指标的测试称为预期指标的性能测试。 这些指标主要是指诸如“系统可以支持并发用户1000”、“系统响应时间不得高于10秒”等在产品说明书等文档中中十分明确的内容，对这种预先承诺的性能要求，测试小组应该“首当其冲”完成这类测试。
（2）独立业务性能测试 独立业务主要是指一些核心业务模块，这些模块通常具有功能比较复杂、使用比较频繁、属于核心业务等特点。这类特殊的、功能比较独立的业务模块始终都是性能测试重点。我们通常不但要测试这类模块的一些和性能相关的算法，还要测试这类模块对并发用户的响应情况。 核心业务模块在需求阶段就可以确定，在系统测试阶段开始单独测试其性能。如果是系统类软件或者特殊应用的软件，通常从单元测试阶段就开始进行测试，在后继的集成测试、系统测试、验收测试中进一步进行测试，以保证核心业务模块的性能稳定。 用户并发测试是核心业务模块的重“并发”的主要内容是模拟一定数量的用户同时使用某一核心模块的“相同”或者“不同”的功能，并且持续一段时间。对“相同”的功
能进行并发测试分为两种类型，一类是在同一时刻进行完全一样的操作，例如打开同一条数据记录进行查看；另外一类是在同一时刻使用完全一样的功能，例如同时提交数据进行保存。可以看出后者是包含前前者的，后者是前者的特例，这种并发测试都要持续一定的时间。
从微观角度讲，同时使用某一核心模块“不同”的功能，也是一种组合业务性能测试，只不过这种组合的相关业务大分类是一致的。
（3）组合业务性能测试 通常不会所有的用户只使用一个或者几个核心业务模块，每个功能模块都可能被使用到，所以Web性能测试既要模拟多用户的“相同”操作(这里的“相同”
指很多用户使用同一功能)，又要模拟多用户的“不同”操作(这里的“不同”指很多用户同时对一个或者多个模块的不同功能进行操作)对多个业务进行组合性能测试。组合业务测试是最接近用户实际使用情况的测试，因而是性能测试的核心内容。我们通常按照用户的实际使用情况来模拟使用各个模板的人数比例。 由于组合业务测试是最反映用户使用系统情况
的测试，因而组合测试往往和服务器（操作系统、Web服务器、数据库服务器）性能测试
结合起来，在通过工具模拟用户行为的同时，还通过测试工具的监控功能采集服务器的计数器信息，进而全面分析系统的瓶颈，为改进系统提供有利的依据。用户并发测试是组合业
务测试的核心内容。“组合”并发的突出特点是分成不同的用户组进行并发，每组的用户比例要根据实际情况来进行匹配。组合业务测试可以理解为包含了“核心业务模块并发”和“非核心业务模块并发”同时进行的并发用户测试。
（4）疲劳强度性能测试 疲劳强度测试是在系统稳定运行下模拟较大的用户数量、并长时间运行系统的测试，通过综合分析执行指标和资源监控来确定系统处理最大业务量时的性能，
主要目的是为了测试系统的稳定性。
（5）大数据量性能测试 大数据量测试分为两种：一种是针对某些系统存储、传输、统计查询等业务进行大数据量的测试，主要是测试数据增多时的性能情况，这类一般都是针对某些特殊的核心业务或者一些日常比较常用的组合业务的测试。 第二种是极限状态下的数据测试，主要是指系统数据量达到一定程度时，通过性能测试来评估系统的响应情况，测试的对象也是某些核心业务或者日常常用的组合业务。例如系统的数据每年只备份转移一次，可分别选择一个季度、半年、一年作为参考，模拟输入各个时间段的预计数据量，然后测试系统的性能，进而预估系统的性能走向。 由于大数据量仍然是为了测试系统的业务处理能力，
因此大数据量性能测试可以独立进行，也可以和前面的独立、组合业务测试结合起来进行，主要由性能测试策略来决定。由于大数据量测试一般在投产环境进行，因此本书把它单独独立出来，和疲劳强度测试放在一起，在整个性能测试的后期进行。大数据量测试可以理解为特定条件下的核心业务或者组合业务测试。
（6）网络性能测试 网络性能测试主要是为了准确展示带宽、延迟、负载和端口的变化是如何影响用户的响应时间的。在实际的软件项目中，主要是测试用户数目与网络带宽的关系。
网络性能测试一般有专门的工具，因此本书不研究网络测试，网络测试的任务通常由系统集成人员来完成。
（7）服务器性能测试 服务器性能测试（操作系统、Web服务器、数据库服务器）分为初级和高级两种形式。“初级服务器性能测试”主要是指在业务系统工作或者进行前面其它
种类性能测试的时候，监控服务器的一些计数器信息，通过这些数据对服务器进行综合性能分析，找出系统瓶颈，为调优或者提高性能提供依据。“高级服务器性能测试”一般不由测试人员进行，由专门的系统管理员来进行，例如数据库服务器由专门的DBA来进行测试和调优。本书主要讨论在测试中常用到的“初级服务器性能测试”，既通过工具对服务器资源进行监控的性能测试。
（8）一些特殊测试 主要是指配置测试、内存泄漏测试一些特殊的Web性能测试。这类性能测试或者和前面的测试结合起来进行，或者在一些特殊情况下会独立进行，本书重点来讨论前一种情况，因为后一种情况往往通过特有的工具、较大投入的进行，可以不作为性能测试的范畴来研究。