软件质量保证与测试实验指导书

实

验

指

导

书

2012年2月

目  录

第1章 实验基础知识    1

1.1 软件测试概述    1

1.2 测试用例的编写    1

第2章 实验要求    4

2.1 实验总体要求    4

2.1.1 实验意义和目的    4

2.1.2 实验内容安排    4

2.1.3 实验过程要求    4

2.2 实验报告要求    5

2.3 实验成绩评价    5

2.3.1 实验成绩评价结构及比例    5

2.3.2 考核方式    5

第3章 实验内容与指导    6

3.1 结构性测试    6

3.1.1 实验类型    6

3.1.2 实验目的    6

3.1.3 背景知识    6

3.1.4 实验设备    7

3.1.5 实验内容    7

3.1.6 实验步骤    8

3.1.7 实验要求    8

3.1.8 实验思考    8

3.2 功能性测试    9

3.2.1 实验类型    9

3.2.2 实验目的    9

3.2.3 背景知识    9

3.2.4 实验设备    11

3.2.5 实验内容    11

3.2.6 实验步骤    12

3.2.7 实验要求    12

3.2.8 实验思考    13

3.3单元测试    14

3.3.1 实验类型：设计型（2学时）    14

3.3.2 实验目的    14

3.3.3 背景知识    14

3.3.4 实验设备    15

3.3.5 实验内容    15

3.3.6 实验步骤    15

3.3.7 实验要求    15

3.3.8 实验思考    15

3.4 QuickTest Professional初级使用    17

3.4.1 实验类型    17

3.4.2 实验目的    17

3.4.3 背景知识    17

3.4.4 实验设备    19

3.4.5 实验内容    19

3.4.6 实验步骤    20

3.4.7 实验要求    23

3.5 QuickTest Professional高级使用    24

3.5.1 实验类型    24

3.5.2 实验目的    24

3.5.3 背景知识    24

3.5.4 实验设备    32

3.5.5 实验内容    32

3.5.6 实验步骤    33

3.5.7 实验要求    33

3.6 LoadRunner的使用    34

3.6.1 实验类型    34

3.6.2 实验目的    34

3.6.3 LoadRunner功能简介    34

3.7 Web系统测试    39

3.7.1 实验类型    39

3.7.2 实验目的    39

3.7.3 背景知识    39

3.7.4 实验设备    40

3.7.5 实验内容    41

3.7.6 实验步骤    41

3.7.7 实验要求    41

第1章 实验基础知识

1.1 软件测试概述

1．软件测试

软件测试就是在软件投入运行前，对软件需求分析、设计规格说明和编码的最终复审，是软件质量保证的关键步骤。 软件测试是为了发现错误而执行程序的过程。或者说，软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例（即输入数据及其预期的输出结果），并利用这些测试用例去运行程序，以发现程序错误的过程。 

2．测试过程

为了保证测试的质量，将测试过程分成几个阶段，即：代码审查、单元测试、集成测试、系统测试和验收测试。

代码会审由一组人通过阅读、讨论和争议对程序进行静态分析的过程。

单元测试集中在检查软件设计的最小单位——模块上，通过测试发现实现该模块的实际功能与定义该模块的功能说明不符合的情况，以及编码的错误。

集成测试是将模块按照设计要求组装起来同时进行测试，主要目标是发现与接口有关的问题。

系统测试是测试整个系统，以证实它满足“需求规格说明书”所规定的功能、质量和性能等方面的特性。

验收测试的目的是向未来的用户表明系统能够像预定要求那样工作。与系统测试非常相似，主要区别是测试人员不同，验收测试由用户执行。

3．测试方法

软件测试的方法分为功能性测试和结构性测试。

功能测试是指在对程序进行功能抽象的基础上，将程序划分成功能单元，然后在数据抽象的基础上，对每个功能单元生成测试数据进行测试。进行功能测试时，被测程序被当作打不开的黑盒，因而无法了解其内部构造，因此又称为黑盒测试。

结构性测试是知道产品内部工作过程，检测产品内部动作是否按照规格说明书的规定正常进行。它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。此方法把测试对象看作一个透明的盒子，又叫白盒测试。

4．测试工具

软件测试的工作量很大（据统计，会用到40% 的开发时间；一些可靠性要求非常高的软件，测试时间甚至占到总开发时间的60% ），但测试却是在整个软件过程中极有可能应用计算机进行自动化的工作，原因是测试的许多操作是重复性的、非智力创造性的、需求细致注意力的工作。测试工具的应用已经成为了普遍的趋势。测试工具一般可分为白盒测试工具、黑盒测试工具、性能测试工具，另外还有用于测试管理（包括测试流程管理、缺陷跟踪管理、测试用例管理）的工具。

本实验课程中主要涉及到QuickTest Professional和LoadRunner自动化测试工具。

1.2 测试用例的编写

1．测试用例

软件测试的本质是针对要测试的内容确定一组测试用例。测试用例是为实施一次测试而向被测系统提供的输入数据、操作或各种环境设置。

测试用例应该包含基本的内容有输入和预期输出，输入实际有两种类型：前提（在测试用例执行前已经存在的环境）和由某种测试方法所标识的实际输入。预期输出也有两类：后果和实际输出。测试活动要建立必要的前提条件，提供测试用例输入、观测输出、然后将这些输出与预期输出进行比较，以确定该测试是否通过。开发良好的测试用例的其他信息（如表1）主要支持测试管理，测试用例需求被开发、评审、使用、管理和保存。

表1-1 测试用例

功能性测试的基本观点是，任何程序都可以看作是将从定义域取值映射到输出值域的函数。这种观点常常在工程中使用，将系统看作是黑盒。采用功能性方法标识测试用例，所使用的唯一信息就是软件的规格说明。功能性测试用例具有两个显著的优点：（1）功能性测试与软件如何实现无关，所以如果实现发生变化，测试用例仍然有用；（2）测试用例开发可以与实现并行进行，因此可缩短总的开发时间。在缺点方面，功能性测试用例也常常带来两个问题：测试用例可能存在严重的冗余，此外可能还会有未测试的软件漏洞。功能性测试的主流方法主要有：边界值分析、健壮性分析、最坏情况分析、特殊值测试、输入等价类、输出等价类和基于决策树的测试。

结构性测试有时也叫白盒测试。结构性测试是知道软件产品内部工作过程，检测软件产品内部动作是否按照规格说明书的规定正常进行。结构性测试需要全面了解程序内部逻辑结构、对所有逻辑路径进行测试。结构性测试是穷举路径测试，并力求提高测试覆盖率。结构性测试的主要方法有：逻辑覆盖测试、基路径测试、数据流测试等方法。

在实际应用中，为全面的测试软件产品，一般将结构性测试和功能性测试结合起来使用。

2．软件缺陷分类

有多种方法可以对缺陷分类：以出现相应错误的开发阶段来划分、以相应失效产生的后果来划分、以解决难度来划分、以不解决难度会产生的风险来划分等等。在日常的软件测试中，通常给出的缺陷是根据缺陷后果的严重程度来进行划分，如下表2所示。在实际应用中可以根据具体情况对严重程度来划分不同的等级。

    3．测试用例的选择

