qileilove

软件测试中用正交实验法设计测试用例

正交实验法的由来

一、正交表的由来

拉丁方名称的由来

古希腊是一个多民族的国家，国王在检阅臣民时要求每个方队中每行有一个民族代表，每列也要有一个民族的代表。

数学家在设计方阵时，以每一个拉丁字母表示一个民族，所以设计的方阵称为拉丁方。

什么是n阶拉丁方？

用n个不同的拉丁字母排成一个n阶方阵（n<26 ），如果每行的n个字母均不相同，每列的n个字母均不相同，则称这种方阵为n*n拉丁方或n阶拉丁方。每个字母在任一行、任一列中只出现一次。

什么是正交拉丁方？

设有两个n阶的拉丁方，如果将它们叠合在一起，恰好出现n2个不同的有序数对，则称为这两个拉丁方为互相正交的拉丁方，简称正交拉丁方。

例如：3阶拉丁方

用数字替代拉丁字母：

二、正交实验法

正交试验设计(Orthogonal experimental design)是研究多因素多水平的又一种设计方法，它是根据正交性从全面试验中挑选出部分有代表性的点进行试验，这些有代表性的点具备了“均匀分散，齐整可比”的特点，正交试验设计是分式析因设计的主要方法。是一种高效率、快速、经济的实验设计方法。

日本著名的统计学家田口玄一将正交试验选择的水平组合列成表格，称为正交表。例如作一个三因素三水平的实验，按全面实验要求，须进行33=27种组 合的实验，且尚未考虑每一组合的重复数。若按L9(33) 正交表按排实验，只需作9次，按L18(37) 正交表进行18次实验，显然大大减少了工作量。因而正交实验设计在很多领域的研究中已经得到广泛应用。

利用因果图来设计测试用例时, 作为输入条件的原因与输出结果之间的因果关系,有时很难从软件需求规格说明中得到。往往因果关系非常庞大,以至于据此因果图而得到的测试用例数目多的惊人，给软件测试带来沉重的负担，为了有效地,合理地减少测试的工时与费用,可利用正交实验设计方法进行测试用例的设计。

正交实验设计方法:依据Galois理论,从大量的（实验）数据（测试例）中挑选适量的、有代表性的点（例），从而合理地安排实验（测试）的一种科学实验设计方法。类似的方法有:聚类分析方法、因子方法方法等。

三、利用正交实验设计测试用例的步骤：

（1）提取功能说明,构造因子--状态表

把影响实验指标的条件称为因子，而影响实验因子的条件叫因子的状态。

利用正交实验设计方法来设计测试用例时，首先要根据被测试软件的规格说明书找出影响其功能实现的操作对象和外部因素，把他们当作因子；而把各个因子 的取值当作状态。对软件需求规格说明中的功能要求进行划分，把整体的、概要性的功能要求进行层层分解与展开，分解成具体的有相对独立性的、基本的功能要 求。这样就可以把被测试软件中所有的因子都确定下来，并为确定每个因子的权值提供参考的依据。确定因子与状态是设计测试用例的关键。因此要求尽可能全面 的、正确的确定取值，以确保测试用例的设计作到完整与有效。

（2）加权筛选,生成因素分析表

对因子与状态的选择可按其重要程度分别加权。可根据各个因子及状态的作用大小、出现频率的大小以及测试的需要，确定权值的大小。

（3）利用正交表构造测试数据集

利用正交实验设计方法设计测试用例，比使用等价类划分、边界值分析、因果图等方法有以下优点：节省测试工作工时；可控制生成的测试用例数量；测试用例具有一定的覆盖率。

在使用正交实验法时，要考虑到被测系统中要准备测试的功能点，而这些功能点就是要获取的因子或因素，但每个功能点要输入的数据按等价类划分有多个，也就是每个因素的输入条件，即状态或水平值。

四、正交表的构成

行数(Runs)：正交表中的行的个数，即试验的次数，也是我们通过正交实验法设计的测试用例的个数。

因素数(Factors) ：正交表中列的个数，即我们要测试的功能点。

水平数(Levels)：任何单个因素能够取得的值的最大个数。正交表中的包含的值为从0到数“水平数-1”或从1到“水平数” 。即要测试功能点的输入条件。

正交表的形式：

L_行数(水平数^因素数)

如：L₈(2⁷)

五、正交表的正交性

整齐可比性

在同一张正交表中，每个因素的每个水平出现的次数是完全相同的。由于在试验中每个因素的每个水平与其它因素的每个水平参与试验的机率是完全相同的，这就保证在各个水平中最大程度的排除了其它因素水平的干扰。因而，能最有效地进行比较和作出展望，容易找到好的试验条件。

均衡分散性

在同一张正交表中，任意两列（两个因素）的水平搭配（横向形成的数字对）是完全相同的。这样就保证了试验条件均衡地分散在因素水平的完全组合之中，，因而具有很强的代表性，容易得到好的试验条件。

用正交实验法设计测试用例

以上介绍了正交实验法的由来。怎么用正交实验法进行用例的设计呢？

一、用正交表设计测试用例的步骤

(1) 有哪些因素（变量）

(2) 每个因素有哪几个水平（变量的取值）

(3) 选择一个合适的正交表

(4) 把变量的值映射到表中

(5) 把每一行的各因素水平的组合做为一个测试用例

(6) 加上你认为可疑且没有在表中出现的组合

二、如何选择正交表

• 考虑因素（变量）的个数
• 考虑因素水平（变量的取值）的个数
• 考虑正交表的行数
• 取行数最少的一个

三、设计测试用例时的三种情况

（1）因素数（变量）、水平数（变量值）相符

（2）因素数不相同

（3）水平数不相同

四、我们来看看第一种情况:

（1）因素数与水平数刚好符合正交表

我们举个例子：

这是个人信息查询系统中的一个窗口。我们可以看到要测试的控件有3个：姓名、身份证号码、手机号码，也就是要考虑的因素有三个；而每个因素里的状态有两个：填与不填。

选择正交表时分析一下：

1、表中的因素数>=3；

2、表中至少有3个因素数的水平数>=2；

3、行数取最少的一个。

从正交表公式中开始查找，结果为：

L₄(2³)

变量映射：

测试用例如下：

1：填写姓名、填写身份证号、填写手机号

2：填写姓名、不填身份证号、不填手机号

3：不填姓名、填写身份证号、不填手机号

