本文共 3135 字，大约阅读时间需要 10 分钟。
测试目的
1、测试是程序的执行过程，目的在于发现错误；
2、一个好的测试用例在于能发现至今未发现的错误；
3、一个成功的测试是发现了至今未发现的错误的测试。
测试原则
1、应当“尽早地和不断的进行软件测试”作为软件开发者的座右铭；
2、测试用例应由测试输入数据和对应的预期输出结构这两部分组成；
3、程序员应避免检查自己的程序；
4、在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。
测试信息流
1、软件配置
2、测试配置
3、测试工具
4、测试结果分析
5、排错（调试）
6、修正后的文档再测试
测试与开发的关系
1、软件开发过程是一个自顶向下，逐步细化的过程；
2、测试过程是依相反顺序安排的自底向上，逐步集成的过程。
测试用例设计
1、黑盒设计
也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。
（1）等价类划分
等价类划分方法把所有可能的输入数据，即程序的输入域划分成若干部分，然后从每一部分中选取少数有代表性的数据作为测试用例。
A.有效等价类
B.无效等价类
划分原则
a.如果输入条件规定了取值范围，或值的个数，则可以确立一个有效等价类和两个无效等价类；
b.如果输入条件规定了输入值的集合，或是规定了“必须如何”的条件，这时可确立一个有效等价类和一个无效等价类；
c.如果输入条件是一个布尔量，则可以确定一个有效等价类和一个无效等价类；
d.如果规定了输入数据的一组值，而且程序要对每个输入值分别进行处理；
e.如果规定了输入数据必须遵守的规则，则可以确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。
（2）边界值分析
通过选择等价类边界的测试用例。边界值分析法不仅重视输入条件边界，而且也必须考虑输出域边界。它是对等价类划分方法的补充。应当选取正好等于，刚刚大于，或刚刚小于等边界的值作为测试数据。设计原则
a.如果输入条件规定了取值范围，则应对该范围的边界内附近，恰好在边界和在边界附近（无效等价类中）设计测试用例；
b.如果输入条件规定了数据的个数，则应对最小个数，最大个数，比最小个数少1，比最大个数大1等情况设计测试用例；
c.针对规格说明中的每个输出条件使用的1和2原则；
d.如果程序规格说明中提到的输入或输出域是个有序的集合（如顺序文件，线性表等）。应选择有序集的第一个和最后一个元素作为测试用例。
（3）错误推测法
错误推测法的基本想法是，列举出程序中所有可能有的错误和同意发生错误的特殊情况，根据他们选择测试用例。（4）因果图
前面介绍的等价类划分方法和边界值分析方法，都是着重考虑输入条件，但未考虑输入条件之间的联系，相互组合等。 考虑输入条件之间的相互组合，可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情，即使把所有输入条件划分成等价类，他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）。基本步骤
a. 分析软件规格说明描述中，哪些是原因（即输入条件或输入条件的等价类），哪些是结果（即输出条件），并给每个原因和结果赋予一个标识符。
b. 分析软件规格说明描述中的语义。找出原因与结果之间，原因与原因之间对应的关系. 根据这些关系，画出因果图。
c. 由于语法或环境限制，有些原因与原因之间，原因与结果之间的组合情况不可能出现. 为表明这些特殊情况，在因果图上用一些记号标明约束或限制条件。
d. 把因果图转换为判定表。
e. 把判定表的每一列拿出来作为依据，设计测试用例。
(5)判定表组成法
规则：任何一个条件组合的特定取值及其相应要执行的操作.在判定表中贯穿条件项和动作项的一列就是一条规则.显然，判定表中列出多少组条件取值，也就有多少条规则，既条件项和动作项有多少列。
判定表的建立步骤
a.确定规则的个数。假如有n个条件.每个条件有两个取值（0,1），故有2n种规则。
b.列出所有的条件桩和动作桩。
c.填入条件项。
d.填入动作项.等到初始判定表。
e.简化.合并相似规则（相同动作）。
2、白盒测试
白盒测试又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是一种测试用例设计方法，盒子指的是被测试的软件，白盒指的是盒子是可视的，你清楚盒子内部的东西以及里面是如何运作的。”白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。”白盒”法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字。
（1）逻辑覆盖
这个是以程序内部的逻辑结构为基础的设计测试用例的技术a.语句覆盖 为了暴露程序中的错误，程序中的每条语句至少应该执行一次。因此语句覆盖（Statement Coverage）的含义是：选择足够多的测试数据，使被测程序中每条语句至少执行一次。语句覆盖是很弱的逻辑覆盖。
b.判定覆盖比语句覆盖稍强的覆盖标准是判定覆盖（Decision Coverage）。判定覆盖的含义是：设计足够的测试用例，使得程序中的每个判定至少都获得一次“真值”或“假值”，或者说使得程序中的每一个取“真”分支和取“假”分支至少经历一次，因此判定覆盖又称为分支覆盖。
c.条件覆盖在设计程序中，一个判定语句是由多个条件组合而成的复合判定。为了更彻底地实现逻辑覆盖，可以采用条件覆盖（Condition Coverage）的标准。条件覆盖的含义是：构造一组测试用例，使得每一判定语句中每个逻辑条件的可能值至少满足一次。
d.多条件覆盖。多条件覆盖也称条件组合覆盖，它的含义是：设计足够的测试用例，使得每个判定中条件的各种可能组合都至少出现一次。显然满足多条件覆盖的测试用例是一定满足判定覆盖、条件覆盖和条件判定组合覆盖的。
e.修正条件判定覆盖。修正条件判定覆盖是由欧美的航空/航天制造厂商和使用单位联合制定的“航空运输和装备系统软件认证标准”，在国外的国防、航空航天领域应用广泛。这个覆盖度量需要足够的测试用例来确定各个条件能够影响到包含的判定的结果。它要求满足两个条件：首先，每一个程序模块的入口和出口点都要考虑至少要被调用一次，每个程序的判定到所有可能的结果值要至少转换一次；其次，程序的判定被分解为通过逻辑操作符（and、or）连接的布尔条件，每个条件对于判定的结果值是独立的。
（2）测试方法
基本路径测试法是在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例的方法。设计出的测试用例要保证在测试中程序的每个可执行语句至少执行一次。
在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例。包括以下4个步骤和一个工具方法：
a.程序的控制流图：描述程序控制流的一种图示方法。
b.程序圈复杂度：McCabe复杂性度量。从程序的环路复杂性可导出程序基本路径集合中的独立路径条数，这是确定程序中每个可执行语句至少执行一次所必须的测试用例数目的上界。
c.导出测试用例：根据圈复杂度和程序结构设计用例数据输入和预期结果。
d.准备测试用例：确保基本路径集中的每一条路径的执行。