边界值分析法能超出边界吗,边界值分析法应用步骤

图5-7 全面试验法取点

全面试验对各因子与指标间的关系剖析得比较清楚。但试验次数太多。特别是当因子数目多，每个因子的水平数目也很多时，试验量非常大。如选6个因子，每个因子取5个水平时，如欲做全面试验，则需56＝15625次试验，这实际上是不可能实现的。如果应用将要介绍的正交试验法，只做25次试验就行了。而且在某种意义上讲，这25次试验代表了15625次试验。

② 简单对比法，即变化一个因素而固定其他因素，如首先固定B、C于Bl、Cl，使A变化：

↗A1

B1C1 →A2

↘A3（好结果）

如得出结果A3最好，则固定A于A3，C还是Cl，使B变化：

↗B1

A3C1 →B2 （好结果）

↘B3

得出结果以B2为最好，则固定B于B2，A于A3，使C变化：

↗C1

A3B2→C2 （好结果）

↘C3

试验结果以C2为最好。于是就认为最好的工艺条件是A3B2C2。

这种方法一般也有一定的效果，但缺点很多。首先这种方法的选点代表性很差，如按上述方法进行试验，试验点完全分布在一个角上，而在一个很大的范围内没有选点，因此这种试验方法不全面，所选的工艺条件A3B2C2不一定是27个组合中最好的。其次，用这种方法比较条件好坏时，是把单个的试验数据拿来，进行数值上的简单比较，而试验数据中必然包含着误差成分，所以单个数据的简单比较不能剔除误差，必然造成结论的不稳定。

简单对比法的最大优点就是试验次数少，例如，6因子5水平试验，在不重复时，只用5 （6–1）×（5–1）＝5 5×4＝25次试验就可以了。

考虑兼顾这两种试验方法的优点，从全面试验的点中选择具有典型性、代表性的点，使试验点在试验范围内分布得很均匀，能反映全面情况。但我们又希望试验点尽量地少，为此还要具体考虑一些问题。 如上例，对应于A有Al、A2、A3 3个平面，对应于B、C也各有3个平面，共9个平面。则这9个平面上的试验点都应当一样多，即对每个因子的每个水平都要同等看待。具体来说，每个平面上都有3行、3列，要求在每行、每列上的点一样多。这样，作出如图5-8所示的设计，试验点用⊙表示。我们看到，在9个平面中每个平面上都恰好有3个点，而每个平面的每行每列都有1个点，而且只有1个点，总共9个点。这样的试验方案，试验点的分布很均匀，试验次数也不多。

当因子数和水平数都不太大时，尚可通过作图的办法来选择分布很均匀的试验点。但是因子数和水平数多了，作图的方法就不行了。试验工作者在长期的工作中总结出一套办法，创造出所谓的正交表。按照正交表来安排试验，既能使试验点分布得很均匀，又能减少试验次数，而且计算分析简单，能够清晰地阐明试验条件与指标之间的关系。用正交表来安排试验及分析试验结果，这种方法叫正交试验设计法。

一般用L代表正交表，常用的有L8（27）、L9（34）、L16（45）、L8（4×24）等。此符号各数字的意义如下。

例如：L8（27），其中，7为此表列的数目（最多可安排的因子数）；2为因子的水平数；8为此表行的数目（试验次数）。

又例如：L18（2×37），有7列是3水平的，有1列是2水平的，L18（2×37）的数字告诉我们，用它来安排试验，做18个试验最多可以考察1个2水平因子和7个3水平因子。

在行数为mn型的正交表中（m，n是正整数），试验次数（行数）＝（每列水平数–1） l，如L8（27），8＝7×（2–1） l，利用上述关系式可以从所要考察的因子水平数来决定最低的试验次数，进而选择合适的正交表。比如要考察5个3水平因子及一个2水平因子，则起码的试验次数为5×（3–1） 1×（2–1） 1＝12（次），这就是说，要在行数不小于12，既有2水平列又有3水平列的正交表中选择，L18（2×37）适合。正交表具有两条性质：每一列中各数字出现的次数都一样多；任何两列所构成的各有序数对出现的次数都一样多。所以称之为正交表。

例如，在L9（34）中（如表5-7所示），各列中的l、2、3都各自出现3次；任何两列，例如第3、4列，所构成的有序数对从上向下共有9种，既没有重复也没有遗漏。其他任何两列所构成的有序数对也是这9种各出现一次。这反映了试验点分布的均匀性。

