软件测试第2章课件.ppt

1、软件测试技术基础学时：60学时 第2章 软件测试原理 熟练掌握：软件测试原理，软件测试的分熟练掌握：软件测试原理，软件测试的分类，软件测试过程，软件测试过程模型。类，软件测试过程，软件测试过程模型。掌握：软件测试原理，良好的测试态度是掌握：软件测试原理，良好的测试态度是怎样的，对待缺陷的基本原则，测试结果怎样的，对待缺陷的基本原则，测试结果的处理原则，软件测试的分类，软件测试的处理原则，软件测试的分类，软件测试的过程模型。的过程模型。了解：软件测试过程了解：软件测试过程2.1 软件测试原则 2.1.1 应尽早和不断地测试 由于软件的复杂性和抽象性，以及项目涉及人员之间沟通的不畅等原因，导致在软

2、件生命周期各阶段都可能产生缺陷，因此，不应该将软件测试看成是程序写完之后才开始的一项工作。问题发现得越早，解决问题的代价越小，反之，缺陷发现得越晚，缺陷修复的成本越高，若缺陷遗留到用户手中，则将对公司、对用户都有可能带来极其严重的后果，例如加拿大的Therac 25放射治疗仪事件（由于软件系统总体安全设计出问题，导致了多起医疗事故，）、熊猫烧香病毒等，类似的案例不胜枚举。不断的测试应表现为一个反复的、递增的过程。在最初的阶段，我们可能会采用一些简单的测试方法和模糊的测试过程，测试的效果也许会很差。但经过每次迭代的修正之后，部分测试将进入回归测试形式，下一次测试的开始将覆盖前几次测试的范围，从而

3、逐步加大测试的覆盖面。从另一方面，我们在多次迭代过程中，将逐渐加强对测试过程的认识，强化集成测试和系统测试，规范单元测试，最终可能会重新修正整个测试过程。2.1.2 不可能穷尽测试 想要穷尽测试，就必须在有限的时间和资源（包括人力、物力和资金资源）条件下，找到软件中所有潜在的缺陷。追求软件的完美，是不可能做到的。从总体来看，软件实现的途径太多。从软件的基本要素输入、输出、数据和计算来分析，能进一步证明穷尽测试是不可能的，原因如下。（1）从输入来看，每个输入条件的数据量太大，不同输入条件之间的组合情况太多，要得到健壮的软件，还需要更多考虑无效的输入，而无效的输入情况相比有效输入而言，其数据量和组

4、合情况则更加纷繁复杂，无法穷尽。（2）从输出来看，输出结果太多。输出地种类可能相比输入要少很多，大部分情况下，我们可以分析出所有可能的输出。但针对每种具体输入都必须有一个明确的系统输出，既然输入无法穷尽，则对应的输出也是无法穷尽的。（3）从数据来看，数据的处理方式可能也不过是常规的方法，如添加数据、删除数据等。然而，由于要处理的数据量太大，每种数据类型所包含的有效和无效数据往往是无穷多的，针对每组数据来测试各种操作无疑也是异想天开。（4）从计算来看，由于算法的复杂度越来越高，结合业务的复杂性，导致路径组合近似天文数字，遍历每条路径的穷尽测试，即使对于一个非常熟练的测试员而言，也是望尘莫及的。2

5、.1.3 良好的测试态度良好的测试态度测试应由独立的第三方机构来完成。但国内的测试环境并不成熟，因此黑盒测试多由测试人员来测，而白盒测试则由开发人员通过交叉测试来完成。让开发人员测试自己的代码是一件相当糟糕的事情，理由如下。（1）不愿否定自己的工作。程序员一向认为测试人员总是在挑刺，让他们自己挑自己程序的毛病，更是难上加难。（2）受到思维定式的局限。程序员对自己开发的程序很熟悉，测试时难以跳出自己的编码思路，若设计时就存在理解错误，或受不良编码习惯影响而导致缺陷，一般都很难发现。（3）受进度压力的影响。程序员总是在赶进度，能在规定时间内写完代码就不错了，哪有时间去做测试。“让测试人员去测吧”，

