软件测试基本概念与原理幻灯片.ppt

《软件测试基本概念与原理幻灯片.ppt》由会员分享，可在线阅读，更多相关《软件测试基本概念与原理幻灯片.ppt（45页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、软件测试基本概念与原理第1页，共45页，编辑于2022年，星期三内容简介测试基本概念测试方法测试阶段测试工具简介第2页，共45页，编辑于2022年，星期三测试的基本概念软件测试的对象测试用例测试环境软件测试与软件开发软件测试分类测试的原则测试工具第3页，共45页，编辑于2022年，星期三测试基本概念测试对象软件测试不等于程序测试，软件测试贯穿于软件定义和开发的真个过程。需求分析，概要设计，详细设计，以及程序编码等各个阶段所得到的文档，包括需求规格说明，概要设计规格说明，详细设计规格说明以及源程序，都是软件测试的对象第4页，共45页，编辑于2022年，星期三测试基本概念测试用例为特定的目的而设计

2、的一组测试输入、执行条件、测试环境和预期的结果；测试用例是执行测试的最小实体；第5页，共45页，编辑于2022年，星期三测试基本概念测试环境软件历时数据硬件网络第6页，共45页，编辑于2022年，星期三测试基本概念软件开发与软件测试软件测试与软件开发的并行性需求评审概要设计概要设计评审详细设计设计走查编码走查单元测试编码系统测试集成测试测试评审测试过程测试计划各子模块第7页，共45页，编辑于2022年，星期三测试基本概念软件开发与软件测试包含测试的完整的开发流程项目规划需求分析概要设计详细设计代码编写产品发布系统规划集成规划单元规划测试代码编写测试需求分析系统测试计划集成测试计划单元测试计划第

3、8页，共45页，编辑于2022年，星期三测试基本概念软件开发与软件测试开发各阶段的测试工作需求分析概要设计详细设计实现/单元测试集成测试确认测试系统测试系统测试确认测试集成测试单元测试计划计划计划计划计划计划执行执行执行执行执行执行执行执行计划计划/设计设计设计设计设计设计设计设计第9页，共45页，编辑于2022年，星期三测试基本概念软件开发与软件测试模型需求获取需求分析需求定义概要设计需求分析书详细设计概要设计书编码详细设计书程序软件产品系统测试可交付软件确认测试已确认软件集成测试已集成软件单元测试已测试模块用户第10页，共45页，编辑于2022年，星期三测试基本概念软件开发与软件测试模型需

4、求需求概要设计概要设计设计设计编码编码单元测试单元测试集成测试集成测试系统测试系统测试验收测试验收测试安装安装集成集成构建构建设计测试设计测试功能测试功能测试需求测试需求测试第11页，共45页，编辑于2022年，星期三测试基本概念软件开发与软件测试模型测试准备测试准备测试执行测试执行其他流程（如设计流程）其他流程（如设计流程）第12页，共45页，编辑于2022年，星期三测试基本概念测试分类按测试按测试技术技术按测试阶段按测试阶段按测试实施组织按测试实施组织按测试方式按测试方式黑盒测试黑盒测试通过软件的外部表现来发现其缺陷和错误白盒测试白盒测试通过对程序内部结构的分析、检测来寻找问题第13页，共

5、45页，编辑于2022年，星期三测试基本概念测试分类按测试技术按测试技术按测试阶段按测试阶段按测试实施组织按测试实施组织按测试按测试方式方式静态测试静态测试不执行被测试软件，而对需求分析说明书、软件设计说明书、源程序做结构检查、流程图分析、符号执行等找出软件错误 动态测试动态测试执行被测程序，通过执行结果分析软件可能出现的错误设计并执行测试用例第14页，共45页，编辑于2022年，星期三测试基本概念测试分类按测试技术按测试技术按测试按测试阶段阶段按测试实施组织按测试实施组织按测试方式按测试方式单元测试单元测试（模块测试）集成测试集成测试（组装测试或联合测试）系统测试系统测试验收测试验收测试（有

