第七章-软件测试类型

第七章软件测试类型IT@ANY本课程的主要内容软件测试的分类单元测试集成测试确认测试系统测试验收测试本章目标掌握软件测试的类型（重点）掌握单元、集成、确认、系统和验收测试的过程及方法（重点）了解Junit，能够使用Junit进行简单的单元测试（重点）第一部分软件测试的分类单元测试集成测试确认测试系统测试验收测试软件测试的理论框架软件测试的分类按开发阶段划分：单元测试、集成测试、系统测试、确认测试、验收测试、回归测试回归测试：就是漏洞修复完成后再对软件进行测试，以确保软件没有产生“回归”或因修复而变得更糟，这种测试一般要重新运行最初发现问题的原始测试程序。

回归测试有两个焦点：

1.是否修复了之前存在的问题

2.是否产生了新问题软件测试的分类按测试技术划分：白盒测试、灰盒测试、黑盒测试，也可划分为静态测试和动态测试。静态测试：不运行程序，对程序和文档进行分析与检查，如走查、符号执行、需求确认。动态测试：通过人工或使用工具运行程序进行检查、分析程序的执行状态和程序的外部表现白盒测试、灰盒测试、黑盒测试，在实现方法上既包含了动态测试又包含了静态测试软件测试的分类白盒测试：通过对程序内部结构的分析、检测来寻找问题。黑盒测试：通过软件的外部表现来发现其缺陷和错误。灰盒测试：介于白盒和黑盒之间的测试软件测试的分类按测试类型划分功能测试：对软件功能进行的测试，主要检查软件功能是否实现了软件功能说明书（软件需求）上的功能要求。界面测试：对软件的用户界面进行的测试，主要检查用户界面的美观度、统一性、易用性等方面的内容。数据处理测试：对软件数据接口进行的测试，主要检查软件数据处理中输入、处理、输出数据过程。软件测试的分类按测试类型划分流程测试：按操作流程进行的测试，主要有业务流程、数据流程、逻辑流程，检查软件在按流程操作时是否能够正确处理安全测试：对软件安全性方面的测试，主要检测软件中加密、解密、数据备份、恢复、病毒检测,网络架构问题安装测试：在不同PC条件、操作系统、模拟客户机,网络环境进行安装测试软件测试的分类按测试类型划分易用性测试：指软件产品被理解、学习、使用和吸引用户的能力。比如安装卸载、功能方面、界面方面、辅助系统兼容性测试：验证软件与其所依赖的环境的依赖程度，包括对硬件、软件的依赖程度。比如，与操作系统的兼容、与数据库的兼容、与浏览器的兼容、与中间件的兼容、与其他软件的兼容等等文档测试：读者群、术语、正确性、完整性、一致性、易用性、图表与界面截图、样例和示例、语言、印刷与包装软件测试的分类按测试类型划分自动化测试借助自动化的工具和手段，来代替人工的方式完成测试。在回归测试和大量重复性劳动测试场景下使用最有效。性能测试对软件整体性能的测试，对适应性、健壮性、可恢复性、灾难恢复能力软件测试的分类按组织结构划分开发方测试（α测试）用户测试（β测试）第三方测试软件测试的分类软件测试过程中的文档用户文档用户手册操作手册维护修改建议开发文档软件需求说明书数据库设计说明书概要设计说明书详细设计说明书可行性研究报告管理文档项目开发计划测试计划测试报告开发进度月报开发总结报告第二部分软件测试的分类标准单元测试集成测试确认测试系统测试验收测试单元测试单元测试什么是单元测试 单元测试又称为模块测试，是针对软件设计的最小单位---程序模块，进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。单元测试需要从程序的内部结构出发设计测试用例。多模块可平行地独立进行单元测试。单元测试时机源程序编制完成并通过复审和编译检查完成，确定没有语法错误之后。单元测试的内容测试依据：详细设计说明书和源程序清单，了解程序的I/O条件和模块的逻辑结构测试内容：所有的局部和全局的数据结构、外部接口和程序代码的关键部分都要进行严格的桌面检查和严格的代码审查。单元测试单元测试的工作模块接口：1）主要关注实参和形参传递的个数、属性、顺序是否匹配2）全局变量的定义在各模块中是否一致局部数据：1）不正确或不一致的数据类型说明2）使用尚未赋值或初始化的变量3）错误的初始值或缺省值4）变量名称拼写错误5）不一致的数据类型单元测试单元测试的工作路径测试：选择适当的用例，对重要的执行路径进行测试，查找错误的计算、不正确的比较或不正常的控制流常见的运算错误：1）运算的优先级不正确或理解错误2）运算对象在类型上不兼容3）运算精度不够常见的比较和控制流错误：1）不同的数据类型相互比较2）不正确的多循环一次或少循环一次单元测试过程驱动模块（driver）：相当于所测模块的主程序，用于接收测试数据，把这些数据传给所测模块，最后再输出实测结果。桩模块（stub）：也叫做存根模块。用以代替所测模块调用的子模块。桩模块可以做少量的数据操作，不需要把子模块所有功能都带进来，但不允许什么事情也不做。单元测试内容检查点分类测试内容模块测试项目模块接口局部数据结构重要的执行路径错误处理路径影响上述各方面特性的边界条件输入/输出的测试要点参数数量和由调用模块传递过来的变量的数量是否相等？参数的属性和变量的属性是否匹配？传递给被调用模块的变量的数量是否等于该模块的参数的数量？传递给被调用模块的变量属性和参数的属性是否一致？传递给内部函数的变量属性、数量和次序是否正确？全局变量的定义和用法在各个模块中是否一致格式说明书与输入/输出语句是否一致？缓冲区大小与记录长度是否匹配？文件结束条件处理了吗？输入/输出错误检查并处理了吗？输出信息中由文字书写错误吗？单元测试内容检查点分类测试内容局部数据结构的测试要点

