软件工程-测试课件

--测试软件工程1谢谢观赏2019-6-29内容提要软件测试的目的错误分类基本任务、特点和原则软件测试的信息流软件测试的方法测试用例的设计软件测试的过程及其相关的角色与职责测试层次测试的类型软件测试与调试软件可靠性2谢谢观赏2019-6-29软件测试是为了发现错误而执行程序的过程。程序运行需要数据，为测试设计的数据称测试用例。软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例，并利用这些测试用例去运行程序，以发现程序错误的过程。3谢谢观赏2019-6-29软件测试在软件生存期中横跨两个阶段：通常在编写出每一个模块之后就对它做必要的测试（称为单元测试）。模块的编写者与测试者是同一个人。编码与单元测试属于软件生存期中的同一个阶段。在这个阶段结束之后，对软件系统还要进行各种综合测试，这是软件生存期的另一个独立的阶段，即测试阶段，通常由专门的测试人员承担这项工作。4谢谢观赏2019-6-29软件测试的目的GrenfordJ.Myers就软件测试目的提出以下观点：测试是程序的执行过程，目的在于发现错误；一个好的测试用例很可能找到迄今为止尚未发现的错误；一个成功的测试是发现了至今未发现的错误的测试。E.W.Dijkstra指出:程序测试能证明错误的存在，但不能证明错误不存在。测试的目的是发现程序中的错误，是为了证明程序有错，而不是证明程序无错。5谢谢观赏2019-6-29软件测试的目的测试的目的是想以最少的时间和人力系统地找出软件中潜在的各种错误和缺陷。如果我们成功地实施了测试，就能够发现软件中的错误。测试的附带收获是，它能够证明软件的功能和性能与需求说明相符合。此外，实施测试收集到的测试结果数据为可靠性分析提供了依据。把证明程序无错当作测试目的不仅是不正确的,完全做不到的，而且对做好测试没有任何益处，甚至是十分有害的。能够发现错误的测试是成功的测试，否则是失败的测试。6谢谢观赏2019-6-29测试者知道软件怎样才能发生故障而导致失败，并可记录发生失败的多种故障类型测试案例没有冗余。每个测试案例都有不同的用途，不要重复相同意义的测试案例使用最具有代表性的案例，它能够高效率揭示所有可能的错误每个测试应该能独立执行，不能太复杂，也不会太简单，它们能够被组合用于一个测试案例中好的测试应该具有的特性7谢谢观赏2019-6-29软件错误的分类由于人们对错误有不同的理解和认识，所以目前还没有一个统一的错误分类方法。错误难于分类的原因，一方面是由于一个错误有许多征兆，因而它可以被归入不同的类。另一方面是因为把一个给定的错误归于哪一类，还与错误的来源和程序员的心理状态有关。Tobecontinue…8谢谢观赏2019-6-29软件错误的分类按错误的影响和后果分类较小错误：只对系统输出有一些非实质性影响。如，输出的数据格式不合要求等。中等错误：对系统的运行有局部影响。如输出的某些数据有错误或出现冗余。较严重错误：系统的行为因错误的干扰而出现明显不合情理的现象。比如开出了0.00元的支票，系统的输出完全不可信赖。严重错误：系统运行不可跟踪，一时不能掌握其规律，时好时坏。非常严重的错误：系统运行中突然停机，其原因不明，无法软启动。最严重的错误：系统运行导致环境破坏，或是造成事故，引起生命、财产的损失。Tobecontinue…9谢谢观赏2019-6-29软件错误的分类按错误的性质和范围分类

B.Beizer从软件测试观点出发，把软件错误分为5类：功能错误系统错误加工错误数据错误代码错误Tobecontinue…10谢谢观赏2019-6-29功能错误规格说明错误：规格说明可能不完全，有二义性或自身矛盾。功能错误：程序实现的功能与用户要求的不一致。这常常是由于规格说明中包含错误的功能、多余的功能或遗漏的功能所致。测试错误：软件测试的设计与实施发生错误。软件测试自身也可能发生错误。测试标准引起的错误：对软件测试的标准要选择适当，若测试标准太复杂，则导致测试过程出错的可能就大。11谢谢观赏2019-6-29系统错误外部接口错误：外部接口指如终端、打印机、通信线路等系统与外部环境通信的手段。所有外部接口之间，人与机器之间的通信都使用形式的或非形式的专门协议。如果协议有错，或太复杂，难以理解，致使在使用中出错。此外还包括对输入／输出格式错误理解，对输入数据不合理的容错等等。内部接口错误：内部接口指程序之间的联系。它所发生的错误与程序内实现的细节有关。例如，设计协议错、输入／输出格式错、数据保护不可靠、子程序访问错等。硬件结构错误：这类错误在于不能正确地理解硬件如何工作。例如，忽视或错误地理解分页机构、地址生成、通道容量、I／O指令、中断处理、设备初始化和启动等而导致的出错。Tobecontinue…12谢谢观赏2019-6-29系统错误操作系统错误：这类错误主要是由于不了解操作系统的工作机制而导致出错。当然，操作系统本身也有错误，但是一般用户很难发现这种错误。软件结构错误：由于软件结构不合理或不清晰而引起的错误。这种错误通常与系统的负载有关，而且往往在系统满载时才出现。这是最难发现的一类错误。例如，错误地设置局部参数或全局参数；错误地假定寄存器与存储器单元初始化了；错误地假定不会发生中断而导致不能封锁或开中断；错误地假定程序可以绕过数据的内部锁而导致不能关闭或打开内部锁；错误地假定被调用子程序常驻内存或非常驻内存等等，都将导致软件出错。Tobecontinue…13谢谢观赏2019-6-29系统错误控制与顺序错误：包括：忽视了时间因素而破坏了事件的顺序；猜测事件出现在指定的序列中；等待一个不可能发生的条件；漏掉先决条件；规定错误的优先级或程序状态；漏掉处理步骤；存在不正确的处理步骤或多余的处理步骤等。资源管理错误：这类错误是由于不正确地使用资源而产生的。例如，使用未经获准的资源；使用后未释放资源；资源死锁；把资源链接在错误的队列中等等。14谢谢观赏2019-6-29加工错误算术与操作错误：指在算术运算、函数求值和一般操作过程中发生的错误。包括：数据类型转换错；除法溢出；错误地使用关系比较符；用整数与浮点数做比较等。初始化错误：典型的错误有：忘记初始化工作区，忘记初始化寄存器和数据区；错误地对循环控制变量赋初值；用不正确的格式，数据或类型进行初始化等等。控制和次序错误：这类错误与系统级同名错误类似，但它是局部错误。包括：遗漏路径；不可达到的代码；不符合语法的循环嵌套；循环返回和终止的条件不正确；漏掉处理步骤或处理步骤有错等。静态逻辑错误：这类错误主要包括：不正确地使用CASE语句；在表达式中使用不正确的否定（例如用“＞”代替“＜”的否定）；对情况不适当地分解与组合；混淆“或”与“异或”等。15谢谢观赏2019-6-29数据错误动态数据错误：动态数据是在程序执行过程中暂时存在的数据。各种不同类型的动态数据在程序执行期间将共享一个共同的存储区域，若程序启动时对这个区域未初始化，就会导致数据出错。由于动态数据被破坏的位置可能与出错的位置在距离上相差很远，因此要发现这类错误比较困难。静态数据错误：静态数据在内容和格式上都是固定的。它们直接或间接地出现在程序或数据库中，由编译程序或其它专门程序对它们做预处理，这是在程序执行前防止静态错误的好办法，但预处理也会出错。数据内容错误：数据内容是指存储于存储单元或数据结构中的位串、字符串或数字。数据内容本身没有特定的含义，除非通过硬件或软件给予解释。数据内容错误就是由于内容被破坏或被错误地解释而造成的错误。Tobecontinue…16谢谢观赏2019-6-29数据错误数据结构错误：数据结构是指数据元素的大小和组织形式。在同一存储区域中可以定义不同的数据结构。数据结构错误主要包括结构说明错误及把一个数据结构误当做另一类数据结构使用的错误。这是更危险的错误。数据属性错误：数据属性是指数据内容的含义或语义。例如，整数、字符串、子程序等等。数据属性错误主要包括：对数据属性不正确地解释，比如错把整数当实数，允许不同类型数据混合运算而导致的错误等。17谢谢观赏2019-6-29代码错误主要包括：语法错误；打字错误；对语句或指令不正确理解所产生的错误。18谢谢观赏2019-6-29程序错误的分类Goodenough－Gerhart分类方法把软件的逻辑错误按生存期不同阶段分为4类:问题定义错误规格说明错误设计错误编码错误19谢谢观赏2019-6-29问题定义错误它们是在软件定义阶段，分析员研究用户的要求后所编写的文档中出现的错误。换句话说，这类错误是由于问题定义不满足用户的要求而导致的错误。20谢谢观赏2019-6-29规格说明错误这类错误是指规格说明与问题定义不一致所产生的错误。它们又可以细分成：不一致性错误--规格说明中功能说明与问题定义发生矛盾。冗余性错误--规格说明中某些功能说明与问题定义相比是多余的。不完整性错误--规格说明中缺少某些必要的功能说明。不可行错误--规格说明中有些功能要求是不可行的。不可测试错误--有些功能的测试要求是不现实的。21谢谢观赏2019-6-29设计错误这是在设计阶段产生的错误，它使系统的设计与需求规格说明中的功能说明不相符。它们又可以细分为：设计不完全错误：某些功能没有被设计，或设计得不完全。算法错误：算法选择不合适。主要表现为算法的基本功能不满足功能要求、算法不可行或者算法的效率不符合要求。模块接口错误：模块结构不合理；模块与外部数据库的界面不一致，模块之间的界面不一致。控制逻辑错误：控制流程与规格说明不一致；控制结构不合理。数据结构错误：数据设计不合理；与算法不匹配；数据结构不满足规格说明要求。22谢谢观赏2019-6-29编码错误编码过程中的错误是多种多样的，大体可归为以下几种：数据说明错、数据使用错、计算错、比较错、控制流错、界面错、输入／输出错，及其它的错误。