6、这是很多开发人员的态度。（4）程序员对程序的功能和接口很熟悉，这与最终用户的情况往往并不吻合，开发人员自己来测试程序难以具有典型性。1.避免测试自己的程序避免测试自己的程序 2.增量测试增量测试 应采用增量测试的方式，即测试范围应从小规模开始，逐步转向大规模。所谓小规模是指测试的粒度，或某种程序的单元测试。进一步的测试将从单个单元的测试逐步过渡到多个单元的组合测试，即集成测试，最终过渡到系统测试。随着从单元测试到集成测试再到系统测试，测试时间、可用资源和测试范围不断扩大。3.测试应该分级测试应该分级 测试应该分级别。不同级别的测试，采用的测试活动、测试方法和测试重点等各有不同（如表2-1）。表

7、中，DT&E测试是指开发测试和评价（Development Test and Evaluation），OT&E是指操作测试和评价（Operational Test and Evaluation）。4.测试应有重点测试应有重点 尽管测试应按一定级别进行，但受到资源和时间的限制，不可能无休止地测试下去。因此在有限的时间和资源下如何有重点地进行测试是测试管理者需充分考虑的事情。测试的重点选择需根据多方面考虑，包括测试对象的关键程度、可能的风险、质量要求等。这些考虑与经验有关，随着实践经验的增长，判断也会更准确。5.避免测试的随意性避免测试的随意性 软件测试是一项系统工程，是有组织、有计划、有步骤的活

8、动。因此，测试应制定合理的测试计划。测试计划反映一个测试团队在正常情况下需完成的工作远景描述，一般包括测试需求、测试策略、资源、项目里程碑、可交付工作等关键内容。但通常情况下，将资源从测试计划中分离出来是一种更好的习惯。2.1.4 对待缺陷的基本原则对待缺陷的基本原则1.缺陷的群集现象缺陷的群集现象 一般情况下，80%的软件缺陷集中在20%的模块中。造成缺陷群集现象的主要原因如下。（1）程序员的疲劳。程序员长期疲劳工作，会造成大量代码缺陷，若让程序员进行12小时或更长时间的持续编码，后期程序片段中出现的缺陷比例会呈直线上升。（2）程序员的习惯。程序员可能因个人变成习惯，而反复犯同样的错误。2.

9、缺陷有免疫力缺陷有免疫力 Boris Beizer曾描述了缺陷的“杀虫剂怪事”现象，即软件测试越多，缺陷的免疫力却越强的现象。因此，在测试中应使用不同的测试方法、针对程序的不同部分进行测试。一般每修复34个缺陷，就会产生一个新缺陷，所以在回归测试中要充分注意缺陷的修复所产生的波及面，圈定合适的回归测试的范围。3.缺陷关联和依赖缺陷关联和依赖。某个缺陷因其他缺陷而出现或消失，关闭某个缺陷必须先关闭其父类缺陷，这类“缺陷关联”现象表明缺陷之间存在着一定的依赖关系。只有经过回归测试才能确保缺陷被正确地修复。2.1.5 测试结果的处理原则测试结果的处理原则1.对缺陷进行复查和确认对缺陷进行复查和确认

10、一般由测试员A（也可以是开发人员和客户）测试出来的缺陷，一定要由项目经理B（或由开发人员、开发经理）来确认，严重的缺陷还应召开评审会议进行讨论和分析，从而防止无效的缺陷对资源的浪费。有的缺陷可能是由测试人员的失误造成的，有的缺陷可能是一个重复提交的缺陷，有的缺陷可能会被开发人员认为是符合设计的。这些都应该通过复查予以确认。测试过程混乱和对设计的歧义是造成无效缺陷的主要来源。在回归测试中尤其应该注意这些，应利用工具对缺陷进行良好的管理。2.测试结果的全面检查 测试结果中可能夹杂着大量正确和错误的输出信息，应仔细区分。要特别注意的是，应尽量用自动检查的方式来确认每个测试结果。自动测试工具可以帮助我