6、效性测试或合格测试）第15页，共45页，编辑于2022年，星期三测试基本概念测试分类按测试技术按测试技术按测试按测试阶段阶段按测试实施组织按测试实施组织按测试方式按测试方式单元测试单元测试（模块测试）集成测试集成测试（组装测试或联合测试）系统测试系统测试验收测试验收测试（有效性测试或合格测试）第16页，共45页，编辑于2022年，星期三测试基本概念测试分类按测试技术按测试技术按测试阶段按测试阶段按测试按测试实施组织实施组织按测试方式按测试方式开发方测试开发方测试用户方测试用户方测试第三方测试第三方测试通常也称为内部测试。在软件开发环境下，由开发者验证软件的实现是否满足软件需求说明的要求。是开发

7、方对软件进行的自我检查与验证希望通过测试，表明软件产品中不存在错误的过程，验证该软件已正确地实现了用户的要求！第17页，共45页，编辑于2022年，星期三测试基本概念测试分类按测试技术按测试技术按测试阶段按测试阶段按测试按测试实施组织实施组织按测试方式按测试方式开发方测试开发方测试用户方测试用户方测试第三方测试第三方测试在用户的应用环境下，由用户通过运行和使用软件，验证软件实现是否符合自己预期的要求。由用户找出软件的应用过程中发现的软件的缺陷与问题，并对使用质量进行评估。希望能通过软件测试暴露软件中隐藏的错误和缺陷！Alpha测试Beta测试第18页，共45页，编辑于2022年，星期三测试基本

8、概念测试分类按测试技术按测试技术按测试阶段按测试阶段按测试按测试实施组织实施组织按测试方式按测试方式开发方测试开发方测试用户方测试用户方测试第三方测试第三方测试也称为独立测试。由开发方和用户之外的测试组织进行的测试。第三方测试是由在技术、管理和财务上与开发方和用户方向对独立的组织进行的软件测试。软件质量工程强调开展独立的验证和确认活动兼顾开发方和用户方角度第19页，共45页，编辑于2022年，星期三测试的基本概念测试的原则应尽早和不断地进行测试程序员应避免检查自己的程序从用户和开发者的角度进行软件测试要站在客户的角度进行测试第20页，共45页，编辑于2022年，星期三测试工具简介测试工作在软件

9、开发整个过程中占有极为重要的位置，而全人工测试是非常麻烦的，所以测试过程的自动化已成为测试发展的重要方向。测试工具的选择对测试的规范化影响很大，目前已开发出了各种自动化软件测试工具，它们为软件测试提供了强有力的支持测试工具从测试的方法上可以分为两种：白盒测试工具和黑盒测试工具。第21页，共45页，编辑于2022年，星期三测试工具简介白盒测试工具白盒测试工具主要有：内存资源泄漏检查：Numega中的bouncechecker，Rational的Purify等；代码覆盖率检查：Numega中的truecoverage，Rational的Purecoverage，Telelogic公司的logisc

10、ope,，Macabe公司的Macabe等；代 码 性 能 检 查：Numega中 的 truetime，Rational的Quantify等；代码静态度量分析质量检查工具：logiscope和Macabe等。第22页，共45页，编辑于2022年，星期三测试工具简介黑盒测试工具黑盒测试工具主要有：客 户 端 功 能 测 试：MI公 司 的 winrunner，compuware的 QACenter，Rational的 SQA robot，SQATeamTest，Rational Viaual Test等。软件性能测试工具：LoadRunner（MI产品）、Rational Visual Qan

11、tify等。第23页，共45页，编辑于2022年，星期三详细参考第24页，共45页，编辑于2022年，星期三黑盒测试黑盒测试主要是为了发现以下几类错误：1、是否有不正确或遗漏的功能？2、在接口上，输入是否能正确的接受？能否输出正确的结果？3、是否有数据结构错误或外部信息（例如数据文件）访问错误？4、性能上是否能够满足要求？5、是否有初始化或终止性错误？第25页，共45页，编辑于2022年，星期三白盒测试白盒测试白盒测试这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否

