软件测试基础讲义PPT文档格式.ppt

软件测试基础讲义PPT文档格式.ppt

《软件测试基础讲义PPT文档格式.ppt》由会员分享，可在线阅读，更多相关《软件测试基础讲义PPT文档格式.ppt（93页珍藏版）》请在冰豆网上搜索。

那只有测试你的软件,我写的代码很干净。

我查了好几遍都没找到错误我不相信还会有错误,软件测试有什么好处？

通过测试可以：

发现软件的错误行为可以界定错误的原因证明软件的正确行为软件测试是质量保证的一个重要手段,软件测试的目的,目的：

寻找软件的缺陷跟踪修正软件缺陷验证修正的软件缺陷一个好的测试在于发现了至今未发现的错误。

软件测试是为了证明软件中存在错误，而不是为了证明软件不存在错误。

软件测试的原则,原则：

所有的软件测试都应追溯到用户需求尽早进行软件测试，早期发现和报告软件缺陷完全测试是不可能的，测试需要终止全程测试，测试过程贯穿于整个项目的生命周期测试独立与开发，开发人员不能测试自己的软件测试是有组织、有计划、有步骤的，尽量避免软件测试的随意性。

有效的测试应当是：

破坏性的系统化的开发和测试过程必须严格分开：

在时间上分开在组织结构上分开在人事上分开独立测试独立测试的好处：

能找到更多其他人的错误无偏见验证设计和开发人员的设想具有专业测试的知识背景,软件测试对象,软件测试不等于程序测试，软件测试贯穿于软件定义和开发的整个期间。

需求分析,概要设计,详细设计,以及程序编码等各个阶段所得到的文档,包括需求规格说明,概要设计规格说明,详细设计规格说明以及源程序,都是软件测试的对象。

常见的引入缺陷的原因,开发过程中缺乏有效的沟通或者没有进行沟通软件复杂度越来越高需求不断变更项目进度的压力不重视开发文档软件开发工具本身隐藏的问题,解决方案,要尽早进行测试,软件测试概述软件测试模型软件测试分类软件测试过程（功能测试）软件性能测试,目录,2.软件测试模型,V模型,在V模型中，测试贯穿在整个软件开发过程活动中，测试人员可以尽早进入项目，测试人员将更加熟悉产品，更多缺陷将在早期被发现，这有利于大幅度降低成本，在项目后期发现严重缺陷的风险大大降低。

同时对设计出高质量的测试用例非常有帮助。

W模型,W模型是V模型的发展，测试伴随整个软件的开发周期，测试的对象包括需求、代码、功能和设计，只要相应的对象开发完成，测试就可以进行。

H模型,准备测试,准备就绪点,测试执行,测试流程,其他流程（如设计流程）,H模型将测试活动完全独立出来，形成了一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。

H模型揭示了一个原理：

软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行。

H模型指出软件测试要尽早准备，尽早执行。

软件测试概述软件测试模型软件测试分类软件测试过程（功能测试）软件性能测试,目录,3.软件测试分类,按照测试阶段划分单元测试单元测试主要用白盒测试方法，一般我们先静态地检查代码是否符合规范，然后动态地运行代码，检查其实际运行结果。

当然，检查程序的运行结果是否正确是一个最基本的要求，我们还要检查很多项，比如程序的容错处理，程序的边界值处理等。

单元测试是在程序员编码之后，代码通过编译后进行单元测试。

单元测试一般由白盒测试工程师或开发人员来测试。

集成测试集成测试是单元测试的下一个阶段，是指将通过测试的单元模块组装成系统或子系统，再进行测试。

重点测试不同模块的接口部分，检查各个单元模块结合到一起能否协同配合，正常运行。

集成测试的依据是单元测试的模块以及概要设计文档。

系统测试集成测试之后，就进行系统测试。

系统测试也是我们测试的重点。

系统测试将整个软件系统看做一个整体进行测试，包括对功能、性能，以及软件所运行的软硬件环境进行测试。

主要依据是系统需求规格说明书文档。

目前系统测试主要由测试工程师在整个系统集成完毕后进行测试，前期主要测试系统的功能是否满足需求，以及系统在不同的软硬件环境中的兼容性等。

验收测试验收测试是以用户为主的测试。

软件开发人员与质量保证人员也应参加。

由用户参加设计测试用例。

使用用户界面输入测试数据，并分析测试的输出结果。

一般使用生产中的实际数据进行测试。

按照是否运行程序划分静态测试静态方法是指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。

对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。

静态测试结果可用于进一步的查错，并为测试用例选取提供指导。

动态测试实际的执行被测对象的程序代码，输入实现设计好的测试用例，检查程序代码运行得到的结果与测试用例中设计的预期结果之间是否有差异，判定实际结果与预测结果是否一致。

动态测试有四部分组成：

设计测试用例，执行测试用例，分析比较输出结果，输出测试报告。

动态测试有三种主要方法：

黑盒测试，白盒测试和灰盒测试。

按照测试技术划分（黑盒测试）功能测试功能测试将系统看成黒盒，又称为黒盒测试，它检查软件的功能是否符合需求规格说明书，确保测试对象的功能正常，其中包括导航，数据输入，处理和检索等。

测试时用有效数据和无效数据来执行各个用例或用例流，以核实在使用有效数据时得到预期的结果，在使用无效数据时显示相应的错误信息或警告信息。

由于正确性是软件最重要的质量因素，所以其测试也最重要。

性能测试性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。

性能测试的目的是为了验证系统是否达到用户提出的性能指标，同时发现系统中存在的性能瓶颈，优化系统。