11、们方便地鉴别测试后输出的数据，并给出清晰地缺陷分析报告。在单元测试、系统测试阶段均可使用自动测试工具。3.出错统计和分析 应对测试过程中找到的所有缺陷进行定期统计和分析，包括对所有缺陷进行定性分析，确定其严重程度和优先级别，同时应支持缺陷的统计分析，如累积打开/关闭缺陷总数，不同模块中的缺陷总数，不同类型的缺陷总数，不同阶段发现的缺陷总数等，以便于根据这些统计结果决定是否可以进入下一个测试阶段。若找到项目的进展过程中最薄弱的环节，如设计较差的模块、编程能力较弱的程序员等，在后续开发过程中应加以改进，包括人员的培训、缺陷检查表的扩充等。4.妥善保存测试过程文档 整个测试过程中，应妥善保存一切测试

12、过程文档，便于后续的开发及测试过程改进，提高软件产品质量。测试过程文档包括各阶段的测试计划、测试设计说明书、测试用例说明书、测试脚本、测试总结报告等。2.2 软件测试的分类软件测试的分类 2.2.1 按是否需查看代码分类 1.黑盒测试黑盒测试是将被测试软件看做一个黑盒子，只考虑系统的输入和输出，完全不考虑程序内部逻辑结构和处理过程。黑盒测试的依据是各阶段的需求规格说明（如需求分析阶段是产品的需求规格说明书，单元测试阶段是函数的详细设计说明书）。黑盒测试的优点如下。黑盒测试用例与程序如何实现无关。因此，若程序内部逻辑结构和处理过程发生变化，将不会影响该黑盒测试用例。测试用例的设计与程序的开发可以

13、并行进行。没有编程经验的人也可以设计黑盒测试用例（这也是造成当前测试人员的素质偏低的主要原因之一）。当然，一般情况下，具备一定的编程经验最好。黑盒测试的局限性如下。不可能做到穷举测试。由于输入控件太大，包括输入条件太多、输入数据量太大、输入条件的组合太复杂等因素，导致黑盒测试不可能做到穷举测试。因不可能做到输入的穷举，只能从中选择部分输入构成测试用例，因此黑盒测试是很有可能存在漏洞的。黑盒测试又称功能性测试（Functional Testing）或数据驱动测试（Data-driven Testing）。但注意，功能性测试不等于功能测试。黑盒测试是从功能的角度检查软件是否满足需求规格说明的要求，

14、但并不仅限于功能测试。2.白盒测试 白盒测试是将黑盒子打开，研究源代码和程序内部的逻辑结构。白盒测试的依据是程序代码。利用白盒测试的覆盖指标所设计的测试用例与采用黑盒方法所得到的测试用例常常存在重复。因此，白盒测试一般充当黑盒测试的补充。与黑盒测试相比，白盒测试具有如下特殊的应用领域。程序代码往往具有多个分支。白盒测试可以利用不同的覆盖准则来测试这些分支，黑盒测试则无法做到这一点。白盒测试的覆盖指标可以充当黑盒测试的检查手段。例如，若采用黑盒方法设计的测试用例（如边界值测试）没有满足某些白盒测试覆盖指标（如判定覆盖）的要求，则证明该测试用例集合必然存在漏洞。代码中常存在内存泄露的问题，尤其是C

15、/C+程序，白盒测试可以方便地发现内存泄露的问题，且是直接定位缺陷，而黑盒测试只能通过长时间运行程序，并仔细地检查用例执行结果，才能发现这类问题。有时只有在某种极端的条件下才会出现的情况，是难以直接进行功能测试的，如卫星在太空中收到电磁辐射。这时，缺陷预防是测试的主要母的，白盒测试通过对源代码的静态分析可以发现该类问题。白盒测试也存在局限性，特别是不可能做到穷举测试，原因如下。程序中的逻辑路径太多，往往需要面对路径爆炸的问题。例如，有的代码可能不到100行，却具有520条可能的路径，若每条路径设计一个测试用例，且每个测试用例执行一次需要1ms，则连续执行所有的测试用例大约需要3170年。由于设