选择测试用例是软件测试员最重要的一项任务，不正确的选择可能导致测试量过大或过小，甚至测试目标不对。

从工程实践的角度讲，测试用例有几条基本准则：

（1）测试用例的代表性：能够代表各种合理和不合理的、合法的和非法的、边界和越界的,以及  极限的输入数据、操作和环境设置等；

（2）测试结果的可判定性：即测试执行结果的正确性是可判定的或可评估的；

（3）测试结果的可再现性：即对同样的测试用例,系统的执行结果应当是相同的。

表1-2 缺陷划分表

2.1 实验总体要求

2.1.1 实验意义和目的

本实验课程配合《软件质量保证与测试》理论课同步开设，其中包括验证型、设计型实验。本实验课程着眼于理论与应用的结合，注重培养学生软件测试的实际动手能力，增强软件工程项目的质量管理意识。通过实验教学，使学生掌握软件测试的方法和技术，并能运用软件测试工具进行自动化测试。

本实验课程要求学生完成适当的上机实习，并写出相应的实验报告。验证和设计题单独完成。验证型题目使学生熟悉常用的软件测试工具。设计型题目使学生掌握软件测试的基本理论和基本方法，培养基本的应用能力。

2.1.2 实验内容安排

实验内容安排如表2-1所示。

表2-1 实验内容安排

实验项目

实验前要充分做好准备工作：

1．复习和掌握与本实验有关的知识内容；

2．预习、思考实验内容；

3．对实验内容进行分析和设计。

实验过程中，实验者必须服从指导教师和实验室工作人员的安排，遵守纪律与实验制度，爱护设备及卫生。在指定的实验时间内，必须到实验室内做实验。

对于上机过程中出现的问题，尽量先思考和解决；对于难以解决的问题可以和同学交流或询问老师；对于同一个实验题目，可以考虑多种方法来实现，然后比较并选择出一种较为有效的方法来实现。

对于设计型和验证型实验，实验时一人一组，上机。

2.2 实验报告要求

实验后，应及时整理出实验报告。

2.3 实验成绩评价

2.3.1 实验成绩评价结构及比例

实验课程的总成绩由实验考勤和实验报告成绩组成，其中实验考勤占10%，实验过程占50%，实验报告占40%。

2.3.2 考核方式

实验考核主要是三个方面：

1．上机实验考勤。每次上机应主动在指导老师处签到，冒签等不诚信行为一旦被发现，取消本次实验成绩。累计缺席实验课3次及3次以上者，期末实验成绩为0分。

如果学生需要请假，必须提前出具正式假条（需要班主任或者辅导员签字），不接受事后假条（如有特殊情况，需要有辅导员或班主任的情况说明）。

2．实验过程考核。每次实验课，指导教师根据实验过程情况，随机抽查同学，进行当次实验的答辩。

3．实验报告提交。应根据指导教师要求按时提交每次实验的数据。如果发现学生抄袭、伪造实验数据，或实验报告和设计报告抄袭、雷同，则涉及的所有学生的该课程实验成绩记为0分。

第3章 实验内容与指导

3.1 结构性测试

3.1.1 实验类型

实验类型为验证型，2个学时。

3.1.2 实验目的

（1）掌握结构性测试技术，并能应用结构性测试技术设计测试用例；

（2）对测试用例进行优化设计；

3.1.3 背景知识

结构性测试是知道产品内部工作过程，检测产品内部动作是否按照规格说明书的规定正常进行。结构性测试允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。

1、逻辑覆盖

结构性测试力求提高测试覆盖率。逻辑覆盖是对一系列测试过程的总称，它是在使用白盒测试法时，选用测试用例执行程序逻辑路径的方法。

逻辑覆盖按覆盖程度由低到高大致分为以下几类：

（1）语句覆盖：设计若干测试用例，使程序中每一可执行语句至少执行一次；

（2）判断覆盖：设计用例，使程序中的每个逻辑判断的取真取假分支至少经历一次；

（3）条件覆盖：设计用例，使判断中的每个条件的可能取值至少满足一次；

（4）判断/条件覆盖：设计用例，使得判断中的每个条件的所有可能结果至少出现一次，而且判断本身所有可能结果也至少出现一次；

（5）条件组合覆盖。设计用例，使得每个判断表达式中条件的各种可能组合都至少出现一次；显然，满足⑤的测试用例也一定是满足②、③、④的测试用例。

（6）路径覆盖。设计足够的测试用例，使程序的每条可能路径都至少执行一次。

如果把路径覆盖和条件组合覆盖结合起来，可以设计出检错能力更强的测试数据用例。

2、基本路径测试

如果把覆盖的路径数压缩到一定限度内，例如，程序中的循环体只执行零次和一次，就成为基本路径测试。它是在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例的方法。

设计出的测试用例要保证在测试中，程序的每一个可执行语句至少要执行一次。

① 程序的控制流图

控制流图是描述程序控制流的一种图示方法。基本控制构造的图形符号如图所示。符号○称为控制流图的一个结点，一组顺序处理框可以映射为一个单一的结点。控制流图中的箭头称为边，它表示了控制流的方向，在选择或多分支结构中分支的汇聚处，即使没有执行语句也应该有一个汇聚结点。边和结点圈定的区域叫做区域，当对区域计数时，图形外的区域也应记为一个区域。

图3-1 控制流图的各种图形符号

如果判定中的条件表达式是复合条件时，即条件表达式是由一个或多个逻辑运算符（OR，AND，NAND，NOR）连接的逻辑表达式，则需要改复合条件的判定为一系列只有单个条件的嵌套的判定。例如对应图3-2. (a) 的复合条件的判定，应该画成如图3-2. (b) 所示的控制流图。 条件语句 if a OR b 中条件a和条件b各有一个只有单个条件的判定结点。

图3-2  复合逻辑下的控制流图

② 计算程序环路复杂性   

进行程序的基本路径测试时，程序的环路复杂性给出了程序基本路径集合中的路径条数，这是确保程序中每个可执行语句至少执行一次所必需的测试用例数目的上界。

所谓路径，是指包括一组以前没有处理的语句或条件的一条路径。如在图3-3(b)所示的控制流图中，一组的路径是：

   path1：1 - 11

   path2：1 - 2 - 3 - 4 - 5 - 10 - 1 - 11

   path3：1 - 2 - 3 - 6 - 8 - 9 - 10 - 1 - 11

   path4：1 - 2 - 3 - 6 - 7 - 9 - 10 - 1 - 11

路径path1，path2，path3，path4组成了图3-3 (b) 所示控制流图的一个基本路径集。只要设计出的测试用例能够确保这些基本路径的执行，就可以使得程序中的每个可执行语句至少执行一次，每个条件的取真分支和取假分支也能得到测试。基本路径集不是唯一的，对于给定的控制流图，可以得到不同的基本路径集。

               (a) 程序流程图                            (b) 控制流图

                      图3-3 程序流程图与对应的控制流图