在不同的开发阶段，错误的类型和表现形式是不同的，故应当采用不同的方法和策略来进行检测。23谢谢观赏2019-6-29软件测试的基本任务测试阶段的基本任务应该是根据软件开发各阶段的文档资料和程序的内部结构，精心设计一组“高产”的测试用例，利用这些用例执行程序，找出软件潜在的缺陷。24谢谢观赏2019-6-29软件测试的特点软件测试的开销大按照Boehm的统计，软件测试的开销大约占总成本的30%－50%。例如：APPOLLO登月计划，80%的经费用于软件测试。不能进行穷举测试只有将所有可能的情况都测试到，才有可能检查出所有的错误。但这是不可能的。例如：程序P有两个整型输入量X、Y，输出量为Z，在32位机上运行。所有的测试数据组(Xi,Yi)的数目为：232×232＝264。假设１毫秒执行１次，如要进行完全测试，共需５亿年。25谢谢观赏2019-6-29例:•Windows95有1000万行代码

•Windows2000有5000万行代码，

3000多个工程师，几百个小团队。Exchange2000和Windows2000开发人员结构Exchange2000Windows2000项目经理25人约250人开发人员140人约1700人测试人员350人约3200人26谢谢观赏2019-6-29软件测试的原则测试是一项非常复杂的、创造性的和需要高度智慧的挑战性的工作。测试一个大型程序所要求的创造力，事实上可能要超过设计那个程序所要求的创造力。软件测试中一些直观上看是很显而易见的至关重要的原则，总是被人们忽视。应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭。 不应把软件测试仅仅看作是软件开发的一个独立阶段，而应当把它贯穿到软件开发的各个阶段中。坚持在软件开发的各个阶段的技术评审，这样才能在开发过程中尽早发现和预防错误，把出现的错误克服在早期，杜绝某些发生错误的隐患。测试用例应由测试输入数据和与之对应的预期输出结果这两部分组成。 测试之前应当根据测试的要求选择测试用例（Testcase），用来检验程序员编制的程序，因此不但需要测试的输入数据，而且需要针对这些输入数据的预期输出结果。Tobecontinue…27谢谢观赏2019-6-29软件测试的原则程序员应避免检查自己的程序。 程序员应尽可能避免测试自己编写的程序，程序开发小组也应尽可能避免测试本小组开发的程序。如果条件允许，最好建立独立的软件测试小组或测试机构。这点不能与程序的调试（debuging）相混淆。调试由程序员自己来做可能更有效。Tobecontinue…28谢谢观赏2019-6-29软件测试的原则开发者在测试自己的程序时存在一些弊病：开发者对自己的程序印象深刻，并总以为是正确的。倘若在设计时就存在理解错误，或因不良的编程习惯而留下隐患，那么他本人很难发现这类错误。开发者对程序的功能、接口十分熟悉，他自己几乎不可能因为使用不当而引发错误，这与大众用户的情况不太相似，所以自己测试程序难以具备典型性。程序设计犹如艺术设计，开发者总是喜欢欣赏程序的成功之处，而不愿看到失败之处。让开发者去做“蓄意破坏”的测试，就像杀自己的孩子一样难以接受。即便开发者非常诚实，但“珍爱程序”的心理让他在测试时不知不觉地带入了虚假成分。29谢谢观赏2019-6-29下面我们再来看看Microsoft公司关于测试的经验教训：IBMPC机一起推出的BASIC软件，用户在用“.1”（或者其他数字）除以10时，就会出错。在FORTRAN软件中也存在破坏数据的“Bug”。由此激起了许多采用Microsoft操作系统的PC厂商的极大不满，而且很多个人用户也纷纷投诉。Microsoft公司的经理们发现很有必要引进更好的内部测试与质量控制方法。但是遭到很多程序设计师甚至一些高级经理的坚决反对，他们固执地认为在高校学生、秘书或者外界合作人士的协助下，开发人员可以自己测试产品。在1984年推出Mac机Multiplan（电子表格软件）之前，Microsoft曾特地请AuthurAnderson咨询公司进行测试。但是外界公司一般没有能力执行全面的软件测试。结果，一种相当厉害的破坏数据的“Bug”迫使Microsoft公司为它的2万多名用户免费提供更新版本，代价是每个版本10美元，一共花了20万美元，可谓损失惨重。痛定思痛后，Microsoft公司的经理们得出一个结论：如果再不成立独立的测试部门，软件产品就不可能达到更高的质量标准。IBM和其他有着成功的软件开发历史的公司便是效法的榜样。但Microsoft公司并不照搬IBM的经验，而是有选择地采用了一些看起来比较先进的方法，如独立的测试小组，自动测试以及为关键性的构件进行代码复查等。30谢谢观赏2019-6-29Microsoft公司的一位开发部门主管戴夫·穆尔回忆说：“我们清楚不能再让开发部门自己测试了。我们需要一个单独的小组来设计测试，运行测试，并把测试信息反馈给开发部门。这是一个伟大的转折点。”但是有了独立的测试小组后，并不等于万事大吉了。自从Microsoft公司在1984年与1986年之间扩大了测试小组后，开发人员开始“变懒”了。他们把代码扔到一边等着测试，忘了唯有开发人员自己才能阻止错误的发生、防患于未来。此时，Microsoft公司历史上第二次灾难降临了。原定于1986年7月发行的Mac机的Word3.0，千呼万唤方于1987年2月问世。这套软件竟然有700多出错误，有的错误可以破坏数据甚至摧毁程序。一下子就使Microsoft名声扫地。公司不得不为用户提供升级版本，费用超过了100万美元。从Microsoft公司的教训中可知，公司内部对产品的测试需要开发人员与独立的测试小组共同参与。31谢谢观赏2019-6-29软件测试的原则在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。 合理的输入条件是指能验证程序正确的输入条件；不合理的输入条件是指异常的，临界的，可能引起问题异变的输入条件。软件系统处理非法命令的能力必须在测试时受到检验。用不合理的输入条件测试程序时，往往比用合理的输入条件进行测试能发现更多的错误。Tobecontinue…32谢谢观赏2019-6-29软件测试的原则充分注意测试中的群集现象。 在被测程序段中，若发现错误数目多，而残存错误数目也比较多，这种错误群集现象。群集现象已为许多程序的测试实践所证实。根据这个规律，应当对错误群集的程序段进行重点测试，以提高测试投资的效益。pareto原则：测试发现的错误中80%很可能起源于20%的模块中。应孤立这些疑点模块重点测试。严格执行测试计划，排除测试的随意性。 测试之前应仔细考虑测试的项目，对每一项测试做出周密的计划，包括被测程序的功能、输入和输出、测试内容、进度安排、资源要求、测试用例的选择、测试的控制方式和过程等，还要包括系统的组装方式、跟踪规程、调试规程，回归测试的规定，以及评价标准等。对于测试计划，要明确规定，不要随意解释。Tobecontinue…33谢谢观赏2019-6-29软件测试的原则应当对每一个测试结果做全面检查。 有些错误的征兆在输出实测结果时已经明显地出现了，但是如果不仔细地全面地检查测试结果，就会使这些错误被遗漏掉。所以必须对预期的输出结果明确定义，对实测的结果仔细分析检查，以暴露错误。妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。34谢谢观赏2019-6-29软件测试阶段的信息流测试结果分析可靠性分析排错软件配置测试配置测试工具预期结果错误率数据测试结果错误改正的软件需求规格说明书软件设计说明书被测源程序测试计划测试用例测试驱动程序35谢谢观赏2019-6-29软件测试阶段的信息流上图中，测试过程需要三类输入：软件配置：包括软件需求规格说明、软件设计规格说明、源代码等；测试配置：包括测试计划、测试用例、测试驱动程序等；测试工具：测试工具为测试的实施提供某种服务。例如，测试数据自动生成程序、静态分析程序、动态分析程序、测试结果分析程序、以及驱动测试的工作台等。36谢谢观赏2019-6-29软件测试阶段的信息流测试之后，用实测结果与预期结果进行比较。如果发现出错的数据，就要进行调试。对已经发现的错误进行错误定位和确定出错性质，并改正这些错误，同时修改相关的文档。修正后的文档一般都要经过再次测试，直到通过测试为止。通过收集和分析测试结果数据，对软件建立可靠性模型。如果测试发现不了错误，那么可以肯定，测试配置考虑得不够细致充分，错误仍然潜伏在软件中。这些错误最终不得不由用户在使用中发现，并在维护时由开发者去改正。但那时改正错误的费用将比在开发阶段改正错误的费用要高出40倍到60倍。37谢谢观赏2019-6-29软件测试方法静态测试方法动态测试方法白盒测试方法黑盒测试方法38谢谢观赏2019-6-29静态和动态测试汽车的检查过程:踩油门看车漆打开前盖检查发动汽车听听发动机声音上路行使静态测试动态测试39谢谢观赏2019-6-29静态测试方法静态测试方法的基本特征是在对软件进行分析、检查和审阅，但并不实际运行被测试的软件。如： 对需求规格说明书、软件设计说明书、源程序做检查和审阅，包括：是否符合标准和规范；通过结构分析、流图分析、符号执行指出软件缺陷。Tobecontinue…40谢谢观赏2019-6-29静态测试方法人工测试：通过人工阅读分析以及评审软件的文档、程序资料等。一些设计上的逻辑错误在机器上不易发现，需要人工复查。好的人工复查，可找出30～70%的编码和逻辑设计错误。计算机辅佐分析：设计一些分析工具对被测程序进行静态分析，从中提取信息。如检查局部变量和全局变量、参数匹配、判断与循环的嵌套匹配、潜在的死循环、不执行的代码、过程调用层次等。41谢谢观赏2019-6-29动态测试方法动态测试：通过运行软件来检验软件的动态行为和运行结果的正确性动态测试的两个基本要素：被测试程序测试数据（测试用例）Tobecontinue…42谢谢观赏2019-6-29动态测试方法动态测试方法的基本步骤：选取定义域有效值，或定义域外无效值；对已选取值决定预期的结果；用选取值执行程序；执行结果与预期的结果相比，不吻合程序有错。如果了解软件产品的内部逻辑结果，可针对某些特定条件设计测试用例，对软件的逻辑路径进行测试，即白盒测试；如果完全不考虑程序的内部结构和处理过程，测试仅在程序界面上进行，测试的目的是为了证实各个功能完全可执行，并在各功能中查找错误，则是黑盒测试。Tobecontinue…43谢谢观赏2019-6-29黑盒测试与白盒测试的比较黑盒测试是从用户观点，按规格说明书要求的输入数据与输出数据的对应关系设计测试用例，是根据程序外部特征进行测试。白盒测试是根据程序内部逻辑结构进行测试。值得指出的是，黑盒测试法与白盒测试法不能互相替代，相反两者应互为补充，在测试的不同阶段为发现不同类型的错误而灵活选用。44谢谢观赏2019-6-29

