|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
测试是可以事先计划并可以系统地进行的一系列活动。因此，应该为软件过程定义软件测试模板，即将特定的测试方法和测试用例设计放在一系列的测试步骤中去。软件测试方法分为静态测试和动态测试。
|
|
|
|
静态测试是指被测试程序不在机器上运行，而是采用人工检测和计算机辅助静态分析的手段对程序进行检测。人工检测是不依靠计算机而是靠人工审查程序或评审软件，包括代码检查、静态结构分析和代码质量度量等。计算机辅助静态分析利用静态分析工具对被测试程序进行特性分析，从程序中提取一些信息，以便检查程序逻辑的各种缺陷和可疑的程序构造。
|
|
|
|
动态测试是指通过运行程序发现错误。对软件产品进行动态测试时可以采用黑盒测试法和白盒测试法。测试用例由测试输入数据和与之对应的预期输出结构组成。在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。
|
|
|
|
|
|
黑盒测试也称为功能测试，在完全不考虑软件的内部结构和特性的情况下，测试软件的外部特性。进行黑盒测试主要是为了发现以下几类错误：
|
|
|
|
|
|
（2）界面是否有误？输入是否正确接收？输出是否正确？
|
|
|
|
|
|
|
|
|
|
常用的黑盒测试技术有等价类划分、边界值分析、错误推测和因果图等。
|
|
|
|
|
|
等价类划分法将程序的输入域划分为若干等价类，然后从每个等价类中选取一个代表性数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值。这样就可以用少量代表性的测试用例取得较好的测试效果。等价类划分有两种不同的情况：有效等价类和无效等价类。在设计测试用例时，要同时考虑这两种等价类。
|
|
|
|
|
|
（1）在输入条件规定了取值范围或值的个数的情况下，可以定义一个有效等价类和两个无效等价类。
|
|
|
|
（2）在输入条件规定了输入值的集合或规定了“必须如何”的条件的情况下，可以定义一个有效等价类和一个无效等价类。
|
|
|
|
（3）在输入条件是一个布尔量的情况下，可以定义一个有效等价类和一个无效等价类。
|
|
|
|
（4）在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可以定义n个有效等价类和一个无效等价类。
|
|
|
|
（5）在规定了输入数据必须遵守的规则的情况下，可定义一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。
|
|
|
|
（6）在确知已划分的等价类中，各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步地划分为更小的等价类。
|
|
|
|
定义好等价类之后，建立等价类表，并为每个等价类编号。在设计一个新的测试用例时，使其尽可能多地覆盖尚未覆盖的有效等价类，不断重复，最后使得所有有效等价类均被测试用例所覆盖。然后设计一个新的测试用例，使其只覆盖一个无效等价类。
|
|
|
|
|
|
输入的边界比中间更加容易发生错误，因此用边界值分析来补充等价类划分的测试用例设计技术。边界值分析选择等价类边界的测试用例，既注重于输入条件边界，又适用于输出域测试用例。
|
|
|
|
|
|
（1）如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据。
|
|
|
|
（2）如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少1、比最大个数多1的数据作为测试数据。
|
|
|
|
（3）根据规格说明的每个输出条件，使用上述两条原则。
|
|
|
|
（4）如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。
|
|
|
|
（5）如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构边界上的值作为测试用例。
|
|
|
|
|
|
|
|
错误推测是基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例的方法。其基本思想是列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。
|
|
|
|
|
|
因果图法是从自然语言描述的程序规格说明中找出因（输入条件）和果（输出或程序状态的改变），通过因果图转换为判定表。
|
|
|
|
|
|
（1）分析程序规格说明的描述中，哪些是原因，哪些是结果。原因常常是输入条件或是输入条件的等价类，而结果是输出条件。
|
|
|
|
（2）分析程序规格说明的描述中语义的内容，并将其表示成连接各个原因与各个结果的“因果图”。
|
|
|
|
（3）标明约束条件。由于语法或环境的限制，有些原因和结果的组合情况是不可能出现的。为表明这些特定的情况，在因果图上使用若干个标准的符号标明约束条件。
|
|
|
|
|
|
|
|
这样生成的测试用例（局部，组合关系下的）包括了所有输入数据的取“真”和取“假”的情况，构成的测试用例数据达到最少，且测试用例数据随输入数据数目的增加而增加。
|
|
|
|
|
|
白盒测试也称为结构测试，根据程序的内部结构和逻辑来设计测试用例，对程序的路径和过程进行测试，检查是否满足设计的需要。
|
|
|
|
|
|
|
|
（2）在所有的逻辑判断中，取“真”和取“假”的两种情况至少都能执行一次。
|
|
|
|
（3）每个循环都应在边界条件和一般条件下各执行一次。
|
|
|
|
|
|
白盒测试常用的技术是逻辑覆盖、循环覆盖和基本路径测试。
|
|
|
|
|
|
逻辑覆盖考察用测试数据运行被测程序时对程序逻辑的覆盖程度。主要的逻辑覆盖标准有语句覆盖、判定覆盖、条件覆盖、判定／条件覆盖、条件组合覆盖和路径覆盖6种。
|
|
|
|
（1）语句覆盖。语句覆盖是指选择足够的测试数据，使被测试程序中每条语句至少执行一次。语句覆盖对程序执行逻辑的覆盖很低，因此一般认为它是很弱的逻辑覆盖。
|
|
|
|
（2）判定覆盖。判定覆盖是指设计足够的测试用例，使得被测程序中每个判定表达式至少获得一次“真”值和“假”值，即程序中的每一个取“真”分支和取“假”分支至少都通过一次，因此判定覆盖也称为分支覆盖。判定覆盖要比语句覆盖更强一些。
|
|
|
|
（3）条件覆盖。条件覆盖是指构造一组测试用例，使得每一判定语句中每个逻辑条件的各种可能的值至少满足一次。
|
|
|
|
（4）判定／条件覆盖。判定／条件覆盖是指设计足够的测试用例，使得判定中每个条件的所有可能取值（真／假）至少出现一次，并使每个判定本身的判定结果（真／假）也至少出现一次。
|
|
|
|
（5）条件组合覆盖。条件组合覆盖是指设计足够的测试用例，使得每个判定中条件的各种可能值的组合都至少出现一次。满足条件组合覆盖的测试用例是一定满足判定覆盖、条件覆盖和判定／条件覆盖的。
|
|
|
|
（6）路径覆盖。路径覆盖是指覆盖被测试程序中所有可能的路径。
|
|
|
|
|
|
执行足够的测试用例，使得循环中的每个条件都得到验证。
|
|
|
|
|
|
基本路径测试法是在程序控制流图的基础上，通过分析控制流图的环路复杂性，导出基本可执行路径集合，从而设计测试用例。设计出的测试用例要保证在测试中程序的每一条独立路径都执行过，即程序中的每条可执行语句至少执行一次。此外，所有条件语句的真值状态和假值状态都测试过。路径测试的起点是程序控制流图。程序控制流图中的节点代表包含一个或多个无分支的语句序列，边代表控制流。
|
|
|