通常环路复杂性可用以下三种方法求得。

 将环路复杂性定义为控制流图中的区域数。

 设E为控制流图的边数，N为图的结点数，则定义环路复杂性为 V(G)＝E－N＋2。

 若设P为控制流图中的判定结点数，则有 V(G)＝P＋1。

因为图5.14(b)所示控制流图有4个区域。其环路复杂性为4。 它是构成基本路径集的路径数的上界。可以据此得到应该设计的测试用例的数目。

③ 导出测试用例

利用逻辑覆盖方法生成测试用例，确保基本路径集中每条路径的执行。

3.1.4 实验设备

主流PC机一套，要求安装windows操作系统、Visual C++开发工具和OFFICE工具；

3.1.5 实验内容

1．题目一：使用逻辑覆盖测试方法测试以下程序段

void DoWork (int x,int y,int z)

{

1int k=0,  j=0;

2if ( (x>3)&&(z<10) )

3{

4       k=x*y-1;

5          j=sqrt(k);

6    }

7    if((x==4)||(y>5))

8    j=x*y+10;

9     j=j%3;

10 }

说明：程序段中每行开头的数字（1~10）是对每条语句的编号。

（1）画出程序的控制流图（用题中给出的语句编号表示）。

（2）分别以语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、组合覆盖和路径覆盖方法设计测试用例，并写出每个测试用例的执行路径（用题中给出的语句编号表示）。

2．题目二：三角形问题

在三角形计算中，要求输入三角型的三个边长：A、B 和C。当三边不可能构成三角形时提示错误，可构成三角形时计算三角形周长。若是等腰三角形打印“等腰三角形”，若是等边三角形，则提示“等边三角形”。画出程序流程图、控制流程图、计算圈复杂度V(g)，找出基本测试路径。

3．题目三：计算生日是星期几

已知公元1年1月1日是星期一。编写一个程序，只要输入年月日，就能回答那天是星期几。应用逻辑覆盖方法和基路径测试方法为上面的问题设计测试用例。   

4．题目四：选择排序

下面是选择排序的程序，其中datalist是数据表，它有两个数据成员：一是元素类型为Element的数组V，另一个是数组大小n。算法中用到两个操作，一是取某数组元素V[i]的关键码操作getKey ( )，一是交换两数组元素内容的操作Swap( )： 

      void SelectSort ( datalist & list ) {

                /对表list.V[0]到list.V[n-1]进行排序,  n是表当前长度。

for ( int i = 0; i < list.n-1; i++ ) {

           int k = i;           //在list.V[i].key到list.V[n-1].key中找具有最小关键码的对象

           for ( int j = i+1;  j < list.n;  j++)

             if ( list.V[j].getKey ( ) < list.V[k].getKey ( ) ) k = j;//当前具最小关键码的对象

           if ( k != i ) Swap ( list.V[i], list.V[k] );          //交换

          }

       }

（1）试计算此程序段的McCabe复杂性；

（2）用基本路径覆盖法给出测试路径；

（3）为各测试路径设计测试用例。

3.1.6 实验步骤

（1）根据结构性测试技术设计测试用例，主要考虑逻辑覆盖测试（语句覆盖、判断覆盖、条件覆盖、判断/条件覆盖、条件组合覆盖、路径覆盖）和基路径测试技术；

（2）根据所学知识确定优化策略（原则：用最少的用例检测出更多的缺陷、软件测试的充分性与冗余性考虑），设计两套测试用例集；

（3）根据设计的两套测试用例集进行测试、参照表2所示的缺陷等级给出缺陷列表；

（4）计算测试用例的分支覆盖率、条件覆盖率和语句覆盖率等测试管理指标；

3.1.7 实验要求

（1）根据题目要求编写测试用例（参照表1进行用例设计）；

（2）实验结果要求给出两套测试用例集测试效果比较；计算测试用例的分支覆盖率、条件覆盖率和语句覆盖率等测试管理指标；

（3）撰写实验报告；

3.1.8 实验思考

（1）使用公式e-n+p/e-n+2p确定的McCabe基路径与实际分析的是否完全一致？

（2）DD-路径和MM-路径的区别与联系。

3.2 功能性测试

3.2.1 实验类型

实验类型为验证型，2个学时。

3.2.2 实验目的

（1）能熟练应用功能性测试技术进行测试用例设计；

（2）对测试用例进行优化设计；

3.2.3 背景知识

功能测试是指在对程序进行功能抽象的基础上，将程序划分成功能单元，然后在数据抽象的基础上，对每个功能单元生成测试数据进行测试。进行功能测试时，被测程序被当作打不开的黑盒，因而无法了解其内部构造，因此又称为黑盒测试。　

1、等价类测试

等价类测试方法是把所有可能的输入数据，即程序的输入域划分成若干部分，然后从每一部分中选取少数有代表性的数据作为测试用例。使用等价类划分方法设计测试用例要经历划分等价类（列出等价类表）和选取测试用例两步。

等价类的划分有两种不同的情况： ① 有效等价类：是指对于程序的规格说明来说，是合理的，有意义的输入数据构成的集合。 ② 无效等价类：是指对于程序的规格说明来说，是不合理的，无意义的输入数据构成的集合。在设计测试用例时，要同时考虑有效等价类和无效等价类的设计。

用等价类划分法设计测试用例步骤：

(1) 形成等价类表，每一等价类规定一个唯一的编号；

(2) 设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类，重复这一步骤，直到所有有效等价类均被测试用例所覆盖；

(3) 设计一个新测试用例，使其只覆盖一个无效等价类，重复这一步骤直到所有无效等价类均被覆盖。

2、边界值测试

1．边界值分析

边界值分析是考虑边界条件而选取测试用例的一种功能测试方法。边界值分析关注输入空间的边界，以标识测试用例，因为错误更可能出现在输入变量的极值附近。

边界值分析的基本思想是：使用在最小值、略高于最小值、正常值、略低于最大值和最大值处取输入变量值。

2．健壮性测试

健壮性是指在异常情况下，软件还能正常运行的能力。健壮性考虑的主要部分是预期输出，而不是输入。

健壮性测试是边界值分析的一种简单扩展。除了变量的5个边界分析取值还要考虑略超过最大值（max）和略小于最小值（min）时的情况。

3．最坏情况测试

最坏情况测试将意味着更大工作量，n变量函数的最坏情况测试会产生5的n次方个测试用例，而边界值分析只产生4n+1个测试用例。

3、基于决策表的测试

决策表适合描述不同条件集合下采取行动的若干组合的情况。使用决策表标识测试用例，则把条件解释为输入，行动解释为输出。有时条件最终引用输入的等价类，行为引用被测试软件的主要功能处理部分，规则解释为测试用例。

对于有限条目决策表，如果有n个条件，则必须有2条规则。如果不关心条目实际地表明条件是不相关的，则没有不关心条目的规则统计为1条规则，规则中每出现一个不关心条目，该规则数乘一次2。

3.2.4 实验设备

主流PC机一套，要求安装windows操作系统、Visual C++开发工具和OFFICE工具；

3.2.5 实验内容

1．题目一：电话号码问题