表5-7 L9（34）正交表

试验方案应该如何设计呢？安排试验时，只要把所考察的每一个因子任意地对应于正交表的一列（一个因子对应一列，不能让两个因子对应同一列），然后把每列的数字“翻译”成所对应因子的水平。这样，每一行的各水平组合就构成了一个试验条件（不考虑没安排因子的列）。对于上例，因子A、B、C都是3水平的，试验次数要不少于3× （3–1） 1＝7（次），可考虑选用L9（34）。因子A、B、C可任意地对应于L9（34）的某三列，例如A、B、C分别放在l、2、3列，然后试验按行进行，顺序不限，每一行中各因素的水平组合就是每一次的试验条件，从上到下就是这个正交试验的方案，如表5-8所示。这个试验方案的几何解释正好是正交试验设计图例。

表5-8试 验 方 案

3个3水平的因子，做全面试验需要33＝27次试验，现用L9（34）来设计试验方案，只要做9次，工作量减少了2/3，而在一定意义上代表了27次试验。

2．正交试验测试用例设计步骤

利用正交试验设计测试用例的步骤如下。

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

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

 利用正交表构造测试数据集，正交表的推导依据Galois理论。

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

正交试验法在软件测试中是一种有效的方法，例如在平台参数配置方面，我们要选择哪种组合方式是最好的，每个参数可能就是一个因子，参数的不同取值就是水平，这样我们可以采用正交试验法设计出最少的测试组合，达到有效的测试目的。

2.8 功能图法

一个程序的功能说明通常由动态说明和静态说明组成。动态说明描述了输入数据的次序或转移的次序。静态说明描述了输入条件与输出条件之间的对应关系。对于较复杂的程序，由于存在大量的组合情况，因此，仅用静态说明组成的规格说明对于测试来说往往是不够的，必须用动态说明来补充功能说明。

1．功能图设计方法

功能图方法是用功能图形象地表示程序的功能说明，并机械地生成功能图的测试用例。功能图模型由状态迁移图和逻辑功能模型构成。

 状态迁移图用于表示输入数据序列以及相应的输出数据。在状态迁移图中，由输入数据和当前状态决定输出数据和后续状态。

 逻辑功能模型用于表示在状态中输入条件和输出条件之间的对应关系。逻辑功能模型只适合于描述静态说明，输出数据仅由输入数据决定。测试用例则是由测试中经过的一系列状态和在每个状态中必须依靠输入/输出数据满足的一对条件组成。

功能图方法实际上是一种黑盒、白盒混合用例设计方法。

功能图方法中要用到逻辑覆盖和路径测试的概念和方法，属白盒测试方法中的内容。逻辑覆盖是以程序内部的逻辑结构为基础的测试用例设计方法，该方法要求测试人员对程序的逻辑结构有清楚的了解。由于覆盖测试的目标不同，逻辑覆盖可分为：语句覆盖、判定覆盖、判定-条件覆盖，条件组合覆盖及路径覆盖。下面我们指的逻辑覆盖和路径是功能或系统水平上的，以区别于白盒测试中的程序内部的，如图5-9及表5-9所示。

图5-9 功能图

表5-9 判 定 表

续表

2．功能图法生成测试用例

功能图由状态迁移图和布尔函数组成。状态迁移图用状态和迁移来描述一个状态，指出数据输入的位置（或时间），而迁移则指明状态的改变，同时要依靠判定表和因果图表示的逻辑功能。

采用什么样的方法生成测试用例？从功能图生成测试用例，得到的测试用例数是可接受的。问题的关键是如何从状态迁移图中选取测试用例。若用节点代替状态，用弧线代替迁移，状态迁移图就可转化成一个程序的控制流程图形式。问题就转化为程序的路径测试问题（白盒测试范畴概念）了。

测试用例生成规则：为了把状态迁移（测试路径）的测试用例与逻辑模型的测试用例组合起来，从功能图生成实用的测试用例，需定义下面的规则。一个结构化的状态迁移中，定义3种形式的循环：顺序、选择和重复。但分辨一个状态迁移中的所有循环是有困难的。

