软件测试技术 课件 项目1、2 认识软件测试、软件测试基本概念

项目一

认识软件测试了解IT行业发展历史了解软件测试的发展历史了解软件测试的发展现状及前景了解软件测试的目的了解软件缺陷的定义了解软件研发模型掌握软件测试模型能够根据项目需求选择合适的软件研发模型

能够根据项目需求选择合适的软件测试模型感受我国在软件领域的迅猛发展，提升民族自豪感树立科技报国的决心培养认真细致的工匠精神任务一

了解IT行业任务二

了解软件测试的历史任务三

了解软件测试的发展现状、前景及从业要求任务四

认知软件测试任务五

认识软件研发模型与软件测试模型任务一

了解IT行业任务一

了解IT行业IT（InformationTeachnology）是信息科技首字母的缩写，IT行业是指以计算机和通信技术为基础的信息技术产业，涵盖了很多领域，大致上可分为硬件、软件和应用三个层面。一、IT行业概述任务一

了解IT行业1946年，在美国宾夕法尼亚大学的莫尔电机学校，人类历史上的第一台电子计算机埃尼阿克（ENIAC）诞生了。随后70多年的岁月里，计算机逻辑元件的迭代更新带来计算机性能的快速提升，CPU运行速度更快，存储设备容量日渐增大，计算机软件也随之经历了巨大的变革。二、IT行业历史任务一

了解IT行业二、IT行业历史1.第一代电子管计算机(1946—1959年)

第一代电子管计算机采用电子管作为基本逻辑元件。其体积大、耗电量大、寿命短、可靠性低、成本高；主存储器采用水银延迟线或静电储存管，容量很小；外存储器(外存或辅存)使用了磁鼓；输入/输出装置主要采用穿孔卡；此时的计算机没有系统软件，用机器语言和汇编语言编程，计算机只能在少数尖端领域中得到运用，一般用于科学，军事和财务等方面的计算，其运算速度仅为每秒数千至数万次。任务一

了解IT行业二、IT行业历史2.第二代晶体管计算机(1960—1964年)第二代晶体管计算机采用晶体管等半导体器件作为逻辑元件。与电子管相比，其体积小、耗电少、速度快、价格低、寿命长；主存储器采用磁性材料制成磁芯；外存储器采用磁盘、磁带，存储器容量有了较大提升；计算机软件技术也取得了较大发展,编程语言取得了不小的发展,此时出现了高级程序设计语言，如FORTRAN语言；计算机开始出现操作系统，大大提高了它的工作效率，计算机开始进入实时过程控制和数据处理领域，运算速度达到每秒数百万次。任务一

了解IT行业二、IT行业历史3.第三代中小规模集成电路计算机(1965-1969年)第三代中小规模集成电路计算机使用中小规模集成电路作为逻辑元件。上世纪60年代初期，美国的基尔比和诺伊斯发明了集成电路，引发了电路设计革命，比手指甲还小的晶片上包含了几千个晶体管元件。其体积更小，耗电更少，寿命更长，价格更低、可靠性更高；前两代计算机主存储器以磁芯为主，从此时开始使用半导体存储器，存储容量大幅度提升，集成电路的集成度以每3-4年提高一个数量级的速度增长；计算机系统软件与应用软件迅速发展，出现了分时操作系统和会话式语言，操作系统日趋完善；运算速度可达每秒几十万次至几百万次基本运算。任务一

了解IT行业二、IT行业历史4.第四代大规模、超大规模集成电路计算机(1970年至今)第四代大规模、超大规模集成电路计算机采用了大规模、超大规模集成电路作为逻辑元件，1967年和1977年分别出现了大规模和超大规模集成电路，自此以后，计算机性能发生巨大改变，例如1985年英特尔公司推出的第一个32位80386微处理器，在面积约为10mm×l0mm的单个芯片上，可以集成大约32万个晶体管；其主存储器采用半导体存储器，容量已达第三代计算机外存储器的水平；外存储器方面，软盘和硬盘的容量成百倍增加，并开始使用光盘、U盘；输入设备出现了光字符阅读器、触摸输入设备和语音输入设备等，操作更加简洁、灵活；输出设备已逐步以激光打印机为主，字符和图形输岀更加逼真、高效。任务一

了解IT行业三、IT行业发展现状截至2022年6月，我国网民规模为10.51亿，互联网普及率达74.4%，互联网已经成为我国民众生活的必需品。在我国，超过十亿用户接入互联网，形成了全球规模最大、应用渗透最强的数字社会，日常生活随处可见“手机控”，互联网应用和服务的广泛渗透构建起数字社会的新形态。王者荣耀、今日头条、抖音等软件，更是彻底的改变了读者的碎片化时间利用方式，8.88亿人看短视频、6.38亿人看直播，短视频、直播正在成为全民新的生活方式；使用淘宝、京东等子商务平台，足不出户就可以买遍全球；使用美团、饿了吗等软件，读者可以很便利的在家享用全城美食，8.12亿人网购、4.69亿人叫外卖，人们的购物方式、餐饮方式发生了明显变化。任务二

了解软件测试的历史任务二

了解软件测试的历史一、软件测试概述计算机软件是计算机系统中一系列计算机指令序列构成的能完成的特定功能的程序及文档。随着软件行业的迅速发展，不同类型的软件被深入应用于人类社会生活各领域，软件系统的规模越来越大，复杂性与日俱增，软件缺陷的数量及其错误概率逐渐增加。一些重要的软件系统，如航空航天自动控制软件、国家军事防御系统、银行结算系统、证券交易系统、医疗诊断系统等如果出现重大缺陷，可能会造成灾难性的后果。水手一号是水手计划中第一个探测器，在1962年采用擎天神运载火箭发射，这是“水星计划”开始后的第一次发射，得到了多方关注，7月22日火箭点火升空，载着400斤重的水星一号奔向金星。接下来的一幕让在成所有的人员瞠目结舌，升空5分钟后因不明故障火箭偏离开始轨道，为了防止其坠落造成二次伤害，美国空军将其摧毁。首次发射的失败，给美国带来了沉重的打击。任务二

了解软件测试的历史一、软件测试概述软件系统的规模越来越大，复杂性与日俱增，软件缺陷的数量及其错误概率逐渐增加，重要软件的缺陷可能会带来巨大的影响。如何衡量“看不见，摸不着”的非有形产品，软件产品的质量呢？任务二

了解软件测试的历史一、软件测试概述软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计的一批测试用例（即输入一些数据而得到其预期的结果），通过人工或者自动检测的方式，使用测试用例去运行程序，弄清楚预期结果与实际结果之间的差异，为了发现错误而审查软件文档、检查软件数据和执行程序代码的过程。一、软件测试概述任务二

了解软件测试的历史二、软件测试发展历程任务二

了解软件测试的历史1973年，比尔.黑则尔（BillHetzel）给出软件测试的第一个定义:“软件测试就是对程序能够按预期的要求运行建立起的一种信心。”该方法是试图验证软件是“工作的”，这是第一类软件测试方法。任务二

了解软件测试的历史二、软件测试发展历程任务二