某城市电话号码由三部分组成。它们的名称和内容分别是：

（1）地区码：空白或三位数字；

（2）前 缀：非'0'或'1'的三位数字；

（3）后 缀：4位数字。

假定被测程序能接受一切符合上述规定的电话号码，拒绝所有不符合规定的电话号码。根据该程序的规格说明，作等价类的划分，并设计测试方案。

2．题目二：三角形问题

根据下面给出的规格说明，利用等价类划分的方法，给出足够的测试用例。

“一个程序读入三个整数。把此三个数值看成是一个三角形的三个边。这个程序要打印出信息，说明这个三角形是三边不等的、是等腰的、还是等边的。”

3．题目三：日期问题

用决策表测试法测试以下程序:该程序有三个输入变量month、day、year（month 、 day和year均为整数值，并且满足：1≤month≤12和1≤day≤31),分别作为输入日期的月份、日、年份，通过程序可以输出该输入日期在日历上隔一天的日期。例如，输入为 2004 年11月29日,则该程序的输出为2004年12月1日。 

(1) 分析各种输入情况，列出为输入变量 month 、 day 、 year 划分的有效等价类。 

(2) 分析程序的规格说明，并结合以上等价类划分的情况，给出问题规定的可能采取的操作（即列出所有的动作桩）。 

(3) 根据 (1) 和 (2) ，画出简化后的决策表。

4．题目四：找零钱最佳组合

假设商店货品价格(R)皆不大于100元（且为整数），若顾客付款在100元内 (P) ， 求找给顾客最少货币个（张）数？（货币面值50元10 元，5 元，1元四 种 ）

3.2.6 实验步骤

（1）根据功能性测试技术设计测试用例，主要考虑等价类划分和边界值分析测试技术；

（2）根据所学知识确定优化策略（原则：用最少的用例检测出更多的缺陷、软件测试的充分性与冗余性考虑），设计两套测试用例集；

（3）根据设计的两套测试用例集进行测试； 

3.2.7 实验要求

（1）根据题目要求编写测试用例（参照表1进行用例设计）；

（2）实验结果要求给出两套测试用例集测试效果比较；

（3）撰写实验报告；

3.2.8 实验思考

（1）在实际的测试中，如何设计测试用例才能达到用最少的测试用例检测出最多的缺陷；

（2）在进行用例设计时，如何考虑软件测试用例的充分性和减少软件测试用例的冗余性；

3.3单元测试

3.3.1 实验类型

实验类型为设计型，2个学时。

3.3.2 实验目的

（1）掌握单元测试技术，并按单元测试的要求设计测试用例。

（2）能熟练应用功能性测试技术进行测试用例设计；

（3）能熟练应用结构性测试技术进行测试用例设计；

（4）对测试用例进行优化设计；

（5）熟悉测试管理中的量化指标。

3.3.3 背景知识

1、单元测试的内容

（1）模块接口测试 ：对通过被测模块的数据流进行测试。为此，对模块接口，包括参数表、调用子模块的参数、全程数据、文件输入／输出操作都必须检查。

（2）局部数据结构测试 ：设计测试用例检查数据类型说明、初始化、缺省值等方面的问题，还要查清全程数据对模块的影响。 

（3）路径测试 ：选择适当的测试用例，对模块中重要的执行路径进行测试。对基本执行路径和循环进行测试可以发现大量的路径错误。

（4）错误处理测试 ：检查模块的错误处理功能是否包含有错误或缺陷。例如，是否拒绝不合理的输入；出错的描述是否难以理解、是否对错误定位有误、是否出错原因报告有误、是否对错误条件的处理不正确；在对错误处理之前错误条件是否已经引起系统的干预等。

（5）边界测试 ：要特别注意数据流、控制流中刚好等于、大于或小于确定的比较值时出错的可能性。对这些地方要仔细地选择测试用例，认真加以测试。

此外，如果对模块运行时间有要求的话，还要专门进行关键路径测试，以确定最坏情况下和平均意义下影响模块运行时间的因素。这类信息对进行性能评价是十分有用的。

2、单元测试的步骤

通常单元测试在编码阶段进行。在源程序代码编制完成，经过评审和验证，确认没有语法错误之后，就开始进行单元测试的测试用例设计。利用设计文档，设计可以验证程序功能、找出程序错误的多个测试用例。对于每一组输入，应有预期的正确结果。

模块并不是一个的程序，在考虑测试模块时，同时要考虑它和外界的联系，用一些辅助模块去模拟与被测模块相联系的其它模块。这些辅助模块分为两种：

（1）驱动模块：相当于被测模块的主程序。它接收测试数据，把这些数据传送给被测模块，最后输出实测结果。

（2）桩模块：用以代替被测模块调用的子模块。桩模块可以做少量的数据操作，不需要把子模块所有功能都带进来，但不允许什么事情也不做。

  被测模块、与它相关的驱动模块及桩模块共同构成了一个“测试环境”，如图3-1所示。

图3-1 单元测试环境

3.3.4 实验设备

主流PC机一套，要求安装windows操作系统、VC开发工具和OFFICE工具；

3.3.5 实验内容

题目一： 针对三角形问题进行单元测试

 三角形问题：接受三个正整数a、b、c作为输入，用做三角形的边。三边必须满足条件： 03.3.6 实验步骤

（1）根据功能测试技术设计测试用例，主要考虑边界测试、等价类（弱一般、强一般、弱健壮性、强健壮性）和基于决策表等技术；

（2）根据结构性测试技术设计测试用例，主要考虑路径测试、数据流等测试技术；

（3）根据所学知识确定优化策略（原则：用最少的用例检测出更多的缺陷、软件测试的充分性与冗余性考虑），设计两套测试用例集；

（4）根据设计的两套测试用例集进行测试、参照表2所示的缺陷等级给出缺陷列表；

（5）计算测试用例的分支覆盖率、条件覆盖率和语句覆盖率等测试管理指标；

3.3.7 实验要求

（1）以实验报告的形式撰写单元测试的测试用例。

（2）实验结果要求给出两套测试用例集测试效果比较（根据实验步骤中的4、5两步进行撰写）；

3.3.8 实验思考

（1）在实际的测试中，如何设计测试用例才能达到用最少的测试用例检测出最多的缺陷；

（2）在进行用例设计时，如何考虑软件测试用例的充分性和减少软件测试用例的冗余性；.

为了高效地进行软件测试，目前还有哪些测试技术可以使用？

3.4 QuickTest Professional初级使用

3.4.1 实验类型

实验类型为验证型，2个学时。

3.4.2 实验目的

了解QuickTest测试工具的操作界面，了解QuickTest测试工具的测试模式和过程，并能使用QuickTest测试工具录制测试脚本、执行并分析测试脚本。

3.4.3 背景知识

Mercury QuickTest Professional是一款先进的自动化测试解决方案，用于创建功能和回归测试。它自动捕获、验证和重放用户的交互行为。使用QuickTest Professional关键字视图、自动文档（Auto-documentation）和活动屏幕（Active Screen），无需一行代码，就可以创建和修改测试脚本，同时满足了技术型和非技术型用户的需求，让各个公司有能力部署更高质量的应用。