4：不填姓名、不填身份证号、填写手机号

增补测试用例

5：不填姓名、不填身份证号、不填手机号

从测试用例可以看出：如果按每个因素两个水平数来考虑的话，需要8个测试用例，而通过正交实验法进行的测试用例只有5个，大大减少了测试用例数。用最小的测试用例集合去获取最大的测试覆盖率。

（2）因素数不相同

如果因素数不同的话，可以采用包含的方法，在正交表公式中找到包含该情况的公式，如果有N个符合条件的公式，那么选取行数最少的公式。

（3）水平数不相同

采用包含和组合的方法选取合适的正交表公式。

正交实验法的又一个例子

上面就正交实验法进行了讲解，现在再拿PowerPoint软件打印功能作为例子，希望能为大家更好地理解给方法的具体应用

假设功能描述如下：

• 打印范围分：全部、当前幻灯片、给定范围 共三种情况；
• 打印内容分：幻灯片、讲义、备注页、大纲视图 共四种方式；
• 打印颜色/灰度分: 颜色、灰度、黑白 共三种设置；
• 打印效果分：幻灯片加框和幻灯片不加框两种方式。

因素状态表：

我们先将中文字转换成字母，便于设计。得到：

因素状态表：

我们分析一下：

被测项目中一共有四个被测对象，每个被测对象的状态都不一样。

选择正交表：

1、表中的因素数>=4

2、表中至少有4个因素的水平数>=2

3、行数取最少的一个

最后选中正交表公式：

L₁₆(4⁵)

正交矩阵为：

用字母替代正交矩阵：

　　在测试过程中，测试人员经常需要将测试对象的各种输入参数进行组合之后进行测试。有时候，将各种输入参数进行组合，得到的测试用例数目将是非常庞大的。由于测试时间和成本的限制，无法对测试对象输入值的所有组合进行测试。下面是某个网站测试的要求：

　　------------案例描述：开始-------------

　　某网站需要支持

　　● 不同的浏览器：IE5.0、IE5.5、IE6.0、Netscape6.0、Netscape6.1、Netscape7.0、Mozilla1.1和Opera7；

　　● 不同的插件：RealPlayer、MediaPlayer或者没有任何插件None；

　　● 不同的客户端操作系统：Windows95、Windows98、WindowsME、、WindowsNT、Windows2000和WindowsXP；

　　● 不同的Web服务器软件：IIS、Apache和WebLogic；

　　● 不同的服务器端操作系统：WindowsNT、Windows2000和Linux。

　　这种情况下，需要针对不同的组合进行测试：

　　● 8种浏览器

　　● 3种插件

　　● 6种客户端操作系统

　　● 3种Web服务器软件

　　● 3种服务器端操作系统

　　如果考虑所有参数不同取值的组合，那么需要设计和执行的测试用例的数目是1296（8 x 3 x 6 x 3 x 3 = 1296）。

　　------------案例描述：结束-------------

　　在软件测试过程中，这种类型的组合是非常普遍的。每种情形都可能有庞大的组合需要进行测试，假如不对它们进行测试，可能会存在较大的风险；而如果对所有组合进行测试，测试时间和资源又不允许。测试人员在面对这种情况的时候，可以采用以下几种常用的策略：

　　● 尝试测试所有输入的组合，延期项目，导致的后果可能是失去产品的市场。

　　● 选择一些容易设计和执行的测试用例，而忽略其是否能够提供产品质量的信息。

　　● 罗列所有的组合，并随机选择其中的子集进行测试。

　　● 采取特殊的测试技术，选择能发现大部分缺陷的子集进行测试。

　 　如果采用最后一个策略，那么使用结对测试技术是一个很好的选择。采用结对测试的技术，测试并不针对输入值的所有组合进行测试，而只是针对所有输入值的两 两组合。结对测试技术可以显著地减少测试用例的数目，同时保证较高的测试质量。下面是应用结对测试技术减少测试用例数目的例子：

　　● 假如软件系统有四个不同的输入参数，每个参数有3个不同的输入值，得到的完全组合数目是34即81。假如采用结对测试的技术，只需要9个测试用例即可覆盖所有参数的两两组合。

　　● 假如软件系统有13个不同的输入参数，每个参数有3个不同的输入值，得到的完全组合数目是313即1594323。假如采用结对测试的技术，只需要15个测试用例即可覆盖所有参数的两两组合。

　　● 假如软件系统有20个不同的输入参数，每个参数有10个不同的输入值，得到的完全组合数目是1020。假如采用结对测试的技术，只需要180个测试用例即可覆盖所有参数的两两组合。

　　结对测试技术能够发现所有的单模式失效（Single-mode Fault）和双模式失效（Double-mode Fault）。但是，结对测试并不一定适合于发现测试对象中的多模式失效（Multimode Fault）。

　　● 单模式失效：失效是由单个参数引起的，只要针对所有独立参数进行测试，就能够发现该失效。

　　● 双模式缺陷：失效是由两个参数共同引起的，必须针对所有参数的两两组合进行测试，才能够确保发现此类缺陷。

　　● 多模式缺陷：失效是由三个或三个以上参数共同引起的，采用结对测试技术也可能发现多模式缺陷，但是不能保证测试的充分性。

　　摘要：本文通过对测试原则与用况驱动思想的分析，提出了用况驱动系统测试用例设计的思想。从功能性测试、性能测试、回归测试等三方面，阐述了该思想在测试用例设计过程中的必要性和应用方式。并重点以功能性测试为例，给出一些该思想应用于实践的方法和经验。

　　关键词：用况驱动；系统测试；测试用例设计

　　一、系统测试用例设计原则和优点

　　软件测试是为了发现错误而执行程序的过程，一般来说横跨软件生命周期的两个阶段：开发阶段和测试阶段。其中开发阶段的测试工作主要是指单元测试和集成测试，一般由开发人员完成；测试阶段是软件生命周期的一个独立阶段，主要的任务是进行系统测试，由专门的测试人员完成。无论单元集成测试，还是系统测试，都应该进行必要的测试用例设计，本文的侧重点在于系统测试的用例设计。

　　系统测试在待测系统组装到一起并通过了单元和集成测试之后进行，一般采用黑盒测试的 方式，侧重于测试软件的功能性需求，兼顾性能、压力等各方面的因素。系统测试的意图在于发现系统与用户期望的差距，通过测试暴露出软件中隐藏的错误和缺 陷，权衡并改进系统。Davis曾经提出了一组测试原则，其中包括两点：一是所有测试都应该可以追溯到用户需求；二是穷举测试是不可能的。