了解软件测试的历史二、软件测试发展历程1979年，迈尔斯(Myers)提出软件测试的目的是证伪，即“软件测试是以发现错误为目的而运行的程序或系统的执行过程”。他还给出了与测试相关的三个重要观点，那就是：“测试是为了证明程序有错，而不是证明程序无错误；一个好的测试用例是在于它能发现至今未发现的错误；一个成功的测试是发现了至今未发现的错误的测试。”这就是软件测试的第二类方法。二、软件测试发展历程任务二

了解软件测试的历史二、软件测试发展历程任务二

了解软件测试的历史1983年，比尔.黑则尔（BillHetzel）提出:“测试是以评价一个程序或系统属性为目标的任何一种活动，测试是对软件质量的度量。”与此同时，电气和电子工程师协会(IEEE)对软件测试的定义是“使用人工或自动的手段来运行或测量软件系统的过程，目的是检验软件系统是否满足前期需求分析的规定，并找出与预期结果之间的差异。”二、软件测试发展历程任务二

了解软件测试的历史任务三

了解软件测试的发展现状、前景及从业要求进入21世纪后，软件测试理论和技术进一步发展，软件测试与软件开发由相对独立逐渐开始出现既独立又融合的特性。开发人员承担部分软件测试的责任，同时，测试人员也将更多参与测试代码的开发工作，软件开发与测试的边界十分清晰，但过程又融为一体。以敏捷开发模式为代表的新一代软件开发模式，产生和融入了软件开发的新思想、新模式、新策略。一、软件测试的发展现状任务三

了解软件测试的发展现状、前景及从业要求出现了针对软件模型分类的测试技术，具体分为故障模型、并发故障模型、不良习惯模型、诱骗代码模型等。在开展基于模型的测试时，首先要确定软件模型，然后通过检测算法进行检测，若检测算法结果符合质量要求，则能排除该类模型。基于模型的软件测试工具能够自动检测软件中的故障，并且善于发现前期测试并没有发现的一些软件故障及隐患二、软件测试的前景任务三

了解软件测试的发展现状、前景及从业要求软件测试团队一般采用如图所示的组织结构，往往一个测试组长或测试经理带领几个测试工程师，一个小型的软件测试团队在5人左右，可根据工作内容及团队技术规划配备自动化测试、性能测试等不同技术方向的测试工程师。三、软件测试团队架构任务三

了解软件测试的发展现状、前景及从业要求1.测试组长测试组长隶属于测试部门，由测试主管指派，有些公司称测试组长为测试经理。接收到一个项目测试需求后，测试主管会根据项目实际情况，如项目技术要求、业务要求，指派合适的测试工程师担当测试组长角色，由其负责该项目的所有测试工作。2.测试设计人员测试设计人员一般由高级测试工程师担当，负责项目测试方法设计，测试用例设计，性能测试步骤、流程、脚本、场景设计等。很多公司将该角色与测试工程师重叠，不严格区分测试设计人员与测试工程师角色。三、软件测试团队架构任务三

了解软件测试的发展现状、前景及从业要求3.测试工程师测试工程师的实际工作内容大多数是执行测试用例，进行系统功能测试，经过多次版本迭代，完成系统测试。一般由初级测试工程师、中级测试工程师担当。4.自动化或性能测试工程师一个测试小组一般配备一个自动化或性能测试工程师，以便开展自动化测试或性能测试。三、软件测试团队架构任务三

了解软件测试的发展现状、前景及从业要求四、软件测试工程师岗位要求任务三

了解软件测试的发展现状、前景及从业要求1.技术技能需求（1）岗位基础要求（2）软件测试相关技术（3）相关软件开发知识（4）行业知识2.职业素质（1）责任心（2）沟通能力（3）团队合作精神（4）耐心、细心、信心（5）良好的文档编写能力四、软件测试工程师岗位要求任务三

了解软件测试的发展现状、前景及从业要求任务四

走进软件测试1.发现被测对象与用户需求之间的差异，即软件缺陷。2.寻找并解决缺陷，提高客户的使用体验。3.帮助开发工程师找到开发过程中存在的问题，包括软件开发模式、工具与技术方面的不足，预防下次缺陷的产生。由于软件测试的目标是暴露程序中的错误，即使从心理学角度看，由程序的编写者自己进行测试也是不恰当的。在综合测试阶段通常由专门的测试人员组成测试小组来完成测试工作。此外，我们应认识到100%没有缺陷的软件是不存在的，即使经过了最严格的测试后，仍然会有缺陷隐藏在程序中。一、软件测试目的任务四

走进软件测试二、软件缺陷概述任务四

走进软件测试软件缺陷（Defect），常常又被叫做Bug。Bug一词的原意是“臭虫”或“虫子”，为何我们管软件缺陷叫做Bug呢？二、软件缺陷概述任务四

走进软件测试“马克二型”计算机世界上第一个计算机BugGraceHopper

二、软件缺陷概述任务四

走进软件测试Therac-25是加拿大原子能有限公司所生产的一种辐射治疗的机器。由于其软件设计时有瑕疵，致命的超剂量设定导致在1985年6月到1987年1月之间的六件已知的医疗事故中，出现患者死亡或严重辐射灼伤。二、软件缺陷概述任务四

走进软件测试软件缺陷，又称做Bug，是计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。二、软件缺陷概述任务四

走进软件测试1.软件没有实现产品规格说明所要求的功能模块；2.软件出现了产品规格说明指明不应该出现的错误；3.软件实现了产品规格说明没有提到的功能模块；4.软件没有实现虽然产品规格说明没有明确提及但应该实现的目标；5.软件难以理解，不容易使用，运行缓慢，或从测试员的角度看，最终用户会认为不好的模块。二、软件缺陷概述任务四

走进软件测试缺陷标识：缺陷标识是标记某个缺陷的一组符号，每个缺陷必须有一个唯一的标识；缺陷类型：缺陷类型是根据缺陷的自然属性划分的缺陷种类；二、软件缺陷概述任务四

走进软件测试3.缺陷严重程度：缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度；二、软件缺陷概述任务四

走进软件测试4.缺陷优先级：缺陷的优先级指缺陷必须修复的紧急程度；二、软件缺陷概述任务四

走进软件测试5.缺陷状态：缺陷状态指缺陷通过一个跟踪修复过程的进展情况；二、软件缺陷概述任务四

走进软件测试6.缺陷来源：缺陷来源指引起缺陷的起因。任务四

认识软件研发模型与软件测试模型一、软件研发模型任务五

认识软件研发模型与软件测试模型软件研发模型是软件生产过程中分析、设计、研发活动所遵循的框架模式。一个常见的软件研发活动包括需求分析、概要设计、详细设计、编码、集成联调等多个环节。一、软件研发模型任务五

认识软件研发模型与软件测试模型1.瀑布模型一、软件研发模型任务五