12、与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。第26页，共45页，编辑于2022年，星期三白盒测试白盒测试主要是想对程序模块进行如下检查：1、对程序模块的所有独立的执行路径至少测试一遍。2、对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。3、在循环的边界和运行的界限内执行循环体。4、测试内部数据结构的有效性，等等。第27页，共45页，编辑于2022年，星期三灰盒测试灰盒测试是介于黑、白盒测试之间的，关注输出对于输入的正确性，同时也关注内部表现。灰盒测试结合了白盒测试盒黑盒测试的要素.它考虑了用户端、特定的系统知识和操作环境。它在系统组件的协同性环境中评价应用软件的设

13、计。第28页，共45页，编辑于2022年，星期三静、动态分析静态分析(Static analysis)就是对软件的源代码进行研读，查找错误或收集一些度量数据，不需要对代码进行编译和执行 动态分析(Dynamic analysis)就是通过观察软件运行时的动作，来提供执行跟踪，时间分析，以及测试覆盖度方面的信息。第29页，共45页，编辑于2022年，星期三单元测试单元测试是对软件设计的最小单位模块进行正确性检验的测试工作，测试模块在语法、格式和逻辑上的错误。使用的测试方法以详细设计为基础，了解I/O条件和模块的逻辑结构。先采用白盒测试法，尽可能达到穷尽测试，然后再用黑盒测试法，使之对任何合理和不

14、合理的输入都能够鉴别和响应。第30页，共45页，编辑于2022年，星期三集成测试用经过单元测试的模块组装成设计所规定的软件系统的过程就是“集成”。集成测试是组装软件的系统技术之一。集成测试的主要目标是要求符合实际软件结构，解决模块接口的一致性问题。例如，数据穿过模块接口时可能丢失；一模块可能对另一模块产生副作用；子功能组装以后，可能系统总的功能达不到；单个模块看来是可以接受的误差，组装以后积累起来的软件误差可能大到无法让人接受的程度；全程数据结构可能有问题等，都是集成测试要解决的问题。第31页，共45页，编辑于2022年，星期三确认测试集成测试通过以后，软件已经组装成一个完整的软件包，这时就可

15、以进行确认测试，用确认测试用例测试程序，将结果与期望值比较，测试软件是否满足需求规格说明的要求，即验证软件功能与用户要求的一致性。在软件需求说明书的有效性标准中，详细定义了用户对软件的合理要求，其中包含的信息是有效性测试的基础和根据。测试计划给出了必须进行的测试类型，测试过程确定了验证软件有效性的特殊测试用例。此外，还必须对文件资料是否完整正确，软件的易移植性、兼容性、出错自动恢复功能和易维护性进行确认。第32页，共45页，编辑于2022年，星期三系统测试系统测试是将通过确认测试的软件作为整个计算机系统的一个元素，与硬件、外设等等其他元素结合在一起，对软件系统进行整体测试和有效性测试。一般相当

16、大的工作量集中在软件系统的某些模块与计算机系统中有关设备打交道时的默契配合方面。例如：当软件系统中调用打印机这种常见输出外设时，软件系统如何通过计算机系统平台的控制去合理驱动、选择、设置、使用打印机。又如，新的软件系统中的一些文件名和计算机系统中别的软件系统中的一些文件完全同名时，两种软件系统之间如何实现相互协调操作。再如，新的软件系统和别的软件系统对系统配置和系统操作环境有矛盾时如何相互协调。如此等等的问题都是系统测试要解决的问题。第33页，共45页，编辑于2022年，星期三系统测试系统测试的内容应包括对各子系统或分系统间的接口正确性的检查和对系统的功能、性能的测试。系统测试一般通过以下几种

17、测试来完成：恢复测试。恢复测试是要采取各种人工方法使软件出错，而不是能正常工作，进而检验系统的恢复能力。如果系统本身能够自动地进行恢复，则应检验：重新初始化、检验点设置机构、数据以及重新启动是否正确。如果这一恢复需要人工干预，则应考虑平均修复时间是否在限定的范围内。结合起来进行。为记录性能需要再安装必要的仪表或度量性能的软件。安全测试。安全测试就是设置一些企图突破系统安全保密措施的测试用例，检验系统是否有安全保密的漏洞。对某些与人身、机器和环境的安全有关的软件，还需特别测试其保护措施和防护手段的有效性和可靠性。强度测试。强度测试检验系统的能力最高能达到什么实际限度。在强度测试中程序被强制在它的

