关于软件测试的一些基本知识

黑盒测试

一． 黑盒测试概述 1．定义
l 也称功能测试，它是通过测试来检测每个功能是否都能正常使用
l 把程序看成一个黑盒子，完全不考虑程序内部结构和内部特性，着眼于程序外部结构，不考虑内部逻辑结构
l 在程序接口进行测试，只检查程序功能是否按照需求说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息
l 主要针对软件界面和软件功能进行测试
2．试图发现的错误类型
l 功能不正确或遗漏
l 界面错误（输入能否正确的接受否输出正确的结果）
l 数据库访问错误（如数据结构定义错误或外部信息（如数据文件）访问错误）
l 性能错误
l 初始化和终止错误
3．黑盒测试用例设计方法
（1） 等价类划分法：把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类的其他值
（2） 边界值分析法：通过选择等价类边界的测试用例。不仅重视输入条件边界，而且也必须考虑输出域边界
（3） 错误推测法：基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例的方法
（4） 因果图法：从用自然语言书写的程序规格说明的描述中找出因（输入条件）和果（输入或程序状态的改变），可以通过因果图转换成判定表
（5） 判定表驱动法：利用判定表进行测试用例的设计
（6） 正交试验设计法：使用已设计好的正交表格来安排试验，并进行数据分析的一种方法，目的是用最少的测试用例达到最高的测试覆盖率
（7） 功能图法：用功能图形象地表示程序的功能说明，并机械地生成功能图的测试用例。功能图模型由状态迁移图和逻辑功能模型构成
二． 黑盒测试用例设计方法
1．等价类划分法
（1）划分基础：需求规格说明书中输入、输出要求
（2）等价类：某个输入域的子集合；分为有效等价类和无效等价类
l 有效等价类：指对于程序规格说明书来说是合理的、有意义的输入数据构成的集合。利用有效等价类可以检验程序是否实现了规格说明书中的功能和性能
l 无效等价类：与有效等价的定义恰巧相反
（3）划分等价类原则（6条）
序 输入条件（数据） 划分等价类
1 规定了取值范围值的个数 一个有效等价类两个无效等价类
2 规定了输入值的集合规定了“必须如何”的条件 一个有效等价类一个无效等价类
3 是一个布尔量 一个有效等价类一个无效等价类
4 输入数据的一组值（n个），并且程序对每一个输入值分别进行处理 n个有效等价类一个无效等价类
5 规定必须遵守的规则 一个有效等价类（符合规则）若干个无效等价类
6 在确知已划分的等价类中，各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步地划分为更小的等价类
    
（4） 列出等价类表
在确定了等价类之后，建立等价类表，列出所有划分出的等价类
输入条件 有效等价类 无效等类
…… …… …… （5） 确定测试用例步骤
l 第一步：为每个等价类规定一个惟一的编
l 第二步：设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类。重复这一步骤，最后使得所有有效等价类均被测试用例所覆盖
l 第三步：设计一个新的测试用例，使其只覆盖一个无效等价类。重复这一步骤，最后使得所有有效等价类均被测试用例所覆盖
小结：采用等价类划分方法设计测试用例，按照划分等价类、列出等价列表、确定测试用例三个步骤完成，目标是把可能的测试用例组合缩减到仍然足以满足软件测试需求为止。 2．边界值分析法
（1） 边界类型
l 边界条件：可以在产品说明书中有定义或者在使用软件过程中确定
l 次边界条件：在软件内部，也称为内部边界条件
l 其他边界条件：如输入信息为空（对于此类问题应建立单独的等价类空间）、非法、错误、不正确和垃圾数据
（2）边界值的选择方法（遵循原则）
序 输入条件（数据） 输入边界值数据
1 规定了取值范围 刚刚达到这个范围刚刚超越这个范围
2 规定值的个数 最大个数、比最大个数大1最小个数、比最小个数少1
3 根据规格说明书的每个输出条件，使用 原则1、2
4 输入或输出是个有序集合 集合的第一个、最后一个元素
5 程序中使用一个内部数据结构 内部数据结构边界上的值
6 分析规格说明，找出其他可能的边界 （3）例子：
l 允许文本输入1～255个字符：测试用例－1、255、254、0、256
l 程序读写软盘：测试用例－文件很小、等于软盘容量限制之内、空、超过
l 程序允许在一张纸上打印多个页面：测试用例－只打印一页，规定最大页，0页，大于允许最大页数 3．错误推测法
基本思想：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例 4．因果图法
   侧重于输入条件的各种组合，各个输入情况之间的相互制约关系