黑盒测试与白盒测试比较黑盒测试

白盒测试优点缺点性质①适用于各阶段测试②从产品功能角度测试③容易入手生成测试数据①可构成测试数据使特定程序部分得到测试②有一定的充分性度量手段③可或较多工具支持①某些代码得不到测试②如果规格说明有误，则无法发现③不易进行充分性测试①不易生成测试数据(通常)②无法对未实现规格说明的部分进行测试③工作量大，通常只用于单元测试，有应用局限是一种确认技术，回答“我们在构造一个正确的系统吗？”是一种验证技术，回答“我们在正确地构造一个系统吗？”45谢谢观赏2019-6-29测试用例的定义测试内容的一系列情景和每个情景中必须依靠输入和输出，而对软件的正确性进行判断的测试文档，称为测试用例。测试用例就是将软件测试的行为活动，做一个科学化的组织归纳。测试用例的设计如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件公司探索和追求的目标。测试用例是测试工作的指导，是软件测试的必须遵守的准则。更是软件测试质量稳定的根本保障。46谢谢观赏2019-6-29测试用例的组成元素与范例测试用例编号ID测试用例标题测试的模块测试输入条件期望的输出结果其它说明ID类型标题测试步骤期望的结果说明001登录输入正确密码用户在登录界面输入正确的密码后，按回车键程序提示登录成功002登录输入错误密码用户在登录界面输入错误的密码后，按回车键程序提示输入密码错误，请重新输入003登录不输入的空密码用户在登录界面没有输入任何密码使密码为空后，按回车键程序提示用户没有输入密码，请输入程序应该告知用户没有输入密码，而不是密码错误47谢谢观赏2019-6-29测试用例的设计方法黑盒测试技术等价类划分法边界值分析法错误推测法白盒测试技术逻辑覆盖法基本路径测试法48谢谢观赏2019-6-29黑盒测试技术等价类划分法边界值分析法错误推测法49谢谢观赏2019-6-29等价类划分法等价类划分法是一种典型的黑盒测试方法，使用这一方法时，完全不考虑程序的内部结构，只依据程序的规格说明来设计测试用例。等价类划分法把所有可能的输入数据，即程序的输入域划分成若干部分，然后从每一部分中选取少数有代表性的数据做为测试用例。使用这一方法设计测试用例要经历划分等价类（列出等价类表）和选取测试用例两步。50谢谢观赏2019-6-29划分等价类等价类的划分有两种不同的情况：有效等价类：是指对于程序的规格说明来说，是合理的，有意义的输入数据构成的集合。无效等价类：是指对于程序的规格说明来说，是不合理的，无意义的输入数据构成的集合。在设计测试用例时，要同时考虑有效等价类和无效等价类的设计。51谢谢观赏2019-6-29划分等价类的原则如果输入条件规定了取值范围，或值的个数，则可以确立一个有效等价类和两个无效等价类。例如，在规格说明中，对输入条件有一句话： “……