认识软件研发模型与软件测试模型优点：瀑布模型为整个项目划分了清晰的检查点，当一个阶段完成之后，只需要把全部精力放在后面的开发上即可。这有利于大型软件开发人员的组织管理及工具的使用与研究，可以提高开发的效率。缺点：瀑布模型是按照线性方式进行的，无法适应用户的需求变更，用户只能等到最后才能看到开发成果，这增加了开发风险。一、软件研发模型任务五

认识软件研发模型与软件测试模型2.

原型模型一、软件研发模型任务五

认识软件研发模型与软件测试模型优点：与瀑布模型相比，快速原型模型规避了需求不明确带来的风险，适用于不能预先确定需求的软件项目。缺点：快速原型模型的关键在于快速构建软件原型，但准确地设计出软件原型存在一定的难度，此外，这种开发模型也不利于开发人员对产品进行扩展。一、软件研发模型任务五

认识软件研发模型与软件测试模型3.

螺旋模型一、软件研发模型任务五

认识软件研发模型与软件测试模型优点：螺旋模型融合了瀑布模型和快速原型模型，它最大的特点是引入了其他模型所忽略的风险分析。如果项目不能排除重大风险，就停止项目从而减小损失，这种模型比较适用于开发复杂的大型软件。缺点：螺旋模型开发周期较长，有时会跟不上软件技术的发展，可能出现软件按开发完毕后，和当前的技术水平有较大的差距，无法满足当前用户需求的情况。一、软件研发模型任务五

认识软件研发模型与软件测试模型4.

RUP模型一、软件研发模型任务五

认识软件研发模型与软件测试模型优点：RUP模型是迭代式开发，通过不断迭代细化对问题的理解，降低项目开发风险，提高软件开发效率。而RUP模型独立的、可替换的、模块化的组件体系结构方便管理，便于复用。缺点：该开发模型比较复杂，因此在模型的运用掌握上需花费较大成本，并对项目管理提出较高的要求。一、软件研发模型任务五

认识软件研发模型与软件测试模型5.

敏捷模型一、软件研发模型任务五

认识软件研发模型与软件测试模型优点：敏捷开发的高适应性，凸显了以人为本的特性，能够更加灵活并且充分利用每个开发者的优势，调动每位开发者的工作热情。缺点：但是由于项目周期很长，如果中途更换开发人员，没有文档资料造成交接困难。二、软件测试模型任务五

认识软件研发模型与软件测试模型类比于软件开发模型，软件测试也有过程模型。软件测试过程模型是对测试过程的一种抽象，用于定义软件测试的流程和方法，指的是软件测试和开发阶段的对应关系，它可以被用来指导整个软件测试过程。二、软件测试模型任务五

认识软件研发模型与软件测试模型1.V模型二、软件测试模型任务五

认识软件研发模型与软件测试模型优点：将复杂的测试工作分成了目标明确的小阶段完成，具有阶段性、顺序性和依赖性，它既包含了对于源代码的底层测试也包含了对于软件需求的高层测试。缺点：只能在编码之后才能开始测试，早期的需求分析等前期工作没有涵盖其中，因此它不能发现需求分析等早期的错误，这为后期的系统测试、验收测试埋下了隐患，仅仅适合中小项目的测试。二、软件测试模型任务五

认识软件研发模型与软件测试模型2.

W模型二、软件测试模型任务五

认识软件研发模型与软件测试模型优点：测试范围不仅包括程序，还包括需求分析、软件设计等前期工作，这样有利于尽早全面的发现问题。缺点：它将软件开发过程分成需求、设计、编码、集成等一系列的串行活动，无法支持迭代、自发性等需要变更调整的项目。二、软件测试模型任务五

认识软件研发模型与软件测试模型3.

H模型测试准备测试开始测试执行测试流程概要设计流程二、软件测试模型任务五

认识软件研发模型与软件测试模型1.测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行。2.可以充分体现测试过程。3.软件测试不只是测试的执行，还包括很多其他的活动（计划、需求分析、用例设计、环境搭建、提交缺陷、评估总结等）。 4.尽早准备，尽早执行，具有很强的灵活性。5.软件测试可以根据被测物的不同而分层次进行。6.不同的测试活动可以是按照某个次序先后进行的，但也可能是反复的，只要某个测试达到准备就绪点,测试执行活动就可以开展。二、软件测试模型任务五

认识软件研发模型与软件测试模型4.

X模型X模型的设计原理是将程序分成多个片段反复迭代测试，然后将多个片段集成再进行迭代测试。二、软件测试模型任务五

认识软件研发模型与软件测试模型优点：对单独程序片段进行的相互分离的编码和测试，保证了测试效果。增加了探索测试，可以帮助测试人员发现计划之外的软件错误。缺点：频繁的集成会增加测试成本；探索测试对测试人员要求更高。二、软件测试模型任务五

认识软件研发模型与软件测试模型5.

敏捷模型

敏捷测试工程师需要关注需求变更、产品设计、源代码设计。通常情况下需要全程参与敏捷开发团队的团队讨论评审活动，并参与决策制定等。在独立完成测试设计、测试执行、测试分析输出的同时，关注用户、有效沟通，协助敏捷流程推动产品的快速开发。三、软件测试与软件开发的关系任务五

认识软件研发模型与软件测试模型

软件开发与软件测试都是软件项目中非常重要的组成部分。软件开发是生产制造软件产品，软件测试是检验软件产品是否合格，两者密切合作才能保证软件产品的质量。软件开发过程是一个自上向下、逐步细化的过程，在开发阶段，使用某种程序语言实现软件设计，随后进入集成、确认及系统测试阶段。而软件的测试过程则是自下而上、逐步集成的过程，低一级测试为上一级测试的准备条件。在软件测试过程中，最先产生的错误可能发现的最晚，例如如需求分析时产生的错误要到验收测试时才能被发现。软件测试与软件开发过程的关系如图所示。谢谢观看！项目二：软件测试基本概念了解软件生命周期的概念掌握常用的软件测试分类方法了解软件测试的基本流程掌握软件测试用例的组成了解软件测试项目的基本特性了解软件测试行业的现状与前景任务一认知软件生命周期任务二掌握软件测试的分类任务三

认识软件测试流程任务四

设计软件测试用例任务五理解软件测试原则任务一认知软件生命周期

软件是一系列按照特定顺序组织的计算机数据和指令的集合。一般认为，软件包括如下内容：1.运行时，能够提供所要求功能和性能的指令或计算机程序集合。2.程序能够满意地处理信息的数据结构。3.描述程序功能需求以及程序如何操作和使用所要求的文档。任务一认知软件生命周期软件的定义软件=程序+数据+

文档软件的定义任务一认知软件生命周期软件的复杂性软件的一致性软件的可变性软件的不可变性1）具有抽象性2）无明显的制造过程3）存在退化问题4）对计算机系统有着不同程度的依赖性5）尚未完全摆脱人工的开发方式6）软件本身是复杂的7）成本相当昂贵8）相当多的软件工作涉及社会因素软件的特性任务一认知软件生命周期•

交付的许多功能不是客户需要的•

交付的日期没有保障•

客户使用时发现许多Bug客户不满意风险与成本问题项目过程 无力管理失控 团队•

开发团队专注技术，忽视风险•

