测试用例设计方法有哪些

一、等价类划分法

所谓「等价」，就是具有相同属性或者方法的集合，这个集合中某个个体所表现的特征与其他个体完全一致。

由此可知，等价类划分就是将所有可能的输入数据，划分成若干个等价类，然后从每个部分中选取具有代表性的数据当做测试用例进行合理的分类，分为有效等价类和无效等价类。

例如，规定的用户名长度区间为4～8个字，那么它的有效等价类是用户名长度在[4,8]，无效等价类为用户名长度大于8位，或用户名长度小于4位。

二、边界值

测试经验告诉我们，在测试有时会涉及到大量的数据，遍历所有数据会使测试效率低下，如果是手工执行，更加难以覆盖所有数据。这时更有效率的做法是，先划分等价类，再从等价类中选择部分参数测试，边界值是等价类所有可选参数中最容易出问题的地方，所以我们一般会选择边界值作为测试的重点，边界值法的应用步骤如下：

1.先根据等价类法划分有效等价类和无效等价类，确定上点、离点及内点。上点是边界上的点，离点是离上点最近的点，内点则是边界有效范围内的任意一点。同样以用户名长度为4～8位为例，4和8为上点，3和9为离点，6则为内点。

2.设计一个新的测试用例，使其尽可能地覆盖所有尚未覆盖的有效等价类，直到所有有效等价类完全覆盖。

3.设计一个新的测试用例，使其仅覆盖一个无效等价类，直到所有无效等价类都被覆盖。

三、判定表法

判定表又称策略表、决策表，能表示输入条件的组合，以及与每一输入组合对应的动作组合。判定表法适合逻辑判断比较复杂的场景，通过穷举条件获得结果，对结果再进行优化合并，具体又明确地表达复杂地逻辑关系和多种条件组合情况。

判定表主要由条件桩和动作桩两部分组成。条件桩是功能要满足地所有条件，动作桩则是所有可能的操作以及产生的结果。

判定表能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。其缺点是判定表的建立过程较烦杂，当条件过多时，需要分析的逻辑组合呈2的倍数增长。测试工程师可根据实际情况与等价类划分法、边界值法结合使用。

四、正交试验法

正交试验法是研究多因素、多水平组合的一种实验法，它是利用正交表来对实验进行设计，通过少数的实验替代全面实验。正交表中所有参与试验的、影响试验结果的条件成为因子，影响试验因子的取值或输入的成为水平。

在设计测试用例时，采用正交试验法能够有效地、合理地减少测试的工作量与和成本。正交试验的一般流程包括以下几个步骤：

1）分析测试需求，获取因子和水平

2）根据因子和水平选择合适的正交表

3）替换正交表中的因子和水平，获取试验次数

4）根据经验或者其他因素补充试验次数

5）细化输出获得测试用例

以上是一些常见的测试用例设计方法，希望能够解答你的问题。

在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率。

测试用例的使用令软件测试的实施重点突出、目的明确。

在软件版本更新后只需修正少部分的测试用例便可展开测试工作，降低工作强度、缩短项目周期。

检验软件是否满足客户需求、体现一个测试人员的工作量、展现测试用例的设计思路。

必须掌握：用例编号(如何命名)、所属模块、用例标题（验证谁在什么情况下，去做什么，最后结果是什么）、优先级、前置条件、操作步骤、测试数据、预期结果、实际结果

了解内容：通过否、bugID、编写人员、编写时间、测试人员、测试时间、备注

测试用例覆盖所有的用户需求

测试用例要简单明了

各类型的测试用例要齐全

用最少的用例覆盖最多的需求

等价类划分 是把所有可能输入的数据分为若干个区域，然后从每个区域中取少量有代表性的数据进行测试即可。

等价类 ：何为等价类，某个输入域的集合，在这个集合中每个输入条件都是等效的。

一般可分为有效等价类和无效等价类。

有效等价类：指符合《需求规格说明书》，输入合理的数据集合

无效等价类：指不符合《需求规格说明书》，输入不合理的数据集合

取值范围型： 输入学生成绩    0-100

恒等类型  ： 只有一个结果是正确的，其他都是错误的    例如  彩票的特等奖

布尔值型：  通过是否来进行选择，如同意协议