QuickTest主要应用在回归测试中。QuickTest针对的是GUI应用程序，包括传统的Windows应用程序，以及现在越来越流行的Web应用。

一、QuickTest窗口

在开始录制测试脚本之前，先熟悉QuickTest 的窗口。QuickTest 的主窗口如图3-2所示。

图3-2 QuickTest 的主窗口

QuickTest 的主窗口包含下列的组件：

◆Title bar：显示目前测试脚本的名称。

◆Menu bar：显示QuickTest 的菜单。

◆File toolbar：管理测试脚本常用的工具列。File toolbar如图3-3所示。

图3-3File toolbar

◆Test toolbar：录制测试脚本常用的工具列。Test toolbar 如图3-4所示。

图3-4 Test toolbar 

◆Debug toolbar：对测试脚本除错常用的工具列。Debug toolbar如图3-5所示。

图3-5 Debug toolbar

◆Action toolbar：包含常用的功能按钮，以及一个显示测试动作（action）的下拉式清单（list），方便你检视整个测试脚本中的测试动作。

◆Test pane：包含Keyword View 以及Expert View。

◆Active Screen pane：包含Active Screen。

◆Data Table：当你对测试脚本做参数化时存放参数数据的地方，除了一个Global 的数据表外，每一个action 也会有各自的资料表。

◆Debug Viewer pane：协助你对测试脚本除错（debug）。Debug Viewer pane 包含WatchExpressions、Variables 以及Command。

◆Status bar：显示测试脚本的状态。

二、QuickTest测试开发流程

QuickTest的测试流程包含七大阶段：

1. 录制测试脚本前的准备

在测试前需要先确认应用程序以及QuickTest 是符合测试需求。

确认你已经知道如何对应用程序进行测试，例如要测那些功能、操作步骤、输入的数据、预期的结果等。

同时应该检查一下QuickTest 的设定，如Test Settings（【Test】>【Settings】）以及Options 对话窗口（【Tools】>【Options】），以确保QuickTest 会适切的录制并储存信息。例如，你应该确认一下QuickTest 的Object Repository 是以什么模式储存信息的。

2. 录制测试脚本

当浏览网站或是操作应用程序时，QuickTest 会在Keyword View 中以表格的方式显示录制的操作步骤。每一个操作步骤都是使用者在录制时的操作，如在网页上点选一个超级链接（link），或是按下窗口上的按钮。

3. 加强测试脚本

◆在测试脚本中加入检查点，可以检查网页超级链接、对象属性或是字符串，以验证应用程序的功能是否正确。

◆将录制的固定值（hard code）参数以取代，使用多组的数据测试应用程序。

◆使用逻辑（logic）或是条件（conditional）判断式，可以进行更复杂的测试。

4. 调试脚本（对测试脚本除错）

在修改过测试脚本之后，需要调试测试脚本，检查脚本是否存在错误，以确保测试脚本能正常且流畅的执行。

5. 在应用程序或网站上执行测试脚本

在对应用程序或网站的回归测试中，通过QuickTest回放对应用程序或网站的操作，检验软件正确性，实现测试的自动化进行。

6. 分析测试结果

查看QuickTest记录的运行结果，分析测试执行的结果，记录问题，找出应用程序的问题所在。

7. 回报问题（defect）

如果安装了Quality Center（TestDirector），则你可以将发现的问题回报到QualityCenter（TestDirector）的数据库中。Quality Center（TestDirector）是Mercury 的测试管理工具。

3.4.4 实验设备

主流PC机一套，要求安装windows操作系统、Quick Test Professional8.2、OFFICE工具；

3.4.5 实验内容

1．题目一：测试MercuryTours网站

使用QuickTest对MercuryTours网站进行功能测试。要求录制预订机票的完整过程，然后执行测试脚本并分析结果。

2．题目二：测试163网站

使用QuickTest对MercuryTours网站进行功能测试。要求录制打开163免费邮箱阅读邮件和发邮件的过程。然后执行测试脚本并分析结果。

3.4.6 实验步骤

一、录制脚本准备

当你浏览网站或使用应用程序时，QuickTest会纪录你的操作步骤，并产生测试脚本。 当你停止录制测试脚本后，会看到QuickTest在Keyword View中以表格的方式显示测试脚本的操作步骤（steps）。 

在测试前需要先确认你的应用程序以及QuickTest是符合你的测试需求的。 

在开始时请先确认以下事项：

假如你是使用Internet Explorer浏览器，请你先取消「自动完成」的功能（取消「自动完成」的设定：

1.  开启Internet Explorer浏览器，点选【工具】>【因特网选项】>【内容】。

2.  点选【个人信息】中的【自动完成】按钮，开启【自动完成设定】对话窗口。

3.  在【使用「自动完成」】取消【窗体上的使用者名称和密码】选项。 ）。  

 关闭所有的浏览器窗口。 

二、录制脚本

录制一个测试脚本。在Mercury Tours范例网站上预订一张从纽约（New York）到旧金山（San Francisco）的机票。  

1. 执行QuickTest并开启一个全新的测试脚本

要开启QuickTest，请点选【开始】>【程序集】>【QuickTest Professional】>【QuickTest Professional】。 

     在【Add-in Manager】勾选【Web Add-in】，并取消其它的add-ins。然后点选【OK】按钮关闭【Add-in Manager】窗口，进入QuickTest Professional主窗口。 

 假如出现【Welcome】窗口，点选【Blank Test】。或者，点选【File】>【New】，或是按下工具列上的【New】按钮。QuickTest Professional会开启全新的测试脚本档案。假如QuickTest Professional已经开启，检查【Help】>【About Quick Test Professional】看目前加载了哪些add-ins 。

2. 开始录制测试脚本 

    点选【Test】>【Record】或是点选工具列上的【Record】按钮。会开启【Record and Run 

Settings】对话窗口。在【Web】页签，勾选【Open the following browser when a record or run session begins】。 从【Type】下拉列表选择使用的浏览器，并且在【Address】输入http://newtours.mercuryinteractive.com。 

    请确认【Do not record and run on browsers that are already open】与【Close the browser when the test is closed】这二个选项都已经勾选了，如图3-6所示。

图3-6 Web选项

在【Windows Applications】页签，勾选【Record and run on these app（opened on session start）】，而且不要选取任何的应用程序。 此设定可以避免录制到其它应用程序（如Outlook）的操作。如图3-7所示。

图3-7 Windows Application选项

点选【OK】。 QuickTest会开启浏览器浏览Mercury Tours网站，并且开始录制测试脚本。 

登入Mercury Tours Web site 网站，在【User Name】与【Password】输入你当初注册的账号与密码。点选【Sign-In】，开启【Flight Finder】网页。 输入订票数据， 选择飞机航班 。点选【CONTINUE】按钮，开启【Book a Flight】页面， 输入必要字段 ，在【Billing Address】勾选【Ticketless Travel】。 按下网页下方的【SECURE PURCHASE】按钮，开启【Flight Confirmation】网页。 检视订票数据，并点选【BACK TO HOME】回到Mercury Tours网站的首页。