从功能图生成测试用例的过程如下。

 生成局部测试用例：在每个状态中，从因果图生成局部测试用例。局部测试库由原因值（输入数据）组合与对应的结果值（输出数据或状态）构成。

 测试路径生成：利用上面的规则生成从初始状态到最后状态的测试路径。

 测试用例合成：合成测试路径与功能图中每个状态的局部测试用例。结果是视状态到最后状态的一个状态序列，以及每个状态中输入数据与对应输出数据组合。

 测试用例的合成算法：采用条件构造树。

2.9 场景法

现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。

提出这种测试思想的是Rational公司，并在RUP2000中文版中有详尽的解释和应用。

用例场景用来描述流经用例的路径，从用例开始到结束遍历这条路径上所有基本流和备选流。

1．基本流和备选流

如图5-10所示，图中经过用例的每条路径都用基本流和备选流来表示，直黑线表示基本流，是经过用例的最简单的路径。备选流用不同的彩色表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中（如备选流1和3）；也可能起源于另一个备选流（如备选流2），或者终止用例而不再重新加入到某个流（如备选流2和4）。

按照如图5-10中所示的每个经过用例的路径，可以确定以下不同的用例场景。

场景1：基本流；

场景2：基本流、备选流1；

场景3：基本流、备选流1、备选流2；

场景4：基本流、备选流3；

场景5：基本流、备选流3、备选流1；

场景6：基本流、备选流3、备选流1、备选流2；

场景7：基本流、备选流4；

场景8：基本流、备选流3、备选流4。

注：为方便起见，场景5、6和8只考虑了备选流 3循环执行一次的情况。

需要说明的是，为了能清晰地说明场景，我们所举的例子都非常简单，在实际应用中，测试用例很少如此简单。

2．ATM例子

（1）例子描述

如图5-11所示是ATM例子的流程示意图。

图5-10 基本流和备选流图

5-11 ATM流程示意图

如表5-10所示，包含了如图5-11中所示提款用例的基本流和某些备用流。

表5-10 用 例 流

续表

（2）场景设计

如表5-11所示是生成的场景。

表5-11 场 景 设 计

注：为方便起见，备选流 3 和 6（场景 3 和 7）内的循环以及循环组合未纳入表中。

（3）用例设计

对于这7个场景中的每一个场景都需要确定测试用例，一般采用矩阵或决策表来确定和管理测试用例。如表5-12所示是一种通用格式，其中行代表各个测试用例，列代表测试用例的信息。本例中的测试用例包含测试用例ID、场景/条件、测试用例中涉及的所有数据元素和预期结果等项目。首先确定执行用例场景所需的数据元素，然后构建矩阵，最后要确定包含执行场景所需的适当条件的测试用例。在下面的矩阵中，V表示这个条件必须是有效的才可执行基本流，I表示这种条件下将激活所需备选流 ，n/a表示这个条件不适用于测试用例。

表5-12 测试用例表

在上面的矩阵中，六个测试用例执行了四个场景。对于基本流，上述测试用例CW1被称为正面测试用例。它一直沿着用例的基本流路径执行，未发生任何偏差。基本流的全面测试必须包括负面测试用例，以确保只有在符合条件的情况下才执行基本流。这些负面测试用例由CW2～CW6表示。虽然CW2～CW6相对于基本流而言都是负面测试用例，但它们相对于备选流2～4而言是正面测试用例。而且对于这些备选流中的每一个而言，至少存在一个负面测试用例，就是CW1-基本流。

每个场景只有一个正面测试用例和负面测试用例是不充分的，场景4正是这样的一个示例。要全面地测试场景4-PIN有误，至少需要三个正面测试用例，以激活场景4：

① 输入了错误的PIN，但仍存在输入机会，此备选流重新加入基本流中的步骤 3-输入PIN。

② 输入了错误的PIN，而且不再有输入机会，则此备选流将保留银行卡并终止用例。

③ 最后一次输入时输入了“正确”的 PIN。备选流在步骤5-输入金额处重新加入基本流。

注意，在上面的矩阵中，无需为条件输入任何实际的值。以这种方式创建测试用例矩阵的一个优点在于容易看到测试的是什么条件。由于只需要查看 V和 I，这种方式还易于判断是否已经确定了充足的测试用例。从表5-12中可发现存在几个无效的条件I，这表明测试用例还不完全，如场景6-不存在的账户/账户类型有误和场景7-账户余额不足就缺少测试用例。

（4）数据设计

一旦确定了所有的测试用例，则应对这些用例进行复审和验证以确保其准确且适度，并取消多余或等效的测试用例。