（1） 因果图设计方法
从用自然语言书写的程序规格说明的描述中找出因果，通过因果图转换成判定表
（2） 因果图导出测试用例步骤
l 第一步：分析程序规格说明的描述中，哪些是原因，哪些是结果。原在因常常是输入条件或是输入条件的等价类，结果是输出条件
l 第二步：分析程序规格说明的描述中语义的内容，并将其表示成连接各个原因与各个结果的‘因果图’
l 第三步：标明约束条件
l 第四步：把因果图转换成判定表
l 第五步：为判定表中每一列表示的情况设计测试用例
（3） 因果图基本图形符
通常在因果图中，用Ci 表示原因，Ei表示结果，各结点表示状态，可取值0（状态不出现） 或1（某状态出现）
l 恒等：若原因出现，则结果出现；若原因不出现，则结果不出现
l 非（～）：若原因出现，则结果不出现；若原因不出现，则结果出现
l 或（V）：若几个原因中有一个出现，则结果出现；若几个原因都不出现，则结果不出现；
l 与（∧）：若几个原因都出现，结果才出现；若其中有一个原因不出现，则结果不出现
（4） 因果图的约束符
从输入（原因）考虑四种约束
l E（互斥）：表示两个原因不会同时成立，两个中最多有一个可能成立
l I（包含）：表示三个原因中至少有一个必须成立
l O（惟一）：表示两个原因中必须有一个，且仅有一个成立
l R（要求）：表示两个原因，a出现时，b也必须出现，a出现时，b不可能不出现
从输出（结果）考虑一种约束
l M（屏蔽）：两个结果，a为1时，b必须是0，当a为0时，b值不定
 

5．判定表驱动法
（1） 判定表：是分析和表达多逻辑条件下执行不同操作的情况的工具
（2） 判定表组成
l 条件桩：列出了问题的所有条件
l 动作桩：列出了问题规定可能采取的操作
l 条件项：列出针对它所列条件的取值，在所有可能情况下的真假值
l 动作项：列出在条件项的各种取值情况下应该采取的动作
l 规则：任何一个条件组合的特定取值及其相应要执行的操作
注：判定表中贯穿条件项和动作项的一列就是一条规则；
（3） 判定表的建立（步骤）
l 第一步：确定规则的个数。假如有n个条件，每个条件有两个取值（0,1），故有2n种规则
l 第二步：列出所有的条件桩和动作桩
l 第三步：填入条件项
l 第四步：填入动作项。制定初始判定表
l 第五步：简化。合并相似规则或者相同动作
（4） 适合使用判定表设计测试用例的条件
l 规格说明以判定表的形式给出，或很容易转换成判定表
l 条件的排列顺序不影响执行哪些操作
l 规则的排列顺序不影响执行哪些操作
l 当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则
l 如果某一规则要执行多个操作，这些操作的执行顺序无关紧要  