　 　正如我们所知，软件测试的目的在于发现错误，而最严重的错误莫过于导致程序无法满足需求的错误。因此测试用例的设计必须充分考虑用户需求，是否正确的满 足了用户需求是判别一个软件系统是否能够通过测试，是否合格产品的最重要标准。在实际的测试工作中，追求系统测试用例对用户明示和隐含需求的100%覆 盖，试图穷举用户需求进行测试是不现实的。系统测试用例的设计原则应该是尽可能覆盖用户工作中使用本系统的各种工作场景和情况（包括正常方式使用和异常方 式使用的情况），至少应完全覆盖用户日常工作使用系统的全部场景和情况。

　　用况驱动（Use-Case Driven）是统一过程（UP）的核心思想之一，也是其精髓所在。统一过程的目标是指导开发人员有效的实现并实施满足用户需求的系统。统一过程一般被认为是一种OO（面向对象）开发方法，实际上它的思想也同样支持非OO系统的开发。统一过程特点在于：用况驱动、以框架为中心、迭代和增量的。

　 　用况（Use-Case）的目的在于捕获真正的需求和使用适于用户、客户、开发、测试等各方人员理解的形式将捕获到的需求加以描述。它几乎普遍用于捕获 软件系统需求。但它的作用不仅如此，还能够驱动整个开发过程，在寻找和确定类、子系统和接口、寻找和确定测试用例、规划开发迭代和系统集成时，均可以将用 况作为主要输入。因而可以毫不夸张地说，在应用统一过程思想指导软件开发过程中，用况的驱动作用贯穿整个软件生命周期。

　　用况驱动设计与 开发过程的思想，目前已被软件业内人士广泛接受，并越来越多地付诸于实践；而用况驱动思想在测试领域的实践中却并未得到应有的重视。我们的测试团队也经历 了一个对此思想逐步认知的过程，在工作实践中积累了一些相关的思路和方法，并且还在继续摸索，希望能对测试过程持续改进。

　　与传统系统测试用例设计相比，强调用况驱动的思想会体现出一定的优越性。

　 　首先，利于系统测试用例贴近用户需求。用况描述用户对系统的期望和真正的需求，这恰恰与系统测试的主要目标不谋而合。因此系统测试用例的设计由用况驱 动，以用况为输入，实现对用况的追踪与覆盖，是确保系统测试用例设计满足功能和场景覆盖，达到系统测试用例设计的质量要求的捷径。

　　其次，便于与其它小 组沟通，便于对用户需求实施追踪。若该项目的需求、设计、开发、维护等过程同样以统一过程思想、用况驱动的思想作为指导，则在整个项目内部更易形成沟通， 在该软件系统生命周期涉及到的各个产物之间能很容易的进行追踪。将以用况为指导形成的系统测试用例应用于测试活动，得到的测试结果直接体现用户需求的实施 情况。

　　二、用况驱动系统测试用例设计实践

　　用况是需求分析阶段的产物，系统测试用例的质量在一定程度上依赖于用况的质量，只有用况描述的真实、全面、易理解，系统测试用例才有可能达到相应的质量目标。

　　对于系统测试的分类，业界有很多种说法，不尽相同。最常见的包括：功能性测试、性能测试、回归测试等。下面将主要就功能性测试，说明用况驱动思想在其测试用例设计过程中的作用；同时说明用况驱动思想对性能测试和回归测试用例选取原则的影响。

　　1．功能性测试

　　（1）用况驱动功能性测试的组成

　 　传统概念中的功能性测试和性能测试主要是针对功能点进行的，这主要源于传统的软件功能相对单一、独立。当前软件发展趋势，越来越综合化、系统化、全面 化，软件系统越来越庞大、复杂，单一、割裂的功能点往往难以满足用户实际需求，将各功能点按用户实际使用场景，以不同的顺序组合起来，才能真正满足用户实 际应用的需要。换言之，用户的需求可以体现为一个个用况，而用况在系统中的实现则体现为功能点的有序组合。

　　第二种，可在同一张用况图中以分层的方式描述出功能点/场景（用况）-测试点-测试用例的逐级细化关系。例如图2，这是以用况图形式体现的用户权限管理部分的功能点-测试点的细化。

图2 用况图描述功能细化举例

　　第三种，可采用状态转移图、活动图、顺序图、协作图等方式或者将它们结合以对测试用例加以描述。

　　2）测试用例包的组织形式

　　描述测试用例包中测试用例的顺序和条件限制关系，并不拘泥于具体的形式。我们曾采用过两种方式，即表格形式和动图形式。

　　例如：前面提到的业务流程正常流转用况的测试用例以及相关功能点测试用例可以以下面的表格形式体现。

　　在活动图中，使用对子活动的嵌套，可以实现在当前测试用例中对其它测试用例的引用，从而方便的实现了测试用例间的组合重用，完成了测试用例包的组织。

　　2. 性能测试

　　广义上的性能测试一般包括常态下的性能测试、压力测试和负载测试等，而实际工作中经常遇到的性能测试往往是对典型用 户环境下使用情况的模拟，在此基础上所进行并发性和持续性压力测试，而并非考验系统极限值的测试。系统的性能指标和性能测试所遵循的都应该是“适度”原 则。系统性能指标优越，性能测试充分当然好，但是这是要付出高昂的代价的。实际上，实际而有效的性能测试也应该是由用况驱动的，是针对用户使用场景所设计 的，需要根据用户对各项指标所提出的明确需求，或者根据用户现场的实际情况，结合测试人员的经验设计出相应的性能测试方案和数据，并依照实施。

　　例如：一个正常情况下最多只有50个并发用户的系统，就没有必要进行1000个用户的并发测试，而一个每天夜间自动重起的系统，就没必要对其实施持续一周的负载测试。

　　3．回归测试

　　用况驱动的思想同样指导回归测试用例的选取。由于时间和成本的限制，每次回归测试，都将所有功能和场景重新测试一遍是不现实的，如何能既尽量降低风险，又提高测试效率呢？就需要在测试用例选取的过程中注意把握平衡。