3.  停止录制 

在QuickTest，点选工具列上的【Stop】按钮，停止录制。现已经完成了预定「纽约-旧金山」机票的动作，QuickTest已经录制了从按下【Record】按钮后，到按下【Stop】按钮之间所有的操作。 

4.  储存测试脚本 

选取【File】>【Save】或是点选工具列上的【Save】按钮，开启【Save】对话窗口。建立一个【Tutorial】目录，将测试脚本命名为【Recording】。 勾选【Save Active Screen files】。 

按下【存盘】按钮，测试脚本名称（Recording）会出现在QuickTest窗口的标题列。 

三、分析Keyword View中的测试脚本

录制测试脚本时，QuickTest会将每一个操作录制下来，并在Keyword View类似Excel工作表的方式显示所录制的测试步骤。可以点选【View】>【Expend All】检视测试脚本的每一个步骤，如图3-8所示。

图3-8 Keyword View视图

在Keyword View的中每个字段都有其意义： 

【Item】：以阶层式的图标显示这个操作步骤所作用到的组件（测试对象（test object）、工具对象（utility object）、函数呼叫（function call）或脚本（statement））。   

【Operation】：要在这个作用到的组件上执行的动作，如点选（Click）、选取（Select）。  

【Value】：执行动作的参数（argument），例如当鼠标点选一张图片时是用左键还是右键。 

【Assignment】：使用到的变量。   

【Comment】：你在测试脚本中加入的批注。   

【Documentation】：自动产生用来描述此操作步骤的英文说明。 

脚本中的每一个步骤在Keyword View中都会以一列来显示，其中包含用来表示此组件类别的图标以及此步骤的详细数据。 

3.4.7 实验要求

（1）撰写实验报告，主要填写本人测试步骤和自己的实验体会。

（2）提交录制的测试脚本。

3.5 QuickTest Professional高级使用

3.5.1 实验类型

实验类型为验证型，2个学时。

3.5.2 实验目的

熟练使用QuickTest Professional进行自动化测试。掌握QuickTest Professional测试流程。

3.5.3 背景知识

一、创建检查点

1. 检查点类型

QuickTest Professional 提供的检查点如表3-1所示。

表3-1 检查点类型

2. 检查对象 

本部分将在“Book a Flight”页中添加标准检查点。该检查点将验证包含乘客名字的框中的值。

执行QuickTest并开启「Recording」测试脚本。将测试另存为“Checkpoint”。

找到要向其添加标准检查点的页面。添加检查点，以便在乘客的名字输入到“First Name”编辑框后，对该框中的属性值进行检查。在关键字视图的“项”列中，单击 (+) 展开“Action1”>“Welcome:Mercury Tours”>“Book a Flight: Mercury”。 

创建标准检查点。在 Active Screen 中，右键单击“First Name”框，然后选择“插入标准检查点”。将打开“对象选择—检查点属性”对话框，如图3-9所示。

图3-9 对象选择—检查点属性

确认已突出显示“WebEdit: passFirst0”，然后单击“确定”。 将打开“检查点属性”对话框，如图3-10所示。

图3-10 检查点属性

该对话窗口会显示对象的属性：【name】是这个对象的名称   【Class】是这个对象的类别。WebEdit表示这个对象是个edit box。 在【Type】字段中的【ABC】图标表示这个属性的值是个常数。

对每个对象，QuickTest会使用预设的属性作为检查的属性。接受预设的设定值，然后点选【OK】。QuickTest会在你选取的步骤之前建立一个标准的检查点。

3. 检查页面

网页检查点会检查网页的链结（link）以及图片的数量是否与当初录制时的数量一样。 

在Keyword View中，展开(+)【Action1】>【"Welcome: Mercury Tours"】。 选取Keyword View中的【"Book a Flight: Mercury"】网页。在【Active Screen】会显示这个网页的画面。 

在【Active Screen】上任意地方按下鼠标右键，选取【Insert Standard Checkpoint】，会开启【Object Selection – Checkpoint Properties】对话窗口，如图3-11所示。由于你点选的位置不同，对话窗口显示被选取的对象可能会不一样。

图3-11 对象选择-检查点属性

点选【Page: Book a Flight: Mercury】（在最上层）然后点选【OK】。接着开启【Page Checkpoint Properties】对话窗口。当执行测试时，QuickTest会检查网页的连结与图片的数量，以及加载的时间。QuickTest也检查每个link的URL以及每个图片的原始文件是否存在。

接受默认值，点选【OK】。QuickTest会在 Book a Flight: Mercury网页下方加上一个网页检查点。

点选【File】>【Save】或是点选工具列上的【Save】按钮保存测试脚本。

4. 检查文本 

在此建立一个文本检查点，检查在【"Flight Confirmation"】网页中是否出现【"New York"】。  

在Keyword View中，展开(+)【Action1】>【"Welcome: Mercury Tours"】。选取Keyword View中的【"Flight Confirmation: Mercury"】网页。在【Active Screen】会显示网页的画面。 

在【Active Screen】中，选取在「Departing,」下方的「New York」。对选取的文字按下鼠标右键，点选【Insert Text Checkpoint】开启【Text Checkpoint Properties】对话窗口，如图3-12所示。 

当【Checked Text】出现在下拉式清单中时，在【Constant】字段会显示刚刚选取的文字。也就是QuickTest在执行测试脚本时所要检查的文字。 点选【OK】关闭对话窗口。Quick Test会在测试脚本上加上一个文字检查点，这个文字检查点会出现在【"Flight Confirmation: Mercury"】网页下方。 

点选【File】>【Save】或是点选工具列上的【Save】按钮保存测试脚本。 

5. 检查表格 

建立一个表格检查点，检查【Book a Flight: Mercury】网页上出国航班的价钱。 

在Keyword View中，展开(+)【Action1】>【"Welcome: Mercury Tours"】。选取Keyword View中的【"Book a Flight: Mercury"】网页。在【Active Screen】会显示网页的画面。

图3-12 文本检查点属性

在【Active Screen】中，在第一个航班的价钱上（New York to San Francisco）—270—点选鼠标右键，然后选取【Insert Standard Checkpoint】。会开启【Object Selection – Checkpoint Properties】对话窗口。 

一开始被选取的是WebElement: 270，这时要点选上一层的WebTable对象，选取Web Table : New York to San Fransisco。 

注意，这时会看到在【Active Screen】上，选取的表格也会被框起来。点选【OK】。 

接着开启【Table Checkpoint Properties】对话窗口，显示整个表格的内容。 

预设是每个字段都会被勾选，表示所有字段都会做检查。你可以对某个字段点二下，取消检查字段，或是选取整个栏或列，执行选取或取消的动作。  

在每个字段的标题列点二下，取消勾选的图示，然后在第3行、第3列点二下，会在270左边出现勾选的图示，则执行时QuickTest会对此字段值做检查。

点选【OK】关闭对话窗口。QuickTest会在测试脚本中，【"Book a Flight: Mercury"】页面下加上一个表格检查点。 