枚举类型：  给出选项内容，只要符合其中任意一个就可以    例如选择学历

规则类型：  给定要求，满足要求的就可以，比如邮箱

在任意文本输入框中可以填写的字符类型： 中文、英文、特殊符号、空格、数字。

定义：边界值分析 是取稍高于或稍低于边界的一些数据进行测试。

原因： 程序开发循环体时的取数可能会因为<,<=搞错。

上点： 是指边界上的点，无论此时的域是开区间还是闭区间，开区间的话，上点就是在域外，闭区间的话，上点就是在域内。

离点： 是指离上点最近的点，这里就跟是闭区间还是开区间就有关系了，如果是开区间，那么离点就在域内，如果是闭区间，那么离点就在域外。(开内闭外)

遵循的原则：开内闭外    开区间往中间找，闭区间往外找

内点： 域内的任意点都是内点。

0<=x<=10          左上点 0左离点 -1右离点 11 右上点 10 内点 5

0<x<10              左上点 0    左离点 1    右离点 9  右上点 10    内点 5

0<=x<10            左上点 0    左离点 -1    右离点 9  右上点 10    内点 5

因果图法比较适合输入条件比较多的情况，测试所有的输入条件的排列组合。所谓的原因就是输入，所谓的结果就是输出。

1、确定原因、结果、中间过程

2、连接因果图

3、标明约束条件

4、输出测试用例

错误猜测法是测试经验丰富的人喜欢使用的一种测试用例设计方法。

一般这种方法是基于经验和直觉推测程序中可能发送的各种错误，有针对性地设计。只能作为一种补充。

输入一串数字，程序可自动从小到大排序

邮箱格式@符合的全角以及半角情况

测试手机终端的通话功能，可以设计各种通话失败的情况来补充测试用 例：

无SIM 卡插入时进行呼出（非紧急呼叫）

插入已欠费SIM卡进行呼出

射频器件损坏或无信号区域插入有效SIM卡呼出

网络正常，插入有效SIM卡，呼出无效号码（如1、888、333333、不输入任何号码等）

网络正常，插入有效SIM卡，使用“快速拨号”功能呼出设置无效号码的数字

最重要的是要思考和分析测试对象的各个方面，多参考以前发现的bug的相关数据，总结的经验，个人多考虑异常的情况、反面的情况、特殊的输入，以一个攻击者的态度对待程序，就能设计出比较完善的测试用例来。

设计测试用例时，分析和表达多输入条件下执行不同操作的黑盒测试方法。

注意： 该方法和因果图法相似。

1、确定原因和动作

2、排列组合

3、标明结果关系

4、输出测试用例

日本人提出

使用工具：正交表

正交实验法就是利用排列整齐的表 -正交表来对试验进行整体设计、综合比较、统计分析，实现通过少数的实验次数找到较好的生产条件，以达到最高生产工艺效果。

这种试验设计法是从大量的试验点中挑选适量的具有代表性的点，利用已经造好的表格—正交表来安排试验并进行数据分析的方法。

正交表能够在因素变化范围内均衡抽样，使每次试验都具有较强的代表性，由于正交表具备均衡分散的特点，保证了全面实验的某些要求，这些试验往往能够较好或更好的达到实验的目的。

正交实验设计包括两部分内容：第一，是怎样安排实验；第二，是怎样分析实验结果。

在一个界面中有多个控件，每个控件有多个取值，控件之间可以相互组合，不可能（也没有必要）为每一种组合编写一条用例，如何使用最少最优的组合进行测试。——正交排列法

测试用例也叫测试案例，是在执行测试之前由测试人员编写的指导测试过程的重要文档，主要包括：用例编号、测试目的、测试步骤、预期结果等

注意：不同公司使用的用例模板可能存在差异，但都大同小异

为什么要写测试用例

1、防止测试点的遗漏，让测试覆盖的更全面

2、方便做版本的回归测试

3、监督测试过程，评估结果

4、提高测试效率，避免盲目测试

5、缩短周期，比如当版本更新或升级时，只需修正少部分测试用例即可，用例资源可以做到重复使用

测试用例编写依据

1、业务需求文档或需求规格说明书

2、开发文档，比如概要设计文档、详细设计文档