16、计的原因，程序的实际执行路径可能比逻辑路径略微少一点，但实际应用的程序也很多。实际上，穷举路径测试也不等于完全的测试，因为它无法发现程序违反设计规范的地方，无法发现程序本身是否缺少某些路径，不能发现程序中已经实现但不是用户所需要的功能，可能无法暴露数据敏感错误，即与数据相关的错误，经常发现不了用户操作行为的缺陷。白盒测试又称结构性测试（Structural Testing）或逻辑驱动测试（Logic-driven Testing）。值得注意的是，白盒测试并非仅限于对程序源代码的测试。对于高层的测试，仍然可以采用某些白盒测试的方法。3.黑盒测试与白盒测试的比较黑盒测试和白盒测试从不同的方面来检查

17、被测软件，无论单独采用黑盒测试，还是单独采用白盒测试都无法做到全面的测试。仅用黑盒测试方法，将无法发现程序内部结构的缺陷，这些缺陷可能暂时不会导致软件的失效，但可能是个隐患，当特定的条件被触发（例如大数据量处理）时，就可能使得软件出现问题，而白盒测试可以及时发现这些缺陷。仅用白盒测试的方法，则无法从宏观上来观察软件运行结果，如程序是否满足设计要求，软件是否符合用户需求，这些都是更加严重的缺陷。黑盒测试通常用于软件的系统测试、验收测试、功能和性能测试等方面，由测试人员来完成。白盒测试一般主要在单元测试、集成测试中采用，通常由开发人员来完成。2.2.2 按是否需要执行被测试软按是否需要执行被测试软

18、件分类件分类 1.静态测试静态测试 静态测试（Static Testing）又称静态分析（Static Analysis），是不实际运行被测软件，而是直接分析软件的形式和结构，查找缺陷。主要包括对源代码、程序界面和各类文档及中间产品（如产品规格说明书、技术设计文档等）所做的测试。（1）对于源代码 静态测试主要是看代码是否符合相应的标准和规范，如可读性、可维护性等，其工作过程类似一个编译器，随着语法分析的进行做特定工作，如分析模块调用图、程序的控制流图等图表，度量软件的代码质量等。一般各公司内部都有自己相应的编码规范，如C/C+编码规范、Java编码规范等，应按照规范中所列出的条目逐条测试。源代

19、码种含有大量原设计信息，以及程序异常的信息。利用静态测试，不仅可以发现程序中明显的缺陷，还可以帮助程序员重点关注那些可能存在缺陷的高风险模块，如多出口的情况、程序复杂度过高的情况、接口过多的情况等。当然，对源代码进行静态测试并非易事，可以借助一些自动化的静态分析工具来降低测试人员的劳动强度。目前市面上已有很多静态分析工具，如Telelogic公司的Logiscope，Parasoft公司的C+Test，这些静态分析工具一般由四个部分组成：语言程序预处理器、数据库、错误分析器和报告生成器。（2）对于程序界面 静态测试主要是查看软件的实际操作和运行界面是否符合需求中的相关说明。（3）对于文档 静态

20、测试主要是检查用户手册与需求说明是否真正符合用户的实际要求。程序界面和文档的静态测试相对容易一些，但要求测试人员应充分熟悉用户需求，且比较细心。从实际情况来讲，界面和文档的测试常常是不收重视的。静态测试是采用走查、同行评审、会审等方法来查找错误或收集所需度量数据的。其不需要运行程序，所以相对动态测试，可以更早地进行。静态分析的查错和分析功能是其他方法所不能替代的，静态分析能发现文档中的问题（也只能通过静态测试发现），通过文档中的问题或其他软件评审发现来发现需求分析、软件设计等问题，而且能有效地检查代码是否具有可读性、可维护性，是否遵守编程规范，包括代码风格、变量/对象/类的命名、注释行等。静态

21、测试已被当做一种主要的自动化代码校验方法。2.动态测试 动态测试（Dynamic Testing）又称动态分析（Dynamic Analysis），是指需要实际运行被测软件，通过观察程序运行时所表现出来的状态、行为等发现软件缺陷，包括在程序运行时，通过有效的测试用例（对应的输入、输出关系）来分析被测程序的运行情况或进行跟踪对比，发现程序所表现的行为与设计规格或客户需求不一致的地方。动态测试是一种经常运行的测试方法，无论在单元测试、集成测试中，还是在系统测试、验收测试中，都是一种有效的测试方法。但它也存在很多局限性，主要体现在以下方面。往往需要借助测试用例来完成。即通过执行测试用例，分析测试用例