表5-13 测试数据表

测试用例一经认可，就可以确定实际数据值（在测试用例实施矩阵中）并且设定测试数据。

以上测试用例只是在本次迭代中需要用来验证提款用例的一部分测试用例。需要的其他测试用例包括以下内容。

场景6——账户不存在/账户类型有误：未找到账户或账户不可用；

场景6——账户不存在/账户类型有误：禁止从该账户中提款；

场景7——账户余额不足：请求的金额超出账面金额。

在将来的迭代中，当实施其他事件流时，在下列情况下将需要测试用例：

① 无效卡（所持卡为挂失卡、被盗卡、非承兑银行发卡、磁条损坏等）；

② 无法读卡（读卡机堵塞、脱机或出现故障）；

③ 账户已消户、冻结或由于其他方面原因而无法使用；

④ ATM内的现金不足或不能提供所请求的金额（与CW3不同，在CW3中只是一种币值不足，而不是所有币值都不足）；

⑤ 无法联系银行系统以获得认可；

⑥ 银行网络离线或交易过程中断电。

结论：所有从事软件测试和即将从事软件测试的人大都是从黑盒测试做起的，每种类型的软件有各自的特点，每种测试用例设计的方法也有各自的特点，针对不同软件如何利用这些黑盒方法是非常重要的，它能极大地提高测试效率和测试覆盖度，认真掌握这些方法的原理，有效提高测试水平，积累更多的测试经验，这是测试人员最宝贵的财富。

2.10 测试方法选择的综合策略

测试用例的设计方法不是单独存在的，具体到每个测试项目里都会用到多种方法，每种类型的软件有各自的特点，每种测试用例设计的方法也有各自的特点，针对不同软件如何利用这些黑盒方法是非常重要的，在实际测试中，往往是综合使用各种方法才能有效地提高测试效率和测试覆盖度，这就需要认真掌握这些方法的原理，积累更多的测试经验，以有效地提高测试水平。

以下是各种测试方法选择的综合策略，可供读者在实际应用过程中参考。

① 首先进行等价类划分，包括输入条件和输出条件的等价划分，将无限测试变成有限测试，这是减少工作量和提高测试效率最有效的方法。

② 在任何情况下都必须使用边界值分析方法。经验表明，用这种方法设计出的测试用例发现程序错误的能力最强。

③ 可以用错误推测法追加一些测试用例，这需要依靠测试工程师的智慧和经验。

④ 对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。如果没有达到要求的覆盖标准，应当再补充足够的测试用例。

⑤ 如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法和判定表驱动法。

⑥ 对于参数配置类的软件，要用正交试验法选择较少的组合方式达到最佳效果。

⑦ 功能图法也是很好的测试用例设计方法，我们可以通过不同时期条件的有效性设计不同的测试数据。

⑧ 对于业务流清晰的系统，可以利用场景法贯穿整个测试案例过程，在案例中综合使用各种测试方法。

3 测试用例的编写

3.1 测试用例计划的目的

仔细计划测试用例，是达成测试目标的必由之路。这样做的重要性体现如下。

即使在小型软件项目上，也可能有数千个测试用例。建立用例可能需要一些测试员经过几个月甚至几年的时间。正确的计划会组织好用例，以便全体测试员和其他项目小组成员有效地审查和使用。

我们已经知道，在项目期间有必要多次执行同样的测试，以寻找新的软件缺陷，保证老的软件缺陷得以修复。假如没有正确的计划，就不可能知道需要执行哪个测试用例，原有的测试是否得到重复。

有时我们需要回答整个项目期间的重要问题。例如，计划执行多少个测试用例；在软件最终版本上执行多少个测试用例；多少个通过，多少个失败；有忽略的测试用例吗，等等。如果没有测试用例计划，就不能回答这些问题。

在少数高风险行业中，软件测试小组必须证明确实执行了计划执行的测试。发布忽略某些测试用例的软件是危险的。正确的测试用例计划和跟踪提供了一种证实测试的手段。

3.2 测试设计说明

大家知道，项目整体测试计划的级别非常高。它虽然把软件拆分为具体特性和可测试项，并将其分派到每个测试员头上，但是它并没有指明如何对这些特性进行测试，可能仅仅对使用自动化测试还是黑盒测试或者白盒测试有一些提示，但是并不会涉及如何使用以及在哪里使用这些工具。