项数可以从1到999……”

则有效等价类是“1≤项数≤999”;

两个无效等价类是“项数＜1”或“项数＞999”。在数轴上表示成:1999有效等价类无效等价类无效等价类Tobecontinue…52谢谢观赏2019-6-29划分等价类的原则如果输入条件规定了输入值的集合，或者是规定了“必须如何”的条件，这时可确立一个有效等价类和一个无效等价类。 例如，在编程语言中对变量标识符规定为“以字母打头的……串”。那么所有以字母打头的构成有效等价类，而不在此集合内（不以字母打头）的归于无效等价类。Tobecontinue…53谢谢观赏2019-6-29划分等价类的原则如果输入条件是一个布尔量，则可以确定一个有效等价类和一个无效等价类。如果规定了输入数据的一组值，而且程序要对每个输入值分别进行处理。这时可为每一个输入值确立一个有效等价类，此外针对这组值确立一个无效等价类，它是所有不允许的输入值的集合。 例如，在教师上岗方案中规定对教授、副教授、讲师和助教分别计算分数，做相应的处理。因此可以确定4个有效等价类为教授、副教授、讲师和助教，一个无效等价类，它是所有不符合以上身分的人员的输入值的集合。Tobecontinue…54谢谢观赏2019-6-29划分等价类的原则如果规定了输入数据必须遵守的规则，则可以确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。 例如，Pascal语言规定“一个语句必须以分号‘;’结束”。这时，可以确定一个有效等价类“以‘;’结束”，若干个无效等价类“以‘:’结束”、“以‘,’结束”、“以‘’结束”、“以LF结束”等。Tobecontinue…55谢谢观赏2019-6-29以上列出的只是测试时可能遇到的情况的很小一部分，实际情况千变万化，根本无法一一列出。如规定了输入数据为整数，可划分出正整数、零和负整数三个有效类，如果程序处理对象是表格，则应使用空表以及含一项或多项的表。要正确划分等价类，必须要注意经验的积累和正确分析被测试程序的功能。不需要设计测试数据来暴露编译程序肯定能发现的错误。划分等价类的原则56谢谢观赏2019-6-29用等价类划分法设计测试用例步骤形成等价类表，每一等价类规定一个唯一的编号；设计一测试用例，使其尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步骤，直到所有有效等价类均被测试用例所覆盖；设计一新测试用例，使其覆盖一个且只覆盖一个尚未被覆盖的无效等价类，重复这一步骤直到所有无效等价类均被覆盖。57谢谢观赏2019-6-29例:某报表处理系统要求用户输入处理报表的日期，日期限制在2003年1月至2008年12月，即系统只能对该段期间内的报表进行处理，如日期不在此范围内，则显示输入错误信息。系统日期规定由年、月的6位数字字符组成，前四位代表年，后两位代表月。如何用等价类划分法设计测试用例,来测试程序的日期检查功能？用等价类划分法设计测试用例步骤58谢谢观赏2019-6-29第一步：等价类划分输入条件有效等价类无效等价类报表日期的类型及长度6位数字字符(1)有非数字字符

(4)少于6个数字字符

(5)多于6个数字字符

(6)年份范围在2003～2008之间

(2)小于2003

(7)大于2008

(8)月份范围在1～12之间(3)小于1

(9)大于12

(10)“报表日期”输入条件的等价类表59谢谢观赏2019-6-29第二步：为有效等价类设计测试用例对表中编号为1,2,3的3个有效等价类用一个测试用例覆盖：测试数据期望结果覆盖范围200306输入有效等价类(1)(2)(3)(1)

6位数字字符(2)

年在2003～2008之间(3)