错误的或不相容的说明使用尚未赋值或尚未初始化的变量错误的初始值或不正确的缺省值错误的变量名字（拼写错误或被截断了）数据类型不相容上溢、下溢或地址异常计算中的常见错误

计算次序不对或误解了运算符的优先次序混合运算（运算对象的类型彼此不相容）变量初始值不正确精度不够表达式的符号表示错误

单元测试内容检查点分类测试内容测试方案中的错误比较数据类型不同的量逻辑运算符不正确或优先次序的错误当由于精度问题两个量不会相等时，程序中却期待着相等条件的出现“差1”错（即，多循环一次或少循环一次）错误的或不存在的循环终止条件当遇到发散的迭代时不能终止循环错误地修改循环变量错误处理通路时常见错误对错误的描述是难于理解的记下的错误与实际遇到的错误不同在错误进行处理之前，错误条件已经引起系统干预。对错误的处理不正确描述错误的信息不足以帮助确定造成错误的位置单元测试工具基于代码层面的功能自动化测试工具主要是一些单元测试工具，例如JUnit、NUnit、MSTest等，这些工具直接访问被测试的应用程序的代码，对其中的类和函数进行调用，输入各种测试数据，检查函数的返回值，通过比较返回值与期待的值是否一致来判断测试是否通过。Junit介绍Junit是一个开发源代码的Java测试框架，用于编写和运行可重复的测试。它是用于单元测试框架体系xUnit的一个实例（用于java语言）框架是一个应用程序的半成品。框架提供了可在应用程序之间共享的可复用的公共结构。开发者把框架融入他们自己的应用程序，并加以扩展，以满足他们特定的需要。框架和工具包不同之处在于，框架提供了一致的结构，而不仅仅是一组工具类。Junit背后的测试模型（称作xUnit）正成为任何语言的标准框架，ASP、C++（CppUnit）、C#、Eiffel、Delphi（Dunit）、Perl、PHP（PhpUnit）、.Net（Nunit）、Python、REBOL、Smalltalk和VisualBasic都已经有了xUnit框架。Juint的安装Junit以jar文件（junit.jar）的形式分发，使用时只需将jar文件添加到项目的编译和执行的Classpath路径中即可。Junit的类结构Junit中的类结构TestCase+TestSuite+BaseTestRunner=TestResultTestCase类（测试用例）扩展了Junit的TestCase类，以TestXXX方法的形式包含一个或多个测试，一个testcase把具有公共行为的测试归入一组TestSuite类（测试集合）一个test