18、设计能力极限状态下运行，进而超出极限，以验证在超出临界状态下性能降低不是灾难性的。性能测试。性能测试检验安装在系统内的软件运行性能，这种测试需与强度测试结合起来进行。为记录性能需要再安装必要的仪表或度量性能的软件。第34页，共45页，编辑于2022年，星期三验收测试系统测试完成后，并使系统试运行了预定的时间，企业应进行验收测试。确认已开发的软件能否达到验收标准，包括对测试有关的文档资料的审查验收和对程序测试验收。对于一些关键性软件，还必须按照合同一些严格条款进行特殊测试，如强化测试和性能降级执行方式测试等，验收测试应在软件投入运行后所处的实际生产环境下进行。验收测试的目的是测试程序的操作和合同

19、规定的要求是否一致。通常以用户为主体来进行，由用户设计测试用例，确定系统功能和性能的可接受性，按照合同中预定的验收原则进行的测试，这是一种非常实用的测试，实质上就是用户用大量的真实数据试用软件系统。第35页，共45页，编辑于2022年，星期三验收测试文档资料的审查验收。所有与测试有关的文档资料是否编写齐全，并得到分类编写，这些文档资料主要包括各测试阶段的测试计划、测试申请及测试报告等。余量要求。必须实际考察计算机存储空间，输入、输出通道和批处理间接使用情况，要保持至少有20%的余量。功能测试。必须根据需求规格说明书中规定的功能，对被验收的软件逐项进行测试，以确认软件是否具备规定的各项功能。性能

20、测试。必须根据需求规格说明书中规定的性能，对被验收的软件进行测试，以确认该软件的性能是否得到满足，开发单位应提交开发阶段内各测试阶段所作的测试分析报告，包括测试中发现的错误类型，以及修正活动情况。开发单位必须设计性能测试用例，并预先征得用户的认可。强化测试。强化测试必须按照 GB8566-88计算机软件开发规范中的强化测试条款进行。开发单位必须设计强化测试用例，其中应包括典型的运行环境、所有的运行方式，以及在系统运行期可能发生的其他情况。性能降级执行方式测试。在某些设备或程序发生故障时，对于允许降级运行的系统，必须确定经用户批准的能够安全完成的性能降级执行方式，开发单位必须按照用户指定的所有性

21、能降级执行方式或性能降级地方式组合来设计测试用例，应设定典型的错误原因和所导致的性能降级执行方式。开发单位必须确保测试结果与需求规格说明中包括的所有运行性能需求一致。安装测试。安装测试的目的不是检查程序的错误，而是检查软件安装时产生的问题，即程序和库、文件系统、配置管理系统的接口有什么问题。第36页，共45页，编辑于2022年，星期三测试设计逻辑覆盖逻辑覆盖是对一系列测试过程的总称，它是在使用白盒测试法时，选用测试用例执行（即这里所说的覆盖）程序逻辑路径的方法。覆盖程度由低到高大致分为以下几类：语句覆盖。设计若干测试用例，使程序中每一可执行语句至少执行一次；判断覆盖。设计用例，使程序中的每个逻

22、辑判断的取真取假分支至少经历一次；条件覆盖。设计用例，使判断中的每个条件的可能取值至少满足一次；第37页，共45页，编辑于2022年，星期三测试设计逻辑覆盖判断/条件覆盖。设计用例，使得判断中的每个条件的所有可能结果至少出现一次，而且判断本身所有可能结果也至少出现一次；条件组合覆盖。设计用例，使得每个判断表达式中条件的各种可能组合都至少出现一次；显然，满足的测试用例也一定是满足、的测试用例。路径覆盖。设计足够的测试用例，使程序的每条可能路径都至少执行一次。如果把路径覆盖和条件组合覆盖结合起来，可以设计出检错能力更强的测试数据用例。第38页，共45页，编辑于2022年，星期三测试设计等价类划分等