点选【File】>【Save】或是点选工具列上的【Save】按钮保存测试脚本。 

6. 使用检查点运行并分析测试 

使用检查点查看测试，运行测试，并分析检查点结果。 

1) 展开并查看测试。

选择“视图”>“全部展开”或使用数字键盘上的“*”快捷键。所显示的关键字视图与图3-13相似。

图3-13关键字视图

2) 开始运行测试。

单击“运行”或选择“测试”>“运行”。将打开“运行”对话框。请确保已选定“新建运行结果文件夹”。接受默认的结果文件夹名。单击“确定”。当完成测试运行时，将打开“测试结果”窗口。 

3) 查看测试结果。

当 QuickTest 完成运行测试时，将打开“测试结果”窗口。测试结果应该为“通过”，表示所有检查点已通过测试。如果一个或多个检查点失败，则测试结果将为“失败”。 

4) 查看页面检查点的结果。

在结果树中，单击 (+) 展开“Checkpoint Iteration 1 (Row 1)”> “Action1 Summary”> “Welcome: Mercury Tours”>“Book a Flight: Mercury”。 突出显示“检查点`Book a Flight: Mercury'”。 

在“详细信息”窗格中列出了已检查的项目，可以查看页面检查点的详细信息。 

检查点通过，因为已检查的实际属性值与预期值相匹配。

5) 查看表检查点的结果。

在结果树中的“Book a Flight:”页上，单击 (+) 展开“New York to San Francisco”。突出显示“检查点`New York to San Francisco'”。 

在“详细信息”窗格中，可以查看表检查点的详细信息。还可以查看表单元格的值（已检查的单元格值显示为黑色；未检查的单元格值显示为灰色）。

6) 查看标准检查点的结果。

在结果树中的“Book a Flight: Mercury”页上，单击 (+) 展开“passFirst0”。

突出显示“检查点passFirst0”。在“详细信息”窗格中列出了已检查的属性及其值，可以查看标准检查点的详细信息。

7) 查看文本检查点的结果。