无能力预测成本，导致预算超支•

客户需求变化频繁，无力应对•

无法预见软件的交付质量•

对流程盲目遵从，忽视客户业务价值•

无法评估开发人员能力及工作进度•

困扰于如何提升团队的能力与效率软件设计的过程面临着多重风险软件的特性任务一认知软件生命周期系统软件为计算机使用提供最基本的功能，但是并不针对某一特定应用领域。应用软件则恰好相反，不同的应用软件根据用户和所服务的领域提供不同的功能。按照功能分类系统软件应用软件软件的分类任务一认知软件生命周期按照许可方式分类01专属软件02共享软件03自由软件04免费软件05公共软件软件的分类任务一认知软件生命周期软件的分类任务一认知软件生命周期任务二

掌握软件测试的分类

目前，软件测试领域有许多测试名称，这些名称来自不同的分类原则。按测试阶段或开发阶段划分

按测试执行方式划分

按是否查看代码划分

按是否手工执行划分

按照测试项目（对象）划分按照测试地域划分任务二掌握软件测试的分类软件测试的分类标准

按测试阶段或开发阶段划分按测试阶段或测试步骤划分，软件测试分为单元测试、集成测试、系统测试和验收测试。

按测试执行方式划分按测试执行方式划分，软件测试分为静态测试和动态测试。软件测试的分类标准任务二掌握软件测试的分类

按是否查看代码划分

按是否查看代码划分，软件测试分为黑盒测试、白盒测试和灰盒测试。相对于黑盒测试来说，白盒测试对测试人员的要求会更高一点，它要求测试人员具有一定的编程能力，而且要熟悉各种脚本语言。但是在企业中，黑盒测试与白盒测试并不是界限分明的，在测试一款软件时往往将黑盒测试与白盒测试相结合对软件进行完整、全面的测试。灰盒测试虽然没有白盒测试详细、完整，但是比黑盒测试更关注程序的内部逻辑，能够用于黑盒测试以提高测试的效率。软件测试的分类标准任务二掌握软件测试的分类(1)黑盒测试黑盒测试又叫功能测试、数据驱动测试、基于需求规格说明书的功能测试，它把软件当作一个有输入与输出的“黑匣子”，只要输入的数据能输出预期的结果即可，不必关心程序内部是怎样实现的，注重于测试软件的功能性需求。

软件测试的分类标准任务二掌握软件测试的分类(2)白盒测试白盒测试又叫透明盒测试、结构测试、逻辑驱动测试或基于代码的测试，它是指测试人员了解软件程序的逻辑结构、路径和运行过程，测试时按照程序的执行路径得出结果。白盒测试把软件（程序）当作透明的“盒子”，测试人员清楚知道输入到输出的每个过程。

软件测试的分类标准任务二掌握软件测试的分类(3)灰盒测试灰盒测试是介于黑盒测试与白盒测试之间的一种软件测试方法，它由方法和工具组成，这些方法和工具取决于应用程序内部交互的环境。灰盒测试通常用于集成测试阶段，测试人员在使用灰盒测试方法时，不仅需要关注输入、输出的正确性，而且需要关注程序内部的情况，通常根据一些现象、事件、标志来判断内部的运行状态。

软件测试的分类标准任务二掌握软件测试的分类手工测试是测试人员编写与执行测试用例的过程。手工测试比较耗时、费力，而且测试人员如果在疲惫状态下，很难保证测试的效果。手工测试自动化测试自动化测试是指借助脚本、自动化测试工具等完成相应测试工作，它也需要人工的参与，但是它可以将要执行的测试代码或流程写成脚本，通过执行脚本完成整个测试工作。

按是否手工执行划分软件测试的分类标准任务二掌握软件测试的分类按照测试项目划分，软件测试分为以下几类：（1）功能测试：主要针对软件/产品需求规格说明的测试，验证功能是否符合需求，如检验原定功能、是否有冗余的功能等。（2）健壮性测试：侧重于软件容错能力的测试，主要是验证软件对各种异常情况（如数据边界、非法数据、异常中断等）是否进行正确处理。（3）恢复测试：对每一类导致恢复或重构的情况进行测试，验证软件自身运行的恢复或重构、软件控制系统的恢复或重构，以及系统控制软件的恢复或重构。任务二掌握软件测试的分类（4）人机界面测试：对人机界面提供的操作进行测试，测试人机界面的有效性、便捷性、直观性等，如人机界面是否友好、是否方便易用、设计是否合理、位置是否准确等。（5）接口测试：测试被测对象与其他软件（包括软件单元、部件、配置项）或硬件的接口。（6）可用性测试：对“用户友好性”的测试。可用性测试受主观因素影响，且取决于最终用户。用户面谈、调查和其他技术都可在该测试中使用。任务二掌握软件测试的分类（7）性能测试：测试软件是否达到需求规格说明中规定的各类性能指标，并满足相关的约束和限制条件。（8）兼容测试：测试软件在一个特定的硬件、软件、操作系统或网络等环境下的性能如何。（9）安全性测试：测试软件在没有授权的内部或者外部用户攻击、恶意破坏时如何进行处理，是否能保证软件和数据的安全。任务二掌握软件测试的分类（10）可靠性测试：这里指的是比较狭义的可靠性测试，它主要是对系统能否稳定运行进行估计。（11）安装测试：安装测试主要检验软件是否可以正确安装、安装文件的各项设置是否有效、安装后是否影响原系统、卸载后是否删除干净和是否影响原系统。（12）文档测试：测试开发过程中生成的文档，以需求规格说明、软件设计、用户手册、安装手册等为主，检验文档是否与实际存在差别。文档测试不需要编写测试用例。任务二掌握软件测试的分类1.功能测试主要针对软件/产品需求规格说明的测试，验证功能是否符合需求，如检验原定功能、是否有冗余的功能等。Cookies测试表单测试链接测试设计语言测试数据库测试功能测试任务二掌握软件测试的分类常见的软件测试分类2.性能测试测试软件是否达到需求规格说明中规定的各类性能指标，并满足相关的约束和限制条件。连接速度测试负载测试压力测试任务二掌握软件测试的分类常见的软件测试分类3.兼容测试测试软件在一个特定的硬件、软件、操作系统或网络等环境下的性能如何。0102平台测试在各种操作系统下对Web系统进行兼容性测试。浏览器测试创建一个兼容性矩阵。在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。常见的软件测试分类任务二掌握软件测试的分类4.用户体验测试对人机界面提供的操作进行测试，测试人机界面的有效性、便捷性、直观性等，如人机界面是否友好、是否方便易用、设计是否合理、位置是否准确等。内容测试导航测试用户体验图形测试安全测试整体界面测试常见的软件测试分类任务二掌握软件测试的分类“纸杯测试”用于考察面试者对软件测试的理解和掌握程度。测试项目：纸杯。需求测试：查看纸杯说明书是否完整。界面测试：观察纸杯的外观，例如表面是否光滑。功能测试：用纸杯装水，观察是否漏水。安全测试：纸杯是否有病毒或细菌。可靠性测试：从不同高度扔下来，观察纸杯的损坏程度。易用性测试：用纸杯盛放开水，检查纸杯是否烫手、纸杯是否易滑、是否方便饮用。兼容性测试：用纸杯分别盛放水、酒精、饮料、汽油等，观察是否有渗漏现象。常见的软件测试分类任务二掌握软件测试的分类可移植性测试：将纸杯放在温度、湿度等不同环境中，查看是否还能正常使用。可维护性：将纸杯揉捏变形，看其是否能恢复。压力测试：用一根针扎在纸杯上，不断增加力量，记录用多大力时能穿透纸杯。疲劳测试：用纸杯分别盛放水、汽油，放置24小时，观察渗漏情况（时间和程度）。跌落测试：让纸杯（加包装）从高处落下，记录可使其破损的高度。震动测试：将纸杯（加包装）震动，评估是否能应对恶劣环境下的各种运输。用户文档：使用手册是否对纸杯的用法、使用条件、限制条件等进行了详细描述。说明书测试：查看纸杯说明书的正确性、准确性和完整性。常见的软件测试分类任务二掌握软件测试的分类软件测试的这些类别之间有着密切的关系