22、来对被测软件重点考查，以期发现缺陷。相比静态测试，动态测试增加了测试用例的设计、执行和分析，以及由测试用例所带来的用例组织与管理等一系列活动。需要搭建软件特定的运行环境，增加了有关测试环境的配置、维护和管理的工作量。不能发现文档问题，必须等程序代码完成后进行，发现问题相对迟得多。3.静态测试与动态测试的比较静态测试与动态测试的比较（1）协同性 静态测试和动态测试在各自的优缺点上具有互补性。静态测试是保守和健壮的，其测试结果离我们的期望值可能还有距离，但它保证了将来的执行。而动态测试是有效和精确的，它不需要花费大量的分析过程，尽管它确实需要测试用例的设计、执行和结果分析。动态测试给出了高度精确的

23、结果。（2）独立性 静态测试需要建立程序的状态模型（如函数调用图、控制流图等），在此基础上确定程序对该状态的反映（如通过各种图表分析，找出多入口多出口的模块，高层控制模块等）。因系统可能执行的状态有很多，测试必须跟踪多个不同的状态，通常经过大量细致的分析后也不一定能考虑到所有的系统状态。因此，静态分析通常采用程序状态的抽象模型，并需要较长时间的等待。2.2.3 按测试阶段分类按测试阶段分类 按照测试的阶段可将软件测试分为单元测试、集成测试、系统测试等。1.单元测试 单元测试（Unit Testing）又称模块测试（Module Testing），是指对软件中的最小可测试单元进行测试，目的是检查

24、每个单元是否能够正确实现详细设计说明中的功能、性能、接口和设计约束等要求，发现各个模块内部可能存在的各种缺陷。在程序员编码之后，代码通过编译后一般就可以进行单元测试了。由于国内的单位测试往往不正规，因此单元测试多由开发人员自己来完成，一般是交叉测试。单元测试的主要依据是程序代码和详细设计文档。根据设计文档、编码规范和注释，从程序内部结构出发，查看代码是否符合设计、规范以及注释的相关说明。单元测试过程中应结合黑盒与白盒测试方法，且大部分软件测试方法基本都适用于单元测试。单元测试的优点在于：是一种管理和组合测试元素的手段。通过单元测试，可实现测试从“小规模”向“大规模”的逐步转变，从而降低测试难度

25、，提高测试效率。减轻调试的难度。调试是准确定位并纠正某个已知缺陷的过程，在测试用例指导下的单元测试针对性更强，更加有利于缺陷的定位和实效原因的分析。提供同时测试多个单元的可能。多个相互独立或关联性不大的单元可以并行地、独立地进行单元测试，从而加快整体的测试速度和项目进度。2.集成测试 集成测试（Integration Testing）又称组装测试，是在单元测试的基础上，按照设计要求，将通过单元测试的单元组装成系统或子系统而进行的有序的测试，目的是检验不同程序单元或部件之间的接口关系是否符合概要设计的要求，能否正常运行。集成测试并非等到所有单元测试完成之后才开始，而是同步进行的，即在单元测试中先

26、对几个单元进行独立的单元测试，然后将其组装起来进行集成测试，查看其接口是否存在缺陷。集成测试一般也由白盒测试工程师或开发人员来完成。集成测试的主要依据是单元测试的单元及概要设计文档。由于软件的集成往往是持续的过程，将形成很多临时版本，在不断的集成过程中，功能集成的稳定是需要解决的主要问题。在每个版本提交的时候，应先进行冒烟测试（Smoke Testing，即版本验证测试），来验证组要功能是否能够正常执行。与单元测试相比，后者主要从单元内部来测试，而前者主要考查单元的外部接口。有人可能会产生疑问：从单元（如函数）内部来测试，也需要检查单元的接口，集成测试时还需要检查接口。3.系统测试系统测试（S