　　回归测试用例的组织应该是分层次、分优先级的，基于用户最常用的场景的测试用例处于最高优先级。每次执行回归测试 时，基于软件修改所影响的范围，根据时间、人员、成本等因素，按照优先级次序抽取适量的相关测试用例，构造一个优化的测试用例组来完成回归测试，才是正确 的选择。

　　三、结语

　　用况驱动系统测试用例设计，是软件系统发展的需要，更符合软件生命周期的规律，广泛应用于功能性测试、性能测试、回归测试等各测试领域。用况驱动系统测试用例设计之路尚在探索之中，并无定式，在实践中不断尝试和改进才是提高测试用例设计水平、提高软件质量的正确途径。

　　上一篇关于测试用例设计的博文《设计测试用例的四条原则》中，介绍了设计测试用例的四条原则。本篇结合最近工作遇到的一个小插曲，介绍一下测试用例本身Passed和Failed的有效性问题。

　 　我所在的团队上个 Sprint有一项很重要的工作，就是进行Stress 测试，需要编写自动化用例测试模拟程序长时间的执行，并观察其内存消耗是否呈现合理的增长趋势，以及有没有内存的泄漏等问题。同事很快编写好了测试用例， 并执行了个把个小时，得出了初步的数据。数据显示程序的表现相当完美，不仅内存没有陡峭的突变，甚至连大斜率的线性增长也木有，基本呈现为一条略有波动的 水平直线。非常让人振奋，这样的表现打消团队之前的担心，完成这项工作所需的时间也将大大小于之前的预估。

　　我对这项测试也非常感兴趣， 并和同事进行了一些交流，想深入了解一些更详细的情况，比如测试数据规模、执行的时间长短、测试数据分布等，随着交流的深入同事突然意识到似乎测试代码似 乎有些不大合乎常理的表现，进一步调试发现代码中一段生成数据的代码并没有正确生成数据，虽然测试仍在执行但输入的数据没有，测试只是在空转，并没有真正 执行被测程序的逻辑，所以整个曲线才呈现为一条水平线。

　　这件事本身是个小问题，但其背后隐藏着一个值得我们深究的问题：当你的测试用例Passed的时候，被测产品果真是正确的吗？仔细想想这个问题，可以得到一些对我们的测试工作有意的思考：

　　1. 自动化测试需要有详细的日志输出，以便于诊断测试的确切执行情况。

　 　自动化测试用例的执行过程对我们来说是一个黑盒过程，我们一般只是看到它的结果是Passed或者Failed。如果这个黑盒过程本身就是错误的，如本 文一开始所给出的例子，结果是Passed就没有任何意义了。而且这样的Passed只会是给问题雪上加霜，减少了发现问题的可能性。

　　2. 测试人员特别是自动化测试工程师，应该对那些看似完美的东东多些疑问，多些探究精神，在经过客观途径验证之前时刻保持谨慎的乐观。

　　从某个角度讲，经常Failed测试用例并不值得你太担心，而那些从来都是Passed的用例，应该是值得你抽时间检查的对象。

　　3. 测试用例要么Passed要么 Failed，看似简单的结果，但其中还是有些值得深究的内容的。

　 　任何一个测试用例实际上是肩负着双重责任： 其一，保证在被测功能正确的情况下，测试用例应该是Passed；其二，则是在被测功能异常的情况下，测试返回Failed。一般的情况下，我们只是验证 了第一种情况后就算完成，并将用例提交到用例管理库或者代码库中。很少真正有人去验证一下在被测试功能异常的情况下，测试用例确实Failed。这样的用 例验证可以总结为如下的模式：

　 　之所以会有这样的情况，首先，是因为从意识上讲，大多数人都认为测试中对被测功能行为的判断以足够强壮，但其实这种没有客观佐证的判断并不可靠；其次， 很多用例的实现和执行多是在被测功能实现之后才开始，这时的被测功能刚实现出来，并经过开发人员反复调试修改，绝大多数情况下都是正确的，由于产品代码已 经提交，此时很难再有简单的途径模拟出错误的功能行为，以验证测试用例Failed的情况。

　　解决的办法有两种：一、尽可能寻找途径去模拟被测功能的异常；二、再就是合理选择实现测试用例的时间。很多情况我们的用例是为了覆盖已有的Bug而添加的，以避免回归缺陷。这样的测试用例最好是在Bug修复之前就实现，那么它一定是Failed，这个机会就可以验证出Failed情况。

　　扩展一下这个话题，从用例Failed/Passed路径这角度上看，测试驱动开发（Test Driven Development，TDD）的模型更为合理和自然。因为，TDD强调先有测试用例，再实现产品功能代码，先实现的测试用例必然是经过一系列的Failed之后，最终达到Passed，其模型可以总结如下：

　　TDD的原理保证了测试用例一定是由Failed开始，到Passed结束，所以不用费心去模拟功能异常以得到Failed结果，同时保证了用例对Failed和Passed都一定进行了验证。

　　4. 产品的质量有测试来监控，那么谁来监控测试本身的质量呢？人、过程和工具。

　　人－测试人员需要更有责任心，保持对任何问题的谨慎乐观和探究精神；过程－测试计划和用例的交叉评审，测试代码也要进行review，同时选择合理的时机实现测试；工具 – 利用代码覆盖来探究测试用例有效性。

　　总之，我们在编写和实现测试用例的时候，除了实现基本功能之外，还要多留意的用例（特别是自动化用例）Passed和Failed有效性，经常容易被忽略地是Failed有效性，所以要尽可的寻找途径来验证其有效性。

　　1、等价类分法的基本概念

　　等价类分法是将测试空间划分成若干个子集，并且满足每个子集中的任一数据对揭露程序中的缺陷都是等价的，这些子集就叫做等价类或者叫等价子集。

　　比如一个程序的输入数据满足   0<x<100为有效数据，其他为无效数据，那么就可以划分成两个等价类，一个是有效数据的等价类，另一个是无效数据的等价类，设计测试用例时就可以从这两个等价类中分别取一个输入数据来得到两个测试用例。有效数据的等价类为1～99，所以可以从1～99中任意取一个数作为输入数据来作为一个测试用例，从x不等于1～99中的数据中任意取一个数据作为输入数据得到另一个测试用例。

　　1～99中的任一数据和其他数据都是等价的，比如使用了2来进行测试，那么可以假定数据2测试通过的话，1～99中的其他数据也能测试通过。