为了更好地进行测试，我们需要为单个软件特性定义具体的测试方法，这就是测试设计说明。ANSI/IEEE 829中对测试设计说明的解释是：测试设计说明就是在测试计划中提炼测试方法，要明确指出设计包含的特性以及相关的测试用例和测试程序，并指定判断特性通过/失败的规则。

测试设计说明的目的是组织和描述针对具体特性需要进行的测试。然而，它并不给出具体的测试用例或者执行测试的步骤。以下内容来自于ANSI/IEEE 829标准，应该作为测试设计说明的部分内容。

 标识符：用于引用和定位测试设计说明的惟一标识符。该说明还应该引用整个测试计划，还应该包含任何其他计划或者说明的引用。

 要测试的特性：对测试设计说明所包含的软件特性的描述。例如“计算器程序的加法功能”、“写字板程序中的字体大小选择和显示”、“QuickTime软件的视频卡配置测试”。该部分还将明确指出要间接测试的特性，它通常作为主特性的辅助特性。例如，文件打开对话框的用户界面虽然不在测试设计说明中重点指出，但是在测试读写功能的过程中要间接测试。

 方法：描述测试的通用方法。如果方法在测试计划中列出，就应该在此详细描述要使用的技术，并给出如何验证测试结果的方法。例如，我们这样描述一种方法，开发一种测试工具，顺序读写不同大小的数据文件，数据文件的数目和大小及包含的内容由程序员提供的示例来确定。用文件比较工具比较输出的文件和源文件，如果相同，则认为通过；如果不同，则认为失败。

 测试用例信息：用于描述所引用的测试用例的相关信息。应该列出所选的等价区间，给出测试用例的引用信息以及用于执行测试用例的测试程序说明。例如：“检查最大值 测试用例ID#15326”、“检查最小值 测试用例ID#15327”，在这部分不定义实际测试用例。

 通过/失败规则：描述用什么规则来判定某项特性的测试结果是通过还是失败。这种描述有可能非常简单和明确，例如“通过是指当执行全部测试用例时没有发现软件缺陷”。也有可能不是非常明确，例如“失败是指10%以上的测试用例没有通过”。

3.3 测试用例说明

如何记录和记载创建的测试用例？如果你已经开始进行一些软件测试了，就可能采用过一些用例描述格式。本节讲解编写测试用例的有关内容，指出将要考虑的重点。

ANSI/IEEE 829标准称测试用例说明为编写用于输入输出的实际数值和预期结果，同时还明确指出，使用具体测试用例产生的测试程序的限制。一个测试用例的编写可参考表5-14。

表5-14 测 试 用 例

编号：

测试用例应该解释要向软件发送什么值或者条件，以及预期结果。一个测试用例说明可以由多个测试用例说明来引用，也可以引用多个测试程序。ANSI/IEEE 829标准还列出了一些应该包含在内的重要信息，如下所示。

 标识符：由测试设计过程说明和测试程序说明引用的惟一标识符。

 测试项：描述被测试的详细特性、代码模块等，应该比测试设计说明中所列的特性更加具体。如果测试设计说明提到“计算器程序的加法功能”，那么测试用例说明就会相应地提到“加法运算的上限溢出处理”。它还要指出引用的产品说明书或者测试用例所依据的其他设计文档。

 输入说明：该说明列举执行测试用例的所有输入内容或者条件。如果测试计算器程序，输入说明可能简单到“1 1”。如果测试蜂窝电话交换软件，输入说明可能是成百上千种输入条件。如果测试基于文件的产品，输入说明可能是文件名和内容的描述。

 输出说明：描述进行测试用例预期的结果。例如，1 1等于2吗？在蜂窝软件中上千个输出变量设置正确吗？读取文件的全部内容和预想的一样吗？

 环境要求：是指执行测试用例必要的硬件、软件、测试工具、人员等。

 特殊要求：描述执行测试必须的特殊要求。测试写字板程序也许不需要任何特殊条件，但是测试一些特殊的软件（如核电站软件）就有特殊要求。

 用例之间的依赖性：如果一个测试用例依赖于其他用例，或者受其他用例的影响，就应该在此注明。

如果按照这里推荐的文档格式，对于每一个测试用例至少都要写上一页的描述文字，数千个测试用例可能要形成几千页文档。所以我们经常把ANSI/IEEE 829标准当作规范而不是标准使用（除非必须这样做，许多政府项目和某些行业要求按照此规格编写测试用例，但是在大多数情况下可以采用简便方法）。