3、参考已开发出来的程序，即一边对照程序+需求文档，一边写测试用例

4、与开发人员、需求人员、客户进行沟通确认

什么是好的测试用例

1、用例覆盖率最大化：好的测试用例是完整的用例集合，能够完全覆盖测试需求

2、测试数据的准确性：等价类划分准确，每个等价类范围的数据，测试效果一致

3、测试数据的全面性：保证所有可能的边界值和边界条件涵盖在内，且正确识别

设计测试用例的常见方法

1、等价类划分法

2、边界值分析法

3、错误推测法

4、因果图法

5、判定表法

6、正交排列法

7、功能图分析法

8、场景法等

其中，等价类划分法、边界值法、错误推测法是平时工作中最常用的方法，也是设计好一个测试用例的装备武器，本节课主讲等价类划分法和边界值分析法。

方法一：等价类划分法

将所有可能的输入数据划分为若干子集，从每一个子集中，挑选任意输入数据，测试效果是一样的。那么这样的子集就是一个等价类。

比如有一个需求是：某输入框只能输入-99（含）至99（含）之间的整数，且不能为空

有效等价类（有效数据）可划分为：

-99至0之间的任意整数

0至99之间的任意整数

无效等价类（无效数据）可划分为：

小于-99的整数

大于99的整数

为空的情况

非整数的情况（浮点数、字母、特殊字符、中文字符）

如下图：

方法二：边界值分析法

对输入或输出的边界值进行测试的一种黑盒测试方法，即选取边界值进行测试。因为测试数据的边界值在程序中最容易出错，所以边界值应该重点测试。

还是以上面需求为例：某输入框只能输入-99（含）至99（含）之间的整数，且不能为空

有效边界值包括：

-99（最小边界值）

-98（有效最小次边界值）

-1（边界值）

0（边界值）

1（边界值）

98（有效最大次边界值）

99（最大边界值）

无效边界值包括：

-100（无效最小次边界值）

100（无效最大次边界值）

备注：测试过程中，只要是需要输入数据的地方，就可以使用等价类划分法和边界值分析法，这两个方法一般是搭配使用的。

方法三：错误推测法

基于对被测软件系统的理解、过往经验以及个人直觉，推测出软件可能存在的缺陷，从而有针对性地设计测试用例的方法。

即错误的操作，比如输入输出数据为0或空格等容易错误的情况。将其作为测试用例来执行。

         定义： 把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,用少量代表性的测试数据，取得较好的测试结果。等价类划分可有两种不同的情况：有效等价类和无效等价类。

1）确定等价类

             有效等价类：     满足输入条件的

             无效等价类：     不能满足输入条件的     超出范围的数值  

            空值   

            特殊字符   

            有空格（前、中、后）

2）生成测试用例

每个等价类编写一个测试用例；

设计一条测试用例，尽可能多地覆盖所有还未被覆盖的有效等价类；

设计一条测试用例，覆盖一条还未被覆盖到的无效等价类。

等价类划分的六大原则：

1）输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类。

例如：手机号码由11位数字组成

有效：11位符合电话号码规则的数字

无效：1、小于11位数字；2、大于11位数字

2）在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可以确立一个有效等价类和一个无效等价类。

3）在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类。布尔量是一个二值枚举类型，一个布尔量具有两种状态：true和false

4）在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。

例如：

输入条件说明输入为：中文、英文、数字三种之一，则分别取这三种值作为三个有效等价类，另外把这三种字符以外的任何字符作为无效等价类

5）在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）

例如：输入条件说明每个学生可选修1~3门课程

有效：选修1~3门课程

无效：1、未选修课程

            2、选修课程超过3门

6）在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步的划分为更小的等价类。

等价类划分法要点：长度、类型、字母、汉字、特殊字符、空、空格

二、边界值分析法

边界值分析方法是对等价类划分方法的补充。

使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是着重测试边界的情况。选取正好等于，刚刚大于或刚刚小于边界值的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。

1）如果输入条件规定了一个输入值范围，那么应针对范围的边界设计测试用例，针对刚刚越界的情况设计无效输入测试用例；

比如：需求规定输入的数字在0~100范围内，此时测试数据应该有一下几类：

a.刚刚等于边界：0、100；