在结果树中，单击 (+) 展开“Checkpoint Iteration1 (Row 1)”> “Action1 Summary”>“Welcome: Mercury Tours”>“Flight Confirmation: Mercury”。突出显示“检查点`New York'”。 

在“详细信息”窗格中，可以查看文本检查点的详细信息。

8) 关闭“测试结果”窗口。

二、参数化测试

当您测试应用程序时，可能希望检查该应用程序用多组数据来执行相同操作的方式。例如，假设您希望检查网站响应十组单独数据的方式。您可以录制十项单独的测试，每项测试都使用自己的一组数据。或者，您也可以创建数据表参数，以便将测试运行十次，而每次运行都使用不同的一组数据。

1．定义数据表参数 

在之前录制的测试脚本预订了从纽约到旧金山的机票，在测试脚本中，纽约是个常数值，也就是说，每次执行测试脚本预定机票时，出发地点都是纽约。在此将会学习如何将测试脚本中的出发地点参数化，如此一来，执行测试脚本时就会以不同的出发地点去预订机票了。 

1) 执行QuickTest并开启「Checkpoint」测试脚本 

2) 将测试脚本另存成名为「Parameter」测试脚本     

3) 确认【Active Screen】是开启的 

4) 选取要参数化的文字 

 在Keyword View中，展开(+)【Action1】>【"Welcome: Mercury Tour"】>【"Find a Flight: Mercury"】。 在Keyword View中点选"fromPort"右边的【Value】字段，然后再点选参数化，如图3-14所示 。 

图3-14 参数值配置选项

 点选图标，会开启【Value Configuration Options】对话窗口。 

5) 设定要参数化的属性 

点选Parameter。如此一来，就可以使用参数值来取代纽约（New York）这个常数值。请选择【Data Table】这个选项，这个选项表示此参数的值会从QuickTest的Data Table中取得。而且【Name】字段会出现p_Item，请将其修改成departure。 如图3-15所示。

点选【OK】关闭窗口。QuickTest会在Data Table中新增departure参数字段，并且插入一行New York的值。则New York会成为测试脚本执行时所用的第一个值。

图3-15 参数值设置

2．在数据表中输入参数 

QuickTest会在Data Table中显示参数值。可以在Data Table中加入更多笔出发地点的资料，让QuickTest可以使用这些资料执行测试脚本。 

1) 在departure字段输入更多数据

2) 储存测试脚本 

请特别注意一下在Keyword View中的变化。在参数化之前，此测试步骤是显示【"fromPort" Select " New York"】。现在，这个测试步骤变成了【fromPort Select DataTable(“departure”, DTGlobalSheet)】。而且当您点选【Value】字段时，【Value】字段会变成，表示此测试步骤已经被参数化了，而且其值是从Data Table中的departure字段中取得。

3．修改受参数化影响的步骤

参数化测试中的某一步骤后，在更改参数化的步骤的值时其他测试对象可能会受到影响。如果发生这种情况，您必须修改这些对象的预期值以匹配从参数化步骤中生成的值。在本部分中，将修改文本检查点，以便在运行测试时，QuickTest 检查与当前出发城市相匹配的文本。 

1) 定位要修改的文本检查点。

在关键字视图中，单击 (+) 展开“Welcome:Mercury Tours”。 

右键单击“Flight Confirmation:Mercury”，然后选择“检查点属性”。将打开“文本检查点属性”对话框，如图3-16所示。

图3-16文本检查点属性

2) 参数化文本检查点。

在“已检查的文本”区域，“New York”显示在“常量”框中。“New York”是每一次循环时检查点的预期值。

选择“参数”，然后单击“参数选项”按钮  。将打开“参数选项”对话框，如图3-17所示。

3-17 参数选项

在“名称”框中，选择“departure”。这将指示检查点使用数据表中的 departure 参数值作为预期结果。 单击“确定”关闭“参数选项”对话框，然后再次单击“确定”关闭“文本检查点属性”对话框。现已将该检查点参数化。 

3) 保存测试。

4. 运行并分析使用参数的测试步骤 

执行修改完成后的「Parameter」测试脚本，QuickTest会使用Data Table中departure字段的值，执行三次测试脚本。  

1) 执行「Parameter」测试脚本 

2) 检查测试结果  

 即使文本检查点在三次循环中都通过，“测试结果”窗口也会显示测试的第二次和第三次循环失败。有关循环失败原因的详细信息，请参阅以下内容。

循环 2： 在results tree中，展开(+)【Parameter Iteration 2】>【Action1 Summary】>【Welcome Mercury Tours】>【Flight Confirmation: Mercury】。选取【Checkpoint:"New York"】。如图3-18所示。

在检查点的【Details】窗格中，显示Portland为预期结果同时也是实际值，所以此文字检查点为通过。你也可以看到在下方的【Application】窗格中，显示机票的出发地点也是Portland。 

循环3（Iteration 3）： 在results tree中，展开(+)【Parameter Iteration 3】>【Action Summary】> 【Welcome Mercury Tours】>【Flight Confirmation: Mercury】。 选取【Checkpoint:"New York"】。

在检查点的【Details】窗格中，显示Seattle为预期结果同时也是实际值，所以此文字检查点为通过。你也可以看到在下方的【Application】窗格中，显示机票的出发地点也是Seattle。

图3-18测试结果

每次执行时，此文字检查点的结果如表3-2所示。

表3-2文本检查点测试结果

注意：虽然每次执行时，文字检查点的结果是通过的，但是第二次与第三次的执行结果仍然为失败。这是因为出发地点改变，造成在表格检查点中的机票价钱改变，导致表格检查点失败。在以后将会修正表格检查点，让QuickTest自动更新表格检查点的预期结果，就可以检查正确的票价了。 

3) 关闭测试结果窗口  

3.5.4 实验设备

主流PC机一套，要求安装windows操作系统、Quick Test Professional8.2、OFFICE工具；

3.5.5 实验内容

1．题目一：创建检查点

在前一个实验（QuickTestProfessional初级使用）中录制的脚本中创建检查点，包括检查对象、检查页面、检查文本、检查表格。然后执行测试脚本，并分析测试脚本。

2．题目二：参数化测试

使用前一个实验（QuickTestProfessional初级使用）录制的脚本，进行参数化测试。

3.5.6 实验步骤

在上一个实验中，创建并运行了测试，以检查在应用程序上或网站上执行的一系列步骤是否可以顺利执行。本实验要求对上一个实验做增强测试。通过在测试中插入检查点可以搜索页面、对象或文本字符串中的特定值，有助于确定应用程序或网站是否正常运行。通过扩大测试范围（用参数替换固定值），可以检查应用程序如何使用多组数据来执行相同的操作。 本实验需测试步骤如下：

1.检查对象：选取一个对象，创建标准检查点，检查该对象的属性值；

2.检查文本：选取文本，创建文本检查点；

3.检查表格：选取一个表格，检查表中的信息；

4.参数化测试：选取可参数化的文本或对象，进行参数化测试。

3.5.7 实验要求

1.撰写实验报告，主要填写本人上机测试步骤和测试内容；

2.提交录制的测试脚本。

3.6 LoadRunner的使用

3.6.1 实验类型

实验类型为验证型，2个学时。

3.6.2 实验目的

了解LoadRunner的安装过程，并进行安装实验。了解LoadRunner测试模式和测试过程，并能够使用LoadRunner进行简单的测试工作。

3.6.3 LoadRunner功能简介

   具体功能介绍见LoadRunnerManual.pdf

3.7 Web系统测试

3.7.1 实验类型

实验类型为综合型，8个学时。

3.7.2 实验目的

应用Web测试工具对Web系统进行功能和性能测试；

3.7.3 背景知识

对Web系统测试需要从功能、性能、可用性、安全性等多方面进行测试。

一、 功能测试 

对Web系统进行功能测试包括以下几个方面：

1. 链接测试 

链接是 Web 应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先，测试所有链接是否按指示的那样确实链接到了该链接的页面；其次，测试所链接的页面是否存在；最后，保证 Web 应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面。 　

2. 表单测试 

当用户给 Web 应用系统管理员提交信息时，就需要使用表单操作，例如用户注册、登陆、信息提交等。在这种情况下，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。如果表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。

3. Cookies测试 

Cookies通常用来存储用户信息和用户在应用系统的操作，当一个用户使用 Cookies访问了某一个应用系统时， Web 服务器将发送关于用户的信息，把该信息以 Cookies 的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。 

如果 Web 应用系统使用了 Cookies ，就必须检查 Cookies 是否能正常工作。测试的内容可包括 Cookies 是否起作用，是否按预定的时间进行保存，刷新对 Cookies 有什么影响等。 

4. 数据库测试 

在 Web 应用技术中，数据库起着重要的作用，数据库为 Web 应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。

    在使用了数据库的 Web 应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。

二、性能测试

对Web系统进行性能测试主要包括以下几个方面：

1. 连接速度测试 

用户连接到 Web 应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果 Web 系统响应时间太长（例如超过 5 秒钟），用户就会因没有耐心等待而离开。 另外，有些页面有超时的，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。 

2. 负载测试 

负载测试是为了测量 Web 系统在某一负载级别上的性能，以保证 Web 系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问 Web 系统的用户数量，也可以是在线数据处理的数量。例如： Web 应用系统能允许多少个用户同时在线？如果超过了这个数量，会出现什么现象？ Web 应用系统能否处理大量用户对同一个页面的请求？ 

3. 压力测试 

进行压力测试是指实际破坏一个 Web 应用系统，测试系统的反映。压力测试是测试系统的和故障恢复能力，也就是测试 Web 应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到 Web 应用系统崩溃，接着当系统重新启动时获得存取权。 

压力测试的区域包括表单、登陆和其他信息传输页面等。

三、 可用性测试 

1. 导航测试 

导航描述了用户在一个页面内操作的方式。通过考虑下列问题，可以决定一个 Web 应用系统是否易于导航：导航是否直观？ Web 系统的主要部分是否可通过主页存取？ Web 系统是否需要站点地图、搜索引擎或其他的导航帮助？ 　　

2. 图形测试 

一个 Web 应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有： 

（1）确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。

（2）验证所有页面字体的风格是否一致。 

（3）背景颜色应该与字体颜色和前景颜色相搭配。

（4）图片的大小和质量也是一个很重要的因素，一般采用 JPG 或 GIF 压缩。 

3. 内容测试 

内容测试用来检验 Web 应用系统提供信息的正确性、准确性和相关性。 

4. 整体界面测试

整体界面是指整个 Web 应用系统的页面结构设计，是给用户的一个整体感。对整体界面的测试过程，其实是一个对最终用户进行调查的过程。一般 Web 应用系统采取在主页上做一个调查问卷的形式，来得到最终用户的反馈信息。 

3.7.4 实验设备

主流PC机一套，要求安装windows操作系统、QuickTest Professional测试工具、WebLoad、OFFICE工具；

3.7.5 实验内容

1．题目一：测试网站功能

选择一个网站，对其进行功能测试。要求首先编写测试用例，然后用QuickTest Professional自动化测试工具对该网站进行测试。

2．题目二：测试网站性能

选择一个网站，对其进行性能测试。要求使用WebLoad进行压力测试。（WebLoad使用方法请参阅文档：“用webload进行web application性能测试.doc”）

3.7.6 实验步骤

1．题目一实验步骤

（1）拟定测试计划；

（2）撰写测试方案；

（3）设计测试用例；

（4）录制测试脚本；

（5）根据录制的脚本和测试用例创建页面检查点、对象检查点、文本检查点或者表格检查点；根据测试脚本和测试用例，进行参数化测试；

（6）分析测试结果。

2．题目二实验步骤

（1）计划一个压力会话；

（2）创建测试议程；

（3）创建压力模板；

（4）运行压力模板；

（5）输入测试报告并分析测试结果。

（6）

3.7.7 实验要求

1．撰写实验报告；

2．撰写Web系统的测试计划，测试方案；

3．撰写Web系统测试的测试用例；

4．撰写缺陷报告；

5．提交测试脚本。