6．正交试验法
（1） 概述
l 从大量的试验数据中挑选适量的、有代表性的点，从而合理地安排测试的一种科学的试验设计方法
l 使用已造好的表格“－”正交表来安排试验并进行数据分析的一种方法
l 因子：影响实现指标的条件
l 因子的状态：影响实现因子的条件
（2） 优点
l 节省测试工时
l 可控制生成的测试用例的数量
l 测试用例具有一定的覆盖率
（3） 设计步骤
l 提取功能说明，构造因子‘－’状态表。
l 加权筛选，生成因素分析表；
l 利用正交表构造测试数据集，正交表的推导依据Galois理论
L：代表正交表，L8（27）代表7为因子数，2为因子的水平数，8为此表行的数目（试验次数）
行数为mn型的正交表中，试验次数（行数）＝∑（每列水平数－1）＋1
例：5个3水平因子及一个2水平因子，表示为35*21，试验次数＝5*(3-1)+1*(2-1)+1＝12，
即L12（35*2）
7．功能图法
（1） 程序功能说明的组成
l 动态说明：描述输入数据的次序或转移次序
l 静态说明：描述输入条件和输出条件之间的对应关系
（2） 功能图：由状态迁移图和布尔函数组成，状态迁移图用状态和迁移来表示。一个状态指出数据输入的位置（或时间），一个迁移指明状态的改变，同时要依靠判定表或因果图表示的逻辑功能
（3） 功能图法概述
l 用功能图形象地表示程序的功能说明，并机械地生成功能图的测试用例
l 功能图模型由状态迁移图和逻辑功能模型构成
v 状态迁移图：用于表示输入数据序列以及相应的输出数据；由输入数据和当前状态决定输出数据和后续状态
v 逻辑功能模型：用于表示在状态中输入条件和输出条件的对应关系。由输入数据决定输出数据。此模型只适用于描述静态说明
l 功能图测试用例由测试中经过的一系列状态和在每个状态中必须依靠输入/输出数据满中的一对条件组成
（4） 测试用例生成方法
从状态迁移图中选取测试用例，用节点代替状态，用弧线代替迁移，状态图就可转化成一个程序的控制流程图形式
（5） 测试用例生成规则
为了把状态迁移（测试路径）的测试用例与逻辑模型（局部测试用例）的测试用例组合起来，从功能图生成实用的测试用例，在一个结构化的状态迁移（SST）中，定义3种形式的循环：顺序，选择和重复
（6） 功能图生成测试用例步骤
l 生成局部测试用例：在每个状态中，从因果图生成局部测试用例。局部测试用例由原因值（输入数据）组合与对应的结果值（输出数据或状态）构成
l 测试路径生成：利用上面的规则生成从初始状态到最后状态的测试路径
l 测试用例合成：合成测试路径与功能图中每个状态的局部测试用例。结果是初始状态到最后状态的一个状态序列，以及每个状态中输入数据与对应输出数据的组合。
l 测试用例的合成算法：采用条件构造树 8．场景法
（1） 基本流和备选流
采用此方法进行设计时，需要进行场景的设计，在场景中采用基本流和备选流表示经过用例的每条路径
l 基本流：采用直黑线表示，是经过用例的最简单的路径（无任何差错，程序从开始直接执行到结束）
l 备选流：采用不同颜色表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中，也可以起源于另一个备选流，或终止用例，不在加入到基本流中；（各种错误情况）
（2） 设计步骤
l 根据说明，描述出程序的基本流及各项备选流
l 根据基本流和各项备选流生成不同的场景
l 对每一个场景生成相应的测试用例
l 对生成的所有测试用例重新复审，去掉多余的测试用例，测试用例确定后，对每一个测试用例确定测试数据值
三． 黑盒测试用例设计方法的选择策略
1． 首先进行等价类划分，包括输入条件和输出条件的等价类划分，将无限测试变成有限测试，这是减少测试量和提高测试效率的最有效办法
2． 在任何情况下都必须使用边界值分析方法。此方法设计的测试用例发现程序错误的能力最强
3． 可以用错误和推测法追加一些测试用例
4． 对照程序的逻辑，检查已设计的测试用例的逻辑覆盖度，如果没有达到要求，应在补充
5． 如果程序的功能说明中含有输入条件的组合情况，一开始就可以使用因果图法和判定表驱动法
6． 对于参数配置类的软件，要用正交试验法选择较少的组合方式达到最佳效果
7． 功能图法也是很好的测试用例设计方法，我们可以通过不同时期条件的有效性设计不同的数据
8． 对于业务流清晰的系统，可以利用场景法贯空整个测试案例过程，在案例中综合使用各种方法
四． 测试用例的编写
1. 测试用例概述
（1） 定义
l 将测试行为具体量化的方法之一
l 设计一种情况，软件程序在这种情况下，必须能够正常运行并且达到程序所设计的执行结果
l 为达到最佳的测试效果或高效的揭露隐藏的错误而精心设计的少量测试数据，
l 一个好的测试用例是在于它能发现至今未发现的错误
（2） 优点：
l 在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率
l 测试用例的使用令软件测试的实施重点突出、目的明确
l 在软件版本更新后只需修正少部分的测试用例便可展开测试工作，降低工作强度，缩短项目周期
l 功能模块的通用化和复用化使软件易于开发，而测试用例的通用化和复用化使软件测试易于开展，并随着测试用例的不断精化其效率也不断攀升
2．计划测试用例的目的
（3） 计划测试用例，是达成测试目标的必由之路
（4） 组织性：使测试用例具有组织性，便于全体测试员和其他项目小组人员有效地审查和使用
（5） 重复性和跟踪，可以明确测试过程中测试用例的执行情况，保证测试的全面性
（6） 计划测试用例，可以避免发布忽略某些测试用例的软件
（7） 测试证实，正确的测试用例计划和跟踪提供了一种证实测试的手段
3．测试设计说明
（1） 定义：在测试计划中提炼测试方法，要明确指出设计包含的特性以及相关的测试用例和测试程序，并指定判断通过/失败的规则
（2） 目的；组织和描述针对具体特性需要进行的测试，注：不给出具体的测试用例或执行测试的步骤
（3） 包含的部分内容（来自ANSI/IEEE829   ANSI 美国国家标准化组织）
l 标识符：用于引用和定位测试设计说明的惟一标识符
l 要测试的特性：对测试设计说明所包含的软件特性的描述。还将明确出要间接测试的特性
l 方法：描述测试的通用方法。如果方法在测试计划中描述，在测试设计说明中要详细描述要使用的技术，并给出如何验证测试结果的方法
l 测试用例信息：用于描述所引用的测试用例的相关信息。如测试用例编
l 通过/失败规则：描述用什么规则来判定某项特性的测试结果是通过还是失败。
4．测试用例说明
（1） 定义（ANSI/IEEE829）：编写用于输入的实际数据和预期结果，并明确指出使用具体测试用例产生的测试程序的任何限制
（2） 包含的内容
l 标识符：由测试设计过程说明和测试程序说明引用的唯一标识符
l 测试项：描述被测试的详细特性、代码模块等
l 输入说明：列举执行测试用例的所有输入内容或者条件
l 输出说明：描述进行测试用例预期的结果
l 环境要求：执行测试用例的软件、硬件、测试工具及人员等要求
l 特殊要求：描述执行测试用例的特殊要求
l 用例之间的依赖性：注明与其分用例的依赖关系或受其他用例的影响
5. 测试程序说明
（1） 定义：明确指出为实现相关测试设计而执行具体测试用例和操作软件系统的全部步骤，有时也称为‘测试脚本说明’，即详细定义了执行测试用例的每一步操作
（2） 包含的内容
l 标识符：把测试程序与相关测试用例和测试设计相联系的惟一标识
l 目的：本程序描述的目的以及将要执行的测试用例的引用信息
l 特殊要求：执行测试所需的其他程、特殊测试技术或者特殊设备
l 程序步骤：执行测试用例的详细描述，包括
v 日志：指出记录测试结果和现象的方式
v 设置：如何准备测试
v 启动：启动测试的步骤
v 程序：运行测试的步骤
v 衡量标准：描述如何判断结果
v 关闭：描述因意外原因页推迟测试的步骤
v 终止：描述正常停止测试的步骤
v 重置：说明如何把环境恢复到测试前的状态
v 偶然事件：说明如何处理计划之外的情况
在相关书籍中看到一个案例，关于黑盒测试用例设计，大家参与一下吧，题目在论坛中也有
测试用例设计练习：
1．采用因果图方法设计测试用例
某个软件的规格说明中包含下面的要求：
第一列字符必须是A或B，第二列字符必须是一个数字，在此情况下进行文件的修改。但如果第一列字符不正确，则给出信息L，如果第二列字符不是数据，则给出信息