b.刚刚超出边界范围：-1、101:；

c.刚刚在范围内：1、99

2）如果输入条件规定了输入值的数量，那么应针对最小数量输入值、最大数量输入值，以及比最小数量少一个、比最大数量多一个的情况设计测试用例；

例1：输入手机号码有：

a 输入11位合法数字；b 输入10 位合法数字；c 输入12位合法数字

例2：输入6~8位数字密码：

a 输入6位数字；b 输入8位数字c 输入5位数字；d 输入9位数字

3）如果程序输入或输出是一个有序序列，则应该特别注意该序列的第一个和最后一个元素。

三、错误推测法

错误推测法是基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。需要多实践，且在实践时多积累常见问题。

      错误推测方法的基本思想： 列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据他们选择测试用例-例如， 在单元测试时曾列出的许多在模块中常见的错误-以前产品测试中曾经发现的错误等， 这些就是经验的总结。还有， 输入数据和输出数据为0的情况。输入表格为空格或输入表格只有一行-这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例。

四、因果图法

        因果图法适用于描述对于多种输入条件组合的测试方法。（有多步输入操作）

        根据输入条件的组合、约束条件和输出条件的因果关系，分析输入条件的各种组合情况，从而设计测试用例的方法，它适用于检查程序输入条件涉及的各种组合情况。

例题：有一个处理单价为1元5角钱的盒装饮料的自动售货机软件。若投入1元5角硬币，按下“可乐”、“雪碧”、“红茶”按钮，相应的饮料就送出来。若投入的是两元硬币，在送出饮料的同时退还5角硬币。

分析：

输入条件：a  投入1元5角硬币      b  投入2元硬币

1  按“可乐”按钮        2  按“雪碧”按钮      3  按“红茶”按钮

中间状态：1  已投币      2  已按按钮

输出结果：A  送出可乐  B  送出雪碧    C  送出红茶    D  退还5角硬币

测试用例：

1）投币1元5角，按“可乐”按钮，送出可乐

2）投币1元5角，按“雪碧”按钮，送出雪碧

3）投币1元5角，按“红茶”按钮，送出红茶

4）投币2元，按“可乐”按钮，送出可乐，退5角硬币

5）投币2元，按“雪碧”按钮，送出雪碧，退5角硬币

6）投币2元，按“红茶”按钮，送出红茶，退5角硬币

输入组合：投硬币+按按钮

结果组合：送出饮料+退钱

用例编号

测试用例的编号有一定的规则，比如系统测试用例的编号这样定义规则： PROJECT1-ST-001 ，命名规则是项目名称+测试阶段类型（系统测试阶段）+编号。定义测试用例编号，便于查找测试用例，便于测试用例的跟踪。

测试标题

对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。比如 “ 测试用户登录时输入错误密码时，软件的响应情况 ” 。

重要级别

定义测试用例的优先级别，可以笼统的分为 四个不同的等级

输入限制

提供测试执行中的各种输入条件。根据需求中的输入条件，确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性，如果软件需求中没有很好的定义需求的输入，那么测试用例设计中会遇到很大的障碍。

操作步骤

提供测试执行过程的步骤。对于复杂的测试用例，测试用例的输入需要分为几个步骤完成，这部分内容在操作步骤中详细列出。

预期结果

提供测试执行的预期结果，预期结果应该根据软件需求中的输出得出。如果在实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过；反之则测试通过。

——从登陆开始说起

一个完整的software testing life cycle包括诸多内容，本文仅从测试用例的编写开始，聊聊测试用例编写的一般步骤，以使编写的测试用例最大程度上满足完备的要求，而又不产生重复而冗余的负担。 测试用例的来源是产品需求，如果足够幸运，我们应当有一份不错的可依赖的Use Case文件，但大部分情况下，Use Case恐怕是不存在，能有一份不错的PRD文件和原型设计图已经是不错的待遇了，如果可能的话，最好还能够有HLD文件，这些已经足够我们开始写详细的测试用例文件我相信在这之前无法产出详细的测试用例文件①。也许LLD文件产生之后或者产品的第一个版本释出之后，我们会不断的更新已有的测试用例，但那将是不断的迭代过程，暂不做讨论。

首先让我们先从理论上了解测试用例编写的一般步骤②：