27、ystem Testing）是为了验证和确认系统是否达到其原始目标，而对集成的硬件和软件系统进行的测试，是在真实或模拟系统运行的环境下，检查完整的程序系统是否能和系统（包括硬件、外设、网络和系统软件、支持平台等）正确配置、连接，并满足用户需求。系统测试主要由黑盒测试工程师在整个系统集成好之后进行。前期主要看系统功能是否满足需求，这被称为功能测试。后期主要测试系统运行是否满足需求，以及系统在不同硬件和软件环境中的兼容性等，这被称为功能测试。后期主要测试系统运行是否满足要求，以及系统在不同硬件和软件环境中的兼容性等，这被分别称为性能测试、兼容性测试、用户界面测试等。有人也喜欢将功能测试从系统测试中

28、单独提出来，作为集成测试和系统测试之间的一个测试环节。系统测试的主要依据是软件的需求规格说明文档。4.验收测试 验收测试（Acceptance Testing）又称接受测试，是一种正式的测试，是在系统测试后期，以用户测试为主，或有测试人员等质量保证人员共同参与的测试，是一般由用客户或其他权威机构来决定是否可以接受一个产品（系统或组件）的验证性测试。验收测试是软件正式交付给用户使用的最后一个测试环节，并决定用户是否最终验收签字和结清所有应付款。验收测试的主要依据是软件需求规格说明文档和验收标准。验收测试的测试用例可以直接采用内部测试组所设计的系统测试用例的子集，也可以游验收人员自行设计。验收测试

29、又分测试和测试。（1）测试也称开发方测试，开发方通过检测和提供客观证据，证明软件运行是否满足用户规定的需求。它是在软件开发环境下，由用户、测试人员和开发人员共同参与的内部测试，属于产品早期性测试。该测试一般在可控制环境下进行，可以是用户在开发环境下进行的测试，也可以是公司内部用户在模拟实际操作环境下进行的受控测试。测试被戏称为放任内部成员胡作非为的测试。（2）测试是内部测试之后的外部公开测试，是将软件完全交给用户，让用户在实际使用环境下进行的对产品预发布版本的测试。该测试是在开发者无法控制的环境下进行的软件现场应用。其实施过程是先将软件产品有计划地分发到目标市场，让最终用户大量使用、评价和检查

30、软件，从而发现软件缺陷，然后从市场收集反馈信息，把关于反馈信息的评价制成容易处理的数据表，再将这些数据分发给所涉及的各个部门进行修改。它通常被看成是一种“用户测试”，这也是测试定义的核心思想。从有效的测试中可以获取大量信息。测试被戏称为让全世界的坏人都胡作非为的测试。2.2.4 按测试执行时是否需要人按测试执行时是否需要人工干预分类工干预分类1.手工测试手工测试 手工测试是完全由人工完成测试工作，包括测试计划的制订，测试用例的设计和执行，以及测试结果的检查和分析等。传统的测试工作都是由人工来完成的。2.自动测试自动测试 自动测试是各种测试活动的管理与实施，是使用自动化测试工具或自动化测试脚本来

31、进行的测试，包括测试脚本的开发与执行等，以某种自动测试工具来验证测试需求。这类测试在执行过程中一般不需要人工干预，通常在功能测试、回归测试和性能测试中使用较为广泛。自动测试的优点如下。（1）能够产生出可靠的系统。自动测试可改进所有的测试领域，若自动测试工具和方法被正确地使用，且遵循定义的测试过程，则自动测试可以改进需求定义，改进性能测试，改进压力测试、质量测量并使测试最佳化，改进与开发组的伙伴关系和改进系统开发生存周期。（2）改进测试工作质量。使用自动测试工具可增加测试的深度和广度，包括改进冒烟测试，改进回归测试，改进多平台兼容性测试，改进普通的测试执行，集中解决高级测试问题，提高重视缺陷的能

32、力，增强业务专业知识，完成手工测试无法完成的测试。（3）减少测试工作并缩短进度。2.2.5 其他测试类型其他测试类型1冒烟测试冒烟测试 冒烟测试冒烟测试(smoke test)在测试中发现问题，找到了一个Bug，然后开发人员会来修复这个Bug。这时想知道这次修复是否真的解决了程序的Bug，或者是否会对其它模块造成影响，就需要针对此问题进行专门测试，这个过程就被称为Smoke Test。在很多情况下，做Smoke Test是开发人员在试图解决一个问题的时候，造成了其它功能模块一系列的连锁反应，原因可能是只集中考虑了一开始的那个问题，而忽略其它的问题，这就可能引起了新的Bug。Smoke Test