23、价类划分是用黑盒测试法设计测试用例的一种技术。它是将程序（或者模块）输入定义域中的所有可能的输入数据（含有效和无效）划分成若干个等价类，每一类的一个代表性的数据在测试中的作用，就等价于这一类中的所有其他数据。也就是说，如果某一类的一个用例发现了错误，这一等价类中的所有其他用例也能发现同样的错误，反之亦然。借以实现测试的经济性，大大减少测试的工作量。第39页，共45页，编辑于2022年，星期三测试设计等价类划分【例】某工厂公开招工，规定报名者年龄应在20周岁至39周岁之间（到2006年6月30日止），即出生年月不早于1967年7月，不晚于1986年6月。报名程序具有自动检验输入数据的功能。如出生

24、年月不在上述范围内，将拒绝接受，并显示“年龄不合格”等出错信息。试用等价分类法设计对这一程序功能的测试用例。第40页，共45页，编辑于2022年，星期三测试设计等价类划分第一步：划分等价类。假定已知出生年月由6位数字字符表示，前4位代表年，后2位代表月，则可以划分为3个有效等价类，7个无效等价类，如表所示输入数据输入数据有效等价类有效等价类无效等价类无效等价类出生年月6位数字字符有非数字字符少于6个数字符多于6个数字符对应数值在196007-197906之间198606月份对应数值在1-12之间等于“0”12第41页，共45页，编辑于2022年，星期三测试设计等价类划分第二步：设计有效等价类需

25、要的测试用例。表7-1中的、等个有效等价类，可以公用一个测试用例，例如：测试数据 期望结果 测试范围 197011 输入有效 、第三步：为每一无效等价类至少设计一个测试用例。本例具有个无效等价类，需要不少于个测试用例。例如 测试数据 期望结果 测试范围 MAY,70 输入无效 19705 输入无效 1968011 输入无效 195512 年龄不合格 198706 年龄不合格 198000 输入无效 197922 输入无效 第42页，共45页，编辑于2022年，星期三测试设计边界分析经验表明，程序在处理边缘情况时常会出现错误，例如，许多程序错误出现在数组下标，数据结构和循环等等的边界附近。因此，

26、设计检查边界值的测试用例暴露程序错误的可能性会更大。所谓边界条件，是相对于输入情形输出等价类直接在其边缘上，稍高于其边界和低于其边界的这些状态条件。使用边界值分析方法设计测试用例，通常输入等价类和输出等价类的边界值，选取刚好等于、稍小于、稍大于等价类边界值的数据作为测试用例。边界分析法与等价类法有两方面区别：边界分析不是从某个等价中随便挑一个作为代表，而是选出一个或几个元素，使得这个等价类的每个边界都要作为测试对象。边界分析不仅根据输入条件，还要根据输出的情况（按输出等价类）设计测试用例。第43页，共45页，编辑于2022年，星期三测试设计因果图因果图法也是较常用的一种黑盒测试技术。因果图是一

27、种简化了的逻辑图。当被测程序具有多种输入条件，程序的输出又依赖于输入条件的各种组合时，用因果图直观地表明输入条件和输出动作之间的因果关系，能帮助测试人员把注意力集中到与程序功能有关的那些输入组合，比采用等价分类法有更高的测试效率，但这种方法的操作步骤比较复杂。第44页，共45页，编辑于2022年，星期三测试设计猜错所谓猜错，就是猜测被测程序在哪些地方容易出错，然后针对可能的薄弱环节来设计测试用例。它的基本想法是列举出程序中可能有的错误和容易发生错误的特殊情况，并且根据这些情况设计测试用例。显然，它比前种方法更多地依靠测试人员的直觉与经验。所以，一般都先用前种方法设计测试用例，然后用猜错法补充一些例子作为辅助的手段。第45页，共45页，编辑于2022年，星期三