（1）在软件开发过程中，不同阶段的测试对应了对不同软件对象的测试软件测试的步骤和对象常见的软件测试分类任务二掌握软件测试的分类（2）在不同的测试阶段，由于测试目标、对象、要求的不同而采用不同的测试技术。常见的软件测试分类任务二掌握软件测试的分类（3）在不同的测试阶段对不同对象的测试包含不同的测试项目。例:确认测试可包含功能测试、性能测试、人机界面测试；组合测试可包括接口测试；系统测试可包括可靠性测试、强度测试等。常见的软件测试分类任务二掌握软件测试的分类还有一些软件测试无法具体归到哪一类，但在测试行业中也会经常进行这些测试，例如α测试、β测试、回归测试、随机测试等。

α测试α测试是指对软件最初版本进行测试。测试人员记录软件最初版本在使用过程中出现的错误和问题，整个测试过程是可控的。β测试随机测试β测试是指对上线之后的软件版本进行测试，由用户在使用过程中发现错误和问题并进行记录，然后反馈给开发人员进行修复。确认原有的缺陷已经消除并且没有引入新的缺陷，这个重新测试的过程称为回归测试。随机测试是没有测试用例、检查列表、脚本或指令的测试，它主要根据测试人员的经验对软件进行功能和性能抽查。回归测试常见的软件测试分类任务二掌握软件测试的分类

任务三认识软件测试流程不同类型的软件产品测试的方式和重点不一样，测试流程也会不一样。同样类型的软件产品，不同公司所制定的测试流程也会不一样。虽然不同软件的详细测试步骤不同，但所遵循最基本的测试流程是一样的。

展开需求评审设计测试计划进行测试设计编写测试用例开展测试执行任务三认识软件测试流程软件测试的步骤在需求评审开始之前，产品经理一般需要将产品需求文档、原型及UI设计图提前发给各个团队，以便预留出熟悉及理解需求的时间。产品部门组织召开需求评审会议，以产品需求文档、原型设计、UI为输出条件，测试团队对需求文档存在异议、需求不完整、不清晰的地方提出问题，相关人员进行解答。1.展开需求评审软件测试的步骤任务三认识软件测试流程2.

制定测试计划测试工作贯穿于整个软件生命周期，需要制定一个完整且详细的测试计划作为指导。

软件版本某APP8.0版本模块发布内容负责人测试组长测试人员测试员1、测试员2测试时间测试用例001~008回归测试软件测试的步骤任务三认识软件测试流程确定测试范围：明确哪些对象是需要测试的，哪些对象是不需要测试的。制定测试策略：将要测试的内容划分出不同的优先级，以确定测试重点，并根据测试模块的特点和测试类型（如功能测试、性能测试）选定测试环境和测试方法（如人工测试、自动化测试）。安排测试资源：通过考虑测试难度、时间、工作量等因素，对测试资源进行合理安排，包括人员分配、工具配置等。安排测试进度：根据软件开发计划、产品的整体计划来安排测试工作的进度，同时还要考虑各部分工作的变化。预估测试风险：罗列出可能会出现的不确定因素，并制定应对策略。 2.

制定测试计划软件测试的步骤任务三认识软件测试流程一个常见的测试计划包含以下内容：1、目标描述通过系统测试计划活动需要达到的目标，主要包括以下几点：所有测试需求都已被标识出来；测试的工作量已被正确估计并合理地分配了人力、物力资源；测试的进度安排是基于工作量估计的、适用的；测试启动、停止的准则已被标识；测试输出的工作产品是已标识的、受控的和适用的。软件测试的步骤任务三认识软件测试流程2、总体概述2.1项目背景简要描述项目背景、项目的主要功能特征、体系结构及项目的简要历史等。2.2适用范围指明该系统测试计划适用于哪些对象和哪些范围软件测试的步骤任务三认识软件测试流程3、测试计划3.1测试资源需求列出项目测试过程中所需的软件/硬件/其他资源，需列出每项资源的名称、版本及数量列出项目测试过程中所需的人力资源，如自动化测试工程师、性能测试工程师、接口测试工程师等，列出具体数量及期望到位时间、工作时长资源描述数量软件测试的步骤任务三认识软件测试流程3.2组织形式列出项目团队组织形式，并说明不同职位职责3.3测试对象列出项目测试对象，例如是运行系统，还是代码，还是文档3.4测试通过/失败标准列出测试通过或失败标准，如：达到100％需求覆盖；所有1级、2级用例被执行，3级、4级用例执行率达到60％；测试过程中缺陷率达到公司系统测试质量标准软件测试的步骤任务三认识软件测试流程3.5测试挂起/恢复条件列出项目测试挂起/恢复条件，如：基本功能测试不能通过；出现致命问题导致30％用例被堵塞，测试无法执行下去3.6测试任务安排指明执行该任务时，应采用的方法、所应遵循的标准、必需的输入及输出。软件测试的步骤任务三认识软件测试流程3.进行测试设计测试方案功能、性能、自动化测试测试环境搭建测试数据准备测试工具使用优先级当测试计划和需求规格说明书完成评审后即开始设计测试方案。软件测试的步骤任务三认识软件测试流程序号检查项检查结果说明1是否覆盖了用户提出的所有需求项是【】否【】NA【】

2用词是否准确、语义是否存在歧义是【】否【】NA【】

3是否清楚地描述了软件需要做什么以及不做什么是【】否【】NA【】

4是否描述了软件的目标环境，包括软硬件环境是【】否【】NA【】

5是否对需求项进行了合理的编号是【】否【】NA【】

6需求项是否前后一致、彼此不冲突是【】否【】NA【】

7是否清楚地说明了软件的每个输入、输出格式，以及输入与输出之间的对应关系是【】否【】NA【】

8是否清晰地描述了软件系统的性能要求是【】否【】NA【】

9需求的优先级是否进行了合理分配是【】否【】NA【】

10是否描述了各种约束条件是【】否【】NA【】