1、确定测试套件Test Suite：测试套件是功能上的划分，是相似测试场景的组合，而非技术划分。如果技术设计中各模组耦合度较高强烈推荐解耦，哪怕复制贴上程式码，可能功能上不相干的模组由于程式码重用的原因会在bug fix时互相引致错误，实际上回归测试即是为了避免这种情况。但是我们在做功能测试划分模组时，还是要从使用者的角度出发，按照使用者场景划分测试的“模组”。值得庆幸的是，相似或相关的功能总是倾向于在同一组页面出现，按钮和输入框、选择选单等内容并不是随机组合的一堆零件。

2、针对每一个测试套件，确定一个或多个基本流程basic flow和可选流程alternative flow，即测试场景Test Scenario：可以借助scenario matrix来清晰地对可能出现的场景进行排列组合。值得注意的是，一方面Use Case或PRD文件中的描述很有可能并没有完整的写尽所有的场景，测试人员尽可能地挖掘测试场景，既有可能是出于测试本身的需要，也可能是基于开发团队的工作另一方面，在复杂系统中，测试场景不可能覆盖所有可能的场景，这便需要测试人员采用一定的测试策略③，对SUTSystem under Testing进行“足够adequate”的测试，而不是完全的测试。

3、针对每一个测试场景，确定一到多个测试用例Test Case：仍然可以借助matrix来清晰地规划测试用例，每一个测试用例都有其对应的预置条件④、输入和期望结果。测试用例分为Positive Test Case和Negative Test Case两种，分别用来测试产品是否完成应当完成的工作和不执行不应当完成的操作。更详尽地说，测试用例一般包括以下列column：用例编号/测试场景/用例描述/需求对应/用例分类Positive/Negative/用例型别/用例级别/是否自动化/预置条件/测试步骤/测试资料/预期结果/实际结果/备注/

4、增加测试资料Test Data完成测试用例：测试资料是测试用例中很重要的内容，一个用例可能对应多套测试资料，测试工程师根据某种测试技术⑤，将尽可能的设计较少的测试资料完成“足够”的测试。 任何规范、流程都是为了让工作更加可靠，对于专案工程，天外飞仙灵机一动应当放在合适的位置，而不应当成为规范和流程的反例存在⑥。

现在让我们开始从登陆PC端网页，如果是PC客户端比如QQ或手机客户端则又不同开始说起。 不开启任何网站的登陆框，想象一下登陆框的样子。

然后对照一下本文最后的附图，一个优秀的登陆框除了基本的使用者名称/密码输入框、登陆按钮之外、不考虑注册、找回密码、第三方登陆、登陆版本、帮助，包含的内容有：输入框文字提示/免登陆选项/输入的表单提示新浪微博/必要的验证码出错时的处理/使用者名称和密码输入错误正确提示/焦点反馈/快速删除已输入字元/Tab切换/滑鼠点选有字元输入框游标位置/Enter键选中/密码非明文显示/是否弹窗显示不要打断正在处理的任务/页面跳转/进度反馈网路较差的情况/多账户登入/多终端登入/Cookie/token

最后值得强调的是，真正能够保证产品质量的是开发人员而不是测试。在一个完整的软体工程周期中，开发人员从建设的角度保证产品质量，测试人员从破坏的角度检验产品质量。如果在测试用例执行环节提交了成百上千的bug，即便最终每个bug都被修复，新产生的bug数量一直在收敛，这样的软体产品恐怕也不是让人有足够信心释出出去的产品。实际上，从经验来看，总是有大量的bug被使用者发现，即使测试人员采用了单元、介面、自动化、Monkey等诸多手段进行测试，由于受限于测试场景、测试次数等因素，这种情况仍然是无法避免的。

让测试人员在专案早期介入，与开发人员一起评审技术设计，是减少这种情况并从根源上提高产品质量的方法之一。但是需要指出的是，这只是理想化的假设。一是测试工程师缺乏专案经验，测试开发与开发毕竟是两种工作，评审技术设计有一定的难度二是如果测试工程师有大量的专案经验，很容易与开发人员从同样的角度思考问题，这便偏离了初衷。

