测试用例设计规范
1、引言
测试设计遵循与软件设计相同的工程原则。好的软件设计包含几个对测试设计进行精心描述的阶段。这些阶段是：
测试策略
测试计划
测试描述
测试过程
上述四个测试设计阶段适用于从单元测试到系统测试各个层面的测试。
测试设计由软件设计说明所驱动。单元测试用于验证模块单元实现了模块设计中定义的规格。一个完整的单元测试说明应该包含正面测试（Positive Testing）和负面的测试（Negative Testing）。正面测试验证程序应该执行的工作，负面测试验证程序不应该执行的工作。
设计富有创造性的测试用例是测试设计的关键。本文档介绍了测试说明的一般设计过程，描述了一些结构化程序设计单元测试中采用的用例设计技术，同时也增加了面向对象编程中对类进行单元测试所采用的测试用例设计技术，这些可作为软件测试人员的参考阅读资料。
2设计单元测试说明
一旦模块单元设计完毕，下一个开发阶段就是设计单元测试。值得注意的是，如果在书写代码之前设计测试，测试设计就会显得更加灵活。一旦代码完成，对软件的测试可能会倾向于测试该段代码在做什么（这根本不是真正的测试），而不是测试其应该做什么。单元测试说明实际上由一系列单元测试用例组成，每个测试用例应该包含4个关键元素：
被测单元模块初始状态声明，即测试用例的开始状态（仅适用于被测单元维持了调用间状态的情况）；
被测单元的输入，包含由被测单元读入的任何外部数据值；
该测试用例实际测试的代码，用被测单元的功能和测试用例设计中使用的分析来说明，如：单元中哪一个决策条件被测试；
测试用例的期望输出结果，测试用例的期望输出结果总是应该在测试进行之前在测试说明中定义。
以下描述进行测试用例设计，书写测试说明的7步通用过程。
2.1测试用例设计步骤
2.1.1步骤1：首先使被测单元运行
任何单元测试说明的第一个测试用例应该是以一种可能的简单方法执行被测单元。看到被测单元第一个测试用例的运行成功可以增强人的自信心。如果不能正确执行，最好选择一个尽可能简单的输入对被测单元进行测试/调试。
这个阶段适合的技术有：
模块设计导出的测试
对等区间划分
2.1.2步骤2：正面测试(Positive Testing)
正面测试的测试用例用于验证被测单元能够执行应该完成的工作。测试设计者应该查阅相关的设计说明；每个测试用例应该测试模块设计说明中一项或多项陈述。如果涉及多个设计说明，最好使测试用例的序列对应一个模块单元的主设计说明。
适合的技术：
设计说明导出的测试
对等区间划分
状态转换测试
2.1.3步骤3：负面测试(Negative Testing)
负面测试用于验证软件不执行其不应该完成的工作。这一步骤主要依赖于错误猜测，需要依靠测试设计者的经验判断可能出现问题的位置。
适合的技术有：
错误猜测
边界值分析
内部边界值测试
状态转换测试
2.1.4步骤4：设计需求中其它测试特性用例设计
如果需要，应该针对性能、余量、安全需要、保密需求等设计测试用例。
在有安全保密需求的情况下，重视安全保密分析和验证是方便的。针对安全保密问题的测试用例应该在测试说明中进行标注。同时应该加入更多的测试用例测试所有的保密和安全冒险问题。
适合的技术：
设计说明导出的测试
2.1.5步骤5：覆盖率测试用例设计
应该或已有测试用例所达到的代码覆盖率。应该增加更多的测试用例到单元测试说明中以达到特定测试的覆盖率目标。一旦覆盖测试设计好，就可以构造测试过程和执行测试。覆盖率测试一般要求语句覆盖率和判断覆盖率。
适合的技术：
分支测试
条件测试
数据定义－使用测试
状态转换测试
2.1.6步骤6：测试执行
使用上述5个步骤设计的测试说明在大多少情况下可以实现一个比较完整的单元测试。
到这一步，就可以使用测试说明构造实际的测试过程和用于执行测试的测试过程。该测试过程可能是特定测试工具的一个测试脚本。
测试过程的执行可以查出模块单元的错误，然后进行修复和重新测试。在测试过程中的动态分析可以产生代码覆盖率测量值，以指示覆盖目标已经达到。因此需要在测试设计说明中需要增加一个完善代码覆盖率的步骤。
2.1.7步骤7：完善代码覆盖
由于模块单元的设计文档规范不一，测试设计中可能引入人为的错误，测试执行后，复杂的决策条件、循环和分支的覆盖率目标可能并没有达到，这时需要进行分析找出原因，导致一些重要执行路径没有被覆盖的可能原因有：
不可行路径或条件――应该标注测试说明证明该路径或条件没有测试的原因。
不可到达或冗余代码――正确处理方法是删除这种代码。这种分析容易出错，特别是使用防卫式程序设计技术（Defensive Programming Techniques）时，如有疑义，这些防卫性程序代码就不要删除。
测试用例不足――应该重新提炼测试用例，设计更多的测试用例添加到测试说明
中以覆盖没有执行过的路径
理想情况下，覆盖完善阶段应该在不阅读实际代码的情况下进行。然而，实际上，为达到覆盖率目标，看一下实际代码也是需要的。覆盖完善步骤的重要程度相对小一些。最有效的测试来自于分析和说明，而不是来自于试验，依赖覆盖完善步骤补充一份不好的测试设计。
适合的技术：
分支测试
条件测试
设计定义――试验测试
状态转换测试
2.2用例设计的一般原则
注意到前面产生测试说明步骤可以用下面的方法完成：
通常应该避免依赖先前测试用例的输出，测试用例的执行序列早期发现的错误可能导致其他的错误而减少测试执行时实际测试的代码量；
测试用例设计过程中，包括作为试验执行这些测试用例时，常常可以在软件构建前就发现BUG。还有可能在测试设计阶段比测试执行阶段发现更多的BUG。
在整个单元测试设计中，主要的输入应该是被测单元的设计文档。在某些情况下，
需要将试验实际代码作为测试设计过程的输入，测试设计者必须意识到不是在测试代码本身。从代码构建出来的测试说明只能证明代码执行代码完成的工作，而不是代码应该完成的工作。
3、测试用例设计技术
广义地分为两类：
黑盒测试：使用单元接口和功能描述，不需了解被测单元的内部结构
白盒测试：使用被测单元内部如何工作的信息
灰盒测试：借助于源代码和测试工具等手段，通过黑盒和白盒测试相结合的方法进行测试的技术。
测试设计最重要的因素是经验和常识。测试设计者不应该让某种测试技术阻碍经验和常识的运用。
白盒测试用例设计：使用程序设计的控制结构导出测试用例。
采用白盒测试的目的主要是:
保证一个模块中的所有独立路径至少被执行一次；
对所有的逻辑值均需要测试真、假两个分支；
在上下边界及可操作范围内运行所有循环；
检查内部数据结构以确保其有效性。
黑盒测试用例设计：使用详细设计导出测试用例。
采用黑盒测试的目的主要是：
检查功能是否实现或遗漏；
检查人机界户是否错误；
数据结构或外部数据库访问错误；
性能等其它特性要求是否满足；
初始化盒终止错误。
3.1软件设计说明导出的测试
测试用例通过根据相关的软件设计说明文档进行设计。每个测试用例测试设计说明中一项或多项陈述。通常为被测单元设计说明的一系列陈述建立一系列对应的设计用例。
例1：考虑下面计算实数平方根的函数的设计说明：
输入：实数
输出：实数
处理：当输入0或大于0时，返回输入数的平方根；当输入小于0时，显示：“Square root
error - illegal negative input"，并返回0；库函数Print_Line用于显示出错信息。
设计说明有3个陈述，可以2个测试用例来对应。
Test Case 1：输入4，返回2。//执行第一个陈述
Test Case 2：输入－10，返回0，显示“Square root error - illegal negative input”//对应第二个和第三个陈述设计说明导出的测试用例提供了与被测单元设计说明陈述序列很好的对应关系，增强了测试说明的可读性和可维护性。但有软件设计说明导出测试是正面的测试用例设计技术。软件设计说明导出的测试应该用负面测试用例进行补充，以提供一个完整的单元测试说明。
设计说明导出的测试设计技术还可用于安全分析、保密分析、软件冒险分析和其他给单元设计的其他补充文档。
3．2基本路径测试
基本路径测试是一种白盒测试技术。测试用例设计者导出一个过程设计的逻辑复杂性测度，并使用改测度作为指南来定义执行路径的基本集，从该基本集导出的测试用例保证对程序中的每一条执行语句至少执行一次。
基本路径测试的方法步骤如下：
3.2.1画出控制流图
C/C++语句中的控制语句表示如下：
图中的每一个圆称为流图的节点，代表一条或多条语句。流图中的箭头称为边或连接，代表控制流。
任何过程设计都要被翻译成控制流图。如下面的C函数：
void Sort(int iRecordNum,int iType)
0 {
1 int x=0;
2 int y=0;
3 while (iRecordNum--)
4 {
5 if(0= =iType)
6 x=y+2;
7 else
8 if(1= =iType)
9 x=y+10;
10 else
11 x=y+20;
12 }
13 }
画出其对应的控制流图如下：