33、优点是节省测试时间，防止build失败。缺点是覆盖率还是比较低。冒烟测试是自由测试的一种。2.随机测试随机测试随机测试是根据测试说明书执行样例测试的重要补充手段，是保证测试覆盖完整性的有效方式和过程。随机测试主要是对被测软件的一些重要功能进行复测，也包括测试那些当前的测试样例(TestCase)没有覆盖到的部分。另外，对于软件更新和新增加的功能要重点测试。重点对一些特殊点情况点、特殊的使用环境、并发性、进行检查。尤其对以前测试发现的重大Bug，进行再次测试，可以结合回归测试(Regressivetesting)一起进行。理论上，每一个被测软件版本都需要执行随机测试，尤其对于最后的将要发布的版本

34、更要重视随机测试。随机测试最好由具有丰富测试经验的熟悉被测软件的测试人员进行测试。对于被测试的软件越熟悉，执行随机测试越容易。只有不断的积累测试经验，包括具体的测试执行和对缺陷跟踪记录的分析，不断总结，才能提高。2.3 软件测试过程 软件测试过程是一种抽象的模型，用于定义软件测试的流程和方法。众所周知，开发过程的质量决定了软件的质量，同样的，测试过程的质量将直接影响测试结果的准确性和有效性。软件测试过程和软件开发过程一样，都遵循软件工程原理，遵循管理学原理。随着测试过程管理的发展，软件测试专家通过实践总结出了很多很好的测试过程模型。这些模型将测试活动进行了抽象，并与开发活动有机的进行了结合，是

35、测试过程管理的重要参考依据。2.4 软件测试的过程模型软件测试的过程模型2.4.1 V模型模型V模型是最具有代表意义的测试模型，如书上图2-4所示。V模型最早是由Paul Rook在20世纪80年代后期提出的，V模型在英国国家计算中心文献中发布，旨在改进软件开发的效率和效果。在传统的开发模型中，比如瀑布模型，人们通常把测试过程作为在需求分析、概要设计、详细设计和编码全部完成之后的一个阶段，尽管有时测试工作会占用整个项目周期一半的时间，但是有人仍然认为测试只是一个收尾工作，而不是主要的过程。V模型的推出就是对此种认识的改进。V模型是软件开发瀑布模型的变种，它反映了测试活动与分析和设计的关系，从左

36、到右，描述了基本的开发过程和测试行为，非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系，如模型图（书上图2-4）中所示，图中的箭头代表了时间方向，左边下降的是开发过程各阶段，与此相对应的是右边上升的部分，即各测试过程的各个阶段。V模型的软件测试策略既包括低层测试又包括了高层测试，低层测试是为了源代码的正确性，高层测试是为了使整个系统满足用户的需求。V模型指出，单元和集成测试是验证的程序设计，开发人员和测试组应检测程序的执行是否满足软件设计的要求；系统测试应当验证系统设计，检测系统功能、性能的质量特性是否达到系统设计的指标；由测试人员和用户进行

37、软件的确认测试和验收测试，追溯软件需求说明书进行测试，以确定软件的实现是否满足用户需求或合同的要求。V模型存在一定的局限性，它仅仅把测试过程作为在需求分析、概要设计、详细设计及编码之后的一个阶段。容易使人理解为测试是软件开发的最后的一个阶段，主要是针对程序进行测试寻找错误，而需求分析阶段隐藏的问题一直到后期的验收测试才被发现。2.4.2 W模型模型 1.W模型建立 V模型的局限性在于没有明确地说明早期的测试，不能体现“尽早地和不断地进行软件测试”的原则。在V模型中增加软件各开发阶段应同步进行的测试，被演化为一种W模型，因为实际上开发是“V”，测试也是与此相并行的“V”。基于“尽早地和不断地进行

