集成测试及系统测试.ppt

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,SJTU School Of Software,*,软件学院,Chapter 8,集成测试与系统测试,8.1,测试层次,8.2,集成测试,8.3,系统测试,8.4,验收测试,8.1,测试层次,8.1.1,传统的观点,图,8-1,瀑布式生命周期,从传统瀑布模型的观点,:,单元测试,:,面向详细设计,完成对软件独立模块的测试。,集成测试：面向概要设计，完成软件模块之间的组合测试。,系统测试：面向需求分析，完成系统的功能测试。,但在实际软件开发中，更多采用的是瀑布模型的派生模型（,为什么,？）。,增量模型：是将一个软件产品分成若干次产品进行提交，每一次新的软件产品的提交，都是在上次软件产品的基础上，增加新的软件功能，直到全部满足客户的需求为止。,快速原型法：快速原型是在需求分析之前，首先提供给客户或用户一个最终产品的原型（部分主要功能的软件）,螺旋模型：它与瀑布模型和快速原型模型十分相似。但重要的是，它在每个阶段都增加了风险分析和验证这两个重要的步骤。,这三种派生模型的好处，是增加了迭代开发的方法，而不是将成功的风险全部放在了最后阶段！,在这样的开发模型中，,回归测试,就成为一种重要的测试方法。,回归测试（,regression test,）：,对已经完成测试的软件进行修改和增加之后，重新测试软件。,回归测试我们在后续章节进行专门的介绍，这里不做特别说明。,8.1.2,将集成测试与系统测试分开,从前面的介绍,我们知道集成测试针对的是模块之间的关系,;,而系统测试针对的是整个系统的功能。,集成测试,需要了解程序的结构，是一种结构化的测试方法，有路径覆盖的含义。,系统测试,不需要了解程序的结构，是一种黑盒的测试方法，是功能覆盖的意义。,集成测试,是由软件开发人员完成的；而,系统测试,往往是需要用户的参与的。,8.1.3,事例,SATM,请阅读,P175P184,(10,分钟阅读,),:,实体,-,关系模型,有限状态机,程序伪代码,问题,?,P179,图,12-11?P180,图,12-12?,P182183,伪代码,?8.2,集成测试,1,）,自顶向下集成,从主程序,(,顶层,),开始,所有下层程序都以“桩程序,”,出现。完成顶层测试后，以真实程序代替“桩程序”，向下进行下一层测试。,“桩程序”：,模拟被调用程序的代码。一般以表格形式存在。,2,）,自底向上集成,从程序的最下层节点（叶子）开始，通过编写“驱动器”完成测试，然后以真实程序代替“驱动器”，向上进行上一层测试。,“驱动器”：,模拟对测试节点的调用驱动。,8.2.1,集成测试的方法,3,）,三明治集成,是自顶向下和自底向上测试的组合，即可以同时从顶和底向中间层集成，可以减少桩程序和驱动的数量。,4,）,大爆炸测试,不分层次，将所有单元放在一起编译并进行一次性测试。,对于,SATM,系统（,P190,图,13-1,），我们知道需要开发（节点,-1,）个桩程序：,32,个；需要开发（节点,-,叶子）个驱动器：,10,个。,8.2.2,基于调用图的集成,换一个角度，从模块之间调用关系的角度，我们可以得到,SATM,的调用图。,成对集成,为免除桩程序和驱动器的开发,可采用调用对的测试方法。,SATM,的成对测试集，就是调用图中边的数量，共,40,个。,相邻集成,为减少测试的数量，以相邻节点为集合，进行测试。,相邻节点：包括所有直接前驱和所有直接后继节点。,对于,SATM,，显然就是除去叶子节点的所有节点的相邻集合，共,11,个。,8.2.3基于路径的集成,在面向结构的测试中,我们经常采用路径覆盖的方法,在集成测试中,我们也有类似的概念。,概念,定义：,程序中的,源节点,是程序开始或重新开始处的语句片段。,汇节点,是程序执行结束处的语句片断。,模块,执行路径,是以,源节点,开始，以,汇节点,结束的一系列语句，中间没有插入,汇节点,。,消息,是一种程序设计语言机制，通过它，一个单元将控制转移给另一个单元。,MM-,路径,是穿插出现模块执行路径和消息的序列。,下图就是在模块,A,、,B,、,C,之间控制转移的,MM-,路径,源节点：汇节点：,上图共有,7,条模块执行路径：,MEP,（,A,，,1,）,=,MEP,（,A,，,2,）,MEP,（,A,，,3,）,=,MEP,（,B,，,1,）,=,MEP,（,B,，,2,）,=,MEP,（,C,，,1,）,=,MEP,（,C,，,2,）,=,定义,:,给定一组单元,其,MM-,路径,是一种有向图,其中的节点表示,模块执行路径,边表示,消息,和单元之间的返回。,那么，上面的,MM-,路径就表示为：,实线箭头表示消息，返回由虚线箭头表示。,DD-,路径：模块内的程序执行路径；,MM-,路径：模块间的模块执行路径序列。,请同学自己阅读,SATM,的例子（,P200P202,伪代码,5,分钟）,从,P202,中间段起进行说明,.,其中，,UML,序列图是,MM-,路径图的表示方式，因此，,UML,序列图可以作为集成测试的路径覆盖标准。,MM-,路径复杂度,圈复杂度的计算：,V,（,G,）,=e-n+2,其中，,e,为边数，,n,为节点数。,大家很容易得到,P204,页对图,13-12,的计算结果。,双向箭头表示,2,条边。,Next Date,的例子（,10,分钟阅读伪代码）,问题？,程序流图：,13-1313-15,13-15,：功能分解图,13-16,：调用图,基于分解的集成：,基于调用图的集成：,基于,MM-,路径的集成：,思考问题：,除了,UML,的序列图可以作为软件模块间测试的依据；,UML,还有什么模型图可以作为测试的依据？,软件测试用例的自动生成都需要哪些条件？请分别针对单元测试和集成测试进行分析。,8.3,系统测试,8.3.1,线索,(thread),线索有不同的层次,单元级线索被理解为指令执行路径,或,DD-,路径,;,集成测试线索是,MM-,路径,即模块执行和消息交替序列。那么系统级线索，就是原子系统功能序列。,系统测试并不是一个十分常用的概念,在软件测试的概念和方法中,产品测试（验收测试）应该是更为重要的一个测试阶段。,本书介绍的系统测试，更象是产品测试中的一个方面：,功能性测试,。,这样的定义并不令人满意，换个角度，单元测试的线索是模块内的路径执行序列（有意义的最小单元）；集成测试的线索是模块间的路径执行序列（是小于系统级的意义单元）；系统级的线索，是系统输入到输出的路径（是功能的最小单元）。,定义：原子系统功能（,ASF,）是一种在系统层可以观察得到的端口输入和输出事件的行动。,SATM,中的可能线索：,数字输入,-,屏幕输出,插卡,-,提示屏幕,密码（,PIN,）验证,输入取款金额,-,取款,放入现金,-,屏幕显示存款,查询帐户,-,输出信息,打印水单,当然，仅对于密码验证而言，还可以细化为三次尝试，而每次尝试又有,4,个数字的输入，而每个数字的输入，都有输入,-,输出对（,ASF,）。,我们总是希望借鉴前面路径覆盖的有效方法，来尝试功能性测试。因此，我们就需要有能够描述功能的图。,定义：给定通过原子系统功能描述的系统，系统的,ASF,图是一种有向图，其中的节点表示,ASF,，边表示串行流。,教材中过多的概念介绍，,数据、行动、设备、事件，,反而容易混淆了主线。,主线：,如何建立,ASF,图，来完成满足一定覆盖标准要求的功能性测试？！,有限状态机（,FSM,）是研究系统功能级线索的有效手段。换言之，有限状态机恰是我们前面定义的,ASF,图。,右图就是,顶层的,SATM,状态机,对,PIN,输入的细化状态机,进一步的细化,我们知道每次,PIN,需要有,4,位数字输入,而且在任何一位数字输入后,都可以按“取消”键返回。则,PIN,的过程可以细化为：,为了使测试用例明确,我们不妨设定,PIN,密码为,:,1234,8.3.2,线索测试的结构策略,在获得系统状态图之后,如何确定测试用例呢,?,既然已经有系统的有限状态图,当然测试用例的选择就是考虑对路径的覆盖了。,对于,PIN,的细化状态图，共有,6,条路径。,输入事件序列,路 径,1234,x1,、,x2,、,x3,、,x4,、,x5,1235,x1,、,x2,、,x3,、,x4,、,x6,C,x7,、,x11,1C,x1,、,x8,、,x11,12C,x1,、,x2,、,x9,、,x11,123C,x1,、,x2,、,x3,、,x10,、,x11,对于,PIN,输入三次尝试，共有四条路径。,输入事件序列,路 径,1234,1,12351234,23,1235C1234,2,、,4,、,5,CCC,2,、,4,、,6,进一步的考虑,上面的考虑是基于路径的测试覆盖，而如果从状态图（有向图）的遍历（覆盖）考虑，可以有节点遍历和边遍历测试。,节点覆盖测试用例：,1234,，,12351234,，,C1234,，,1C12C1234,，,123C1C1C,。,P225,：表,14-8,。,同样的测试用例可以覆盖所有的边。,P225,：表,14-9,8.3.3,基于功能的线索测试,基于状态图的测试方法很有效，但并不是所有的软件系统都能够方便的得到状态图。而系统功能确是各个系统都十分明确的线索，下面我们就从功能定义的三个基本构件：事件、端口和数据，讨论测试的线索。,1),基于事件的线索测试,从端口的输入事件考虑，有,5,个覆盖标准：,PI1,：每个端口输入事件发生。,PI2,：端口输入事件的常见序列发生。,PI3,：每个端口输入事件在所有“相关”数据语境中发生。,PI4,：对于给定语境，所有“不合适”的输入事件发生。,PI5,：对于给定语境，所有可能的输入事件发生。,显然，从,PI1,到,PI5,，要求的覆盖越来越高。,PI1,是易于达到的，,PI2,是基本可行的。而,PI3,就有可能形成测试爆炸，而,PI4,和,PI5,往往是供参考的选项。,从端口的输出事件考虑，可以有两种覆盖指标：,PO1,：每个端口输出事件发生。,PO2,：每个端口输出事件在每种情况下发生。,PI1,是基本的要求，,PO2,不仅要求所有的输出事件，而且要考虑导致这种输出的所有可能原因，这个要求往往也是难以完全满足的（常见原因也许是一个可接受的选择）。,2),基于端口的线索测试,基于端口的线索测试是基于事件的测试的有用补充。,基于事件的测试以事件为中心，考虑的是事件到端口的一对多测试；,基于端口的测试以端口设备为中心，考虑的是端口到事件的一对多测试。,3),基于数据的线索测试,基于端口和事件的测试适合主要以事件驱动的系统，但并不是所有的系统都是事件驱动系统，例如以数据库为基础的系统，主要是数据的转换，此时就可以采用基于数据的测试。,以,E-R,模型作为测试的线索。,覆盖指标：,DM1,：检查每个关系的基数。,DM2,：检查每个关系的参与。,DM3,：检查关系之间的函数依赖关系。,基数指：关系间的一对一、一对多、多对一、多对多关系。,SATM,实例（由学生阅读）,8.3.4,系统测试指导方针,伪结构系统测试,伪结构是系统的行为模型,是系统实际情况的近似模型。,决策表、状态图、,Petri,网是系统功能性测试的常见选择。,运行剖面,齐夫定理（,Zipfs,Law,）在大多数情况下都成立。即,80%,的活动发生在,20%,的空间里（二八定理）。因此，确定各种线索的执行频率，对事件发生频率高的线索执行测试，可以大大提高测试的效率。,最大概率路径最小概率路径：,运行剖面提供了系统的使用情况，对优化系统测试有意义。,更进一步的，对客户使用情况的了解，是改进系统设计的重要依据。对于发生概率极小甚至为零的线索，也许恰恰占用了系统的极大资源！,8.4,产品测试（验收测试）,功能性测试,可靠性测试,易用性测试,效率测试,维护性测试,可移植性测试,8.4.1,功能性测试内容：,适合性,a.,验证是否有在软件的“软件需求规格说明”中没有指明的功能（即功能多余物）。软件的所有输出都应有意义，并在“软件需求规格说明”中指明。,b.,在预先规定的一个时期内，在软件设计能力的极限状态，进而超出此极限状态下，运行软件的所有功能，验证软件的所有功能是否正确执行。,c.,根据需求，对由于计算机的部件硬件失效而需降级运行的软件能力进行测试。,准确性,a.,测试软件在获得定量结果时程序计算的精确性；,b.,对软件输出信息的准确性进行测试。,互操作性,a.,根据需求，对与其它系统进行交互的能力进行测试，检查软件是否能与其它系统进行规定的交互操作；,b.,测试软件的所有外部接口，检查软件处理外部接口信息格式及内容的能力；,c.,测试人,-,机界面的正确性和处理错误操作的能力。,依从性,a.,对软件是否遵循特定的标准、约定、法规及有关规定进行审查和测试。,b.,测试软件处理规定的输入,/,输出信息格式的正确性，和处理错误信息格式的能力。,安全性,根据需求，对软件中的程序和数据进行非授权的故意或意外访问，测试其应对的能力。,8.4.2,可靠性测试测试内容：,成熟性,选择适合的可靠性评估模型，在软件测试中详细收集可靠性评估模型所需的信息，用软件失效数据对软件故障引起的失效频度进行分析评估。,容错性,在软件或软件的某些部分出现一定限度的接口功能错误时，测试软件能维持规定功能和性能水平的能力；,易恢复性,a.,对于有恢复（系统自动恢复或人工干预恢复）或重置（,RESET,）功能需求的软件，测试其在失效发生后，重建其性能水平并恢复直接受影响数据的能力；对每一类导致恢复或重置的情况进行测试。,b.,测试软件在失效发生后，重建其性能水平并恢复直接受影响数据所需时间是否满足要求。,8.4.3,易用性测试测试内容：,易理解性,:,审查软件与使用相关的内容是否符合规定并易于阅读和理解。例如，人,-,机界面、系统操作员手册、软件程序员手册、软件用户手册等。,易学性,:,软件操作人员根据人,-,机界面、系统操作员手册、软件程序员手册、软件用户手册等，对软件系统进行操作，审查软件的易学习程度。,易操作性,a.,测试软件的所有 人,-,机交互界面 提供的操作和显示界面，并以正确操作、误操作、快速操作来检验界面的正确性和识别误操作的能力，以最终用户为背景检验界面显示的清晰性、完备性和方便性；,b.,按照系统操作员手册、软件程序员手册、软件用户手册等逐条进行操作和检查。,8.4.4,效率测试内容：,时间特性,:,在规定的条件下，测试软件在有时间限制要求时完成功能的时间量；对特定功能的响应时间、处理时间及完成规定吞吐量的时间进行测试；,资源特性,:,在规定的条件下，测试软件运行占用的,CPU,时间、内存空间、外存空间、网络容量和接口等资源；根据需求测试软件资源的余量是否满足“软件需求规格说明”的要求。,8.4.5,维护性测试内容：,易分析性,:,从维护软件的角度，检查软件是否具有要求的诊断和自检能力。例如，当软件出现错误时，软件能否发现错误，并把错误信息记入日志；显示的错误信息是否准确、详细；根据日志信息和显示的错误信息确定软件的待修改部分是否容易等。,易改变性,:,从维护软件的角度，检查软件的内部结构对于修改、排除错误或适应环境变化的难易程度。例如，软件单元（模块）的结构是否合理；软件单元的功能是否独立：软件单元之间的界面是否简单、清晰等。,稳定性,:,从维护软件的角度，对于修改软件中的任何部分是否会造成不可预料的结果进行分析和评估。,易测试性,:,从维护软件的角度，为满足新要求、环境发生变化、发现新错误等原因对软件进行修改。对“确认已修改软件”是否容易进行分析和评估。,8.4.6,可移植性测试内容：,适应性,:,根据需求，对软件是否能适应不同的、规定环境的要求进行测试和验证：例如，要求一个软件能在,Windows95,、,Windows98,和,Windows NT,下安装和运行。这个软件就必须同时适应这三个不同的操作系统。,易安装性,:,验证按安装规程把软件运行需要的所有文件装入计算机的正确性，包括从各种安装价质装入计算机的参数、文件的内容和位置是否正确。安装测试的目的不是找软件的错误，而是找安装的错误。,遵循性,:,根据软件的可移植性要求，检查软件是否符合与可移植性相关的标准或约定。例如，要求一个软件的部分或全部软件单元，能被,C+,、,Ada,、,FORTRAN,、,PASCAL,等编程语言所调用。这些软件单元必须遵守统一的接口约定。,易替换性,:,根据软件的替换性需求，对软件、或软件的部件，能替换其它软件的能力和可能性进行分析和测试；,8.4.7,软件验收测试的具体要求：,a.,软件的每一个软件功能必须被一个测试用例或一个被认可的异常所覆盖；,b.,软件的每一个软件功能必须使用至少一个有效等价类值、无效等价类值和边界数据值作为测试用例进行测试，考察其功能的正确性和完备性；,c.,对安全性关键的计算机软件的部件，必须单独测试，以确认该计算机软件的部件是否满足安全性需求；,d.,操作员接口测试必须包括在安全性关键操作中的操作员误操作，以验证安全系统对这些错误的响应；,e.,应测试防止非法运行计算机软件，和保护计算机软件数据完整性能力；,f.,对于可能导致软件运行方式改变的一些边界条件和环境条件必须进行针对性测试g.,对计算机软件设计中用于是提高计算机软件安全性的结构、算法、容错、冗余、中断处理等方案,必须进行针对性测试；,h.,除在正常条件下测试外，应在异常条件下测试计算机软件，以表明不会因可能的单个或多个输入错误而导致不可靠状态；,i.,必须包含在最坏情况配置下的最小和最大输入数据率，以确定系统的固有能力及对这些环境的反应；,j.,对于有恢复（系统自动恢复或人工干预恢复）或重置（,RESET,）功能需求的计算机软件，必须测试其恢复或重置功能，对每一类导致恢复或重置的情况进行测试。在人工干预恢复的情况，还要考虑平均恢复时间是否在限定范围之内。,l.,全部测试用例（包括测试输入数据和期望测试结果）和测试结果应存档保留；,8.4.8,软件验收测试的实施步骤：,a.,制定“计算机软件验收测试计划”；,b.,进行测试准备，建立软件验收测试环境、设计软件验收测试用例、编写“软件验收测试说明”；,c.,依照验收测试计划和测试说明，执行全部的软件验收测试用例，并详细记录执行结果和相关的信息；,d.,确认用户手册和操作手册的实用性和有效性；,e.,分析测试结果，若发现错误，则找出产生错误的原因，并修正错误后进行回归测试；,f.,分析记录的测试结果和相关信息，制定“软件验收测试报告”，软件验收测试报告应包括：测试记录、测试结果分析、“软件错误报告单”、“软件更动报告单”和回归测试的测试记录。,8.4.9,软件验收测试评估：,根据软件需求规格说明书、计算机软件验收测试结果和测试中发现的错误信息情况，评价计算机软件的质量特性情况。,8.4.10,软件验收测试通过准则：,a.,测试环境满足要求、测试阶段的文档齐全、符合规范；,b.,测试活动满足独立性要求；,c.,满足“软件需求规格说明”中所规定的功能和质量特性要求明确的和隐含的需求；,d.,经过回归测试之后，所有测试用例都获得通过，或者给出合理解释；,e.,没有,1,、,2,级软件错误,；,f.,每,64KB,可执行代码中不多于一个,3,级软件错误；每,32KB,可执行代码中不多于一个,4,、,5,级软件错误；,g.,完成软件验收测试报告。,小 结,在本章，我们介绍了,测试层次 测试的分层概念,集成测试 模块间的测试方法,系统测试 功能性测试覆盖,验收测试 软件验收的标准,至此对软件测试的基本内容介绍告一段落。在后面的时间里，我们对软件测试的部分高级话题：回归测试、面向对象的测试、,GUI,测试等进行介绍和讨论。,