《软件测试》课件

软件测试第八

章8.1软件测试的基本概念一、软件测试的目的和重要性因为开发工作的前期不可避免地会引入错误，测试的目的是为了发现和改正错误，这对于某些涉及人的生命安全或重要的军事、经济目标的项目显得尤其重要。软件测试是软件开发过程中保证软件质量、提高软件可靠性的最主要的手段之一，是在软件产品交互用户使用之前，对分析、设计、编码等开发工作的最后检查和复审，及时发现并校正错误。测试的根本目的就是发现尽可能多的缺陷。测试：测试由测试员完成。调试：调试由程序员完成。1963年美国飞往火星的火箭爆炸，原因是FORTRAN程序：DO5I=1，3误写为：DO5I=1.3损失1000万美元。1967年苏联“联盟一号”宇宙飞船返回时因忽略一个小数点，在进入大气层时打不开降落伞而烧毁。测试的目标以最小的工作量和成本，尽可能多地发现软件系统中潜在的各种错误和缺陷，以确保软件系统的正确性和可靠性。二、软件测试的特点1、软件测试的开销大 按照Boehm的统计，软件测试的开销大约占总成本的30%-50%。例如：APPOLLO登月计划，80%的经费用于软件测试。2、不能进行“穷举”测试 只有将所有可能的情况都测试到，才有可能检查出所有的错误。但这是不可能的：例：程序P有两个整型输入量X、Y，输出量为Z，在32位机上运行。所有的测试数据组（Xi，Yi）的数目为：2

2=21毫秒执行1次，共需5亿年。323264PXYZ3、软件测试难度大 根据上述分析，既然不能进行