　　等价类分法可以用来对一些不能穷举的集合进行合理分类，从各个等价类中选出有代表性的数据进行测试，从而保证设计出来的设计用例具有一定的代表性和一定范围内的完整性，有效地缩减测试用例的数量。

　 　等价类实际上是符合测试空间划分原则的一种特殊划分形式，即划分完后的子集里的可测数据是等价的，而测试空间划分原则则是要求里面有一个可测数据测试通 过能够代表其他测试数据在满足选取概率条件下也都可以通过。等价类选取测试数据时可以选取等价类中的任意数据作为测试数据，而测试空间划分原则划分的子集 一般是选择指定的数据作为测试数据，如果按测试空间划分原则划分后的子集刚好成为了等价类才可以选择里面的任一数据作为测试数据。

　　2、等价类的几种类型

　　在现实情况中，由于缺陷的可能情况非常多，一个子集中的数据对某种缺陷是等价的，但对另外一种缺陷可能又是不等价的。所以把等价类分为弱等价类、强等价类、理想等价类三种类型。

　　1）弱等价类

　　弱等价类是考虑某个单一缺陷情况下的等价情况，子集里所有数据在这种缺陷假设下是等价的，并且划分成的几个等价类能够覆盖整个测试空间的单一缺陷。比如以下一段程序：

　 　我们可以将数据划分为两个等价类，0~10为1个等价类，大于10的数据为1个等价类，在考虑“>”号误写成“<”号这种缺陷的情况下，这 两个等价集中的数据都是等价的，比如0～10这个等价类中，使用0或使用10来进行测试都能发现缺陷。这两个等价类中各自抽取一个测试数据进行测试，都能 代表其他数据揭示出“>”号误写成“<”号这种缺陷来，因此整个测试空间都被覆盖了。

　　2）强等价类

　　强等价类是在多个缺陷假设前提下，各个等价类中的可测数据在单个或多个缺陷假设下是等价的，并且划分的各个等价子集中各自取一个测试数据可以覆盖整个测试空间的多个缺陷情况。

　 　再考虑前面弱等价类中的例子程序，出错的可能性有那些呢？除了大于号会错写成小于号外，实际上还有可能写成大于等于号，10有可能写成1或100等大于 10或小于10的数，为方便描述以错写成1和100为例，事实上错误成其他数和错写成1和100是等价的。这样将各种可能出错的情况组合起来，程序中的判 断条件有可能有以下12种情况：

　　考虑0～10这个集合，在误写成中间一列条件中情况下，里面的数据并不等价，比如误写成x>1的情况下，使用1做测试和使用2做测试揭示缺陷是不同的，使用1做测试发现不了缺陷，但使用2测试就能发现缺陷。

　　在判断条件误写成x>=10条件下，10和0~9中的任一数据也不等价，并且使用大于10的数据也无法揭示出条件错写成x>=10这个缺陷，因此整个测试空间的多个缺陷无法被已划分的两个等价类来覆盖，10需要单独划分成一个等价类。

　 　这样将数据划分成三个等价类{0～9}、{10}、{大于10的数据}，再看看这三个等价类是否可以覆盖表中各种出错情况，显然在x>100和 x>=100两种情况下，大于10的数据集合中的数据是不等价的，使用大于100的数据不能揭示出缺陷，但使用大于10小于100的数据却能揭示出 缺陷，因此需要对大于10的数据再划分等价类，实际上只要将边界值{11}划一个单独的等价类就可以了。

　　这 样总共得到四个等价类{0～9}、{10}、{11}、{大于11的数据}，从这四个等价类中各取一个数据的话就可以将以上列出的所有可能的缺陷情况都揭 示出来，但是各个等价类并不是对所有缺陷都等价的，这种划分的等价类由于可以将各种缺陷情况覆盖到，把它叫叫做强等价类。

　　一、测试用例设计概述

　　测试伴随在整个手机软件开发的各个阶段中，测试质量的高低直接关系到手机软件的可用性，友好性，可靠性。可以说，测试环节是手机软件开发的重要环节，是整个开发过程的“中枢神经”。同时，测试用例的设计在测试过程中是非常重要的一个环节，是重中之重。

　　一般来说，设计测试用例应该考虑如下几方面：

　　1）有效性：测试用例是测试人员测试过程中的重要参考依据。不同的测试人员依据相同的测试用例所得到的输出应该是一致的。

　　2）可复用性：良好的测试用例具有重复使用的功能，使得测试过程事半功倍，设计良好的测试用例将大大节约时间，提高测试效率。

　　3）易组织性：即使是很小的项目，也可能有几千甚至更多的测试用例，测试用例可能在数月甚至几年的测试过程中被创建和使用，正确的测试计划会很好地组织这些测试用例并提供给测试人员或者其他项目的人参考和有效的使用。

　　4）可评估性：从测试的项目管理角度来说，测试用例的通过率是检验代码质量的保证。经常说代码的质量不高或者代码的质量很好，量化的标准应该是测试用例的通过率和软件错误（bug）的数目。

　　5）可管理性：测试用例也可以作为检验测试人员进度、工作量以及跟踪/管理测试人员的工作效率的因素，尤其是比较适用于对于新的测试人员的检验，从而更加合理做出测试安排和计划。

　　二、手机软件测试用例设计分析

　　通常手机软件测试用例可以分为如下几类：

　　1）基本功能测试用例设计

　　基本功能是指手机软件向手机用户提供的最小的、可以进行的所有简单操作的集合。

　 　基本功能测试是指测试工程师在被测试的手机上进行实际操作，来验证操作是否可行，操作的结果是否满足设计要求，如果不满足，就要报告错误。具体的操作例 如：接电话，打电话，发送普通短信，接收普通短信，发送彩信，接收彩信，播放静态音乐文件（mp3），播放一段视频文件，等等。

　　以“短消息SMS”功能为例，基本功能测试的用例可以从如下方面进行考虑：

　　测试系统包括客户端仿真平台以及与客户端仿真平台连接的统计模块，通过在客户端仿真平台中模拟并向被测彩信中心系统发送基于MM1，MM3，MM4或MM7接口的彩信业务，通过统计模块对运行结果进行统计显示，实现了对MMSC上的各个接口的处理性能的有效分析。

　　1. 引言