由此可见，成为一个优秀的测试工程师并不是一件容易的事情，既需要有专业的技术，又需要能够从技术中抽身，从不同的角度考虑问题既要有吹毛求疵的完美主义精神，又要能够权衡效率，并对自己的选择所可能产生的风险有所估量。运用之妙存乎一心，这实际上就是大量实践中才能获得的经验了，无法详述。

Notes：

①关于这种说法需要进一步关注Model-based Testing另，Software Development Life CycleSDLC是一个让人眼花缭乱的概念，务虚，但又十分有用。

②这实际上是采用了自顶向下的设计方法

③测试策略：Traceability Matrix等，待完善

④我希望Test Cases成为一个池子，测试条件放在System Testing Specification文件中来统一归档，该文件中还应当包括测试环境等相关配置。除此之外，如果有Test Procedure，也使用另外的文件用来管理。

⑤测试技术：等价类划分、边界值条件等

⑥敏捷、探索性测试待深入理解

测试用例设计结果分析

软体测试执行结束后，测试活动还没有结束。测试结果分析是必不可少的重要环节， “ 编筐编篓，全在收口 ” ，测试结果的分析对下一轮测试工作的开展有很大的借鉴意义。前面的 “ 测试准备工作 ” 中，建议测试人员走读缺陷跟踪库，查阅其他测试人员发现的软体缺陷。测试结束后，也应该分析自己发现的软体缺陷，对发现的缺陷分类，你会发现自己提交的问题只有固定的几个类别然后，再把一起完成测试执行工作的其他测试人员发现的问题也汇总起来，你会发现，你所提交问题的类别与他们有差异。这很正常，人的思维是有局限性，在测试的过程中，每个测试人员都有自己思考问题的盲区和测试执行的盲区，有效的自我分析和分析其他测试人员，你会发现自己的盲区，有针对性的分析盲区，必定会在下一轮测试中避免盲区。

我总结的测试用例的划分有三种：

1）按照功能划分

2）按照路径（业务流程）划分

3）按照功能和路径（业务流程）划分

目前我用的方法是第三种。第一种按照功能划分，优点是最简捷，但其缺点是：对于复杂操作的程序模块，其各功能的实施是相互影响，紧密相关，环环相扣的。如果没有严密的逻辑分析，很容易产生遗漏。第二种纯粹按照路径划分也容易造成对功能点的遗漏。所以我基本都是大方向用功能块的划分来走，然后再结合上路径（业务流程）的划分方法。

case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。

目的：

⒈指导测试的实施

测试用例主要适用于集成测试、系统测试和回归测试。在实施测试时测试用例作为测试的标准，测试人员一定要按照测试用例严格按用例项目和测试步骤逐一实施测试。并对测试情况记录在测试用例管理软件中，以便自动生成测试结果文档。

根据测试用例的测试等级，集成测试应测试那些用例，系统测试和回归测试又该测试那些用例，在设计测试用例时都已作明确规定，实施测试时测试人员不能随意作变动。

⒉规划测试数据的准备

在我们的实践中测试数据是与测试用例分离的。按照测试用例配套准备一组或若干组测试原始数据，以及标准测试结果。尤其象测试报表之类数据集的正确性，按照测试用例规划准备测试数据是十分必须的。

除正常数据之外，还必须根据测试用例设计大量边缘数据和错误数据。

⒊编写测试脚本的"设计规格说明书"

为提高测试效率，软件测试已大力发展自动测试。自动测试的中心任务是编写测试脚本。如果说软件工程中软件编程必须有设计规格说明书，那么测试脚本的设计规格说明书就是测试用例。

⒋评估测试结果的度量基准

完成测试实施后需要对测试结果进行评估，并且编制测试报告。判断软件测试是否完成、衡量测试质量需要一些量化的结果。例：测试覆盖率是多少、测试合格率是多少、重要测试合格率是多少，等等。以前统计基准是软件模块或功能点，显得过于粗糙。采用测试用例作度量基准更加准确、有效。

⒌分析缺陷的标准

通过收集缺陷，对比测试用例和缺陷数据库，分析确证是漏测还是缺陷复现。漏测反映了测试用例的不完善，应立即补充相应测试用例，最终达到逐步完善软件质量。而已有相应测试用例，则反映实施测试或变更处理存在问题。