软件测试的目标概述
合集下载
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
软件测试的目标
测试的目的就是在软件投入生产性运行之前， 尽可能多地发现软件中的错误。目前软件测试仍然 是保证软件质量的关键步骤， 测试是对软件规 格说明、设计和编码的最后复审。
根本目标：尽可能多地发现并排除软件中潜 藏的错误，最终把高质量的软件系统交给用户。
无论怎样强调软件测试的重要性和它对软件 可靠性的影响都不过分。
自底向上测试方法的优缺点刚好相反。
混合策略：
➢ 改进的自顶向下测试方法： 基本上使用自顶 向下的测试方法，但是在早期，就使用自底 向上的方法测试软件中的少数关键模块。
➢ 混合法：对软件结构中较上层，使用的是自 顶向下方法；对软件结构中较下层，使用的 是自底向上方法，两者相结合。
７．４ 验收测试
验收测试的任务——验证软件的有效性。 软件有效性定义——如果软件的功能和性 能如同用户所合理地期待的那样，则软件 是有效的。
（4）对错误的处理（例外处理）不正确；
（5）描述错误的信息不足以帮助确定造成错误 的位置。
边界测试是单元测试中最后的也可能是最 重要的任务。软件常常在它的边界上失效。
7.2.2 单元测试过程 通常经过人工测试和计算机测试两种类型的测
试。
1. 代码审查 人工测试源程序可以由编写者本人非正式地进
行，也可以由审查小组正式进行。后者称为代码审 查，它是一种非常有效的程序验证技术，对于典型 的程序来说，可以查出30％～70％的逻辑设计错误 和编码错误。
发现的错误的测试方案； （3）成功的测试是发现了至今为止尚未发现的
错误的测试。 测试的定义——为了发现程序中的错误而执 行程序的过程。
测试目标决定了测试方案的设计。如果为 了表明程序是正确的而进行测试，就会设计 一些不易暴露错误的测试方案；相反，如果 测试是为了发现程序中的错误，就会力求设 计出最能暴露错误的测试方案。
如果一个模块完成外部的输入或输出时， 还应该再检查下述各点：
（1）文件属性是否正确？ （2）打开文件语句是否正确？ （3）格式说明书与输入／输出语句是否一致？ （4）缓冲区大小与记录长度是否匹配？ （5）使用文件之前先打开文件了吗？ （6）文件结束条件处理了吗？ （7）输入／输出错误检查并处理了吗？ （8）输出信息中有文字书写错误吗？
在所有的模块都完成单元测试以后 提一个问题：
如果每个模块都工作的很好，那么为什么 要怀疑把它们放在一起就不能正常工作呢？ 问题在于：“怎样放在一起”——接口 问题数不胜数
集成测试
集成测试是通过测试发现和接口有关的问 题来构造程序结构的系统化技术。 目标：把通过了单元测试的模块拿来，构 造一个在设计中所描述的程序结构。
7．３ 集成测试
集成测试是组装软件的系统技术，由模块组装 成程序时有两种方法。
一种方法是先分别测试每个模块，再把所有模块 按设计要求放在一起结合成所要的程序，这种方 法称为非渐增式测试方法；（通常存在的倾向）
另一种方法是把下一个要测试的模块同已经测试 好的那些模块结合起来进行测试，测试完以后再 把下一个应该测试的模块结合进来测试。这种每 次增加一个模块的方法称为渐增式测试，这种方 法实际上同时完成单元测试和集成测试。
由于错误的计算、不正确的比较或不适当 的控制流造成的错误： （1）计算次序不对或误解了运算符的优先次序； （2）混合运算（运算对象的类型彼此不相容）； （3）变量初始值不正确； （4）精度不够； （5）表达式的符号表示错误。
比较后控制流变化的错误： （1）比较数据类型不同的量； （2）逻辑运算符不正确或优先次序的错误； （3）当由于精度问题两个量不会相等时，程序中却
7.3.2 自底向上结合
自底向上测试从“原子”模块（即在软件结构最 低层的模块）开始组装和测试。
7.3.3 不同测试策略的比较 自顶向下结合的优点：
不需要测试驱动程序，能在早期实现并验 证系统的主要功能，能较早发现上层模快的 接口错误。
自顶向下结合的缺点：
需要存根程序，可能遇到与此相联系的测 试困难，低层关键模块中的错误发现较晚， 而且用这种方法在早期不能充分展开人力。
代码审查比计算机测试优越的是：一次审查会 上可以发现许多错误。可减少系统验证的总工作量
实践表明，对于查找某些类型的错误来说，人 工测试比计算机测试更有效；对于其他类型的错误 立的程序，因此必须为
每个单元测试开发驱动软件和（或）存根软 件。
高内聚可简化单元测试过程。（减少所需的 测试方案，且模块中的错误也更容易预测和 发现）
➢ 渐增式测试方法对程序的测试更彻底。 ➢ 渐增式测试需要较多的机器时间。
➢ 非渐增式测试方法可以并行测试所有模块， 因此能充分利用人力，加快工程进度。
总的说来，渐增式测试方法比较好。
使用渐增方式把模块结合到软件系统中去 时，有自顶向下和自底向上两种方法。
7.3.1自顶向下结合
从主控制模块（“主程序”）开始，沿着软件的 控制层次向下移动，从而逐渐把各个模块结合起来。
“好”测试的属性
一个好测试发现错误的可能性很高。 一个好测试并不冗余。（每个测试都该有 不同的用途） 一个好测试应该是一组目的相似的测试中 最佳的，最可能找到所有错误的测试。 一个好测试既不会太简单，也不会太复杂。
7.1.2 黑盒测试和白盒测试 测试任何产品都有两种方法：
黑盒测试——如果已经知道了产品应该具有 的功能，可以通过测试来检验是否每个功能 都能正常使用；
3. 系统测试
系统测试是把经过测试的子系统装配成一 个完整的系统来测试。在这个测试步骤中发 现的往往是软件设计中的错误，也可能发现 需求说明中的错误。
4. 验收测试
验收测试把软件系统作为单一的实体进行 测试，目的是验证系统确实能够满足用户的 需要，在这个测试步骤中发现的往往是系统 需求说明书中的错误。
软件测试在软件生命周期中横跨两个阶段。 软件测试包括两种：
单元测试——模块的编写者和测试者是同一 个人
综合测试——由专门的测试人员承担 软件测试的工作量往往占软件开发总工作
量的40％以上
7.１ 基本概念
7.1.1 软件测试的目标 （1）测试是为了发现程序中的错误而执行程序
的过程； （2）好的测试方案是极可能发现迄今为止尚未
5. 平行运行
平行运行就是同时运行新开发出来的系统和将 被它取代的旧系统，以便比较新旧两个系统的处理 结果。这样做的具体目的有如下几点：
（1）可以在准生产环境中运行新系统而又不冒风 险；
（2）用户能有一段熟悉新系统的时间；
（3）可以验证用户指南和使用手册之类的文档；
（4）能够以准生产模式对新系统进行全负荷测试， 可以用测试结果验证性能指标。
在单元测试期间主要评价模块的下述五个特性： ➢ 模块接口； ➢ 局部数据结构； ➢ 重要的执行通路； ➢ 出错处理通路； ➢ 影响上述各方面特性的边界条件。
在对接口进行测试时主要检查下述各点； （１）参数数目和由调用模块送来的变元的数目是否
相等？ （2）参数的属性和变元的属性是否匹配？ （3）参数和变元的单位系统是否匹配？ （4）传送给被调用模块的变元的数目是否等于那个 模块的参数的数目？ （5）传送给被调用模块的变元属性和参数的属性是 否一致？ （6）传送给被调用模块的变元的单位系统和该模块参 数的单位系统是否一致？ （7）传送给内部函数的变元属性、数目和次序是否 正确？ （8）是否修改了只做输入用的变元？ （9）全程变量的定义和用法在各个模块中是否一致？
测试原则
所有的测试都应追溯到用户需求。 应在测试工作真正开始的前较长时间内就
进行测试计划。（测试计划可在设计模型 一完成就开始，详细测试方案定义可在设 计模型被确定后立即开始） 穷举测试是不可能的。 为达到最佳效果，应由独立的第三方来构 造测试。
可测试性
软件的可测试性就是一个计算机程序能够被测试的容易程度。 可测试性特征：
（使用程序设计的控制结构导出测试方案）
包含所有可能情况的测试称为穷尽测试， 对于实际程序而言，穷尽测试通常是不可能 做到的。
白盒测试功能
保证一个模块中的所有独立路径至少被执 行一次。 对所有逻辑值均需测试TRUE和FALSE。 在上下边界及可操作范围内运行所有循环。 检查内部数据结构以确保其有效性。
两种方法的主要优缺点：
➢ 非渐增式测试方法工作量比较大
➢ 渐增式测试可以较早发规模块间的接口错误； 非渐增式测试最后才把模块组装在一起，因 此接口错误发现得晚。
➢ 非渐增式测试一下子把所有模块组合在一起， 如果发现错误则较难诊断定位；使用渐增式 测试方法时，如果发生错误则往往和最近加 进来的那个模块有关。
期待着相等条件的出现； （4）“差1”错（即，多循环一次或少循环一次）； （5）错误的或不存在的循环终止条件； （6）当遇到发散的迭代时不能终止循环； （7）错误地修改循环变量。
当错误处理部分，应该考虑潜在的错误：
（1）对错误的描述是难于理解的； （2）记下的错误与实际遇到的错误不同；
（3）在对错误进行处理之前，错误条件已经引 起系统异常；
对于一个模块而言，局部数据结构是常见 的错误来源。应该仔细设计测试方案，以便 发现下述类型的错误：
（1）错误的或不相容的说明； （2）使用尚未赋值或尚未初始化的变量； （3）错误的初始值或不正确的缺省值； （4）错误的变量名字（拼写错或截短了）； （5）数据类型不相容； （6）上溢、下溢或地址异常。
白盒测试——如果知道产品内部工作过程， 可以通过测试来检验产品内部动作是否按照 规格说明书的规定正常进行，且所有内部部 件被充分利用（确保“所有齿轮吻合”）。
黑盒测试又称为功能测试，它把程序看成 一个黑盒子，完全不考虑程序的内部结构和 处理过程。也就是说，黑盒测试是在程序接 口进行的测试，它只检查程序功能是否能按
测试阶段的信息流
软件配置： 测试配置 + 测试实际结果 + 调试纪录
测试配置： 测试计划 + 测试方案
测试方案： 测试时使用的输入数据（测试用例） 每组输入数据预定要检查的功能 每组输入数据预期应该得到的正确输出
7.1.4 测试阶段的信息流
7．２ 单元测试
单元测试集中检验软件设计的最小单元——模 块。单元测试通常使用白盒测试法，而且对多个模 块的测试可以并行地进行。 7.2.1 单元测试考虑
需求分析阶段产生的文档准确地描述了 用户对软件的合理期望，因此是软件有效
由于测试的目标是暴露程序中的错误，因 此由程序的编写者自己进行测试是不恰当的。 因此，在综合测试阶段通常由其他人员组成 测试小组来完成测试工作。
测试不能证明错误不存在，只能表示软件 错误已经出现。
测试决不能证明程序是正确的。即使经过 了最严格的测试之后，仍然可能还有没被发 现的错误潜藏在程序中。测试只能查找出程 序中的错误，不能证明程序中没有错误。
照规格说明书的规定正常使用，程序是否能 适当地接收输入数据产生正确的输出信息， 并且保持外部信息（如，数据库或文件）的 完整性。
（故意不考虑控制结构，而是注意信息域）
黑盒测试检测的错误类型
功能不对或遗漏。 界面错误。 数据结构或外部数据库访问错误。 性能错误。 初始化和终止错误。
白盒测试又称为结构测试，它的前提是可 以把程序看成装在一个透明的白盒子里，也 就是完全了解程序的结构和处理过程。这种 方法按照程序内部的逻辑测试程序，检验程 序中的每条通路是否都能按预定要求正确工 作。
7.1.3 软件测试的步骤
1. 模块测试
模块测试的目的是保证每个模块作为一个单元 能正确运行，所以模块测试通常又称为单元测试。 在这个测试步骤中所发现的往往是编码和详细设计 的错误。
2. 子系统测试
子系统测试是把经过单元测试的模块放在一起 形成一个子系统来测试。模块相互间的协调和通信 是这个测试过程中的主要问题，因此这个步骤着重 测试模块的接口。
可操作性“运行得越好，被测试的效率越高” 可观察性。“你所见的即为你所测试的” 可控制性。“对软件控制越好，测试越能够被自动执行与 优化” 可分解性。“通过控制测试范围，能更快的分界问题，执 行更灵巧的再测试” 简单性。“需测试的内容越少，测试速度越快” 稳定性。“改变越少，对测试的破坏越小” 易理解性。“得到的信息越多，进行的测试越灵巧”
测试的目的就是在软件投入生产性运行之前， 尽可能多地发现软件中的错误。目前软件测试仍然 是保证软件质量的关键步骤， 测试是对软件规 格说明、设计和编码的最后复审。
根本目标：尽可能多地发现并排除软件中潜 藏的错误，最终把高质量的软件系统交给用户。
无论怎样强调软件测试的重要性和它对软件 可靠性的影响都不过分。
自底向上测试方法的优缺点刚好相反。
混合策略：
➢ 改进的自顶向下测试方法： 基本上使用自顶 向下的测试方法，但是在早期，就使用自底 向上的方法测试软件中的少数关键模块。
➢ 混合法：对软件结构中较上层，使用的是自 顶向下方法；对软件结构中较下层，使用的 是自底向上方法，两者相结合。
７．４ 验收测试
验收测试的任务——验证软件的有效性。 软件有效性定义——如果软件的功能和性 能如同用户所合理地期待的那样，则软件 是有效的。
（4）对错误的处理（例外处理）不正确；
（5）描述错误的信息不足以帮助确定造成错误 的位置。
边界测试是单元测试中最后的也可能是最 重要的任务。软件常常在它的边界上失效。
7.2.2 单元测试过程 通常经过人工测试和计算机测试两种类型的测
试。
1. 代码审查 人工测试源程序可以由编写者本人非正式地进
行，也可以由审查小组正式进行。后者称为代码审 查，它是一种非常有效的程序验证技术，对于典型 的程序来说，可以查出30％～70％的逻辑设计错误 和编码错误。
发现的错误的测试方案； （3）成功的测试是发现了至今为止尚未发现的
错误的测试。 测试的定义——为了发现程序中的错误而执 行程序的过程。
测试目标决定了测试方案的设计。如果为 了表明程序是正确的而进行测试，就会设计 一些不易暴露错误的测试方案；相反，如果 测试是为了发现程序中的错误，就会力求设 计出最能暴露错误的测试方案。
如果一个模块完成外部的输入或输出时， 还应该再检查下述各点：
（1）文件属性是否正确？ （2）打开文件语句是否正确？ （3）格式说明书与输入／输出语句是否一致？ （4）缓冲区大小与记录长度是否匹配？ （5）使用文件之前先打开文件了吗？ （6）文件结束条件处理了吗？ （7）输入／输出错误检查并处理了吗？ （8）输出信息中有文字书写错误吗？
在所有的模块都完成单元测试以后 提一个问题：
如果每个模块都工作的很好，那么为什么 要怀疑把它们放在一起就不能正常工作呢？ 问题在于：“怎样放在一起”——接口 问题数不胜数
集成测试
集成测试是通过测试发现和接口有关的问 题来构造程序结构的系统化技术。 目标：把通过了单元测试的模块拿来，构 造一个在设计中所描述的程序结构。
7．３ 集成测试
集成测试是组装软件的系统技术，由模块组装 成程序时有两种方法。
一种方法是先分别测试每个模块，再把所有模块 按设计要求放在一起结合成所要的程序，这种方 法称为非渐增式测试方法；（通常存在的倾向）
另一种方法是把下一个要测试的模块同已经测试 好的那些模块结合起来进行测试，测试完以后再 把下一个应该测试的模块结合进来测试。这种每 次增加一个模块的方法称为渐增式测试，这种方 法实际上同时完成单元测试和集成测试。
由于错误的计算、不正确的比较或不适当 的控制流造成的错误： （1）计算次序不对或误解了运算符的优先次序； （2）混合运算（运算对象的类型彼此不相容）； （3）变量初始值不正确； （4）精度不够； （5）表达式的符号表示错误。
比较后控制流变化的错误： （1）比较数据类型不同的量； （2）逻辑运算符不正确或优先次序的错误； （3）当由于精度问题两个量不会相等时，程序中却
7.3.2 自底向上结合
自底向上测试从“原子”模块（即在软件结构最 低层的模块）开始组装和测试。
7.3.3 不同测试策略的比较 自顶向下结合的优点：
不需要测试驱动程序，能在早期实现并验 证系统的主要功能，能较早发现上层模快的 接口错误。
自顶向下结合的缺点：
需要存根程序，可能遇到与此相联系的测 试困难，低层关键模块中的错误发现较晚， 而且用这种方法在早期不能充分展开人力。
代码审查比计算机测试优越的是：一次审查会 上可以发现许多错误。可减少系统验证的总工作量
实践表明，对于查找某些类型的错误来说，人 工测试比计算机测试更有效；对于其他类型的错误 立的程序，因此必须为
每个单元测试开发驱动软件和（或）存根软 件。
高内聚可简化单元测试过程。（减少所需的 测试方案，且模块中的错误也更容易预测和 发现）
➢ 渐增式测试方法对程序的测试更彻底。 ➢ 渐增式测试需要较多的机器时间。
➢ 非渐增式测试方法可以并行测试所有模块， 因此能充分利用人力，加快工程进度。
总的说来，渐增式测试方法比较好。
使用渐增方式把模块结合到软件系统中去 时，有自顶向下和自底向上两种方法。
7.3.1自顶向下结合
从主控制模块（“主程序”）开始，沿着软件的 控制层次向下移动，从而逐渐把各个模块结合起来。
“好”测试的属性
一个好测试发现错误的可能性很高。 一个好测试并不冗余。（每个测试都该有 不同的用途） 一个好测试应该是一组目的相似的测试中 最佳的，最可能找到所有错误的测试。 一个好测试既不会太简单，也不会太复杂。
7.1.2 黑盒测试和白盒测试 测试任何产品都有两种方法：
黑盒测试——如果已经知道了产品应该具有 的功能，可以通过测试来检验是否每个功能 都能正常使用；
3. 系统测试
系统测试是把经过测试的子系统装配成一 个完整的系统来测试。在这个测试步骤中发 现的往往是软件设计中的错误，也可能发现 需求说明中的错误。
4. 验收测试
验收测试把软件系统作为单一的实体进行 测试，目的是验证系统确实能够满足用户的 需要，在这个测试步骤中发现的往往是系统 需求说明书中的错误。
软件测试在软件生命周期中横跨两个阶段。 软件测试包括两种：
单元测试——模块的编写者和测试者是同一 个人
综合测试——由专门的测试人员承担 软件测试的工作量往往占软件开发总工作
量的40％以上
7.１ 基本概念
7.1.1 软件测试的目标 （1）测试是为了发现程序中的错误而执行程序
的过程； （2）好的测试方案是极可能发现迄今为止尚未
5. 平行运行
平行运行就是同时运行新开发出来的系统和将 被它取代的旧系统，以便比较新旧两个系统的处理 结果。这样做的具体目的有如下几点：
（1）可以在准生产环境中运行新系统而又不冒风 险；
（2）用户能有一段熟悉新系统的时间；
（3）可以验证用户指南和使用手册之类的文档；
（4）能够以准生产模式对新系统进行全负荷测试， 可以用测试结果验证性能指标。
在单元测试期间主要评价模块的下述五个特性： ➢ 模块接口； ➢ 局部数据结构； ➢ 重要的执行通路； ➢ 出错处理通路； ➢ 影响上述各方面特性的边界条件。
在对接口进行测试时主要检查下述各点； （１）参数数目和由调用模块送来的变元的数目是否
相等？ （2）参数的属性和变元的属性是否匹配？ （3）参数和变元的单位系统是否匹配？ （4）传送给被调用模块的变元的数目是否等于那个 模块的参数的数目？ （5）传送给被调用模块的变元属性和参数的属性是 否一致？ （6）传送给被调用模块的变元的单位系统和该模块参 数的单位系统是否一致？ （7）传送给内部函数的变元属性、数目和次序是否 正确？ （8）是否修改了只做输入用的变元？ （9）全程变量的定义和用法在各个模块中是否一致？
测试原则
所有的测试都应追溯到用户需求。 应在测试工作真正开始的前较长时间内就
进行测试计划。（测试计划可在设计模型 一完成就开始，详细测试方案定义可在设 计模型被确定后立即开始） 穷举测试是不可能的。 为达到最佳效果，应由独立的第三方来构 造测试。
可测试性
软件的可测试性就是一个计算机程序能够被测试的容易程度。 可测试性特征：
（使用程序设计的控制结构导出测试方案）
包含所有可能情况的测试称为穷尽测试， 对于实际程序而言，穷尽测试通常是不可能 做到的。
白盒测试功能
保证一个模块中的所有独立路径至少被执 行一次。 对所有逻辑值均需测试TRUE和FALSE。 在上下边界及可操作范围内运行所有循环。 检查内部数据结构以确保其有效性。
两种方法的主要优缺点：
➢ 非渐增式测试方法工作量比较大
➢ 渐增式测试可以较早发规模块间的接口错误； 非渐增式测试最后才把模块组装在一起，因 此接口错误发现得晚。
➢ 非渐增式测试一下子把所有模块组合在一起， 如果发现错误则较难诊断定位；使用渐增式 测试方法时，如果发生错误则往往和最近加 进来的那个模块有关。
期待着相等条件的出现； （4）“差1”错（即，多循环一次或少循环一次）； （5）错误的或不存在的循环终止条件； （6）当遇到发散的迭代时不能终止循环； （7）错误地修改循环变量。
当错误处理部分，应该考虑潜在的错误：
（1）对错误的描述是难于理解的； （2）记下的错误与实际遇到的错误不同；
（3）在对错误进行处理之前，错误条件已经引 起系统异常；
对于一个模块而言，局部数据结构是常见 的错误来源。应该仔细设计测试方案，以便 发现下述类型的错误：
（1）错误的或不相容的说明； （2）使用尚未赋值或尚未初始化的变量； （3）错误的初始值或不正确的缺省值； （4）错误的变量名字（拼写错或截短了）； （5）数据类型不相容； （6）上溢、下溢或地址异常。
白盒测试——如果知道产品内部工作过程， 可以通过测试来检验产品内部动作是否按照 规格说明书的规定正常进行，且所有内部部 件被充分利用（确保“所有齿轮吻合”）。
黑盒测试又称为功能测试，它把程序看成 一个黑盒子，完全不考虑程序的内部结构和 处理过程。也就是说，黑盒测试是在程序接 口进行的测试，它只检查程序功能是否能按
测试阶段的信息流
软件配置： 测试配置 + 测试实际结果 + 调试纪录
测试配置： 测试计划 + 测试方案
测试方案： 测试时使用的输入数据（测试用例） 每组输入数据预定要检查的功能 每组输入数据预期应该得到的正确输出
7.1.4 测试阶段的信息流
7．２ 单元测试
单元测试集中检验软件设计的最小单元——模 块。单元测试通常使用白盒测试法，而且对多个模 块的测试可以并行地进行。 7.2.1 单元测试考虑
需求分析阶段产生的文档准确地描述了 用户对软件的合理期望，因此是软件有效
由于测试的目标是暴露程序中的错误，因 此由程序的编写者自己进行测试是不恰当的。 因此，在综合测试阶段通常由其他人员组成 测试小组来完成测试工作。
测试不能证明错误不存在，只能表示软件 错误已经出现。
测试决不能证明程序是正确的。即使经过 了最严格的测试之后，仍然可能还有没被发 现的错误潜藏在程序中。测试只能查找出程 序中的错误，不能证明程序中没有错误。
照规格说明书的规定正常使用，程序是否能 适当地接收输入数据产生正确的输出信息， 并且保持外部信息（如，数据库或文件）的 完整性。
（故意不考虑控制结构，而是注意信息域）
黑盒测试检测的错误类型
功能不对或遗漏。 界面错误。 数据结构或外部数据库访问错误。 性能错误。 初始化和终止错误。
白盒测试又称为结构测试，它的前提是可 以把程序看成装在一个透明的白盒子里，也 就是完全了解程序的结构和处理过程。这种 方法按照程序内部的逻辑测试程序，检验程 序中的每条通路是否都能按预定要求正确工 作。
7.1.3 软件测试的步骤
1. 模块测试
模块测试的目的是保证每个模块作为一个单元 能正确运行，所以模块测试通常又称为单元测试。 在这个测试步骤中所发现的往往是编码和详细设计 的错误。
2. 子系统测试
子系统测试是把经过单元测试的模块放在一起 形成一个子系统来测试。模块相互间的协调和通信 是这个测试过程中的主要问题，因此这个步骤着重 测试模块的接口。
可操作性“运行得越好，被测试的效率越高” 可观察性。“你所见的即为你所测试的” 可控制性。“对软件控制越好，测试越能够被自动执行与 优化” 可分解性。“通过控制测试范围，能更快的分界问题，执 行更灵巧的再测试” 简单性。“需测试的内容越少，测试速度越快” 稳定性。“改变越少，对测试的破坏越小” 易理解性。“得到的信息越多，进行的测试越灵巧”