月在1～12之间60谢谢观赏2019-6-29第三步：为每一个无效等价类 至少设计一个测试用例测试数据期望结果覆盖范围003MAY输入无效等价类(4)20035输入无效等价类(5)2003005输入无效等价类(6)200105输入无效等价类(7)200905输入无效等价类(8)200300输入无效等价类(9)200313输入无效等价类(10)不能出现相同的测试用例本例的10个等价类至少需要8个测试用例61谢谢观赏2019-6-29边界值分析法边界值分析也是一种黑盒测试方法，是对等价类划分方法的补充。边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。人们从长期的测试工作经验得知，大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。被测试子域测试内点测试外点62谢谢观赏2019-6-29软件边界与悬崖很类似边界值分析法如果在悬崖峭壁边可以自信地安全行走，平地就不在话下。如果软件在能力达到极限时能够运行，那么在正常情况下就不会出什么问题。63谢谢观赏2019-6-29确定边界值的方式如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据。如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少一、比最大个数多一的数作为测试数据。如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例。分析规格说明，找出其他可能的边界条件。64谢谢观赏2019-6-29“报表日期”边界值分析法测试用例输入条件测试用例说明测试数据期望结果选取理由报表日期类型及长度1个数字字符5显示出错仅有1个合法字符6个数字字符200305输入有效类型及长度均有效5个数字字符20035显示出错比有效长度少17个数字字符2003005显示出错比有效长度多1有1个非数字字符2003.5显示出错只有1个非法字符全是非数字字符MAY---显示出错6个非法字符年份范围年份为2003年200305输入有效最小年份年份为2008年200805输入有效最大年份年份<2003年200205显示出错刚好小于最小年份年份>2008年200905显示出错刚好大于最大年份月份范围月份为1月200301输入有效最小月份月份为12月200312输入有效最大月份月份<1200300显示出错刚好小于最小月份月份>12200313显示出错刚好大于最大月份65谢谢观赏2019-6-29错误推测法基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例。经验表明，一段程序中已经发现的错误数往往和尚未发现的错误数成正比。因此进一步测试要着重测试发现错误较多的程序段。66谢谢观赏2019-6-29错误推测法测试用例设计发现程序经常出现的错误的方法：单元测试中发现的模块错误；产品的以前版本曾经发现的错误；输入数据为0或字符为空；当软件要求输入时(比如在文本框中)，不是没有输入正确的信息，而是根本没有输入任何内容，单单按了Enter键；这种情况在产品说明书中常常忽视，程序员也可能经常遗忘，但是在实际使用中却时有发生。程序员总会习惯性的认为用户要么输入信息，不管是看起来合法的或非法的信息，要不就会选择Cancel键放弃输入。67谢谢观赏2019-6-29白盒测试技术逻辑覆盖法法基本路径测试法白盒测试应该根据程序的控制结构设计测试用例,原则是:保证模块中每一独立的路径至少执行一次;保证所有判断的每一分枝至少执行一次；保证每一循环都在边界条件和一般条件下至少各执行一次;验证所有内部数据结构的有效性。68谢谢观赏2019-6-29逻辑覆盖逻辑覆盖是以程序内部的逻辑结构为基础的设计测试用例的技术。这一方法要求测试人员对程序的逻辑结构有清楚的了解，甚至要能掌握源程序的所有细节。由于覆盖测试的目标不同，逻辑覆盖又可分为：语句覆盖判定覆盖条件覆盖判定/条件覆盖条件组合覆盖路径覆盖69谢谢观赏2019-6-29语句覆盖语句覆盖就是设计若干个测试用例，运行被测程序，使得每一可执行语句至少执行一次。这种覆盖又称为点覆盖，它使得程序中每个可执行语句都得到执行，但它是最弱的逻辑覆盖准，效果有限，必须与其它方法交互使用。Tobecontinue…70谢谢观赏2019-6-29(A>1)

and

(B=0)(A=2)

or(X>1)X=X/AX=X+1TTFFbcea1sd234567PROCEDUREExample(A,B:real;X:real);BeginIF(A>1)AND(B=0)THENX:=X/A;IF(A=2)OR(X>1)THENX:=X+1END;I.A=2,B=0,X=4----sacbed语句覆盖所有的语句至少执行一次！是最弱的逻辑覆盖71谢谢观赏2019-6-29判定覆盖判定覆盖就是设计若干个测试用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次。判定覆盖又称为分支覆盖。判定覆盖只比语句覆盖稍强一些，但实际效果表明，只是判定覆盖，还不能保证一定能查出在判断的条件中存在的错误。因此，还需要更强的逻辑覆盖准则去检验判断内部条件。

Tobecontinue…72谢谢观赏2019-6-29(A>1)

and

(B=0)(A=2)

or

(X>1)X=X/AX=X+1TTFFbcea1sd234567每个语句至少执行一次！每个判定的每种可能都至少执行一次！即每个判定的真假分支都至少执行一次！I:A=3,B=0,X=3:sacbdII:A=2,B=1,X=1:sabed满足判定覆盖的测试用例一定满足语句覆盖：判定覆盖比语句覆盖强。但仍是弱的逻辑覆盖。73谢谢观赏2019-6-29条件覆盖条件覆盖就是设计若干个测试用例，运行被测程序，使得程序中每个判断的每个条件的可能取值至少执行一次。条件覆盖深入到判定中的每个条件，但可能不能满足判定覆盖的要求。Tobecontinue…74谢谢观赏2019-6-29每个语句至少执行一次，而且判定表达式中的每个条件都要取得各种可能的结果。第一判定表达式:设条件A>1取真记为T1

假T1

条件B=0取真记为T2

假T2第二判定表达式:设条件A=2取真记为T3

假T3

条件X>1取真记为T4

假T4条件覆盖要求这8种值都要取到(A>1)

and

(B=0)(A=2)

or

(X>1)X=X/AX=X+1TTFFbcea1sd23456775谢谢观赏2019-6-29(A>1)

and

(B=0)(A=2)

or

(X>1)X=X/AX=X+1TTFFbcea1sd234567(A>1)(A≤1)(B=0)(B≠0)(A=2)(A≠2)(X>1)(X≤1)Ⅱ:A=1,B=1,X=1:sabdⅠ:A=2,B=0,X=4:sacbed测试用例通过路径满足的条件ABX204sacbedT1,T2,T3,T4111sabdT1,T2,T3,T4满足判定覆盖76谢谢观赏2019-6-29(A>1)

and

(B=0)(A=2)

or

(X>1)X=X/AX=X+1TTFFbcea1sd234567(A>1)(A≤1)(B=0)(B≠0)(A=2)(A≠2)(X>1)(X≤1)Ⅳ:A=1,B=1,X=2:sabedⅢ:A=2,B=0,X=1:sacbed测试用例通过路径满足的条件ABX201sacbedT1,T2,T3,T4112sabedT1,T2,T3,T4不满足判定覆盖77谢谢观赏2019-6-29(A>1)(A≤1)(B=0)(B≠0)(A=2)(A≠2)(X>1)(X≤1)Ⅵ:A=2,B=1,X=1:sabed测试用例通过路径满足的条件ABX103sabedT1,T2,T3,T4211sabedT1,T2,T3,T4Ⅴ:A=1,B=0,X=3:sabed(A>1)

and

(B=0)(A=2)

or

(X>1)X=X/AX=X+1TTFFbcea1sd234567既不满足条件覆盖又不满足判定覆盖78谢谢观赏2019-6-29

条件覆盖不一定包含判定覆盖判定覆盖也不一定包含条件覆盖