采用简便方法并不是说放弃或者忽视重要的信息，而是意在找出一个更有效的方法对这些信息进行精简，例如，没有必要刻意要求不能用书面段落形式表述测试用例。如表5-15给出了一个打印机兼容性简单列表的例子。

表5-15 打印机兼容性简单列表

表中的每一行是一个测试用例，有自己的标识符。伴随测试用例的所有其他信息，例如测试项、输入说明、输出说明、环境要求、特殊要求和依赖性等对所有这些用例都必须有，可以一并编写，附加到表格中。审查测试用例的人可以快速看完测试用例信息，然后审查表格，检查其范围。

表述测试用例的其他选择有大纲、状态表或数据流程图等方式。

3.4 测试程序说明

编写完测试设计和测试用例之后，就要说明执行测试用例的程序。什么是测试程序呢？ANSI/IEEE 829标准把测试程序定义为“明确指出为实现相关测试设计而执行具体测试用例和操作软件系统的全部步骤”。

测试程序，有时也叫“测试脚本说明”，详细定义了执行测试用例的每一步操作。以下是需要定义的内容。

 标识符：用来把测试程序与相关测试用例和测试设计相联系的惟一标识。

 目的：本程序描述的目的以及将要执行的测试用例的引用信息。

 特殊要求：执行测试所需的其他程序、特殊测试技术或者特殊设备。

 程序步骤：执行测试用例的详细描述。它包含以下内容。

① 日志：指出用什么方法记录测试结果和现象。

② 设置：说明如何准备测试。

③ 启动：说明启动测试的步骤。

④ 程序：描述运行测试的步骤。

⑤ 衡量标准：描述如何判断结果。

⑥ 关闭：描述因意外原因而推迟测试的步骤。

⑦ 终止：描述正常停止测试的步骤。

⑧ 重置：说明如何把环境恢复到测试前的状态。

⑨ 偶然事件：说明如何处理计划之外的情况。

如果我们把测试程序只理解成“尝试执行所有的测试用例并报告发现的问题”是不够的。这虽然简单、容易，但是无法告诉新加入的测试员如何进行测试，不能重复而且无法证明哪些步骤执行了。使用详细的程序说明，则把要测试什么、如何测试等问题都表述得一目了然。如图5-12所示是“Windows计算器”的测试程序说明的例子片断。

俗话说“做什么都要适可而止”，测试用例计划也一样。测试用例计划包括四个目标，即组织性、重复性、跟踪和测试证实。开发测试用例的软件测试工程师要力争实现这些目标，但是其实现程度取决于行业、公司、项目和测试组的具体情况，通常也不太可能按照最细致的程度去编写测试用例。

我们设计的测试用例计划要力求达到最佳的详细程度，比如，在一个测试程序中要求在PC机上安装Windows 2000来执行测试，测试程序在其设置部分声明需要 Windows 2000，但是未声明Windows 2000的哪个版本。那么一两年内出现新版本会怎样？测试程序需要升级来反映这个变化吗？为了避免这个问题，可以省略具体的版本，而用“可用的最新版本”这样的说明来替代。

无比详细的测试用例说明减少了测试的随意性，使测试可以很好地重复，使得无经验的测试人员按照测试用例说明也能执行测试。但是编写如此细致的测试用例说明要花费相当多的时间和精力，并且由于细节繁多，也会阻滞测试工作，造成测试执行时间变长

。

开始编写测试用例时，最好是采用当前项目的标准，同时需要根据ANSI/IEEE 829标准定义的格式，看什么符合项目要求，并可以做适当的调整。

不同的测试工程师设计的测试用例也会有所不同。通常有经验的测试工程师设计出来的测试用例，在深度及广度上会比经验少的测试工程师的完整，这也是所谓的测试经验值。举例来讲，客户反应前一版V1.3的软件在Windows 98的环境下运行时，在屏幕保护程序激活后会产生问题，开发工程师将这问题解决并且已提交修正版本供客户网络下载，并且目前开发工程师所开发的软件最新版本为V1.5版，软件测试工程师就必须在V1.5版的测试用例内，加入屏幕保护程序激活测试用例，甚至将这个用例增加至其他的测试平台。

作者：西边人

欢迎来到西说测试