软件测试的步骤任务三认识软件测试流程4.

编写测试用例测试用例（TestCase）是指一套详细的测试方案，包括测试环境、测试步骤、测试数据和预期结果。不同的公司会有不同的测试用例模板，虽然它们在风格和样式上有所不同，但本质上是一样的，都包括测试用例的基本要素。测试用例编写的原则是尽量用最少的测试用例达到最大测试覆盖率。测试用例常用的设计方法包括等价类划分法、边界值分析法、因果图与决策表法、正交实验设计法、逻辑覆盖法等。软件测试的步骤任务三认识软件测试流程5.

开展测试执行执行测试是按照测试用例执行测试的过程，这是测试人员最主要的活动阶段。在执行测试时要根据测试用例的优先级进行。测试执行过程看似简单，只要按照测试用例完成测试工作即可，但实则并不如此。测试用例的数目非常多，测试人员需要完成所有测试用例的执行，每一个测试用例都可能会发现很多缺陷，测试人员要做好测试记录与跟踪，衡量缺陷的质量并编写缺陷报告。

软件测试的步骤任务三认识软件测试流程测试报告是对一个测试活动的总结，包括对项目测试过程进行归纳，对测试数据进行统计，对项目的测试质量进行客观评价。测试报告的数据必须是真实的，每一条结论的得出都要有评价依据，不能是主观臆断的。 编写软件测试报告任务三认识软件测试流程引言：描述测试报告编写目的、专业术语解释和参考资料等。测试概要：介绍项目背景、测试时间、测试地点及测试人员等信息。测试内容及执行情况：描述本次测试模块的版本、测试类型，使用的测试用例设计方法及测试通过覆盖率，依据测试的通过情况提供对测试执行过程的评估结论，并给出测试执行活动的改进建议，以供后续测试执行活动借鉴。缺陷统计与分析：统计缺陷数目、类型等，分析缺陷产生的原因，给出规避措施等建议，同时还要记录残留缺陷和未解决问题。测试结论与建议：从需求符合度、功能正确性、性能指标等多个维度对版本质量进行总体评价，给出具体、明确的结论与建议。一份完整的测试报告任务三认识软件测试流程测试报告可以按照如下目录编写。一、引言1.目的2.术语解释3.参考资料二、测试概要1.项目简介2.测试环境3.测试时间、地点及人员三、测试内容及执行情况1.测试目标2.测试范围3.测试用例使用情况4.回归测试四、缺陷统计与分析1.缺陷数目与类型2.缺陷的解决情况3.缺陷的趋势分析五、测试分析1.测试覆盖率分析2.需求符合度分析3.功能正确性分析4.产品质量分析5.测试局限性六、测试总结1.遗留问题2.测试经验总结七、附件1.测试用例清单2.缺陷清单3.交付的测试工作产品4.遗留问题报告任务三认识软件测试流程任务四设计软件测试用例测试作为贯穿整个软件开发过程的活动，需要有一份完善且周详的测试计划作为指导。测试计划是整个测试过程的路由图，在需求活动一开始时，相关人员就需要着手进行测试计划的编写，形成一份完整、详细的测试文档。测试计划主要的任务就是确定测试策略，它定义了项目的测试目标和实现方法。计划准备检查修改继续任务四设计软件测试用例

测试计划所要达到的目标：（1）为测试各项活动制订一个现实可行的、综合的计划，内容包括每项测试活动的对象、范围、方法、进度和预期结果。（2）为项目实施建立一个组织模型，并定义测试项目中每个角色的责任和内容。（3）开发有效的测试模型，能正确地验证正在开发的软件系统。（4）确定测试所需要的时间和资源，以保证其可获得性和有效性。（5）确立每个测试阶段测试完成及测试成功的标准和要实现的目标。（6）识别出测试活动中的各种风险，并消除可能存在的风险，降低由不可能消除的风险所带来的损失。任务四设计软件测试用例测试强度很大程度上取决于使用哪种测试工具，需要达到哪一个级别的测试覆盖率，涉及源代码的测试覆盖率常用作测试出口准则之一。保证软件的最重要部分优先级最高，最先被测试，以免由于时间上的限制而无法执行已经计划好的测试。测试计划完成后，测试过程就进入了测试用例的设计和测试脚本的开发阶段。测试用例的规格说明分为两步进行：定义逻辑测试用例选择实际输入，将逻辑测试用例转换成具体测试用例任务四设计软件测试用例用例设计考虑因素设计测试用例首先要考虑以下几个问题：为什么要设计测试用例？谁来写测试用例？这些写测试用例的人的测试技术如何？以及对被测试产品了解有多深入？测试用例写给谁看，多少人将使用测试用例文档？分配给编写测试用例的时间是多长？要安排几个人来写？怎么在测试用例的成本、质量和效率方面达到平衡？任务四设计软件测试用例测试用例的管理测试用例设计必须考虑有效：容易发现并呈现错误；测试用例设计必须覆盖全面又不冗余：数量上不应有重复的、多余的用例，对软件规格说明书和设计功能点有全面的覆盖，不仅包括功能测试用例，还包括性能测试用例，外场测试、易用性等测试用例；测试用例设计必须明确粒度和测试分类的程度：粒度越细，测试成本就越高，测试周期就越长；分类越多，测试成本相应增加，测试周期就越长；测试用例设计完成后必须经过评审：以帮助进一步补充用例，提高测试覆盖率，提高用例质量。任务四设计软件测试用例测试用例的管理设计测试用例时应遵循以下原则（1）正确性。满足需求规格说明书的要求；覆盖需求规格说明书中的各项功能。（2）代表性。覆盖所有的需求功能项。（3）可复用性。由于软件开发过程中需求变更等原因的影响，常常需要对测试用例进行修改、增加、删除等。随着测试用例的不断精化，测试效率需要不断提高。（4）可评估性。检验程序代码质量的保证。（5）可管理性。作为检验测试进度、测试工作量及测试人员效率的因素。任务四设计软件测试用例对于测试执行工程师来说，测试用例的内容应包括以下几个方面：测试用例的测试目标；测试用例的被测功能点描述；测试用例的测试运行环境；测试用例的执行方法（包括测试步骤，输入测试数据或测试脚本）；测试期望的结果；执行测试的实际结果；其他辅助说明。任务四设计软件测试用例一个优秀的测试用例应该包含以下要素：用例的编号（ID）

测试输入说明测试标题操作步骤测试项预期结果测试环境要求测试用例之间的关联特殊要求测试用例设计和测试人员测试技术测试日期任务四设计软件测试用例测试用例的管理每个测试用例都必须描述其初始状况，即前置条件：测试用例要清楚定义需要什么样的环境条件，以及必须满足的其他条件，此外，还需要提前定义期望得到哪些结果和行为。结果包括输出、全局化数据和状态的变更，以及执行测试用例后的其他任何结果。任务四设计软件测试用例测试用例的管理测试阶段测试类型执行人员单元测试模块功能测试，包含部分接口测试、路径测试开发人员集成测试接口测试、路径测试，含部分功能测试开发人员，如果测试人员水平较高可以由测试人员执行系统测试功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/反安装测试测试人员验收测试对于实际项目基本同上，并包含文档测试；对于软件产品主要测试相关技术文档测试人员，可能包含用户任务四设计软件测试用例测试用例的管理搭建测试环境之后，根据定义的顺序，即可逐个执行测试用例。测试用例执行中应该注意以下几个问题：（1）全方位地观察测试用例执行结果（2）加强测试过程记录（3）及时确认发现的问题（4）与开发人员良好沟通（5）及时更新测试用例（6）提交一份优秀的问题报告单（7）测试结果分析