条件覆盖通常比判定覆盖强，因为它使判定表达式中每个条件都取到了两个不同的结果，判定覆盖却关心整个判定表达式的值。但也可能有相反的情况：虽然每个条件都取到了不同值，但判定表达式却始终只取一个值。79谢谢观赏2019-6-29判定-条件覆盖既然判定条件不一定包含条件覆盖，条件覆盖也不一定包含判定覆盖，就自然会提出一种能同时满足两种覆盖标准的逻辑覆盖，这就是判定/条件覆盖。判定－条件覆盖就是设计足够的测试用例，使得判断中每个条件的所有可能取值至少执行一次，同时每个判断本身的所有可能判断结果至少执行一次。换言之，即是要求各个判断的所有可能的条件取值组合至少执行一次。Tobecontinue…80谢谢观赏2019-6-29判定-条件覆盖测试用例I,II既满足判定覆盖也满足条件覆盖的要求。严格来讲，合适的条件覆盖测试用例设计应该做到满足判定/条件覆盖的标准：判定/条件覆盖并不比条件覆盖更强。判定－条件覆盖有缺陷。表面上，它测试了所有条件的取值，但事实并非如此，往往某些条件掩盖了另一些条件，会遗漏某些条件取值错误的情况。为彻底地检查所有条件的取值，需要将判定语句中给出的复合条件表达式进行分解，形成由多个基本判定嵌套的流程图。这样就可以有效地检查所有的条件是否正确了。81谢谢观赏2019-6-29判定-条件覆盖复合判定的例子：Tobecontinue…(A>1)

and

(B=0)(A=2)

or

(X>1)X=X/AX=X+1TTFFbcea1sd23456782谢谢观赏2019-6-29A>1X=X/AX=X+1TTFFsdB=0TA=2X>1TFF判定-条件覆盖复合判定的例子：改为单个条件判定83谢谢观赏2019-6-29条件组合覆盖条件组合覆盖就是设计足够的测试用例，运行被测程序，使得每个判断的所有可能的条件取值组合至少执行一次。这是一种相当强的覆盖准则，可以有效地检查各种可能的条件取值的组合是否正确。它不但可覆盖所有条件的可能取值的组合，还可覆盖所有判断的可取分支，但可能有的路径会遗漏掉。测试还不完全。84谢谢观赏2019-6-29A＞1,B＝0A＞1,B≠0A≯1,B＝0A≯1,B≠0A＝2,X＞1A＝2,X≯1A≠2,X＞1A≠2,X≯1选取足够多的测试数据，使得每个判定表达式中条件的各种可能组合都至少出现一次。(A>1)

and

(B=0)(A=2)

or

(X>1)X=X/AX=X+1TTFFbcea1sd23456785谢谢观赏2019-6-29(A>1)

and

(B=0)(A=2)

or

(X>1)X=X/AX=X+1TTFFbcea1sd234567(A>1)(A≤1)(B=0)(B≠0)(A=2)(A≠2)(X>1)(X≤1)I.A=2,B=0,X=4II.A=2,B=1,X=1III.A=1,B=0,X=2IV.A=1,B=1,X=1I:sacbedII:sabedIII:sabedIV:sabd覆盖路径满足条件组合覆盖标准的测试数据，也一定满足判定覆盖、条件覆盖和判定/条件覆盖标准。86谢谢观赏2019-6-29测试用例通过路径满足的条件条件组合覆盖分支ABX204sacbedT1,T2,T3,T41,54563211sabedT1,T2,T3,T42,6263102sabedT1,T2,T3,T43,7263111sabdT1,T2,T3,T44,8234组测试数据可以使8种条件组合每种至少出现一次：显然，满足条件组合覆盖的测试用例，也一定满足判定覆盖、条件覆盖和判定/条件覆盖。所以，条件组合覆盖是前述几种覆盖中最强的。但满足条件组合覆盖的不一定能使程序中的每条路径都执行到，如sacbd。87谢谢观赏2019-6-29如果连通图G的子图G´是连通的，而且包含G的所有节点，则称G´是G的点覆盖。与语句覆盖标准相同。点覆盖88谢谢观赏2019-6-29如果连通图G的子图G´是连通的，而且包含G的所有边，则称G´是G的边覆盖。通常与判定覆盖标准相同。1234567Ⅰ:A=3,B=0,X=3(1-4-5-3);Ⅱ:A=2,B=1,X=1(1-2-6-7)Ⅲ:A=1,B=1,X=1(1-2-3);Ⅳ:A=2,B=0,X=4(1-4-5-6-7)或边覆盖89谢谢观赏2019-6-29路径覆盖路径测试就是设计足够的测试用例，覆盖程序中所有可能的路径。这是最强的覆盖准则。但在路径数目很大时，真正做到完全覆盖是很困难的，必须把覆盖路径数目压缩到一定限度。90谢谢观赏2019-6-29测试用例通过路径满足的条件ABX111sabdT1,T2,T3,T4112sabedT1,T2,T3,T4301sacbdT1,T2,T3,T4204sacbedT1,T2,T3,T4路径覆盖是相当强的逻辑覆盖，它保证程序中每条可能的路径都至少执行一次，因此更具代表性，暴露错误的能力也比较强。但为了做到路径覆盖，只需考虑每个判定式的取值，并没有检验表达式中条件的各种可能组合。如果将路径覆盖和条件组合覆盖结合起来，可以设计出检错能力更强的测试数据。路径覆盖91谢谢观赏2019-6-29通过分析由控制构造的环路的复杂性，导出基本路径集合，从而设计测试用例，保证这些路径至少通过一次。为了使用图论的知识和术语，引入流图(亦即程序图)的概念，流图即把流程图中结构化构件改用一般有向图的表示形式。基本路径测试法92谢谢观赏2019-6-29流图(flowgraph)在流图中用圆表示节点，一个圆代表一条或多条语句。程序流程图中的一个处理框序列和一个菱形判定框，可以映射成流图中的一个节点。流图中的箭头线称为边，它和程序流程图中的箭头线类似，代表控制流。在流图中一条边必须终止于一个节点，即使这个节点并不代表任何语句(实际上相当于一个空语句)。由边和节点围成的面积称为区域，当计算区域数时应该包括图外部未被围起来的那个区域。93谢谢观赏2019-6-29利用流图表示控制逻辑顺序结构if结构Case结构while结构until结构流图94谢谢观赏2019-6-29(A>1)

and

(B=0)(A=2)

or

(X>1)X=X/AX=X+1TTFFbcea1sd2345671234567流图95谢谢观赏2019-6-29导出程序流程图的拓扑结构-流图计算流图G的环路复杂度V(G)确定只包含独立路径的基本路径集设计测试用例流程图==>流图==>基本路径==>测试用例基本路径测试步骤96谢谢观赏2019-6-29Step1