　 　随着彩信业务的发展迅速，其用户数量不断增长，对彩信业务系统的性能也提出了很高的要求。彩信业务在实际网络环境中的系统结构图（见图1）主要包括多媒 体信息中心（MultimediaMessageServiceCenter，简称MMSC，通常又称为彩信中心）、MMS终端用户UA，Push代理网 关PPG、外部邮件（ExternalE-mail）服务器SMTP、增值业务提供商VAS。这些设备可以互为客户端或服务器端，即发送方或接收方。

　 　对于一个MMSC而言，体系架构中一般包含了MM1/MM3/MM4/MM7各个接口信息的处理，包括来自终端用户（MO）的MM1接口信息，来自 VASP下发的MM7接口信息，来自外部邮件（ExternalE-mail）服务器smtp的MM3接口信息以及来自其他MMSC的MM4接口信息。

　 　为了衡量MMSC是否能够承载移动商用网业务以及突发高峰时段对MMSC的影响，保证移动运营商的服务质量，需要获知MMSC上的各个接口的处理性能。 然而，目前国内外包括一些国际标准化组织尚未对MMSC上的各个接口的处理性能进行有效的分析，例如OMA组织一般仅侧重于通信协议进行分析，并没有针对 MMS系统的性能进行测试。本文提出了一种彩信中心系统性能测试系统，包括客户端仿真平台、统计模块和服务器端仿真平台。本文还提出了彩信系统性能测试方 法，并给出了彩信系统不同信息传递流程的具体测试方法和步骤。

　　2. 彩信中心性能测试系统

　 　图2是彩信中心系统性能测试系统组成图：客户端仿真平台用于模拟彩信发送端并向被测彩信中心系统发送彩信测试消息，测试被测彩信中心接口MM4的处理性 能。统计模块与该客户端仿真平台连接，用于统计及显示该客户端仿真平台发送和接收的信息。服务器端仿真平台通过被测彩信中心系统与客户端仿真平台连接，用 于模拟彩信接收端接收被测彩信中心转发的彩信。加入服务器端仿真平台后，本系统可以测试被测彩信中心更多接口的处理性能。

　 　客户端仿真平台模拟包含MM1/MM3/MM4/MM7各个接口的客户：信息发起终端（MO）模块用于模拟终端用户（UA）和WAP网关（WG）；E- mail客户端（SMTP）模块用于模拟E-mail客户端发送E-mail信息到MM3接口；彩信中心仿真模块用于模拟彩信中心客户端从MM4接口向被 测的彩信中心发送MM4-Forward信息；增值应用服务商客户端（VAS）模块用于模拟增值应用服务商客户端发送MM7接口信息。

　　 服务器仿真平台模拟各个接口的服务器端，包括：PPG模块直接与彩信中心的MM1接口进行通信，用于处理彩信中心的PUSH信息；E-mail服务器端 （SMTP）模块用于模拟E-mail服务器端从MM3接口接收E-mai信息并且处理接收到的信息；用户接收终端（MT）模块用于接收来自PPG转发的 彩信；增值应用服务商服务器端（VAS）模块用于模拟增值应用服务商服务器端接收并处理MM7接口信息。MMS系统性能测试主要包括 MM1，MM3，MM4，MM7四个接口的协议处理。

　　本系统通过模拟实现MMSC四个接口的所有彩信发送和接收流程以及各个接口之间的 信息交互，即通过彩信中心接收来自各个接口的信息，并且同时通过各个接口下发彩信信息，真实仿真现网各种业务流程，并对收发信息进行统计显示，从而得出彩 信中心系统的处理性能参数，实现对彩信中心系统性能的有效测试。本系统将被测MMSC独立出来，完全脱离除被测MMS中心以外的其他网络设备，用客户端仿真平台和服务器仿真平台模拟了除被测MMS中心以外和MMS中心交互的网络设备（如WAP网关和PPG），以保证测试结果的正确性。

　　1）走通性能测试流程，从造数据到测试，可以走通，方可交由测试同学。毕竟开发（相对性能测试人员而非功能测试）对业务逻辑更了解一些。

　　2）测试一些显而易见的bug；

　　3）建立性能方面的信心；

　　4）可在测试的同学做完测试以后做一个对比，不至于偏离太过离谱。

　　参照测试部门的意见，我把这次的性能测试总结了如下几个步骤：

　　1、测试目标和范围：根据需要满足的非功能需求，确定上线功能点哪些需要测试。测试性能、稳定性、最大压力。

　　2、测试方案准备：包括施压方式，环境配置，环境依赖，资源监控，整理方案文档。

　　3、环境准备：准备压力测试环境，一般是压力测试机配置，压力测试数据库配置。

　　4、数据准备：根据线上预估数据，对数据库数据进行准备和模拟。

　　5、测试准备：包括需要编写的程序，如其他系统间依赖可写mock程序。另外编写jmeter的测试计划等。尝试测试，并确保一个请求或处理过程能顺利通过。

　　6、进行测试：通过客户端施压服务器，监控器各方面资源利用。

　　7、进行测试分析总结：写测试报告。TPS，吞吐量，CPU占比等。对异常现象记录，如内存溢出等。

　　8、根据测试报告对程序进行优化或重构。

　　做技术还是有做技术的天性，我们开发最关心的也就是5-8的步骤。我们的应用主要以hessian接口的形式向外面暴露，另外的就是任务在后台处理接口推送过来的数据。所以，我们的测试主要集中在接口测试和任务测试。比一般网页的性能测试更简单一些。

　　我们选用的施压客户端是开源的jmeter，文档较为丰富，且操作极为方便，扩展性好。服务器端性能监控工具，均采用linux的shell命令和jvm自带的工具或命令。jvm的工具已经够强大了，测试团队也是利用linux的命令采集服务器端资源，然后把消息发送到自己编写的一些资源监控工具上，其实都是利用了原生的shell命令和jvm命令来周期性采集并绘图的。

　　JMeter没有现成的sampler施压hessian的接口，所以我们需要利用它极具扩展性的java请 求sampler来施压hessian接口。我们查看jmeter安装目录下的lib>ext下可以发现其他多种类型的sampler。其他的种类 都可以由javasampler来实现。我们只需要继承org.apache.jmeter.protocol.java.sampler. AbstractJavaSamplerClient该类，在runTest方法中调用hessian接口，并封装返回值即可。然后把工程打成jar包， 放到jmeter安装目录下的lib>ext下。启动jemter，在利用javasampler就可以定为到我们编写的扩展测试程序了。