suite是把多个相关测试归入一组的便捷方式TestRunner类（测试运行器）执行TestSuite程序Junit的类结构7个Junit类及接口（接口用斜体表示）类/接口功能说明Assert当条件成立时，assert方法保持沉默，但若条件不成立就抛出异常TestResultTestResult包含了测试中发生的所有错误或失败Test可以运行Test并把结果传递给TestResult，包run()和CountTestCases()两个方法TestListener测试中若产生事件（开始、结束、错误、失败）会通知TestListenerTestCaseTestCase定义了可用于运行多项测试的环境（或者说固定设备）TestSuiteTestSuite运行一组TestCase（它们可能包含其他的TestSuite）BaseTestRunnerTestRunner是用来启动测试的用户界面，BaseTestRunner是所有TestRunner的超类Junit的类结构Junit的TestCase类TestCaseTestCase包含两个组件fixture和单元测试Fixture运行一个或多个测试所需公共资源或数据集合。TestCase通过setUp和tearDown方法来自动创建和销毁fixtureTestCase的生命周期TestCase会在每个测试之前调用setUp，每个测试完成后调用tearDownJUNIT实例使用Junit进行简单的单元测试第三部分软件测试的分类标准单元测试集成测试确认测试系统测试验收测试集成测试集成测试的定义什么是集成测试集成测试也叫组装测试或联合测试，是单元测试的逻辑扩展。集成是指多个单元的聚合，许多单元组合成模块，而这些模块又聚合成程序的更大部分，如分系统或系统。集成测试的标准集成测试应由专门的测试小组来进行，由有经验的系统设计人员和程序员组成，整个测试活动要在评审人员出席的情况下进行。在完成预定的组装测试工作之后，测试小组应负责对测试结果进行整理、分析，形成测试报告。测试报告中要记录实际的测试结果、在测试中发现的问题、解决这些问题的方法以及解决之后再次测试的结果。此外还应提出目前不能解决、还需要管理人员和开发人员注意的一些问题，提供测试评审和最终决策，以提出处理意见。集成测试完成的标准:成功地执行了测试计划中规定的所有集成测试；修正了所发现的错误；测试结果通过了专门小组的评审。集成测试的目的为什么要做集成测试？

每个模块都能单独工作，但这些模块集成在一起之后却不能正常工作。主要原因是，模块相互调用时接口会引入许多新问题。

集成测试有那些常见问题？

1、数据经过接口可能丢失；

2、一个模块对另一模块可能造成不应有的影响；

3、几个子功能组合起来不能实现主功能；

4、误差不断积累达到不可接受的程度；

5、全局数据结构出现错误。集成测试方法集成测试主要有两种方法：非渐增式测试方法 先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序。渐增式测试方法 把下一个要测试的模块同已经测试好的模块结合起来进行测试，测试完以后再把下一个应该测试的模块结合进来测试。集成测试方法非渐增式与渐增式两种测试方法的比较：非渐增式测试方法需要编写的测试用例较多，工作量较大；渐增式测试方法开销小。渐增式测试方法发现模块间接口错误早；而非渐增式测试方法晚。非渐增式测试方法发现错误，较难诊断；而使用渐增式测试方法，如果发生错误则往往和最近加进来的那个模块有关。渐增式测试方法测试更彻底渐增式测试方法需要较多的机器时间使用非渐增式测试方法，可以并行测试。集成测试方法渐增式测试：自顶向下和自底向上两种方法。自顶向下集成从主控模块（“主程序”）开始，沿着软件的控制层次向下移动，从而逐渐把各个模块结合起来。在组装过程中，可以使用深度优先的策略，或宽度优先的策略。

集成测试方法自顶向下集成实施步骤对主控模块进行测试，测试时用存根程序代替所有直接附属于主控模块的模块根据选定的结合策略（深度优先或宽度优先），每次用一个实际模块代替一个存根程序（新结合进来的模块往往又需要新的存根程序）,在结合下一个模块同时进行测试为了保证加入模块没有引进新的错误，可能需要进行回归测试（即：全部或部分地重复以前做过的测试）从第2步开始不断地重复进行上述过程，直至完成集成测试方法渐增式测试：自顶向下和自底向上两种方法自底向上集成从“原子”模块（即软件结构最低层的模块）开始组装测试，因测试到较高层模块时，所需的下层模块功能均已具备。集成测试方法自底向上集成步骤把低层模块组织成实现某个子功能的模块（cluster）;测试驱动模块控制测试数据的输入和测试结果的输出；对每个模块群进行测试；删除测试使用的驱动模块，用较高层模块把模块群组织成为完成更大功能的新模块群。从第一步开始循环执行上述步骤，直至整个程序构造完毕集成测试方法两种集成策略的比较“自顶向下”法的主要优点：