根据程序的逻辑结构画出流程图voidFunc(intnPosX,intnPosY){

while(nPosX>0) {

intnSum=nPosX+nPosY;

if(nSum>1) { nPosX--;nPosY--; }

else

{

if(nSum<

-1)nPosX-=2;

elsenPosX-=4; }//endofif }//endofwhile}762318451191097谢谢观赏2019-6-29待测试程序1762,38910114,5节点边区域区域：由边和节点封闭起来的区域计算区域：不要忘记区域外的部分用流图表示的待测试程序Step2根据流程图画出流图762318451191098谢谢观赏2019-6-29Step3确定基本路径的集合流图的环形复杂度正好是基本路径的数目计算V(G)的不同方法(1)V(G)

=区域个数=4(2)V(G)

=边的条数-节点个数+2=11-9+2=4(3)V(G)

=判定节点个数+1=3+1=4确定只包含独立路径的基本路径集Path1：1-11Path2：1-2-3-4-5-10-1-11Path3：1-2-3-6-8-9-10-1-11Path4：1-2-3-6-7-9-10-1-11一条新路径必须包含一条新边99谢谢观赏2019-6-29独立路径：至少沿一条新的边移动的路径路径1：1-11路径2：1-2-3-4-5-10-1-11路径3：1-2-3-6-8-9-10-1-11路径4：1-2-3-6-7-9-10-1-111762,38910114,5对以上路径的遍历，就是至少一次地执行了程序中的所有语句。Step3确定基本路径的集合100谢谢观赏2019-6-29Step4对每条基本路径设计测试用例路径1–11nPosX取-1,nPosY取任意值路径1–2–3–4–5–10–1–11nPosX取1,nPosY取1路径1–2–3–6–8–9–10–1–11

nPosX取1,nPosY取-3路径1–2–3–6–7–9–10–1–11nPosX取1,nPosY取-1设计测试用例,保证基本路径集中每条路径的执行101谢谢观赏2019-6-29测试用例设计的步骤为测试需求确定测试用例为测试用例确定输入输出编写测试用例评审测试用例跟踪测试用例102谢谢观赏2019-6-29为测试需求确定测试用例测试需求：来源于需求规格说明书（用例、补充规约），设计规格。需要我们在测试计划中明确。测试需求编号：TR_XXXX_XX每一个测试需求至少确定两个测试用例：正面，负面103谢谢观赏2019-6-29为测试用例确定输入和输出输入是指在执行该测试用例时，由用户输入的与之交互的对象、字段和特定数据值（或生成的对象状态）。输出即预期结果，是指执行该测试用例完毕后得到的状态或数据。在确定输入和输出参数时，我们采用以下原则：在任何情况下都必须使用边界值分析方法。经验表明用这种方法设计出测试用例发现程序错误的能力最强。必要时用等价类划分方法补充一些测试用例。对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。如果没有达到要求的覆盖标准，应当再补充足够的测试用例。如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法。104谢谢观赏2019-6-29编写测试用例测试用例编号为

TC_测试需求标识。测试需求标识 测试计划中的测试需求标识。测试目标状态和测试数据状态 执行此用例前系统应具备的状态。输入(操作)

为各输入数据（操作）的组合。输出(预期结果)

测试用例执行后得到的状态或数据。105谢谢观赏2019-6-29评审测试用例测试用例检查表是否每一个需求都有其对应的测试用例来验证？是否每一个设计元素都有其对应的测试用例来验证？或事件顺序，它能够产生唯一的测试目标行为？是否每个测试用例都阐述了预期结果？是否每个测试用例（或每组相关的测试用例）都确定了初始的测试目标状态和测试数据状态？测试用例是否包含了所有的单一边界？测试用例是否包含了所有的业务数据流？是否所有的测试用例名称，ID都与测试工件命名约定一致？参加人员项目经理、系统分析员、测试设计员、测试员106谢谢观赏2019-6-29跟踪测试用例需求管理 需求-〉测试用例测试用例是否覆盖了需求测试用例执行率、通过率107谢谢观赏2019-6-29软件测试过程TestPlaningTestDesignTestImplementExec.Exec....Exec.BuildBuildRevisionEvaluationDefectTracking...Tobecontinue…108谢谢观赏2019-6-29软件测试过程制定测试计划定义测试项目的阶段，以便于对项目进行适当的评估与控制，包括测试需求，测试策略，测试资源和测试进度。测试设计设计测试用例及测试过程的阶段，它是验证测试需求被测试到的最有效的方法。测试实施对测试设计阶段已被定义的测试进行创建或修正的阶段，如脚本、驱动、桩的实施。Tobecontinue…109谢谢观赏2019-6-29软件测试过程测试执行对被测软件进行一系列的测试并记录日志结果的阶段。测试评估分析测试结果并判断测试的标准是否被满足的阶段。缺陷跟踪记录测试发现的问题，并且跟踪其修改的阶段。110谢谢观赏2019-6-29软件测试过程涉及的角色和职责测试设计员制定和维护测试计划。设计测试用例及测试过程。评估测试，生成测试分析报告。测试人员执行集成测试和系统测试。记录测试结果。设计人员设计测试需要的驱动程序和稳定桩。编码人员编写测试驱动程序和稳定桩。执行单元测试。111谢谢观赏2019-6-29软件测试的层次单元测试集成测试确认测试系统测试112谢谢观赏2019-6-29软件测试的层次与软件开发的关系需求分析设计编码单元测试集成测试确认测试系统测试113谢谢观赏2019-6-29单元测试单元测试针对程序模块，进行正确性检验的测试。其目的在于发现各模块内部可能存在的各种差错。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。114谢谢观赏2019-6-29模块错误处理模块接口局部数据结构

重要的执行路径边界条件主要对模块的五个基本特性进行评价在单元测试时，测试者需要依据详细设计说明书和源程序清单，了解该模块的I/O条件和模块的逻辑结构，主要采用白盒测试的测试用例，辅之以黑盒测试的测试用例，使之对任何合理的输入和不合理的输入，都能鉴别和响应。单元测试的内容115谢谢观赏2019-6-29模块接口测试对被测模块的数据流进行测试。Tobecontinue…实际参数与形式参数的个数是否相同；实际参数与形式参数的属性是否匹配；实际参数与形式参数的量纲是否一致；调用预定义函数时所用参数的个数、属性和次序是否正确；是否存在与当前入口点无关的参数引用；是否修改了只读型参数；对全程变量的定义各模块是否一致；是否把某些约束作为参数传递。116谢谢观赏2019-6-29如果模块内包括外部I/O，还应该考虑下列因素:文件属性是否正确；OPEN与CLOSE语句是否正确；缓冲区容量与记录长度是否匹配；在进行读写操作之前是否打开了文件；在结束文件处理时是否关闭了文件；正文书写／输入错误；I/O错误是否检查并做了处理。模块接口测试117谢谢观赏2019-6-29局部数据结构测试局部数据结构往往是错误的根源，应仔细设计测试用例，力求发现下面几类错误：不合适或不相容的类型说明；变量无初值；变量初始化或缺省值有错；不正确的变量名(拚错或不正确地截断)；出现上溢、下溢和地址异常。118谢谢观赏2019-6-29路径测试选择适当的测试用例，对模块中重要的执行路径进行测试。应当设计测试用例查找由于错误的计算、不正确的比较或不正常的控制流而导致的错误。对基本执行路径和循环进行测试可以发现大量的路径错误。119谢谢观赏2019-6-29错误处理测试检查模块的错误处理功能是否包含有错误或缺陷。出错的描述是否难以理解出错的描述是否能够对错误定位显示的错误与实际的错误是否相符对错误条件的处理正确与否在对错误进行处理之前，错误条件是否已经引起系统的干预等120谢谢观赏2019-6-29边界测试注意数据流、控制流中刚好等于、大于或小于确定的比较值时出错的可能性。对这些地方要仔细地选择测试用例，认真加以测试。如果对模块运行时间有要求的话，还要专门进行关键路径测试，以确定最坏情况下和平均意义下影响模块运行时间的因素。这类信息对进行性能评价是十分有用的。121谢谢观赏2019-6-29单元测试的步骤通常单元测试在编码阶段进行。在源程序代码编制完成，经过评审和验证，确认没有语法错误之后，就开始进行单元测试的测试用例设计。利用设计文档，设计可以验证程序功能、找出程序错误的多个测试用例。对于每一组输入，应有预期的正确结果。Tobecontinue…122谢谢观赏2019-6-29单元测试的方法模块并不是一个独立的程序，在考虑测试模块时，同时要考虑它和外界的联系，用一些辅助模块去模拟与被测模块相联系的其它模块。这些辅助模块分为两种：驱动模块(Driver)：相当于被测模块的主程序。它接收测试数据，把这些数据传送给被测模块，最后输出实测结果。桩模块(Stub)：用以代替被测模块调用的子模块。桩模块可以做少量的数据操作，不需要把子模块所有功能都带进来，但不允许什么事情也不做。123谢谢观赏2019-6-29单元测试的方法被测模块，与它相关的驱动模块及桩模块共同构成了一个“测试环境”，如下图：测试用例驱动模块测试结果被测模块桩模块桩模块桩模块124谢谢观赏2019-6-29驱动模块和桩模块是测试使用的软件，而不是软件产品的组成部分，它需要一定的开发费用。若驱动模块和桩模块比较简单，实际开销相对低些。仅用简单的驱动模块和桩模块不能完成某些模块的测试任务，这些模块的单元测试只能采用下面讨论的综合测试方法。提高模块的内聚度可简化单元测试，如果每个模块只完成一个功能，所需测试用例数目将显著减少，模块中的错误也更容易发现。单元测试方法125谢谢观赏2019-6-29集成测试在单元测试的基础上，需要将所有模块按照设计要求组装成为系统。这时需要考虑：在把各个模块连接起来的时侯，穿越模块接口的数据是否会丢失；一个模块的功能是否会对另一个模块的功能产生不利的影响；各个子功能组合起来，能否达到预期要求的父功能；全局数据结构是否有问题；单个模块的误差累积起来，是否会放大，从而达到不能接受的程度。单个模块的错误是否会导致数据库错误。Tobecontinue…126谢谢观赏2019-6-29集成测试选择什么方式把模块组装起来形成一个可运行的系统，直接影响到模块测试用例的形式、所用测试工具的类型、模块编号的次序和测试的次序、以及生成测试用例的费用和调试的费用。通常，把模块组装成为系统的方式有两种方式：一次性集成方式增殖式集成方式自顶向下增值方式自底向上增值方式混合增值方式Tobecontinue…127谢谢观赏2019-6-29一次性集成方式它是一种非增殖式集成方式。也叫做整体拼装。使用这种方式，首先对每个模块分别进行模块测试，然后再把所有模块组装在一起进行测试，最终得到要求的软件系统。缺点：错误难以诊断定位。Tobecontinue…ABCDEF系统结构图DCEFAs1s2d1d2d3d4d5s3s4s5B单元测试ABCDEF整体组装128谢谢观赏2019-6-29增殖式集成方式增殖式集成方式又称渐增式集成方式。首先对一个个模块进行模块测试，然后将这些模块逐步组装成较大的系统，在组装的过程中边连接边测试，以发现连接过程中产生的问题。最后组装成为要求的软件系统。自顶向下的增殖方式自底向上的增殖方式混合增殖方式演变的自顶向下增值方式自顶向下-自底向上增值方式回归测试129谢谢观赏2019-6-29自顶向下的增殖方式将模块按系统程序结构，沿控制层次自顶向下进行集成。由于这种增殖方式在测试过程中较早地验证了主要的控制和判断点。在一个功能划分合理的程序结构中，判断常出现在较高的层次，较早就能遇到。如果主要控制有问题，尽早发现它能够减少以后的返工。可以采取深度优先或广度优先策略；深度优先策略首先把主控制路径上的模块集成在一起，至于选择哪一条路径作为主控制路径多少带点随意性，一般根据问题的特性确定。Tobecontinue…130谢谢观赏2019-6-29步骤以主控模块作为测试驱动模块，把对主控模块进行单元测试时引入的所有桩模块用实际模块替代;依据所选的集成策略(深度优先或广度优先),每次只替代一个桩模块;每集成一个模块立即测试一遍;只有每组测试完成后，才着手替换下一个桩模块;为避免引入新错误，须不断进行回归测试(即全部或部分地重复已做过的测试)。从第二步开始，循环执行上述步骤,直至整个程序结构构造完毕。131谢谢观赏2019-6-29模块测试结合顺序ADBECF深度优先:A、B、E、C、D、F广度优先:A、B、C、D、E、F举例：132谢谢观赏2019-6-29As1s2s3s2s3s4s2s3ECs3Ds5F测试A加入B加入E加入C加入D加入F深度优先:ABEABABABCEABCDE133谢谢观赏2019-6-29自底向上的增殖方式这种组装的方式是从程序模块结构的最底层的模块开始组装和测试。因为模块是自底向上进行组装，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）已经组装并测试完成，所以不再需要桩模块。在模块的测试过程中需要从子模块得到的信息可以直接运行子模块得到。Tobecontinue…134谢谢观赏2019-6-29自底向上增值方式ABCDEFd1Ed2Cd3Fd4BEd5DF135谢谢观赏2019-6-29自顶向下增殖方式的缺点是需要建立桩模块。要使桩模块能够模拟实际子模块的功能将是十分困难的。同时涉及复杂算法和真正输入／输出的模块一般在底层，它们是最容易出问题的模块，到组装和测试的后期才遇到这些模块，一旦发现问题，导致过多的回归测试。而自顶向下增殖方式的优点是能够较早地发现在主要控制方面的问题。自底向上增殖方式的缺点是“程序一直未能做为一个实体存在，直到最后一个模块加上去后才形成一个实体”。就是说，在自底向上组装和测试的过程中，对主要的控制直到最后才接触到。而自底向上增殖方式的优点是不需要桩模块，而建立驱动模块一般比建立桩模块容易，同时由于涉及到复杂算法和真正输入／输出的模块最先得到组装和测试，可以把最容易出问题的部分在早期解决。此外自底向上增殖的方式可以实施多个模块的并行测试。两种增殖方式优缺点比较136谢谢观赏2019-6-29混合增值方式有鉴于此，通常是把以上两种方式结合起来进行组装和测试。演变的自顶向下的增殖测试：它的基本思想是强化对输入／输出模块和引入新算法模块的测试，并自底向上组装成为功能相当完整且相对独立的子系统，然后由主模块开始自