　　在压力测试过程中，包括两部分的资源检测，jvm的资源占用。一般利用jdk自带工具集

　　1、jps

　　常用的几个参数：

　　-l输出java应用程序的mainclass的完整包

　　-q仅显示pid，不显示其它任何相关信息

　　-m输出传递给main方法的参数

　　-v输出传递给JVM的参数。在诊断JVM相关问题的时候，这个参数可以查看JVM相关参数的设置

　　2、jstat-JavaVirtualMachineStatisticsMonitoringTool

　　jstat[Options]vmid[interval][count]

　　Options--选项，我们一般使用-gcutil查看gc情况还有其他选项如：

　　-class-compiler-gc-gccapacity-gccause-gcnew-gcnewcapacity-gcold-gcoldcapacity-gcpermcapacity-gcutil-printcompilation

　　vmid--VM的进程号，即当前运行的java进程号

　　interval--间隔时间，单位为毫秒

　　count--打印次数，如果缺省则打印无数次

　　-----------------------------------------------jstat-gcutil[pid]输出解释

　　S0--Heap上的Survivorspace0区已使用空间的百分比

　　S1--Heap上的Survivorspace1区已使用空间的百分比

　　E--Heap上的Edenspace区已使用空间的百分比

　　O--Heap上的Oldspace区已使用空间的百分比

　　P--Permspace区已使用空间的百分比

　　YGC--从应用程序启动到采样时发生YoungGC的次数

　　YGCT--从应用程序启动到采样时YoungGC所用的时间（单位秒）

　　FGC--从应用程序启动到采样时发生FullGC的次数

　　FGCT--从应用程序启动到采样时FullGC所用的时间（单位秒）

　　GCT--从应用程序启动到采样时用于垃圾回收的总时间（单位秒）

　　云计算数据中心的网络测试主要包含虚拟化测试、安全测试、高可靠测试和性能测试四 个部分。前三者重点在于对数据中心网络的功能设计进行测试验证，性能测试则是度量整个云网络的关键，用以确认其能够提供的服务能力基线。云计算技术目前很 多应用在大型的高性能计算（超算）数据中心中，在此类数据中心内部，性能处于业务保障的第一关键位置。本文重点关注性能测试的部分，从测试设计方面进行探 讨。

　　测试设计

　　数据中心网络性能测试手段很多，业务仿真测试是最能体现实际应用情 况的测试方法。业务仿真测试往往需要利用大量服务器和存储设备，通过部署仿真应用环境来测试网络针对此类型应用的转发性能。但此方法受成本和测试复杂度影 响，一般只在超大型且应用较为单一的数据中心测试时使用，如百度/SOHU搜索业务仿真、QQ/MSN实时通讯业务仿真、石油勘探/气象预报计算业务仿真 等。

　　除了上述专用测试方法外，还可以通过测试仪器模拟一些基本的应用流量来测试其主要性能。此方式由于实施简便、通用型强，在数据中心 网络性能测试中应用较多。受当前整个Internet应用使用情况影响，测试仪模拟的网络应用以TCP的HTTP为主，有时会根据具体的实际业务情况添加 Mail、FTP和HTTPS进行补充，这种测试设计也符合当前云计算数据中心的实际应用情况。

　　测试环境

　　在测试数据中心网络性能时，通常使用成对的测试仪器端口，连接到数据中心网络两端，将整个网络视为黑盒进行端到端的性能结果测试。典型测试组网设计如图1所示。

图1   数据中心性能典型测试组网

　 　图1中的数据中心网络结构采用典型的3层双冗余结构。核心层设备采用高端交换设备进行三层路由转发，其与汇聚层设备间通过OSPF动态路由协议互连，以 提供多路冗余保障，同时通过只发布缺省路由到汇聚层设备的方式来减轻汇聚层设备的路由压力；汇聚层设备作为模拟服务器设备的网关提供三层转发功能，使能 VRRP等网关冗余协议来保证双机热备，并通过VLANTRUNK方式与接入层设备相连；接入层设备部署为二层转发模式，通过MSTP协议确保多VLAN 环境下的冗余链路备份功能。

　　测试仪器通过多个接口分别与核心层设备和接入层设备连接，并模拟Client和Server进行有状态的流量转发性能测试。测试模拟的协议类型尽量与使用环境贴近，最常见的是使用HTTP协议进行基于L7的业务流量模拟。

　　另外为了确保数据中心测试的仿真度，还需要模拟大量的路由、VLAN和流数量。例如测试的为一个大型的企业云数据中心，则需要定义以下背景环境参量：

　　1. 首先设置背景路由，在核心设备上模拟发布1万条OSPF散列路由，其发起源为50个Router，路由模拟调配比例为NetworkLSA：SummaryLSA：ExternalLSA=1：3：16

　　2. 然后设置背景VLAN与模拟服务器，在汇聚层与接入层设备上部署8个MSTP的Instance，每个Instance中包含8个VLAN，使用测试仪器在每个VLAN中模拟100个HostServer，总共64个VLAN，6400个Server。

　　3. 最后构造测试流量，定义1万个Client源IP地址一一对应到模拟的1万条散列OSPF路由中，目的IP地址64个，分别为模拟的64个VLAN中每个VLAN随机抽取的各一个HostServer地址。总共为64万条IP测试流。

　　上述测试参数定义均可通过测试仪器配置完成。

　　当测试环境部署完毕后，即可使用测试仪器进行整网性能指标的测试执行工作。

　　举例：期望的网络并发数为300万，使用1千CPS的速率进行新建，则需要将测试仪器的会话回应等待时间调整至 3，000，000/1，000=3000s才能得到接近期望的测试结果，而如此长的会话保持时间对网络中间设备来说属于并不符合实际网络业务模型的处理 方式。

　　因此正确的测试方法是，先测试出中间网络的极限CPS能力，然后取中间设备稳定运行时（如CPU使用率在60％）能够处理的新建速率，再根据并发数期望测试结果计算出测试仪的会话回应关闭等待时间，通过调整此时间测试出实际的设备并发数处理能力。

　　举例：先测试出的网络新建速率极限值为20万CPS，CPU稳定在60％时的最大新建速率值为15万CPS，期望的最大并发数为300万，则在 测试并发数时设置测试仪器的新建速率为15万CPS，会话回应关闭等待时间为20s上下调整，以确认网络能够达到的实际最大并发数。