38、软件测试”的原则，在软件的需求和设计阶段的测试活动应遵循IEEE std 1012-1998软件验证和确认（V&V）的原则。2.W模型应用W模型由Evolutif公司公司提出，相对于V模型，W模型更科学。W模型可以说是V模型自然而然的发展。它强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。这样，只要相应的开发活动完成，我们就可以开始执行测试，可以说，测试与开发是同步进行的，从而有利于尽早地发现问题。以需求为例，需求分析一完成，我们就可以对需求进行测试，而不是等到最后才进行针对需求的验收测试。如果测试文档能尽早提交，那么就有了更多的检查和检阅的时间，这些

39、文档还可用于评估开发文档。另外还有一个很大的益处是，测试者可以在项目中尽可能早地找出缺陷所在，从而帮助改进项目内部的质量。参与前期工作的测试者可以预先估计问题和难度，这将可以显著地减少总体测试时间，加快项目进度。根据W模型的要求，一旦有文档提供，就要及时确定测试条件，以及编写测试用例，这些工作对测试的各级别都有意义。当需求被提交后，就需要确定高级别的测试用例来测试这些需求。当概要设计编写完成后，就需要确定测试条件来查找该阶段的设计缺陷。W模型也是有局限性的。W模型和V模型都把软件的开发视为需求、设计、编码等一系列串行的活动。同样的，软件开发和测试保持一种线性的前后关系，需要有严格的指令表示上一

40、阶段完全结束，才可正式开始下一阶段。这样就无法支持迭代、自发性以及变更调整。相对于当前很多文档需要时候补充，或者根本没有文档的做法下（这已成为一种开发的文化），开发人员和测试人员都面临同样的困惑。2.4.3 H模型模型 1.H模型建立V模型和W模型均存在一些不妥之处。首先，如前所述，它们都把软件的开发视为需求、设计、编码等一系列串行的活动，而事实上，虽然这些活动之间存在相互牵制的关系，但在大部分时间内，它们是可以交叉进行的。虽然软件开发期望有清晰的需求、设计和编码阶段，但实践告诉我们，严格的阶段划分只是一种理想状况。试问，有几个软件项目是在有了明确的需求之后才开始设计的呢？所以，相应的测试之间

41、也不存在严格的次序关系。同时，各层次之间的测试也存在反复触发、迭代和增量关系。其次，V模型和W模型都没有很好地体现测试流程的完整性。为了解决以上问题，有专家提出了H模型。它将测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。2.H模型应用H模型揭示了：软件测试不仅仅指测试的执行，还包括很多其他的活动。软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行。软件测试要尽早准备，尽早执行。软件测试是根据被测物的不同而分层次进行的。不同层次的测试活动可以是按照某个次序先后进行的，但也可能是反复的。在H模型中，软件测试模型是一个独立的流程，贯穿于整

42、个产品周期，与其他流程并发地进行。当某个测试时间点就绪时，软件测试即从测试准备阶段进入测试执行阶段。2.4.4 X模型模型 由于V模型收到了很多人的质疑，因此，也有人提出了一些不同的观点和意见。在此，我们向大家介绍另外一种测试模型，即X模型，其目标是弥补V模型的一些缺陷。X模型的基本思想是由Marick提出的，但首先Marick不建议建立一个替代模型，同时，他也认为他的观点并不足以支撑一个模型的完整描述。不过，Robin F.Goldsmith先生在自己的文章里将其思想定义为X模型，理由是，在Marick的观点中已经具备一个模型所需要的一些主要内容，其中也包括了像探索性测试这样的亮点 Marick对V模型最主要的批评是V模型无法引导项目的全部过程。他认为一个模型必须能处理开发的所有方面，包括交接、频繁重复的集成以及需求文档的缺乏等。Marick认为一个模型不应该规定那些和当前所公认的实践不一致的行为。X模型左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后，将进行频繁的交接，通过集成最终合成为可执行的程序。这一点在图的右上方得以体现，而且这些可执行程序还需要进行测试，已通过集成测试的成品可以进行封版并提交给用户，也可以作为更大规模和范围内集成的一部分。第第2章结束章结束 谢谢！