软件测试基本内容（转贴）

第 1 帖【 2004 － 5 － 10 】：软件测试的理想模式是什么 Brian Marick ：我不认为存在什么理想模式。我觉得让开发人员承担某些测试也许会更加有效，而其他测试则由独立测试组来进行。因为如果你把所有测试都交给独立测试组，他们不可能有时间把所有测试都做好。所以，最佳的方式是让开发人员承担一定量的测试，独立测试组给予他们支持。独立测试组主要承担整个系统的测试，去寻找开发人员还没有发现的缺陷，如子系统间的交互、运行条件、内存使用等。 如何更有效地开展系统测试呢测试人员在项目初期就参与进去，让他们看到第一版的系统需求、用户手册和系统原型，在系统实现前就对需求进行捕获和跟踪。在该过程中，他们从这些文档构造最初的测试设计。这也可以通过检视或评审的形式进行，并且在该过程中会发现一些缺陷。大家都知道，这个阶段，问题发现是非常 “ 便宜 ” 的。 这样，系统测试工程师在项目早期就介入，产生测试设计及基本的需要测试的项目列表。这时不可能产生一个绝对完备的测试设计，因为书写完整测试的条件还不成熟，但这却是构建完整测试的基础。 注： Brian Marick 是 Reliability Software 公司的专职测试技术顾问。 第 2 帖【 2004 － 5 － 11 】：测试经理角色定位 Johanna Rothman ：测试经理服务于两种完全不同的客户：测试工程师和高层管理者。对于测试工程师，测试经理帮助他们开发产品测试策略，积累产品测试经验并在测试组内充分共享。对于高层管理者，测试经理搜集尽可能全面的产品信息，供其就产品是否可以发布进行决策。但是有一点是相同的：无论是对于测试工程师还是高层管理者，测试经理将帮助其定义和校验产品发布标准。 产品发布标准的定义和校验：作为一个测试经理，应该找机会与市场、开发人员商讨产品发布标准，并根据客户的反馈对该标准进行修正和校验。开发部门的工作是如何达到公司对产品的期望，要用客户需求为开发人员勾画出客户眼中的产品以及产品应如何工作。一旦产品被清楚地定义，就可以通过测试去验证产品在多大程度上满足了客户需求。 对于测试工程师而言有一点非常重要：将测试任务按优先级划分，使产品发布标准得以满足。由于只有极少数的项目有充足的时间去完成所有事情，所以告诉测试工程师关于 “ 测什么和何时测 ” 测试经理的一个重要职责。 高层管理者需要充分理解产品发布标准，以决定产品是否可以按时发布。我不认为测试组有权利裁决产品是否应该被发布，该权利在组织高层管理者那里。在有了一个通过讨论、达成一致的产品发布标准后，项目组也可以更清楚地了解和认识产品质量。 第 3 贴【 2004 － 5 － 12 】：测试的基本原则 （美） Roger S. Pressman
在设计有效测试用例之前，测试工程师必需理解软件测试的基本原则。这里有一组测试原则：
1 、所有的测试都应追溯到用户需求。正如我们所知：软件测试的目标在于揭示错误。而最严重的错误（从用户角度来看）是那些导致程序无法满足需求的错误。
2 、应该在测试工作真正开始前的较长时间内就进行测试计划。测试计划可以在需求模型一完成就开始，详细的测试用例定义可以在设计模型被确定后立即开始。因此，所有测试应该在任何代码被产生前就进行计划和设计。
3 、 Pareto 原则应用于软件测试。简单地讲， Pareto 原则暗示着测试发现的错误中的 80 ％很可能起源于程序模块中的 20 ％。当然，问题在于如何孤立这些有疑点的模块并进行彻底的测试。
4 、测试应从 “ 小规模 ” 开始，逐步转向 “ 大规模 ” 。最初的测试通常把焦点放在单个程序模块上，进一步测试的焦点则转向在集成的模块簇中寻找错误，最后在整个系统中寻找错误。
5 、穷举测试是不可能的。即使是一个大小适度的程序，其路径排列的数量也非常大。因此，在测试中不可能运行路径的每一种组合。然而，充分覆盖程序逻辑，并确保程序设计中使用的所有条件是有可能的。
6 、为了达到最佳效果，应该由独立的第三方来构造测试。 “ 最佳效果 ” 指最有可能发现错误的测试（测试的主要目标），所以创建系统的软件工程师并不是构造软件测试的最佳人选。 第 4 贴【 2004 － 5 － 13 】：什么是 “ 好 ” 的测试 什么是 “ 好 ” 的测试Kaner ， Falk & Nguyen
1 、一个好的测试发现错误的可能性很高
为了达到这个目标，测试者必需理解软件、并尝试设想软件如何才能失败，例如：在 GUI （图形用户界面）中有一种潜在的错误，即错误识别鼠标位置，那么就应该设计一个测试集来验证是否存在鼠标位置识别的错误。
2 、一个好的测试并不冗余
测试的时间和资源是有限的，没有必要构造一个与其他测试用例完全相同的测试，每一个测试都应该有不同的用途〔哪怕是细微的差异〕。例如，软件 SafeHome 中有一个模块被用来识别用户密码以决定是否启动系统，为了测试密码输入的错误，测试者设计了一系列的输入密码。在不同的测试中输入有效与无效密码（ 4 个数字），然而，每一个有效 / 无效密码将只检测一种不同错误模式，例如一个将 8080 作为有效密码的系统将不会接受非法密码 1234 ，如果接受 1234 ，将产生错误，另一个测试输入 1235 ，与 1234 的测试意图相同，因此是冗余的，然而，非法输入 8081 或 8180 就有些细微的差异，即对与有效密码相近但并不相同的密码应该进行测试。
3 、一个好的测试应该是 “ 最佳品种 ”
在一组目的相似的测试中，时间和资源的限制可能只影响其某个子集的执行，此时，应该使用最可能找到所有错误的测试。
4 、一个好的测试既不会太简单，也不会太复杂
虽然有时会将一组测试组合到一个测试用例中，其副作用可能屏蔽错误，通常每一个测试应该独立执行。 第 5 贴【 2004 － 5 － 14 】：软件可测试性 Roger S. Pressman
理想情况下，软件工程师在设计计算机程序、系统或产品时应该考虑可测试性，这就使得测试工程师能够更容易地设计有效的测试用例。 什么是 “ 可测试性 ” 件的可测试性是指软件发现故障并隔离、定位其故障的能力特性，以及在一定的时间和成本前提下，进行测试设计、测试执行的能力。 James Bach 这样描述可测试性：软件可测试性就是一个计算机程序能够被测试的容易程度。 以下是一个常见的软件可测试性检查表：
· 可操作性－ “ 运行地越好，被测试的效率越高。 ”
· 可观察性－ “ 所看见的，就是所测试的。 ”
· 可控制性－ “ 对软件的控制越好，测试越能够被自动执行与优化。 ”
· 可分解性－ “ 通过控制测试范围，能够更好地分解问题，执行更灵巧的再测试。 ”
· 简单性－ “ 需要测试的内容越少，测试的速度越快。 ”
· 稳定性－ “ 改变越少，对测试的破坏越小。 ”
· 易理解性－ “ 得到的信息越多，进行的测试越灵巧。 ” 第 6 贴【 2004 － 5 － 15 】：实时系统测试 Roger S. Pressman 很多实时系统的时间依赖性和异步性给测试带来新的困难－－时间！测试用例的设计者考虑的不仅是白盒和黑盒测试用例，而且包括事件处理（如中断处理）、数据的时间序列以及处理数据的任务（进程）的并发性。很多情况下，提供的测试数据有时使得实时系统在某状态下可以正常运行，而同样的数据在系统处于不同状态时有时又会导致错误。 另外，实时系统的软件和硬件之间的密切关系也会导致测试问题，软件测试必须考虑硬件故障对软件处理的影响，这种故障很难实时仿真。由于实时系统的特殊性和复杂性，还没有一个完善的综合性的测试用例设计方法，但是，大致可以分为以下四个步骤： 1 、任务测试。测试实时系统的第一步是独立的测试各个任务。对每一个任务设计白盒和黑盒测试用例，并在测试时执行每个任务。任务测试能够发现逻辑和功能错误，但是不能发现时间和行为错误。 2 、行为测试。利用 CASE 工具创建软件模型，就可能仿真实时系统，并按照外部事件的序列检查其行为，这些分析活动可作为创建实时系统时设计测试用例的基础。 3 、任务间测试。在隔离了任务内部和系统行为错误以后，测试就要转向时间相关的错误。用不同的数据率和处理负载来测试与其他任务通讯的异步任务，看任务间的同步是否会产生错误。另外，测试通过消息队列和数据存储进行通讯的任务，以发现这些数据存储区区域大小方面的错误。 4 、系统测试。集成软件和硬件，并进行大范围的系统测试，以发现软件 / 硬件口间的错误。 第 7 贴【 2004 － 5 － 16 】：单元测试、集成测试、系统测试、验收测试、回归测试 Software Research
单元测试：单元测试是对软件中的基本组成单位进行的测试，如一个模块、一个过程等等。它是软件动态测试的最基本的部分，也是最重要的部分之一，其目的是检验软件基本组成单位的正确性。一个软件单元的正确性是相对于该单元的规约而言的。因此，单元测试以被测试单位的规约为基准。单元测试的主要方法有控制流测试、数据流测试、排错测试、分域测试等等。 集成测试：集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。它根据集成测试计划，一边将模块或其他软件单位组合成越来越大的系统，一边运行该系统，以分析所组成的系统是否正确，各组成部分是否合拍。集成测试的策略主要有自顶向下和自底向上两种。 系统测试：系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并非一项简单的任务，它被称为测试的 “ 先知者问题 ” 。因此，系统测试应该按照测试计划进行，其输入、输出和其他动态运行行为应该与软件规约进行对比。软件系统测试方法很多，主要有功能测试、性能测试、随机测试等等。 验收测试：验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。它的测试数据通常是系统测试的测试数据的子集。所不同的是，验收测试常常有软件系统的购买者代表在现场，甚至是在软件安装使用的现场。这是软件在投入使用之前的最后测试。 回归测试：回归测试是在软件维护阶段，对软件进行修改之后进行的测试。其目的是检验对软件进行的修改是否正确。这里，修改的正确性有两重含义：一是所作的修改达到了预定目的，如错误得到改正，能够适应新的运行环境等等；二是不影响软件的其他功能的正确性。  
 