　　L4并发数测试配置需要注意以下几点：

　　1. 根据网络L4新建速率测试结果，设置稳定的新建速率参数和会话回应关闭等待时间参数。

　　2. 可以适当调整TCP会话关闭方式，以减少中间网络设备压力，如采用Reset方式关闭。

　　3. 同新建速率测试一样，设置HTTP载荷为尽量小值（如64byte），并将每个TCPConnection中的HTTPTransaction数量设置为1，减少对测试结果的干扰。

　　4. 将整个测试周期时间设置为一个较长值（如3600s），同步验证网络的稳定性。

　　5. 测试前中后的整个过程中记录网络主要设备的关键性能指标，进行比较确认。

　　L4并发数测试结果体现了整网会话保持与表项存储的能力，与网络中L4-L7处理设备的内存大小有直接关系。这里的内存大小依据各个厂商设备实现的不同也指DRAM、接口内存和CAM等TCP会话表项存储单元容量。TCP并发数与内存使用大小的线性关系如图3所示。

　　图3  L4并发数结果与网络设备Memory使用率关系示意图

　　L7吞吐量测试

　　L7吞吐量指当前网络可以有效传输的最大HTTP数据量，也被称为有效吞吐GoodPut，区别于传统意义上的测试指标L3吞吐量ThroughPut，结果单位为BPS（BytePerSecond）。

　　L7吞吐量测试结果很大程度上依赖于L4新建速率能力，其间关系类似于传统L3吞吐量BPS（BitPerSecond）与网络设备包转发能力 PPS（PacketsPerSecond）之间的关系。在测试L7吞吐量的过程中，首先测得网络的新建速率，然后将新建速率测试结果乘以一定比率系数 （例如80％），作为L7吞吐量测试中使用的的稳定新建速率参数始终不变，测试时逐步提高HTTP有效载荷大小，通过观察出现HTTP连接出现失败前的有 效载荷最大传输速率，得到其L7吞吐量测试结果。

　　举例：采用的稳定持续新建速率为20万CPS，能够无失败传输的最大有效载荷值为500Byte，则系统的L7吞吐量为100MBPS（BytePerSecond）。

　　在L7吞吐量测试中还需要注意的是可以适当提高每TCPConnection中的HTTPTransaction数量，如采用1：10的比例， 这样能够进一步提高L7吞吐量测试结果。但需要注意采用多Transaction方式时，需要将测试仪器上的HTTP协议类型设置为HTTP1。 1，HTTP1。0协议不支持此种传输加载方式。

　　L7吞吐量的测试结果除了受L4新建速率的直接影响外，还会受到网络中各设备的交换架构、接口总线等元件单位间处理能力的限制，其测试结果也直接体现了整个网络的应用数据吞吐转发能力。

　　L7响应时间测试

　　L7响应时间指从客户端发起http请求，到得到正确数据响应所经历的时间，一般用来衡量中间网络的综合处理能力，单位为毫秒。

　　L7响应时间与L7延迟时间的主要区别是：延迟时间指客户端发出报文到服务器接收到此报文或反向发送接收的间隔时间；响应时间则指的时一个完整 连接的客户端于服务器报文来回交互过程时间。在数据中心网络中，响应时间可以更好的表现出整个网络对有状态的流量处理能力，在HTTP这种需要客户端与服 务器进行反复交互的应用协议使用中尤为重要。

　　响应时间的测试方法主要有两种：一种是基于真实服务器的业务响应时间测试，此测试结果包含了中间网络设备与服务器两部分处理延迟时间；另一种是 通过测试仪模拟服务器快速响应请求的测试，这种测试方法可以尽量减少服务器端处理延迟的影响，得到近乎纯粹的网络处理延迟时间。

　　L7响应时间测试要在一定的新建速率下进行，这样做也是为了尽量贴近实际网络情况。但此测试中的新建速率需要维持在一个较低的水平线上，最好是根据真实环境平均值设定，这是因为新建速率较高时会导致CPU资源占用较高，影响设备对连接的处理能力。

　　常用测试工具

　　使用专用测试工具测试数据中心网络性能时，可以采用软件与硬件两类。

　　软件测试工具指需要运行在例如UNIX、Linux和Windows等开放的操作系统及通用的硬件架构上，并且只需对现有系统做出微小甚至不做改动就能够完成测试任务的软件。

　　部分性能测试软件如下：

　　HTTP–HTTPLOAD，WebServerStress，LOADRunner，WebBench，WebStone，SPECweb99

　　MAIL–Loadsim，Medusa（MicrosoftExchange），

　　DB-BenchmarkFactoryforDatabases，Jetstress，DBstress

　　IPSAN–IOmeter，Iozone，Bonnie++，dd

　　硬件测试工具指使用单独的硬件设备配合装载在PC上的控制软件完成测试工作，其性能要远优于一般的软件测试工具，但相对的缺点是价格较高和可扩 展性较差（功能升级有时需要对硬件产品进行改变，成本很高）。基于数据中心以应用为根本的网络流量特点，通常采用支持L7应用的测试仪器进行测试。目前主 流的测试仪器厂商有Spirent、IXIA和BreakingPoint等。

　　在云计算数据中心网络性能测试中，如果需要更好的仿真业务应用，建议采用软件集群服务器安装测试方式；如果希望得到最大的极限能力，建议采用硬件测试仪器来进行测试。

　　结束语

　　在数据中心网络性能测试中，还有以下一些常用经验可以在测试设计和执行中进行参考：

　　1. 当测试模拟的流量越接近真实网络，测试环境就需要越复杂。

　　2. 永远不能通过测试设计去完全的模拟真实网络环境。

　　3. 没有任何两个测试环境是完全相同的，因此所有测试结果只有参考性，不具标准性。

　　4. 不同的网络环境体现不同的流量模型，最好的不见得是最适合的。

　　5. 数据中心性能测试结果永远向网络中性能最差设备指标看齐。

　　6. 所有测试之前一定先要进行测试工具的自测试，了解其能力限制。

　　云计算数据中心的广泛部署是一个持续渐进的过程，而基于云计算数据中心的测试是使其大范围推广的关键保障。做好云计算数据中心网络的测试设计和 执行，可以更好的了解当前网络设计的能力范畴，以便更准确的应对基于云计算技术的应用业务需求，为云应用提供更好的通道架构服务。