完成测试实施后，需要对测试结果进行评估，并且编制测试报告。任务四设计软件测试用例测试用例的管理开发阶段依据文档编写的用例需求分析结束后需求文档系统测试对应的用例概要设计阶段结束后概要设计、体系设计集成测试对应的用例详细设计阶段详细设计文档单元测试对应的用例

与软件本身的生命周期一样，测试用例也需经过—“设计”、“评审”、“修改”、“执行”、“版本管理”、“发布”、“维护”等一系列阶段。任务四设计软件测试用例测试用例的管理1.等价划分法实际软件测试活动中，保证被测对象测试充分性的最好方法即是使用穷举法完全覆盖、完全组合。等价类划分依据用户需求规格说明书，细分用户期望，设计用例。等价类即是某个测试对象的输入域集合，在此集合中，单个个体对于揭露被测对象缺陷的效用是等价的。可根据被测对象用户需求的实际情况，做出合理的推断归纳，将输入域划分为若干等价类，并在每个等价类集合中选择一个个体作为测试输入，利用少量的测试输入取得较好的测试效果，在测试效率与效果间达到平衡。功能测试常用的方法任务四设计软件测试用例

有效等价类

无效等价类针对被测对象需求规格说明而言，有意义、有效的测试输入集合。针对被测对象需求规格说明而言，无意义、无效的测试输入集合。0102功能测试常用的方法任务四设计软件测试用例根据被测对象的需求规格说明书，通常可从以下几个层面考虑等价类划分。（1）若规定取值范围或值个数时，可以设立一个有效等价类和两个无效等价类。例：字符长度在6～18位，两个无效等价类可以是1～5和>18位的姓名长度。（2）若规定输入值的集合或者规定了必须遵循某个规则时，可确立一个有效等价类和一个无效等价类。（3）若输入条件是一个布尔值（即真假值），可确定一个有效等价类和一个无效等价类。（4）若规定输入数据是一组值，并且程序要对每一个输入值分别处理，则可确立若干有效等价类和一个无效等价类。例：会员管理有普通会员、金牌会员、铜牌会员、钻石会员等，不同会员的积分规则、优惠策略不同，设计用例时可划为若干等价类分别考虑。（5）若规定输入数据必须遵守某些规则，则可确立一个符合规则的有效等价类和若干从不同角度违反规则的无效等价类。功能测试常用的方法任务四设计软件测试用例在设计有效用例过程中，需注意有效等价类之间的互斥性，不能将所有有效等价类设计为一条用例，否则将会出现规则错误，导致测试覆盖降低、漏测。等价类设计法可用于功能测试、性能测试、兼容性测试、安全性测试等方面。一般带有输入性需求的被测对象都可以采用等价类设计法，但等价类设计法是以效率换取效果的，考虑得越细致，设计的用例可能就越多，同时，输入与输入之间的约束考虑较少，可能产生一些逻辑错误，不同的思考角度可能会导致不同的用例设计角度及产生的用例数量。在实际使用过程中，需根据测试的投入确定测试风险及优先级，从而保证该方法的使用效果。功能测试常用的方法任务四设计软件测试用例边界值属于等价类方法特定的输入域，包含在有效等价类或无效等价类中，根据等价类推断理论，边界值方法产生的测试效果与等价类方法相同，只是边界值方法选择测试数据时更有针对性，通常选择输入域的边界值。如用户名长度限制在6～18位，测试工程师构造有效用户名长度时可选择6和18，对于长度大于18的无效等价类，可构造长度为19的用户名，如果该用户名无法完成注册，那么长度大于19以后的测试数据也将不符合条件。当需求规格说明书中规定了输入域的取值个数、范围或者明确了一个有序集合时，即可使用边界值方法。2.边界划分法功能测试常用的方法任务四设计软件测试用例边界值设计法是对等价类设计法的必要补充，在实际使用过程中，基本上是等价类的后续步骤，因此设计用例的方法类似。参考等价类设计法中等价类划分方法，确定了有效等价类及无效等价类后，分析每个输入域的上点、离点、内点，填入表格。测试项等价类名上点编号离点编号内点编号功能测试常用的方法任务四设计软件测试用例在等价类设计法中，详细考虑了需求输入域但是对于输入域及输入域存在关联时无法覆盖，因此需要一种能考虑输入域相互关系的用例设计方法来考虑业务描述性的测试需求。等价类设计法在特定需求下存在着不足：例：若用户欠费或停机，则不允许主被叫。此时用户欠费或停机作为一个布尔类型等价类，欠费或停机作为有效等价类，未欠费或未停机作为无效等价类考虑，使用等价类设计法设计用例如表所示。测试项有效等价类编号无效等价类编号欠费欠费A01未欠费B01停机停机A02未停机B02功能测试常用的方法任务四设计软件测试用例提取测试用例如下：有效用例：无效用例：上述3条测试用例无法测试B01B02用户未欠费、未停机的情况，因为按照等价类设计法思想，B01B02两个无效等价类不能组合。A01A02：用户欠费且停机，不允许主被叫；B01:用户未欠费但停机，不允许主被叫；B02:用户欠费但未停机，不允许主被叫任务四设计软件测试用例功能测试常用的方法判定表是分析和表达若干输入条件下，被测对象根据输入做出不同响应的工具。在遇到复杂业务逻辑关系和多种条件组合情况时，利用判定表可将需求或逻辑关系表达得既具体又明确。判定表通常包含：条件桩：需求规格定义被测对象的所有输入。条件项：针对条件桩所可能输入的真假值。动作桩：针对条件被测对象可能采取的所有操作。动作项：针对动作桩，被测对象响应的可能结果取值。条件桩条件项1条件项2动作桩动作项3.判定表法功能测试常用的方法任务四设计软件测试用例案例：用户欠费或停机，则不允许主被叫。欠费：1表示真，欠费，0表示假，未欠费。停机：1表示真，停机，0表示假，未停机。主被叫：1表示真，允许主被叫，0表示假，不允许主被叫