软件测试策略 Roger S. Pressman
测试是一系列可以事先计划并且可以系统地进行管理的活动。正是由于这个原因，应当为软件工程过程定义一个软件测试的模板－我们可以把特定的测试用例方法放置进去的一系列步骤。 人们已经提出了许多软件测试策略，所有这些策略都为如开发人员提供了一个供测试用的模板，而且它们都包含下列的类属特征：
· 测试开始于模块层，然后 “ 延伸 ” 到整个基于计算机的系统集合中。
· 不同的测试技术适用于不同的时间点。
· 测试是由软件的开发人员和（对于大型系统而言）独立的测试组来管理的。
· 测试和调试是不同的活动，但是调试必须能够适应任何的测试策略。 软件测试策略必须提供可以用来检验一小段源代码是否得以正确实现的低层测试，同时也要提供能够验证整个系统的功能是否符合用户需求的高层测试。一种策略必须为使用者提供指南，并且为管理者提供一系列的重要的里程碑。因为测试策略的步骤是在软件完成的最终期限的压力已经开始出现的时候才开始进行的，所以测试的进度必须是可测量的，而且问题要尽可能早的暴露出来。   白盒测试 Rex Black
白盒测试，也称为结构化测试、基于代码的测试，是一种测试用例设计方法，它从程序的控制结构导出测试用例。用白盒测试产生的测试用例能够：
1 ）保证一个模块中的所有独立路径至少被使用一次；
2 ）对所有逻辑值均需测试 true 和 false ；
3 ）在上下边界及可操作范围内运行所有循环；
4 ）检查内部数据结构以确保其有效性。 “ 我们应该更注重于保证程序需求的实现，为什么要花费时间和精力来担心（和测试）逻辑细节” 答案在于软件自身的缺陷：
1 、逻辑错误和不正确假设与一条程序路径被运行的可能性成反比。当我们设计和实现主流之外的功能、条件或控制时，错误往往开始出现在我们工作中。日常处理往往被很好地了解，而 “ 特殊情况 ” 的处理则难于发现。
2 、我们经常相信某逻辑路径不可能被执行，而事实上，它可能在正常的基础上被执行。程序的逻辑流有时是违反直觉的，这意味着我们关于控制流和数据流的一些无意识的假设可能导致设计错误，只有路径测试才能发现这些错误。
3 、笔误是随机的。当一个程序被翻译为程序设计语言源代码时，有可能产生某些笔误，很多将被语法检查机制发现，但是，其他的会在测试开始时才会被发现。笔误出现在主流上和不明显的逻辑路径上的机率是一样的。 正如 Beizer 所说的： “ 错误潜伏在角落里，聚集在边界上 ” ，而白盒测试更可能发现它。   黑盒测试 黑盒测试注重于测试软件的功能性需求，也即黑盒测试使软件工程师派生出执行程序所有功能需求的输入条件。黑盒测试并不是白盒测试的替代品，而是用于辅助白盒测试发现其他类型的错误。黑盒测试试图发现以下类型的错误：
1 ）功能错误或遗漏；
2 ）界面错误；
3 ）数据结构或外部数据库访问错误；
4 ）性能错误；
5 ）初始化和终止错误。 白盒测试在测试的早期采用，而黑盒测试主要用于测试的后期。黑盒测试故意不考虑控制结构，而是注意信息域。黑盒测试用于回答以下问题：
1 ）如何测试功能的有效性
2 ）何种类型的输入会产生好的测试用例
3 ）系统是否对特定的输入值尤其敏感
4 ）如何分隔数据类的边界
5 ）系统能够承受何种数据率和数据量
6 ）特定类型的数据组合会对系统产生何种影响 运用黑盒测试方法，可以导出满足以下标准的测试用例集：
1 ）所设计的测试用例能够减少达到合理测试所需的附加测试用例数；
2 ）所设计的测试用例能够告知某些类型错误的存在或不存在，而不是仅仅与特定测试相关的错误。   软件测试充分性准则 （ 1 ）空测试对任何软件都是不充分的。
（ 2 ）对任何软件都存在有限的充分测试集合。
（ 3 ）如果一个软件系统在一个测试数据集合上的测试是充分的，那么再多测试一些数据也应该是充分的。这一特性称为单调性。
（ 4 ）即使对软件所有成分都进行了充分的测试，也并不意味着整个软件的测试已经充分了。这一特性称为非复合性。
（ 5 ）即使对一个软件系统整体的测试是充分的，也并不意味着软件系统中各个成分都已经充分地得到了测试。这个特性称为非分解性。
（ 6 ）软件测试的充分性应该与软件的需