能够较早的发现主要控制方面的问题“自顶向下”法的主要缺点：(1)需要建立桩模块模拟实际模块的子功能十分困难，增加了桩模块的负责度，导致一些附加的测试。(2)涉及算法和真正输入输出的模块通常在底层，需要在组装后期才被发现，一旦被发现就会导致过多的回归测试。“自底向上”法的主要优点：（1）不需要建立桩模块，建立驱动模块比较容易（2）能较早的测试底层的复杂算法和真正的输入输出模块，容易较早的发现并解决问题（3）能够多个组装模块并行测试，提高测试效率“自底向上”法的主要缺点：

程序一直未能作为一个实体存在，直到最后一个模块加上去才形成一个实体第四部分软件测试的分类标准单元测试集成测试确认测试系统测试验收测试确认测试确认测试确认测试的任务是验证软件的功能和性能及其他特性是否与用户的要求一致。对软件的功能和性能要求在软件需求规格说明书中明确规定。确认测试一般包括有效性测试和配置复审。确认测试一般由独立的第三方测试机构进行确认测试有效性测试在模拟环境下，运用黑盒测试的方法，验证所测软件是否满足需求规格说明书中列出的需求。因此要求制定测试计划，设计测试步骤和用例。通过执行这些预期的内容达到如下目标：1、确定软件的特性是否与需求相符2、确保所有的软件功能都能得到满足3、确保所有的软件性能需求都能够达到4、确保所有的文档都是正确且便于使用的5、对其他软件需求，比如可移植性、可靠性、易用性、兼容性、可维护性等，也要进行测试，确认是否满足确认测试全部软件测试完成后，测试结果可以分为两类1、测试结果与预期结果相符。说明软件的这部分功能和性能与需求规格说明书相符，从而接受了这部分程序。2、测试结果与预期结果不符。说明软件的这部分功能和性能与需求规格说明书不一致，因此要为这部分内容提交一份问题报告。确认测试配置复审软件配置复审的目的是保证软件配置的所有成分都齐全，各方面的质量都符合要求，具有维护阶段所必须的细节，而且已经编排好分类的目录。注意事项在确认测试过程中还应该严格遵守用户手册和操作手册中规定的使用步骤，一边检查文档资料的完整性和正确性第五部分软件测试的分类标准单元测试集成测试确认测试系统测试验收测试系统测试系统测试对象系统测试是将通过集成测试的软件，作为整个基于计算机系统的一个元素，与计算机的硬件、外设、某些支持软件及其借口、数据和人员等其他系统元素结合在一起，在实际或模拟运行的环境下，对计算机系统进行的一系列测试。因此，必须将系统中的软件与各种依赖的资源结合起来，在系统实际运行环境下来进行测试系统测试的目的系统测试的目的是通过与系统的需求定义相比较，发现所开发的系统与用户需求不符或矛盾的地方，从而提出更加完善的方案。系统测试系统测试三步曲模块测试，测试每个模块的程序是否有错误组装测试，测试模块之间的接口是否正确确认测试，测试整个软件系统是否满足用户功能和性能的要求。单元、集成、系统测试类型之间的比较测试类型测试对象测试目的测试依据测试方法单元测试模块内部的程序错误消除局部模块的逻辑和功能上的错误和缺陷模块详细设计大量采用白盒测试方法集成测试模块间的组装和调用关系找出与软件设计相关的程序结构，模块调用关系，模块间接口方面的问题概要设计灰盒测试系统测试整个系统对整个系统进行一系列整体有效的测试需求规格说明书黑盒测试第六部分软件测试的分类标准单元测试集成测试确认测试系统测试验收测试验收测试验收测试验收测试：验收测试按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审，决定是否接收或拒收系统。它是系统开发生命周期方法论的一个阶段，一项确定产品是否能够满足合同或用户所规定需求的测试。这是管理性和防御性控制。验收测试是以用户为主的测试。软件开发人员和质量保证人员也应该参加。由用户参加设计测试用例，使用用户界面输入测试数据，分析测试结果。一般使用生产中的实际数据进行测试。验收测试一般在系统测试完成后、项目最终交付前进行。验收测试验收测试的测试计划、测试方案与测试案例一般由开发方制定，由用户方与监理方联合进行评审。验收小组由开发方、用户方、监理方代表、主管单位领导及行业专家构成。与系统测试和确认测试不同的是，验收测试往往不是对系统的全面覆盖测试，而是针对用户的核心业务流程进行的测试；同时，测试的执行人员也不是开发方的测试组成员，而是由用户方的使用人员完成。验收测试验收测试的任务：功能和性能是否符合用户需求（需求规格说明书）验收测试的目的：是向未来的用户表明系统能够像预定要求工作。验收测试的内容安装（升级）功能测试（正例、重要算