“穷举”测试，又要查出尽可能多的错误，软件测试工作的难度大。只有选择— “高效的测试用例” 什么是“高效的测试用例”？ 如何选择“高效的测试用例”？ 这就是本章讨论的主要问题！！！三、软件测试的基本原则1、应尽早地和不断地进行软件测试。2、尽量不由程序设计者进行测试，采用独立测试。开发者总以为程序正确开发者对程序功能、接口十分熟悉，使用不会出错开发者对程序的珍爱心理3、关键是注重测试用例的选择。 输入数据的组成（输入数据、预期的输出结果）既有合理输入数据，也有不合理的输入数据。用例既能检查应完成的任务，也能够检查不应该完成的任务。长期保存测试用例。测试用例的质量可以由以下四个特性来描述：有效性：能否发现软件缺陷或至少可能发现软件缺陷；可仿效性：可仿效的测试用例可以测试多项内容，从而减少测试用例数量；经济性：测试用例的执行分析和排错是否经济；修改性：每次软件修改后对测试用例的维护成本。四个特性之间会有影响，如可仿效性有可能导致经济性和修改性较低。因此，通常情况下，应对上述四个特性进行一定的权衡折衷。4、充分注意测试中的群集现象。群集现象是指，在测试过程中，发现错误比较集中的程序段，往往可能残留的错误数较多。因此必须注意这种群集现象，对错误群集的程序段进行重点测试，以提高测试投资的效率。5、避免测试的随意性，制定详细、完善的测试计划（包括测试范围、测试方式、测试成本、测试工作量、测试时间等）、严格执行测试计划。6、全面检查每一个测试结果。7、妥善保管测试过程中的一切文档，为软件维护提供方便。测试计划、测试用例、测试结果、出错统计等都是软件测试的重要文档。另外，Davis也提出了一组测试原则，在设计有效地测试用例时必须理解。⑴所有的测试都应根据用户的需求来进行。⑵应该在测试工作真正开始前的较长时间内就进行测试计划（测试规划）。一般而言，测试计划可以在需求分析完成后开始，详细的测试用例定义可以在设计模型被确定后立即开始。因此，所有测试可以在任何代码被编写前进行计划和设计。⑶Pareto原则应用于软件测试。Pareto原则意味着测试发现的错误80%的很可能集中在20%的程序模块中。⑷测试应从“小规模”开始，逐步转向“大规模”。即从模块测试开始再进行系统测试。⑸穷举测试是不可能的，因此，在测试中不可能覆盖路径的每一个组合，然而，充分覆盖程序逻辑，确保覆盖程序设计中使用的所有条件是有可能的。⑹为达到最佳的测试效果，提倡由第三方来进行测试。四、软件测试的过程软件测试的过程图测试的基本步骤模块测试整体测试功能测试预测试系统测试验收测试安装测试概要设计审查详细设计审查代码审查测试(单元测试）（组装测试）（有效性测试）（确认测试）{{软件测试文档1、测试计划2、测试规范3、测试用例4、缺陷报告3、软件测试文档模块测试报告至少选择一个典型模块进行测试。A、综合测试策略（静态分析、白盒法为主，辅以黑盒法）B、测试情况（根据覆盖标准列出）C、测试用例（保留）D、查错记录（数量、位置）、分析结果。组装测试报告A、组装次序、测试方法（以黑盒法为主）B、测试情况C、测试用例（保留）D、查错记录（数量、位置）、分析结果。功能测试与系统测试与上类似。8.2软件测试方法软件测试方法分为两类：静态分析、动态测试一、静态分析方法指以人工的、非形式化的方法对程序进行分析和测试，并不运行程序。桌前检查（DeskChecking）由程序员检查自己的程序，对源代码进行分析、检验。代码会审（CodeReadingReview）由程序员和测试员组成评审小组，按照“常见的错误清单”，进行会议讨论检查。步行检查（Walkthroughs）最常用的静态分析方法。与代码会审类似，也要进行代码评审，但评审过程主要采取人工执行程序的方式，故也称为“走查”。①调用图

无论Y为何值，都不能够调用子程序。 READYY>0NX:=YX<0YNY调用子程序ABCDE即执行ABC后，是不可能执行路径CDE的。步行检查时，还常使用以下分析方法：①

调用图 从语义的角度考察程序的控制路线。②数据流分析图 检查分析变量的定义和引用情况。②数据流分析图节点—表示单个语句。有向边—表示控制结构。

d—定义

r—引用

u—未引用R：duuuuuS：uruuurY：uuddru R=0.5W=1/SY=A**WY=E*WZ=X+YC=Z*S123456只定义不用未定义引用连续定义二、动态测试方法（1）通过选择适当的测试用例，执行程序。常用的方法：1、白盒法 又称结构测试、逻辑驱动测试或基于程序的测试。分析程序的内部逻辑结构，注意选择适当的覆盖标准，设计测试用例，对主要路径进行尽可能多的测试。2、黑盒法又称功能测试、数据驱动测试或基于规格说明的测试，是一种从用户观点出发的测试。不考虑程序的内部结构与特性，只根据程序功能或程序的外部特性设计测试用例。白盒法

白盒法又称为逻辑覆盖法，因为要以程序（模块）内部的逻辑结构为基础来设计测试用例，主要用于单元测试。测试的关键也是如何选择高效的测试用例，其测试用例选择，是按照不同覆盖标准确定的。语句覆盖判定覆盖条件覆盖判定条件覆盖条件组合覆盖弱强发现错误能力①语句覆盖：选择足够的测试用例，使得程序中每个语句至少都能被执行一次。②判定覆盖：执行足够的测试用例，使得程序中每个判定至少都获得一次“真”值和“假”值。（每个分支）③条件覆盖：执行足够的测试用例，使得判定中的每个条件获得各种可能的结果。（至少满足一次）④判定/条件覆盖：执行足够的测试用例，使得判定中每个条件取到各种可能的值，并使每个判定取到各种可能的结果。⑤条件组合覆盖：执行足够的例子，使得每个判定中条件的各种可能组合都至少出现一次。白盒法常用的覆盖标准白盒法步骤：例：用白盒法测试以下程序段：Procedure（VARA，B，X：REAL）；BEGINIF（A>1)AND(B=0)THENX:=X/A;IF(A=2)OR(X>1)THENX:=X+1END;1）选择逻辑覆盖标准。2）按照覆盖标准列出所有情况。3）选择确定测试用例。4）验证分析运行结果与预期结果。逻辑结构A>1ANDB=0X:=X/AA=2ORX>1X:=X+1YNYN1、语句覆盖使得程序中每个执行语句至少都能被执行一次。A>1ANDB=0X:=X/AA=2ORX>1X:=X+1abcde满足语句覆盖的情况：执行路径：ace选择用例：[(2,0,4),(2,0,3)]用例格式：[输入(A,B,X)，输出(A,B,X)]YNYN2、判定覆盖使得程序中每个判定至少为TRUE或FALSE各一次。A>1ANDB=0X:=X/AA=2ORX>1X:=X+1abcde覆盖情况：应执行路径ace∧abd 或：acd∧abe选择用例(其一）：⑴[(2,0,4),(2,0,3)]ace[(1,1,1),(1,1,1)]abd⑵[(2,1,1),(2,1,2)]abe[(3,0,3),(3,1,1)]acdYYNN3、条件覆盖A>1ANDB=0X:=X/AA=2ORX>1X:=X+1abcde使得判定中的每个条件获得各种可能的结果。应满足以下覆盖情况：判定一:A>1,A≤1,B=0,B≠0判定二:A=2,A≠2,X>1,X≤1选择用例：[(2,0,4),(2,0,3)][(1,1,1),(1,1,1)]NNYY2A≤1A≠20B=04X>11A>1A=21B≠01X≤1注意:[(1,0,3),(1,0,4)] [(2,1,1),(2,1,2)]满足条件覆盖，但不满足判定覆盖。4、判定/条件覆盖 同时满足判断覆盖和条件覆盖。A>1ANDB=0X:=X/AA=2ORX>1X:=X+1abcde应满足以下覆盖情况：条件:A>1,A≤1,B=0,B≠0 A=2,A≠2,X>1,X≤1应执行路径ace∧abd 或：acd∧abe选择用例：[(2,0,4),(2,0,3)]（ace)[(1,1,1),(1,1,1)](abd)YYNN5、条件组合覆盖使得每个判定中条件的各种可能组合都至少出现一次。A>1X:=X/AA=2X:=X+1abcdeB=0X>1YNYNYNYN编译系统下的执行情况：部分路径未被执行。满足以下覆盖情况：①A>1,B=0②A>1,B≠0③A≤1,B=0

④A≤1,B≠0⑤A=2,X>1

⑥A=2,X≤1

⑦A≠2,X>1

⑧A≠2,X≤1选择用例：[(2,0,4),(2,0,3)]①⑤[(2,1,1),(2,1,2)]②⑥[(1,0,3),(1,0,4)]③⑦[(1,1,1),(1,1,1)]④⑧二、动态测试方法（2）等价分类法边值分析法错误推测法因果图法(2)黑盒法

不考虑程序的内部结构与特性，只根据程序功能或程序的外部特性设计测试用例。黑盒测试法注重于测试软件的功能需求，主要试图发现下列几类错误：功能不对或遗漏；性能错误；初始化和终止错误；界面错误；数据结构或外部数据库访问错误。1.等价分类法基本思想：根据程序的I/O特性，将程序的定义域划分为有限个等价区段—“等价类”，从等价类中选择出的用例，具有“代表性”。等价类分为：有效等价类—对于程序的规格说明，是合理的、有意义的输入数据构成的集合。无效等价类—对于程序的规格说明，是不合理的、没有意义的输入数据构成的集合。等价分类法步骤

应按照输入条件（如输入值的范围，值的个数，值的集合，输入条件必须如何）划分为有效等价类和无效等价类。例如：每个学生可选修1-3门课程可以划分一个有效等价类：选修1-3门课程。可以划分两个无效等价类：未选修课，选修课超过3门。①划分“等价类”

显然，关键是如何划分等价类A为每个等价类编号；B使一个测试用例尽可能覆盖多个有效等价类C特别要注意：一个测试用例只能覆盖一个无效等价类。②选择测试用例等价分类法步骤2.边值分析法

基本思想：选择等价类的边缘值作为测试用例，让每个等价类的边界都得到测试，选择测试用例既考虑输入亦考虑输出。

分析步骤：

A先划分等价类。

B选择测试用例，测试等价类边界。边界选择原则：

A按照输入值范围的边界。

B按照输入/输出值个数的边界。

C输出值域的边界。

D输入/输出有序集的边界。

A按照输入值范围的边界。例如：输入值的范围是-1.0至1.0，则可选择用例:–1.0、1.0、-1.001、1.001。

B按照输入/输出值个数的边界。

例如：输入文件可有1-255个记录，则设计用例：文件的记录数为0个、1个、255个、256个。

C输出值域的边界。

例如：检索文献摘要，最多4篇。设计用例：可检索0篇、1篇、4篇，和5篇（错误）。

D输入/输出有序集（如顺序文件、线性表）的边界。

应选择第一个元素和最后一个元素。边值分析法举例黑盒法应用实例

对FORTRAN编译系统中的DIMENSION语句进行测试。语句格式为：DIMENSIONad[,ad]…ad为数组描述符，形式为n（d[,]…其中：n－数组名，字母打头的字母数字串，长6。D为界偶（1-7个）：[ld:]ndld和nd的值为1-65535，ld缺省为1。输入条件合理的等价类不合理的等价类数组描述的个数1个（1）、多于1个（2）没有数组描述（3）数组名的字符数1—6个（4）0（5），>6（6）数组名有字母（7）有数字（8）有其他字符（9）数组名的第1个字符为字母是（10）不是（11）维数1—7（12）0（13），>7（14）上界常数（15）数组元素名（1640个等价类3.错误推测法 凭经验或直觉推测可能的错误，列出程序中可能有的错误和容易发生错误的特殊情况，选择测试用例。 把输入条件视为“因”，把输出条件视为“果”，将黑盒看成是从因到果的网络图，采用逻辑图的形式来表达功能说明书中输入条件的各种组合与输出的关系。根据这种关系可选择高效的测试用例。因果图是一种形式化语言，是一种组合逻辑网络图。因果图法的基本原理是通过因果图，把自然语言描述的功能说明转换为判定表，然后为判定表的每一列设计一个测试用例。4.因果图法（causeeffectgraphics）⑴因果图的基本符号 0-表示“不出现” 1-表示“出现” 恒等 若a为1，则b为1，否则b为0。 “非”函数

若a为1，则b为0，否则b为1。 “或”函数若a或b为1，则d为1，否则d为0。 “与”函数若a与b同为1，则d为1，否则d为0。abababd∨abd∧对“与”、“或”函数的限制符号

E约束（异）—排斥 即a、b不能同时为1。

I约束（或）—包容

a、b、c不能同时为0。

O约束（唯一）—选一

a、b中仅有一个为1。

R约束（要求）—需要

a为1时，b必须为1

M约束（强制）—屏蔽若a为1时，则b强制为1。abEabcIabRabOabM⑵因果图法的步骤

分析规范，即将问题分为若干可工作的步骤。标识出规范中的原因与结果。 原因—输入条件 结果—输出或系统变换将因果图转换为有限项判断表。将判断表的每一列，转换为一个测试用例。

分析规范语义、内容，转换为因果图。

⑶因果图法应用举例规范：文件名第一列字符必须为A或B，第二列字符必须为数字。满足则修改文件。第一字符不正确发出信息X12，第二个字符不正确发出信息X13。1.分析规范

原因 结果1—第一列字符为A 50—修改文件2—第一列字符为B 51—发信息X123—第二列字符为数字52—发信息X132.画出因果图中间结点 是导出结果的进一步原因。

考虑到原因1、2不可能同时为1，加上E约束。

1111∨5150352∧12E发X12发X13

修改文件3.将因果图转换为判断表

12345678条件原因①11110000②11001100③10101010111100动作结果000011101000010101测试用例A3A8AMA？B5B4BNB！C2X6DYPI11515052白盒测试与黑盒测试两类方法的对比条件组合覆盖等价分类法边界值分析法错误推测法因果图法8.3软件测试的步骤测试步骤及策略

所有测试过程都应采用综合测试策略；即先作静态分析，再作动态测试。并事先制订测试计划。测试过程通常可分4步进行：单元测试单元测试单元测试被测模块被测模块集成测试设计信息已测试的模块确认测试已集成的模块软件需求系统测试已确认的软件可交付的软件系统其他元素一、模块测试（ModuleTesting）1.测试内容模块模块接口测试局部数据结构测试重要路径测试错误处理测试边界条件测试I/O参数值的个数、类型、次序、格式是否正确，I/O文件属性、操作是否正确等。数据说明是否正确、一致，变量及其初值定义是否正确等。检查“错误处理程序”本身的错误。边界条件常包括循环边界，最大最小值、控制流中等于、大于、小于的比较值等。重要路径通常是指完成模块功能的主要路径，一般是控制结构。也称单元测试（unittesting)以白盒法为主2.模块测试步骤

考虑到被测模块与其它模块的联系，因此测试时需要使用两类辅助模块来模拟其他模块。

驱动模块（driver）—模拟主程序功能，用于向被测模块传递数据，接收、打印从被测模块返回的数据。

桩模块（stub）—又称为假模块，用于模拟那些由被测模块所调用的下属模块功能。

一般，驱动模块比桩模块容易设计。但都是额外开销。测试方法以白盒法为主。被测模块驱动模块桩模块桩模块桩模块二、组装测试（IntegrationTesting）1.组装测试的任务①确定模块组装方案，将经过测试的模块组装为一个完整的系统。组装方案分为渐增式及非渐增式。②测试方法以黑盒法为主，按照组装方案进行测试。 也称为联合测试或集成测试，重点测试模块的接口部分，需设计测试过程使用的驱动模块或桩模块。问题：渐增式与非渐增式各有何优、缺点？为什么通常采用渐增式？2.渐增式组装测试 渐增式是先进行模块测试，然后将这些模块逐步组装成较大的系统，每连接一个模块进行一次测试。两种方案：设计驱动模块或桩模块，对每一个新组装的子系统进行测试，对发现问题较多的子系统或模块应该用白盒法作回归测试。自顶而下增值自底而上增值自顶而下增值M1M4M3M2M6M5程序模块示意图S5M1S1S1S1S2S2S2S3S3S3第一步，测试主控模块M1设计桩模块S1、S2、S3，模拟被M1调用的M2、M3、M4。M2M3M4第二步，依次用M2、M3、M4替代桩模块S1、S2、S3，每替代一次进行一次测试。S4S4S4S5S5第三步，对由主控模块M1和模块M2、M3、M4构成的子系统进行测试，设计桩模块S4、S5。M5M6第四步，依次用模块M5和M6替代桩模块S4、S5，并同时进行新的测试。组装测试完毕。自底而上增值M3M6M5D1D2D3D1D1D2D2D3D3M2M4M1第四步，把已测试的子系统按程序结构连接起来完成程序整体的组装测试。D4D4D4D5D5D5M1M4M3M2M6M5程序模块示意图第一步，对最底层的模块M3、M5、M6进行测试,设计驱动模块D1、D2、D3来模拟调用。第三步，设计驱动模块D4、D5和D6模拟调用，分别对新子系统进行测试。第二步，用实际模块M2、M1和M4替换驱动模块D1、D2、D3。D6深度优先与宽度优先

无论是自顶而下增值还是自底而上增值，还可选择深度优先或者宽度优先增值。

举例：按自顶而下增值法，写出下图中分别按照深度优先或者宽度优先增值的模块组装次序。ABCDHGJEFIKLMN确定集成过程的原则自顶而下增值优点：能够尽早发现系统主控方面的问题。缺点：无法验证桩模块是否完全模拟了下属模块的功能。自底而上增值优点：驱动模块较容易编写，能够尽早查出底层涉及较复杂的算法和实际的I/O模块中的错误。缺点：最后才能发现系统主控方面的问题。集成过程的原则①尽早测试关键模块。②尽早测试包含I/O的模块。3.混合增值常见的混合增值方案：衍变的自顶而下先自底而上集成子系统，再自顶而下集成总系统。自底而上—自顶而下增值对含有读操作的子系统采用自底而上。对含有写操作的子系统采用自顶而下。回归测试在回归测试中自底而上，对其余部分（引起是对修改过的子系统）采用自顶而下。问题（1）自顶而下增值与自底而上增值各有何优、缺点？（2）为什么在实际的组装测试中，都应该采用混合增值的方法？（3）请自己设计2-3个混合增值的测试方法。三、确认测试(validationtesting)

1.任务

又称为有效性测试或功能测试。其任务是在开发环境下验证系统的功能、性能等特性是否符合需求规格说明。以黑盒法为主。选择测试人员选择测试用例实际运行测试软件计划用户文档开发文档源程序文本支持环境有效性测试软件配置审查管理机构裁决专家鉴定会交用户运行维护测试报告软件配置2.确认测试步骤（1）有效性测试 制定测试计划，运用黑盒法，验证软件特性是否与需求符合。（2）软件配置复查 软件配置—指软件工程过程中所产生的所有信息项：文档、报告、程序、表格、数据。随着软件工程过程的进展软件配置项（SCIsoftwareConfigurationItem）快速增加和变化。应复查SCI是否齐全。 （3）测试和

测试 测试是在开发机构的监督下，由个别用户在确认测试阶段后期对软件进行测试，目的是评价软件的FLURPS（功能、局域化、可使用性、可靠性、性能和支持），注重界面和特色。

测试由支持软件预发行的客户对FLURPS进行测试，主要目的是测试系统的可支持性。FunctionTesting功能测试

LocalAreaTesting局域化测试

UsabilityTesting可使用性测试

RegressionTesting回归测试

PerformanceTesting性能测试

SupportabilityTesting可支持性测试四、系统测试（systemtesting）将经过确认测试的软件，与计算机硬件、外设、支持软件等一起，在实际运行环境下测试。五、验收测试（acceptancetesting）验收测试是以用户为主的测试。步骤：（1）由课题组根据测试用例，自己演示系统所有功能。（2）由用户进行测试。8.3.6综合测试策略

软件测试是保证软件可靠性的主要手段，也是软件开发过程中最艰巨、最繁杂的任务。软件测试方案是测试阶段的关键技术问题，基本目标是选择最少量的高效测试用例，从而尽可能多地发现软件中的问题。因此，无论哪一个测试阶段，都应该采用综合测试策略，才能够实现测试的目标。

一般都应该先进行静态测试，再考虑动态测试。最后进行验收测试（AcceptanceTesting），是以用户为主的测试，测试过程、方法和测试内容与系统测试基本相同。有时也将验收测试与系统测试合二为一，此时，参加测试的人员最好包括：有经验的系统测试专家，用户代表，软件开发人员及QA（质量保证）人员也应参加。8.4面向对象的测试

而面向对象的测试贯穿软件开发的全过程，是与开发过程密切相关，而又分离出来的过程。

面向对象的测试，既要使用许多传统的成熟的软件测试方法和技术，也有其不同的特点；主要反映在测试对象和内容的不同。

传统的观点认为测试要在编码之后才进行，主要测试的对象是程序代码。面向对象的测试更关注对象，而不是完成单一的输入/输出功能，因此测试可以在分析和设计阶段介入，可以更好地配合软件生产过程。8.4.1面向对象测试的特点1.强调需求或设计的测试，通常以两种方式进行：

在没有代码的情况下进行测试；在有代码的情况下进行测试。2.在传统测试方法的基础上，根据面向对象的主要特性，需要改变测试策略和方法。例如：封装—对数据的隐蔽，减少了对数据非法操作，可简化该类测试。继承—提高了代码复用性，但错误也会以同样方式被复用。多态性—提供强大的处理能力，但也增加测试的复杂性。8.4.2面向对象测试类型模型测试类测试交互测试系统（子系统）测试验收和发布测试采用正式技术评审的方法，检查分析与设计模型的正确性、完整性和一制性。模型测试方法包括：

用例场景测试；

系统原型走查；

需求模型一致性检查；

分析模型的检查和走查。8.4.2面向对象测试类型模型测试类测试交互测试系统（子系统）测试验收和发布测试

类测试即传统测试中的单元测试，即验证类的实现与类的规约是否一致的活动。完整的类测试包括：

类属性的测试

类操作的测试

可能状态下的对象测试注意：不能“孤立”进行测试，操作测试应该包括其可能被调用的各种情况。8.4.2面向对象测试类型模型测试类测试交互测试系统（子系统）测试验收和发布测试交互测试用于代替传统测试方法中的集成测试。将类进行联合测试，以确定它们能否在一起共同工作。交互测试的方法有：

用例或基于场景的测试

线程测试

对象的测试。8.4.2面向对象测试类型模型测试类测试交互测试系统（子系统）测试验收和发布测试

测试系统或独立子系统，确保系统无明显故障，并满足用户需求。系统测试包括：

功能测试

压力测试

安全测试

兼容性测试

安装测试

恢复测试8.4.2面向对象测试类型模型测试类测试交互测试系统（子系统）测试验收和发布测试

验收测试：交付用户前的系统测试。

发布测试：为了确保系统安装软件包能够正常交付使用。8.4.3分析模型测试2、需求测试可以较早地发现需求中问题

如：不合理的项目，以及错误地理解了用户需求的项目，避免对于成本和资源的消耗。1、需求的质量影响并决定了设计的质量在软件开发过程模型中，需求、设计和编码总是有一定的时序特性。而且，需求模型、设计模型和实现代码之间还具备解释特性。一、分析模型测试的重要性3、减少需求的模糊性

用户需求是用户对待实现的系统的要求，通常以一种非正规的形式给出，具有一定的模糊性。这种模糊性带入了设计，甚至代码中，将可能引发几倍，甚至几十倍的错误，这必将极大消耗系统的资源和成本。

测试实际上也是一个项目。测试也有需求、设计和实现，并且测试本身也会有测试(测试中的测试)。测试作为项目开发活动中的一部分，在时间上应该有明确的要求，测试计划对于测试来说也是至关重要的。

UML分析模型的每个模式，从严格意义上说都应该经过测试。实际上，通常对用例模型、类对象模型以及用例中典型场景进行测试。二、测试过程通常测试步骤如下：测试用例模型测试某些用例中的典型场景类及对象模型某些类测试其状态模型

单个用例测试采取典型应用场景的测试方法，用例模型的测试相当于系统测试，测试的主要目标是用例模型对于用户需求的可跟踪性。以系统的用户为主要的出发点设计测试用例，通过模拟某个系统用户的行为来测试整个系统，对于该用户的服务提供情况，从而检查系统功能的完整性，用户需求可跟踪性等情况。用例模型的测试从系统用户的角度测试系统的服务，并不关心每个测试用例所实现的功能如何，所以应该是黑盒测试。三、用例模型的测试下面以一个订货中心系统的用例模型为例说明测试用例的设计。有一个订货中心，接受客户的电话、传真、电子邮件、信件和Web主页表单等形式的订货请求，建立订单。根据客户要求的发货目的地，订货中心将以最经济的方式确定一家仓库来负责向客户发货。当仓库收到订单后，按照一定的策略进行发货，在填写发货的有关信息后，将订单返回订货中心。案例订货中心系统

识别五个主要的系统角色(用户)：

管理者(Manager)、发货人员(Shipper)

收款人员(Tollcollector)、商务客户(Customer)

信用卡(Creditcard)

从各个角色出发，通过下边的问题识别用例：

角色要求系统提供的功能有哪些？系统在提供这些功能的时候该角色需要做什么？角色需要创建、阅读、销毁或存储系统的哪些信息？系统中的哪些事件需要通知该角色？以管理者为例：(1)管理者要求系统为他提供什么功能？管理者需要做哪些工作？

答：管理者要求系统提供：

a.接受顾客订货请求并创建订单；

b.计算订单的价钱；

c.根据订单信息选择仓库，并将订单发送给仓库；

d.查询订单货物发送情况；

e.查询客户订单付款情况；

f.评价商务结果；

g.顾客退货处理；

h.把仓库返回的订单发送到收费处；

i.商品价格更新。

管理者需要做：生成订单；查询订单时输入订单号。(2)管理者需要阅读创建、销毁、更新或者存储系统哪些信息？

答：信息包括：订单、职员(仓库人员、收费人员等)信息、顾客信息、物品条目及价格信息、仓库信息和税务信息。(3)系统中的事件一定要告诉管理者吗？

答：是。这些事件包括：仓库有关物品短缺以致无法满足某订单；订单数据出现错误；顾客超过期限未付款。

可见，管理者要使用系统的十个功能，因此至少可以设计出十个测试用例。

以第三条功能“根据订单信息选择仓库，并将订单发送给该仓库”为例，说明用例的选择。假设订货中心共有三个仓库，管理者要决定应该选择哪个仓库处理订单。仓库名称仓库位置存货品名及数量订单处理客户信誉度A东城G1(200)，G5(100)，G6(1000)，G10(70)，G11(90)85B西城G1(1000)，G2(100)，G5(550)，G8(150)，G10(980)95C北城G1(220)，G4(300)，G5(350)，G7(400)，G10(700)80订单主要信息：订单号、送货地点、货物名称及数量等。管理者考虑将订单分配到某仓库的因素：

(1)首先仓库必须能够满足订单上的货物要求；

(2)选择地理位置与发货点较近的仓库发货；

(3)信誉满意度越高的客户就越应该以较高的服务质量来回报。结合考虑上面三个因素，以最少的成本取得最好的收益，三个订单信息如下：订单号送货地点货物名称及数量客户信誉订单1北城某集团公司G1(200)，G5(100)，G10(40)95订单2东城某街道

G5(10)，G6(5)80订单3北城某街道

G4(10)85仓库名称仓库位置存货品名及数量订单处理客户信誉度A东城G1(200)，G5(100)，G6(1000)，G10(70)，G11(90)85B西城G1(1000)，G2(100)，G5(550)，G8(150)，G10(980)95C北城G1(220)，G4(300)，G5(350)，G7(400)，G10(700)80订单号送货地点货物名称及数量客户信誉订单1北城某集团公司G1(200)，G5(100)，G10(40)95订单2东城某街道

G5(10)，G6(5)80订单3北城某街道

G4(10)85测试用例1：输入：订单1

预期结果：选择仓库B来处理订单(三个均可，大宗订单，客户信誉度高)；测试用例2：输入：订单2

预期结果：选择仓库A来处理订单(个人订单，客户信誉一般)；测试用例3：输入：订单3

预期结果：选择仓库C来处理订单。

以上测试未涉及某个具体用例，体现了用例模型测试和用例测试的区别。8.4.4类的测试类测试即传统测试中的单元测试，即验证类的实现与类的规约是否一致的活动。

类测试包括：类属性的测试、类操作的测试等。

例2Date类是一个描述日期的类，其属性为三个成员变量：年、月、日，在Date类中，操作decrease（）是使Date类的对象改变为当前日期的前一天。printDate（）是打印日期信息。而Date类的三个成员变量所属的类是calendarUnit类的子类。在calendarUnit类中，也有操作decrease（），并通过继承关系在Day、Month、Yers三个类中重写。设计测试用例，对Date类的操作decrease（）进行测试。8.4.4类的测试datedd:Daymm:Monthyy:YersDate(pDay:integer,pMonth:integer,pYers:integer)decrease(argname)printDate()calendarUnitcurrentVal:IntegerCalenderUnit(pVal:Integer)SetValue(pVal:Integer)decrease()DayMonthYers注意：操作测试应该考虑其可能被调用的各种情况。图8.16calendarUnit类的继承关系calendarUnitcurrentVal:IntegerCalenderUnit(pVal:Integer)SetValue(pVal:Integer)decrease():BooleanDaymm:MonthDay（pDay:integer,pMonth:Month）setDay（pDay:integer,pMonth:Month）getDay():integerdecrease():BooleanYersYear(pYear:Integer)getYear():Intgerdecrease():BooleanisLeap():BooleanMonthyy:Yearsizeindex:integer[]={31,28,31,30,31,30,3131,30,31,30,31}Month(pMonth::integer,pYear:Year)get(Month():integergetMonthSize():Integerdecrease():Boolean例如：对date类中的decrease方法进行测试,在设计测试用例时，采用等价分类法。划分等价类时要考虑边界及闰年等情况。有效等价类:D1=|一个月的第一天与最后一天之间|D2=|一个月的第一天|D3=|1月1日|M1=|前一个月是30天|M2=|前一个月是31天|M3=|前一个月是2月|Y1=|非闰年|Y2=|闰年|Y3=|2005年|无效等价类:D4=|<本月的第一天|D4=|>本月的最后一天|M4=|<1|M5=|>12|Y=|<0|用例ID月日年预期结果171919981998年7月18日