软件测试概述软件测试模型软件测试分类软件测试过程（功能测试）软件性能测试,目录,软件测试过程,制定测试计划,设计测试用例,执行测试,撰写测试报告,修正软件缺陷,回归测试,测试需求分析,功能测试概述,任何程序都可以看作是将从输入定义域取值映射到输出值域的函数功能测试将系统看成黒盒，又称为黒盒测试。

黒盒的实现是不需要了解的，只需要知道输入和预期输出。

功能性测试与软件如何实现无关，如果实现发生变化，功能性测试用例仍然可用。

测试用例开发可以与软件开发同时进行，可节省软件开发时间，通过软件的用例（usecase）就可以设计出大部分功能性测试用例。

功能测试的优点,需求分析,通过详细的分析测试需求，可以了解整个测试的规模、复杂程度，以及可能存在的风险。

测试需求越详细精准，表明对所测软件的了解越深，对所要进行的任务内容就越清晰，就更有把握保证测试的质量与进度。

整个需求分析过程分以下几个阶段和任务：

分析需求测试时，要遵循以下原则：

完整性：

每一项需求都必须将所要实现的功能描述清楚。

正确性：

每一项需求都必须准确地陈述其要开发的功能。

一致性：

是指与其它软件需求或高层（系统，业务）需求不相矛盾。

可行性：

每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。

无二义性：

对所有需求说明的读者都只能有一个明确统一的解释，应尽量把每项需求用简洁明了的用户性的语言表达出来。

健壮性：

测试需求的说明中是否对可能出现的异常进行了分析，并且对这些异常进行了容错处理。

必要性：

是指每项需求都是用来授权你编写文档的“根源”，要使每项需求都能回溯至某项客户的输入。

可测试性：

每项需求都能通过设计测试用例或其它的验证方法来进行测试。

可修改性：

每项需求只应在测试需求分析中出现一次。

这样更改时易于保持一致性。

可跟踪性：

在每项测试需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，使得每项测试需求以一种结构化的，粒度好的方式编写并单独标明，而不是大段大段的叙述。

测试计划阶段功能点整理,测试计划,软件项目的测试计划是描述测试目的、范围、方法和软件测试的重点等的文档。

对于验证软件产品的可接受程度编写测试计划文档是一种有用的方式。

测试计划包括：

测试目的测试范围测试环境测试方法测试人员和时间安排,“5W1H”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、“Who”（谁去做）“How（如何做）”。

利用“5W1H”规则创建软件测试计划，可以帮助测试团队理解测试的目的（Why），明确测试的范围和内容（What），确定测试的开始和结束日期（When），确定团队人员（Who），指出测试的方法和工具（How），给出测试文档和软件的存放位置（Where）。

为了使“5W1H”规则更具体化，需要准确理解被测软件的功能特征、应用行业的知识和软件测试技术，在需要测试的内容里面突出关键部分，可以列出关键及风险内容、属性、场景或者测试技术。

对测试过程的阶段划分、文档管理、缺陷管理、进度管理给出切实可行的方法,测试计划评审,测试计划编写后，内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员。

测试计划包含多方面的内容，编写人员可能受自身测试经验和对软件需求的理解所限，而且软件开发是一个渐进的过程，所以最初创建的测试计划可能是不完善的、需要更新的。

需要采取相应的评审机制对测试计划的完整性、正确性、可行性进行评估。

测试计划变更,更来源于以下几个方面：

项目计划的变更；

需求的变更；

测试产品版本的变更；

测试时间变更；

测试资源的变更。

测试用例设计,什么是测试用例？

测试用例是为特定的目的设计的一组测试输入、执行条件、和预期的结果。

测试用例是执行的最小实体。

测试用例的重要性为什么要写测试用例？

测试人员工作不主动的时候测试时思维混乱的情况测试时间紧迫的情况情绪不佳、人员流动频繁,测试用例的组成元素测试用例的必要组成元素,用例编号用例名称步骤预期结果设计人员,测试用例模板解释,序号,用例名称,设计者,描述,步骤序号,具体步骤描述,预期结果,实际结果,格式：

用例编号，每个工作表的用例从1开始，例如：

1,2,3,解释：

该测试用例的名称格式：

模块名称_子模块名称_功能点名称_流水号（从01开始）举例：

客户管理_对公客户_新增客户_01,解释：

编写此测试需求点的人员姓名全拼（要求中文拼音）,解释：

对此测试案例的场景的简要描述,解释：

步骤序号举例：

步骤1、步骤2、,解释：

案例场景每一步操作对应的输入要素、数据描述（前置条件和输入值要明确填写，并用蓝色标识）要求：

多个操作才能产生一个预期结果，请作为一个步骤,解释：

每一步骤操作对应产生的预期结果要求：

在预期结果中，一定要把检查点的预期结果明确描述，以便明确判断是成功还是失败,格式：

成功、失败解释：

执行测试用例步骤的结果,测试用例设计方法,测试用例设计基本方法,等价类划分法,边界值分析法,因果图法,错误推测法,流程分析法,解释：

把所有可能的输入数据，即程序的输入域划分成若干部分（子集），然后从每一个子集中选取少量具有代表性的数据作为测试用例,等价类划分法,等价类某些数据的集合，该集合内每个数据都是等效的，那么可以将该集合视为等价的一类,等效对于计算机软件而言，即对于数据的处理方式完全一致,有效等价类,无效等价类,四条确定等价类的原则,在输入条件规定了取值范围的情况下,则可以确立一个有效等价类和两个无效等价类在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,则可以确立一个有效等价类和一个无效等价类在规定了输入数据必须遵守的规则的情