1234条件桩欠费1100停机1010动作桩主被叫0001判定表用例示例一功能测试常用的方法任务四设计软件测试用例因果图又称鱼骨图，是由日本管理大师石川馨先生所发展出来的，故又名石川图。在软件测试用例设计过程中，用于描述被测对象输入与输入、输入与输出之间的约束关系。因果图的绘制过程，为用例设计者针对因果关系业务的建模过程。根据需求规格，绘制因果图，然后得到判定表进行用例设计，通常理解因果图为判定表的前置过程，当被测对象因果关系较为简单时，可直接使用判定表设计用例，不然可使用因果图与判定表结合的方法设计用例。4.因果图法功能测试常用的方法任务四设计软件测试用例状态迁移设计法是关注被测对象的状态变化，在需求规格说明中是否有不可达的状态和非法的状态，是否可能产生非法的状态迁移等。对于被测对象而言，如果根据需求规格抽象出它的若干状态以及这些状态之间的迁移条件和迁移路径，那么可以从其状态迁移路径覆盖的角度来设计用例。状态迁移设计法的目标是设计足够多的用例，以覆盖被测对象的所有状态。使用状态迁移设计法时，首先需提取被测对象需求规格说明中定义的状态，利用有向箭头标识在某些输入条件下状态间的迁移关系，根据广度优先及深度优先法则抽取测试用例规则，最后细化测试用例。5.状态迁移法功能测试常用的方法任务四设计软件测试用例案例：飞机售票系统（1）客户向航空公司打电话预定机票，此时机票信息处于“预订”状态。（2）顾客支付了机票费用后，机票信息变为“已支付”状态。（3）旅行当天到达机场，拿到机票后，机票信息变为“已出票”状态。（4）登机检票后，机票信息变为“已使用”状态。（5）在登机检票之前任何时间都可以取消自己的订票信息，如果已经支付了机票的费用，则还可以退款，取消后，订票信息处于“已取消”状态。功能测试常用的方法任务四设计软件测试用例分析上述需求，可以得到该被测对象一共有预订、已支付、已出票、已使用、已取消这5种状态。绘制状态迁移图如图所示。

飞机售票系统状态迁移图功能测试常用的方法任务四设计软件测试用例根据状态迁移树，抽取测试路径，每个叶子节点构成一条路径，则可抽取4条路径。4条路径分别构成4条测试规则，需注意的是，仅仅是构成4条规则，针对每个节点的功能仍需通过等价类及边界值进行功能验证，状态迁移设计法不保证单个功能点的正确性，仅保证状态间的转换是否与需求描述一致。路径1：预订—已取消路径2：预订—已支付—已取消路径3：预订—已支付—已出票—已取消路径4：预订—已支付—已出票—已使用功能测试常用的方法任务四设计软件测试用例现在的软件几乎都是用事件触发来控制业务流程的，事件触发时的情景形成场景，而同一事件不同的触发顺序和处理结果形成事件流。针对场景业务流，通常可分为基本流、备选流及异常流3种业务流向。基本流表示输入经过每一个正确的流程运转最终达到预期结果备选流表示输入经过每一个流程运转时可能产生异常情况，但经过纠正后仍能达到预期结果，异常流表示输入经过每一个流程运转时，产生异常终止的现象。基本流和备选流，通常作为业务流程测试过程中优先级较高的测试分支，应详细设计定义。异常流作为可靠性健壮性用例亦需同步考虑。6.场景法功能测试常用的方法任务四设计软件测试用例基本流从流程开始直至流程结束，中间无任何异常分支，往往表述一个正向的业务流程，也是优先级较高的流程。备选流尽管在流程流转过程中出现了异常，但仍能回到基本流主线，如备选流程1及备选流程2，最终仍能回归基本流，直至流程结束，异常流，如异常流程1及异常流程2，在基本流或备选流基础上出现了异常，并最终异常结束业务流程。

场景分析设计法流程示意图功能测试常用的方法任务四设计软件测试用例正交实验方法，是研究多因子（因素）多水平（状态）的一种试验设计方法。它是根据试验数据的正交性从全面试验数据中挑选出部分有代表性的点进行试验，这些点具备了“均匀分散，齐整可比”的特点，正交试验设计是一种基于正交表的、高效率、快速、经济的试验设计方法。通常把所有参与试验、影响试验结果的条件称为因子，影响试验因子的取值或输入称为因子的水平。正交试验方法与传统的测试用例设计方法相比，利用数学理论大大减少了测试组合的数量，保证每个实验因子及其取值都能参与实验，减少了人为测试习惯导致覆盖率低及冗余测试用例的风险。7.正交实验法功能测试常用的方法任务四设计软件测试用例

在测试程序时，人们可以根据经验或直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的测试用例的方法。8.错误推测法功能测试常用的方法任务四设计软件测试用例白盒测试中经常使用的一个覆盖测试方法，要求对被测代码的每条语句都覆盖。所谓的语句，一般指除了注释、空行外的代码。语句覆盖是白盒测试所有方法覆盖性最弱的一种覆盖测试方法。if(a>1&&b==0)x=x/a;if(a==2||x>1)x=x1;

程序流程图1.语句覆盖白盒测试常用的方法任务四设计软件测试用例被测程序中如果包含判定，通常为if语句，则需将该条件的真假取值都覆盖到。两个if语句，各自去真假值，则有4个分支需覆盖。若以路径划分，则可分为（p1、p2、p4），（p1、p3、p5），（p1、p2、p5）及（p1、p3、p4）。判定覆盖，则需覆盖FFTT或FTTF，即为（p1、p2、p4），（p1、p3、p5）或者（p1、p2、p5），（p1、p3、p4）。根据上述分析，可设计两条测试用例达到100%判定覆盖。Case1：A=1，B=0，X=1，覆盖（p1、p2、p4）Case2：A=2，B=0，X=3，覆盖（p1、p3、p5）2.判定覆盖任务四设计软件测试用例白盒测试常用的方法与判定覆盖不同的是，条件覆盖虽然也关注的是if语句，但条件覆盖考察的是判定中每个条件的真假覆盖情况，要求针对于判定中每个条件的真假都覆盖到。例：被测对象共有两个判定，每个判定中有两个条件，每个条件取真假值，因此共有8个值需覆盖。条件取值a>1T1F1b=0T2F2a=2T3F3x>1T4F4条件覆盖取值表if(a>1&&b==0)x=x/a;if(a==2||x>1)x=x1;3.条件覆盖白盒测试常用的方法任务四设计软件测试用例根据上表分析，设计以下用例即可达到100%条件覆盖：从上述用例可以看出，虽然走了相同的路径，但在条件覆盖上是不同的，每个条件的真假值都被覆盖了。Case1：a=1，b=0，x=3，覆盖p1、p2、p5路径，覆盖条件取值为F1T2F3T4；Case2：a=2，b=1，x=1，覆盖p1、p2、p5路径，覆盖条件取值为T1F2T3F4；白盒测试常用的方法任务四设计软件测试用例判定条件覆盖，则是判定覆盖与条件覆盖的迭代，即被测对象的所有判定及条件所取的真假值至少被覆盖一次。上述用例达到了100%判定条件覆盖，但从路径角度而言，遗漏了p1、p3、p4，仍然存在漏测风险。Case1：a=2，b=0，x=3，覆盖路径p1、p3、p5，覆盖判定及条件取值为：T1T2T3T4Case2：a=2，b=1，x=1，覆盖路径p1、p2、p5，覆盖判定及条件取值为：T1F2T3F4Case3：a=1，b=0，x=3