软件测试管理与实践PPT完整全套教学课件

软件测试管理与实践ch01-认识软件测试管理ch01-认识软件测试管理.pptxch02-软件测试流程.pptxch03-软件测试需求分析.pptxch04-软件测试计划.pptxch05-软件测试用例设计和管理.pptxch06-软件测试缺陷管理.pptxch07-1-测试执行管理.pptxch07-2-测试报告和总结.pptxch08-测试组织管理.pptxch09-1-软件配置管理.pptxch09-2-软件质量保证.pptxch09-3-评审.pptxch10-ALM工具.pptx全套PPT课件理解软件质量的含义、软件测试与软件质量的关系了解软件项目管理与软件测试管理的交互理解软件测试管理的要素了解软件测试管理工具的种类、基本功能以及选择依据学习目标软件质量与软件质量模型项目管理与软件测试管理软件测试管理工具及其选择软件质量与软件质量模型1软件质量的概念软件质量越来越受到重视ANSI/IEEEStd729-1983《软件工程术语的IEEE标准术语表》(Glossaryofsoftwareengineeringterminology)定义软件质量为：“与软件产品满足规定的和隐含的需求的能力有关的特征或特性的全体”软件质量模型软件产品各种质量特性的组合称为软件质量模型。常见的软件质量模型：Boehm模型(1976年)MCCALL模型(1978年)ISO9126软件质量模型(1993年)Boehm质量模型1976年由Boehm等提出的分层方案将软件的质量定义为分层的模型MCCALL质量模型1979年由McCall等人提出的软件质量模型将软件质量的概念建立在11个质量特性之上这些质量特性分别是面向软件产品的运行、修正和转移的ISO9126质量模型软件质量模型可以分为：内部质量和外部质量模型、使用质量模型质量模型中又将内部和外部质量分成六个质量特性将使用质量分成四个质量属性常见的软件质量特性编号属性名属性含义1性能(Performance)系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件个数2可用性(Availability)系统能够正常运行的时间比例3可靠性(Reliability)系统在应用或者错误面前，在意外或者错误使用的情况下维持软件系统功能特性的能力4健壮性(Robustness)在处理或者环境中系统能够承受的压力或者变更能力5安全性(Security)系统向合法用户提供服务的同时能够阻止非授权用户使用企图或者拒绝服务的能力常见的软件质量特性编号属性名属性含义6可修改性(Modification)能够快速地以较高的性能价格比对系统进行变更的能力7可变性(Changeability)体系结构扩充或者变更成为新体系结构的能力8易用性(Usability)衡量用户使用软件产品完成指定任务的难易程度9可测试性(Testability)软件发现故障并隔离定位其故障的能力特性，以及在一定的时间或者成本前提下进行测试设计、测试执行能力；10功能性(Functionability)系统所能完成的期望工作能力11互操作性(Inter-Operation)系统与外界或系统与系统之间的相互作用能力软件质量保证的手段软件质量保证的手段有：软件测试软件研发过程保证软件研发配置管理……软件测试VS软件质量软件测试是保证软件质量的重要手段之一软件测试是有计划有组织的活动软件测试管理确保测试活动的顺利开展项目管理与软件测试管理2项目及项目管理项目：一系列复杂的并相互关联的活动有着一个明确的目标必须在特定的时间、预算、资源限定内，依据规范完成项目管理：在项目活动中运用专门的知识、技能、工具和方法，使项目能够在有限资源限定条件下，实现设定的需求和期望的过程。范畴：范围管理、时间管理、费用管理、质量管理、人力资源管理、风险管理、沟通管理、采购与合同管理……软件测试管理

VS软件项目管理软件测试管理是特殊的软件项目管理与软件项目管理密切相关，有时从属于软件项目管理的一部分可以借用软件项目管理的方法因任务特点有自身特殊的知识、流程、方法、工具软件测试管理的要素过程工具人软件测试管理的要素测试过程和资产管理测试团队管理测试需求管理测试计划管理(测试规划)测试用例管理(测试设计)测试缺陷管理测试工具选择和使用测试执行和汇报管理资产计划缺陷报告软件测试管理的要素测试过程与测试资产管理建立并维护测试的过程建立并维护测试过程中建立的指南、模板、评审单等管理测试工作相关的资产软件测试管理的要素测试需求管理收集需求分析需求测试需求跟踪测试计划管理制订计划执行计划监控计划软件测试管理的要素测试用例管理组织编写测试用例评审测试用例维护分析测试用例测试执行管理测试执行的启动测试执行任务管理测试执行监控和汇报软件测试管理的要素测试缺陷管理报告测试缺陷回归测试发现的缺陷缺陷分析软件测试管理的要素测试工具管理选择测试工具维护测试工具测试团队管理建立并维护测试团队团队日常管理团队绩效考核……软件测试管理工具3软件测试工具软件测试工具分类自动化测试工具：单元测试工具、性能测试工具、动能测试工具……软件测试管理工具：ALM、

BUGzilla……软件测试管理工具的基本功能用户及权限管理测试项目的创建测试项目需求管理测试任务分配和实施测试项目缺陷管理测试数据收集测试项目数据分析统计和报告生成测试项目用例管理测试执行管理测试文档管理软件测试管理工具的分类专项测试管理工具这类工具是管理软件测试中的某个内容，如缺陷管理工具、用例管理工具。比如BUGzilla和BUGfree。专门测测试管理工具这类工具对测试的整个流程进行管理，比如IBMRationalQualityManager、HPALM(ApplicationLifecycleManagement)等。包含开发和测试的项目管理工具：如果开发和测试属于同一个团队，此时研发团队会使用覆盖整个研发周期的软件产品，这些产品或者是有公司自己开发的或者是市场购买的也可能是开源的软件。比如，禅道项目管理软件是一款国产开源项目管理软件。其他小型项目团队、初创业的团队、学生课程设计团队往往直接利用Office办公软件完成软件测试的管理，包括OfficeProject、Word、Excel。对于软件测试中的文档管理则可以借助于一些文件管理软件，比如TortoiseSVN、Tortoisehg。软件测试管理工具的选择在进行测试管理工具的选择时，要综合考虑，项目大小、团队规模、团队性质、成本预算等因素，工具是一个载体，重要的是按照流程开展工作。对于新创业项目、学生项目等团队规模比较小的情况可以选择开源工具或Office办公软件，节省成本简单易用；对于第三方测试团队则可以选用专门测试工具；对于研发测试一体化的团队则可以采用完整的项目管理工具。软件测试管理工具的发展趋势与其他软件自动化测试工具集成，比如在软件测试用例的管理中，用例可能是Loadrunner的性能测试脚本，也可能是QTP的功能测试脚本，也可能是需要手工测试的用例。目前的测试管理工具倾向于能通过工具直接启动测试用例的执行，这就要求测试管理工具要与Loadrunner、QTP等自动化测试工具有很好的衔接。与软件研发的其他环节集成越来越紧密，比如软件测试管理工具中集成版本管理功能。基于云计算的测试管理工具，比如QASymphony开发的QTest是基于云计算的测试管理工具,有各种典型的关键特性。QTest在连接器的帮助下,它可以集成JIRA整个端到端质量的解决方案,它还集成了其他工具,比如BUGzilla、FogBUGz,Rally等。公司常用测试管理工具统计软件测试管理工具-禅道http:///禅道由青岛易软天创网络科技有限公司开发，国产开源项目管理软件。它集产品管理、项目管理、质量管理、文档管理、组织管理和事务管理于一体，是一款专业的研发项目管理软件，完整覆盖了研发项目管理的核心流程。禅道管理思想注重实效，功能完备丰富，操作简洁高效，界面美观大方，搜索功能强大，统计报表丰富多样，软件架构合理，扩展灵活，有完善的API可以调用。禅道，专注研发项目管理！软件测试管理工具-禅道演示版界面软件质量是软件满足需求的能力常见的软件质量模型：V模型、W模型、H模型软件测试是保证软件质量的重要手段之一软件测试管理是软件项目管理的一种软件测试管理的要素：需求、计划、用例、缺陷、总结、工具、团队…测试工具分类：专项测试管理、全流程测试管理、项目管理典型的软件测试工具小结完成项目实践作业一谢谢观看软件测试管理与实践ch02-软件测试流程36理解研发过程和测试过程的交互过程。理解典型的软件测试模型。理解软件测试的一般流程。了解建立一个测试流程应该包含的内容。了解测试中涉及的文档资产以及度量分析。学习目标3738软件研发中的测试软件测试模型软件测试流程测试流程的建立和维护测试流程涉及的资产企业测试流程样例软件研发中的测试139软件测试与软件研发软件测试和软件开发一样，都遵循软件工程的原理测试和开发是密切相关的测试活动是贯穿于软件项目开发的全过程的，和开发活动交互开展。软件研发中的测试环节与测试活动1.软件需求完成后，需要进行需求的评审，此时测试人员可以参与需求的评审，当需求确定后，测试人员可以开始进行系统测试方案以及计划的制订。研发中的测试活动：软件需求评审2.软件项目总体设计方案完成后，测试人员可以开始进行集成测试方案以及计划的制订。3.详细设计完成后，测试方可以开始进行模块测试方案以及计划的制订。研发中的测试活动：测试方案制订4.单元测试和编码一般是同步的，由开发人员自己完成的。5.整个模块开发完成后，测试人员开始进行模块测试，当然在这之前，所有的模块测试用例已经准备完毕。6.模块测试后是集成测试和系统测试。研发中的测试活动：测试执行7.软件运行维护期间则要对运行期间发现的问题进行回归测试。研发中的测试活动：回归测试常见软件测试模型246软件测试和软件开发一样，都遵循软件工程原理。测试与开发密切相关，通过实践产生了许多测试模型。这些模型将测试活动进行了抽象，明确了测试与开发之间的关系，是测试管理的重要参考依据。软件测试模型47V模型W模型H模型X模型(不成熟)常见的软件测试模型发展自软件开发的瀑布模型，说明了基本的开发过程和测试行为。明确地标识了测试过程中存在的不同级别以及测试阶段和开发过程各阶段的关系局限性：测试对象只有程序代码测试作为编码后的活动，没有体现”尽早测试”的原则。软件测试模型1-V模型49从V模型演化而来在V模型中增加与软件各开发阶段同步进行的测试。强调：测试伴随着整个软件开发周期测试的对象不仅仅是程序，需求、功能和设计同样要测试。测试与开发是同步进行的，从而有利于尽早地发现问题。局限性：W模型和V模型都把软件的开发视为需求、设计、编码等一系列串行的活动，无法支持迭代以及变更调整。软件测试模型2-W模型50强调：测试活动独立，贯穿于整个产品周期，与研发流程并发。循环：测试点准备就绪就可以开始执行测试。测试可以尽早进行，可以对被测对象分层次、反复测试。局限性模型要能指导实际工作，H模型本身并无太多的可执行的指导意义。软件测试模型3-H模型51软件测试的流程352测试过程定义了企业在产品开发过程中在设计、开发与实现、维护、退出等阶段与测试相关活动的内容、流程以及规范。测试过程指导项目如何开展各项测试活动，以及各项活动的输入与输出；约定活动中所涉及的角色与职责，规范各个活动的内容和规程，以及所使用到的统一的模板、表单、指导书和检查单。测试流程内容定义测试过程的目的是给本公司在产品开发过程中测试相关的活动提供指导，确保产品可以真正满足用户的要求。测试流程的作用软件项目中测试和开发是相互配合同步推进的，为软件项目的复杂性被测对象往往不断发生变化，实际项目中测试与开发的关系更加复杂，虽然复杂，测试工作的开展是有自己的过程要遵循的。

虽然在一个项目的研发过程中，有很多种不同的测试类型，不同的测试阶段，但是对单次测试来说，存在一个一般性的过程。测试的一般过程软件测试一般性过程561.需求分析阶段收集相关资料，学习业务(测试对象)，分析测试需求点。2.测试计划阶段测试主管组织编写《测试计划》，该文档指明测试范围、方法、资源以及相应测试活动人员时间进度安排。测试计划需要进行评审，测试计划一旦开始执行，就要定期监控计划的执行情况。3.测试设计及开发测试设计一般由对需求熟悉的资深的测试工程师设计，为每个需求点设计出包括需求点简介，测试思路和详细测试方法三部分的方案。测试开发主要完成对测试用例编写、测试数据准备、测试环境准备。测试设计和测试用例完成后需要进行评审。软件测试一般性过程574.测试执行及报告执行测试用例，及时提交有质量的Bug和测试阶段报告反馈测试情况。5.软件评估报告及批准根据测试结果给出对软件的整体评估，以及是否通过测试的建议。一般决策部门会根据这份评估报告决定产品是否可以发布。6.测试总结及资产归档结项阶段对整个过程进行回顾总结，将项目相关资源进行整理归档。软件测试一般性过程58软件测试流程的建立和维护459从实际情况出发，优化流程，解决问题重点考虑四个问题哪些测试要做谁做什么时间做如何做创建软件测试流程注意事项60对当前存在的问题进行收集、诊断分析根据实际情况建立新的流程流程发布和试运行促进流程的执行，收集问题流程更新和发布创建测试流程步骤测试执行是按照测试计划去执行测试活动测试过程执行是严格按照测试的过程去开展测试活动。测试执行VS测试过程执行需要注意的是，测试过程创建后并不是一成不变的，要根据实际实践情况不断改进和完善，进行修订后要及时进行过程发布。测试流程并不是静止的一般在测试过程执行中要设置一定的机制，去保证测试人员有按照测试过程开展测试活动。促进测试的执行QA人员对项目的监督和指导组织级审计促进测试过程的执行64测试流程在每一轮执行完毕之后，根据执行情况对流程进行更新和完善。用好的实践去更新完善流程测试流程的改进软件测试流程涉及的资产566测试计划文档测试方案文档测试用例测试报告测试缺陷库其他新开发或引入的测试工具测试工作会议记录测试计划、测试方案、测试用例的评审报告测试总结测试原始数据以及度量数据测试日志：每天测试日程记录。周期性测试报告任务报告：任务完成情况报告。测试过程中涉及的文档等资产67描述为完成软件特性的测试而采用的测试方法的细节。其主要内容：概述被测对象应测试的特性不被测试的特性测试模型测试需求测试设计测试方案文档68测试用例表描述测试用例测试项目用例编号用例级别：测试用例重要程度。用例可用性输入值预期输出实测结果特殊环境需求[可选]特殊测试步骤[可选]…测试用例文档69描述测试结果的文档主要内容：概述测试时间、地点、人员。测试环境测试结果统计分析测试评估测试总结与改进测试缺陷列表测试报告文档70描述测试缺陷主要内容：缺陷简述缺陷描述缺陷级别缺陷分析与对策测试缺陷71企业测试流程样例672某企业测试过程实例-概览73某企业测试过程实例-测试过程描述74某企业测试过程实例-活动流程定义75某企业测试过程实例-测试相关的文档模板76理解研发过程和测试过程的交互过程。理解典型的软件测试模型。理解软件测试的一般流程。了解建立一个测试流程应该包含的内容。了解测试中涉及的文档资产以及度量分析。小结77完成项目实践作业二谢谢观看79软件测试管理与实践ch03-软件测试需求分析80了解不同层次的软件需求。理解测试需求的重要性以及测试需求分析的步骤。掌握测试类型分析的方法。掌握测试需求的表达方式。能够根据理论开展软件项目测试需求的分析。学习目标8182软件需求和软件测试需求测试需求分析知识准备测试需求分析的步骤软件需求和软件测试需求18384认识软件需求85业务需求组织或客户的高层次目标描述为什么要开发系统(Why)，希望达到什么样的目标一般2-5条，记录在《软件愿景和范围》文档中用户需求从用户角度，描述用户使用产品必须要完成什么任务用户能使用系统来做什么(What)通过用户访谈、调查、对用户使用场景进行整理等方法获取功能需求描述开发人员在产品中实现的软件功能描述开发人员如何设计具体的解决方案来实现这些需求(how)数量往往比用户需求高一个数量级属于《软件需求规格说明书》的一部分认识软件需求-需求的三个层次86功能需求用户需求系统需求：用于描述包含多个子系统的产品(即系统)的顶级需求，它是从系统实现的角度描述的需求，有时还需要考虑相关的硬件、环境方面的需求。业务规则：业务规划本身并非软件需求，因为它们不属于任何特定软件系统的范围。然而，业务规则常常会限制谁能够执行某些特定用例，或者规定系统为符合相关规则必须实现某些特定功能。它包括企业方针、政府条例、工业标准、会计准则和计算方法等。有时，功能中特定的质量属性（通过功能实现）也源于业务规则。所以，对某些功能需求进行追溯时，会发现其来源正是一条特定的业务规则。非功能需求质量属性：产品必须具备的属性或品质。系统的质量属性包括可用性、可修改、性能、安全性、可测试行、易用性等。约束：也称为限制条件、补充规约，通常是对解决方案的一些约束说明。外部接口认识软件需求-软件需求规格说明书87测试需求与软件需求密切相关。测试需求分析的主要输入是软件需求规格说明书。测试需求是解决“测什么”的问题，是整个测试项目的基础，是制定测试计划、开发测试用例的依据。测试需求必须是可以核实的，它们必须有一个可观察、可评测的结果。测试需求88明确测试范围功能点明确功能处理过程单功能点业务场景组合测试需求分析的目标测试需求分析只是准备28990软件测试是一项系统性工程，从不同的角度考虑可以有不同的划分方法，了解各种不同的测试分类，能更好地理解测试、开展测试。了解软件测试分类91常见软件测试分类921.根据测试阶段进行划分依据软件测试流程中各个阶段要开展的测试来划分，包括单元测试、模块测试、集成测试、系统测试、验收测试等。2.根据是否执行被测对象进行划分按照是否需要执行被测软件的角度可分为静态测试和动态测试。静态测试不运行被测软件，比如需求文档评审、设计文档评审、代码走查等。动态测试则通过运行被测试软件开展测试。3.根据是否使用工具划分根据测试是手工执行的还是工具执行的可以分为手工测试和自动化测试，一般情况下性能测试用自动化测试方式。软件测试分类934.根据测试技术划分根据测试技术可以划分为黑盒测试、白盒测试和灰盒测试。白盒测试通过对程序内部结构的分析、检测来寻找问题。黑盒测试通过软件的外部表现来发现其缺陷和错误。灰盒测试是介于白盒测试和黑盒测试之间的测试，灰盒测试不仅关注输出、输入的正确性，同时也关注程序内部的情况。灰盒测试不像白盒测试那么详细、完整，但又比黑盒测试更关注程序的内部逻辑，常常是通过一些表征性的现象、事件、标志来判断内部的运行状态。5.根据测试类型划分测试类型是从不同的角度来分析和测试产品，测试类型概念很早就已经存在，比如：性能测试、安全性测试、功能测试、兼容性测试等等。软件测试分类94软件测试类型是从不同的角度有针对性地来分析和测试产品。软件测试执行阶段是由一系列不同的测试类型的执行过程组成的，每种测试类型都有其具体的测试目标和支持技术，每种测试类型都只侧重于对测试目标的一个或多个特征或属性进行测试，准确的测试类型可以给软件测试带事半功倍的效果。测试类型95常见的测试类型及其测试内容说明编号测试类型测试角度1功能性测试是对产品的各功能进行验证，根据功能需求逐项测试，检查产品是否达到用户要求的功能。2兼容性测试测试软件在特定的硬件平台上、不同的应用软件之间、不同的操作系统平台上、不同的网络等环境中是否能够正常的运行。3安全性测试针对未授权的访问，拒绝访问攻击等,一般包括程序、网络、数据库安全性测试。4接口测试测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。5数据库完整性测试该项测试内容主要是以数据库表为单位，检查数据库表以及表中各字段命名是否符合命名规范，表中字段是否完整，数据库表中的字段描述是否正确包括字段的类型、长度、是否为空，数据库表中的关系、索引、主键、约束是否正确。6用户界面测试即UI测试，测试用户界面的功能模块的布局是否合理，整体风格是否一致，各个控件的放置位置是否符合客户使用习惯，操作是否便捷，导航是否简单易懂，界面文字是否正确，命名是否统一，页面是否美观，文字、图片组合是否合适等等。除此之外，UI测试还要确保UI功能内部的对象符合预期要求，并遵循公司或行业的标准。96常见的测试类型及其测试内容说明编号测试类型测试角度7负载测试负载测试是通过改变系统负载方式、增加负载等来发现系统中所存在的性能问题。负载测试更多的是一种测试方法，而不是测试类型，可以为性能测试、压力测试所采用。负载测试的加载方式也有很多种，可以根据测试需要来选择。8性能测试性能测试是为获取或验证系统性能指标而进行测试。多数情况下，性能测试会在不同负载情况下进行。性能指标主要有：系统吞吐量、响应速度、cpu占用率、内存占用率等。9压力测试压力测试通常是在高负载情况下来对系统的稳定性进行测试，更有效地发现系统稳定性的隐患和系统在负载峰值的条件下功能隐患等。10疲劳强度测试通过长时间运行系统，测试系统的性能，发现性能问题。一般会测试系统的日常业务（正常情况）和高峰业务（最大业务量）情况下长时间运行系统的结果。11恢复性测试测试一个系统从灾难或出错中能否很好地恢复的过程，如遇到系统崩溃、硬件损坏或其他灾难性出错。可恢复测试一般是通过人为的各种强制性手段让软件或硬件出现故障，然后检测系统是否能正确的恢复(自动恢复和人工恢复)。12配置测试一般是针对硬件配置的测试，测试软件在最低配置和推荐配置情况下是否能够正常运行。97常见的测试类型及其测试内容说明编号测试类型测试角度13安装卸载测试确保软件在正常情况和异常情况的不同条件下，都能正确地完成安装和卸载。例如，进行首次安装、升级、完整的或自定义的安装。14用户文档测试软件文档是软件的一部分，要确保文档能够给用户提供正确的说明或指引，重点关注文档的正确性、完备性以及可理解性。交给用户的文档主要有：系统帮助、用户使用手册、用户安装手册、示例以及模板、图像声音帮助、用户许可协议等。15可用性测试(易用性测试)让一群具有代表性的用户对产品进行典型操作，同时观察员和开发人员在一旁观察，聆听，做记录。可用性有五个指标，分别是易学性、易记性、容错性、交互效率和用户满意度。16稳定性测试(可靠性测试)稳定性测试（亦可称可靠性测试）通过给系统加载一定的业务压力，让系统持续运行一段时间（一般为7x24小时），检测系统是否能够稳定运行。17内存泄漏测试内存泄漏是指用动态存储分配函数动态开辟的空间，在使用完毕后未释放，结果导致一直占据该内存单元，直到程序结束。内存泄漏测试就是测试有没有内存空间使用完毕之后未回收的情况，一般用专门的检测工具。18本地化测试也称为国际化测试，有些产品为了满足特定区域用户的需要有多个语言版本，比如简体中文、繁体中文、英文、日文等，本地化测试是针对特定目标区域性或区域设置的产品进行测试，在本地化的软硬件环境下测试界面、安装卸载等内容，也要关注产品目标地区的文化、宗教、喜好等适用性测试。98测试类型是指功能测试、性能测试、安全性测试等等实际实践：不同类型的测试会发现不同类型的Bug；测试类型是从不同的角度来分析和测试产品；不同产品对应的测试类型集合可能不同；不同测试类型的测试方法不同；不同测试阶段其测试类型不同一般做法：测试团队根据产品特点建立测试类型库如果没有自己的测试类型库可以参考质量特性与测试类型的对应关系表在测试类型分析中分析并列出测试需求项需要哪些类型的测试测试类型分析99附：质量子特性与测试类型的对应表100某单机产品系统测试阶段测试类型列表功能测试性能和压力测试兼容性测试可用性测试错误恢复和可靠性测试安全性测试用户文档测试安装部署测试版本配置项测试测试类型分析-举例1101某手机产品测试类型列表功能性测试一致性测试互操作测试安全性测试流控测试性能测试压力测试大容量测试长时间测试配置测试兼容测试安装测试备份测试恢复测试易用性测试Qos测试国际化测试测试类型分析-举例2测试需求分析步骤3102103测试需求分析的步骤104广泛、全面结合具体的产品背景、团队管理水平、测试阶段有针对性的收集1.原始测试需求收集注意事项105测试需求可能的来源用户需求系统开发需求产品愿景产品设计说明书；同类竞争产品及其说明书；旧产品及其说明书：如果是产品升级换代的情形相关的协议和规范：如果产品要符合某种规范则要将协议和规范包含在需求范围内，比如儿童手机对辐射度的规范要求。……原始测试需求可能的来源106产生原始需求来源表原始测试需求来源表来源编号原始需求来源文档名称备注1用户需求用户需求规格说明书_作业管理系统.doc

2开发需求系统需求规格说明书_作业管理系统.doc

107概要需求整理对被测对象有一个整体的把握满足短时间内给出测试计划的需要方便分配任务进行详细需求的整理举例2.原始需求概要整理108详细需求整理明确每个测试功能点对应的输入,处理和输出明确每一个测试需求的具体要求原始需求详细整理109测试需求项分析与旧版本关系分析与其他需求项关系分析测试类型分析需求项分析-测试需求项分析110项目型软件VS产品型软件被测试的新版本与以前版本之间的关系新增加的需求修改的需求修改了什么？以前的测试设计、用例和测试记录？是整个需求重新开发？还是在原来的基础上修改？需求项分析1-与旧版本关系分析111产品功能不是独立的，功能之间存在交互关系为了提高测试的完备性，要对需求与需求之间的关系进行分析。可以参考《软件需求跟踪矩阵》中需求与需求之间的关系(横向关系)时序关系(时间顺序关系)共享资源关系(共享数据和资源)需求项分析2-与其他需求项关系分析112测试类型是指功能测试、性能测试、安全性测试等等实际实践：不同类型的测试会发现不同类型的Bug；测试类型是从不同的角度来分析和测试产品；不同产品对应的测试类型集合可能不同；不同测试类型的测试方法不同；不同测试阶段其测试类型不同一般做法：测试团队根据产品特点建立测试类型库如果没有自己的测试类型库可以参考质量特性与测试类型的对应关系表在测试类型分析中分析并列出测试需求项需要哪些类型的测试需求项分析3-测试类型分析113附：质量子特性与测试类型的对应表114某单机产品系统测试阶段测试类型列表功能测试性能和压力测试兼容性测试可用性测试错误恢复和可靠性测试安全性测试用户文档测试安装部署测试版本配置项测试需求项分析3-测试类型分析-举例1115某手机产品测试类型列表功能性测试一致性测试互操作测试安全性测试流控测试性能测试压力测试大容量测试长时间测试配置测试兼容测试安装测试备份测试恢复测试易用性测试Qos测试国际化测试需求项分析3-测试类型分析-举例2116测试需求分析完成后，为了方便后续对测试需求的跟踪和维护需要建立测试需求跟踪矩阵。测试需求跟踪矩阵记录软件需求到测试需求的分解以及测试项到测试用例的分解。需求跟踪-建立软件测试需求跟踪矩阵117测试需求跟踪矩阵应该记录的主要内容软件需求到测试需求的分解测试需求项后续跟进测试需求向测试用例的分解需求跟踪-软件测试需求跟踪矩阵的内容下表是一个简单形式的测试需求跟踪矩阵实际项目中可以根据需要扩充测试需求的属性，比如测试需求的优先级、测试需求的测试类型等等。需求跟踪-需求跟踪表119测试需求跟踪矩阵需要不断的维护。一方面，软件需求一旦发生变化，应启动配置管理过程，将与软件需求变更相关的内容进行同步变更；另一方面，随着测试工作的进行，会不断添加新的跟踪内容，对跟踪表进行扩展。例如，测试设计阶段的测试用例、测试执行阶段的测试记录和测试缺陷都可以添加到跟踪矩阵中。需求跟踪-测试需求跟踪矩阵可能的变更原因了解不同层次的软件需求。理解测试需求的重要性以及测试需求分析的步骤。掌握测试类型分析的方法。掌握测试需求的表达方式。能够根据理论开展软件项目测试需求的分析。120小结完成项目实践作业三谢谢观看122软件测试管理与实践ch04-软件测试计划123了解测试计划的重要性。掌握测试计划的主要内容。了解组织编写测试计划的方法。了解测试计划的评审、执行和监控。能够根据理论开展项目测试计划的制订。学习目标124125什么是测试计划测试计划的内容和模板组织编写测试计划评审测试计划测试计划的执行和监控1什么是测试计划127《ANSI/IEEE软件测试文档标准829-1983》将测试计划定义为：“一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。它确认了测试项、被测特征、测试任务、人员安排，以及任何偶发事件的风险。”什么是测试计划128管理者能够根据测试计划做宏观调控，进行相应资源配置等测试人员能够了解整个项目测试情况，以及项目测试不同阶段的所要进行的工作便于其他人员了解测试人员的工作内容，进行有关配合工作为什么要制定测试计划129测试计划是在需求整理完成，和开发计划一起制定的一份计划书，它从属于项目计划中其中的一个计划。测试计划的制订是有粗略到详细的一个过程测试需求分析前总体测试计划书测试需求分析后详细测试计划书什么时候制定测试计划？130测试计划应该由项目测试负责人或测试组长，亦或具有丰富经验的测试人员来进行组织编写。中小型项目，测试负责人可以直接承担大型项目，测试负责人和子模块测试负责人共同完成测试计划由测试工程师来实施。谁负责制订测试计划？131开展软件测试计划的基础和依据(基本输入)：软件测试任务书（或合同）被测软件的需求规格说明书测试需求其他输入类似产品或同一产品旧版本的测试计划软件测试工作的输出:软件测试计划测试计划工作的输入和输出132测试计划的制订是有粗略到详细的一个过程。测试计划不是“编”出来的，是在充分了解测试需求的情况下，结合测试的原理和经验得出的。项目大小不同，项目测试计划的制订过程也不同。如果项目规模比较小，则测试计划直接有一个经验丰富的测试工程师负责即可；如果项目规模比较大，参加的测试人员多，则测试的需求分析和测试计划先是分模块展开，各个测试工程师完成自己负责部分的测试需求分析和测试计划，最后测试经理牵头组织大家一起完成整个项目的测试计划。如何组织制订测试计划2测试计划内容和编写模板不同标准和团队在制订测试计划时内容不尽相同，但是核心目录都大同小异企业在实际开展工作时会根据自己的业务需要定义符合产品和团队需求的内容测试计划的一般内容虽然不同团队的测试计划内容不尽相同，但是整体上都是从技术和管理两个方面对测试的开展进行规划：技术方面主要是明确开展什么样的测试、使用什么样的测试策略和方法、使用什么样的测试工具等内容。管理方面主要是明确如何组织、需要哪些人力和非人力资源、任务如何划分、进度如何定义、启动和结束的条件等内容。测试计划的一般内容136《IEEE软件测试文档标准829-2008》标准中软件测试计划文档的主要内容：测试计划主要内容-IEEE标准137测试计划主要内容-某企业138基本说明被测对象(产品名,版本号,终端用户等)术语与缩略语参考资料测试范围及策略功能性测试需求以及测试方法和途径非功能测试需求以及测试方法和途径测试优先级和重点实施的测试阶段测试计划主要内容1139测试环境和工具分析软件实际环境软件测试环境以及与实际环境差异分析测试非人力资源：计算机、工具等自动化测试分析(解决什么问题、成本、提高多少效率)测试数据测试计划主要内容2140测试的出入口、暂停标准测试开始标准测试中止标准测试完成标准测试人员要求技能和经验要求人力资源数量以及介入时间需要的支持和培训测试计划主要内容3141测试管理内外部角色和职责工作汇报要求缺陷管理测试执行管理测试用例管理变更管理测试计划主要内容4142任务划分以及进度计划里程碑任务分解及时间人员安排(可以用officeproject)风险和应急分析预测测试中的风险给出对各种风险的规避和应急措施测试计划主要内容5143不同产品类型使用的模板不尽相同举例软件测试计划模板-某企业软件测试计划模板-(GB8567-88)样例测试计划模板144软件测试计划模板-某企业测试计划模板举例-某企业145软件测试计划模板-(GB8567-88)测试计划模板举例-软件测试计划模板-(GB8567-88)146软件测试计划模板-(GB8567-88)测试计划模板举例-软件测试计划模板-(GB8567-88)组织编制测试计划3148组织编写测试计划的原则编写测试计划的主要任务难点5W1H方法注意事项组织编写测试计划149尽早开始灵活变更合理评审简洁易读编制测试计划的原则150根据测试策略，选定测试计划包含的测试范围划分测试阶段，明确测试方法，确定测试任务确定测试过程监控方法评估测试工作量确定时间并生成进度计划评估进度计划风险编制测试计划的主要任务151根据本阶段测试需求，细化测试任务划分任务优先级，说明和主要任务关联关系确定辅助任务清单（如培训等）形成WBS（工作任务分解图)或者任务分配列表测试任务分配的两种方式及优缺点：按照功能模块划分、按照测试类型划分按照功能模块划分是将同一个模块的功能测试、界面测试、相关的性能测试、兼容性测试等都分给同一个工程师负责；按照测试类型划分将所有性能测试分给一个工程师，兼容性测试分给另一个工程师；难点1：确定测试任务某项目WBS图某项目测试任务分配列表测试活动工作量评估计划开始日期计划结束日期负责人工作要点产出制定测试计划

设计测试

集成测试

系统测试

性能测试

安装测试

用户验收测试

对测试进行评估

……

154目前没有任何一种方法能准确的评估出软件测试工作的工作量，要想更有效的做出估算，必须持之以恒的统计和分析历史数据主要的估算方法为：分析以前的同类项目同行专家判断分解细化项目(如何把握分解的程度？)经验主义预估模型（LOC、FP等）难点2：评估测试工作量155收集与进度相关的信息：总体工作量估算人员数量关键资源项目时间安排等确定各阶段任务安排和资源分配，确定里程碑依据项目总体时间安排，形成进度计划难点3：确定时间进度计划156美国政治学家拉斯维尔提出“5W分析法”，后经过人们的不断运用和总结，逐步形成了一套成熟的“5W+IH”模式。5W+1H就是对工作进行科学地分析，就其工作内容（What）、责任者（Who）、工作岗位（Where）、工作时间（When）、怎样操作（How）以及为何这样做（Why），进行书面描述，并按此描述进行操作，达到完成职务任务的目标。借助5W1H分析法编制测试计划1157What(做什么)：测试范围和内容Why(为什么做)：测试目的When(何时做)：测试时间Where(在哪里)：测试地点、文档和软件位置Who(谁做)：测试人力资源How(怎么做)：测试方法和工具在测试需求分析阶段确定what和why在测试计划阶段确定when，where，who，how借助5W1H分析法编制测试计划1158借助5W1H分析法编制测试计划2159切合实际，根据项目特点、公司实际情况制订，确实能指导测试活动的开展根据实际情况不断变化调整，满足实际测试要求。从宏观上反映测试整体安排，避免过于详细。编制测试计划注意事项测试计划的评审4161测试计划作为测试活动的规划文档对测试工作的开展有重要指导意义测试计划编写完成后，一般要对测试计划的正确性、全面性以及可行性等进行评审评审人员的组成包括软件开发人员、测试人员、测试负责人以及其他有关项目负责人。可以参考：测试计划评审检查单测试计划的评审测试计划评审检查单与测试团队和被测试软件有很大关系，不同企业会根据自己实际情况制订不同的检查单并在实践过程中不断完善检查单。检查单列出的是团队关注的测试计划要点以及在制订测试计划时容易遗漏的内容。测试计划评审检查单163测试计划评审检查单样例测试计划的执行和监控5165根据实际情况，及时更新项目计划变更需求变更……测试计划需要及时更新166测试计划完成后要监督测试过程中计划的执行情况。在制订测试计划的同时，应该制订一个计划跟踪表或者进度表，在测试计划执行过程中定期对照执行情况是否符合预期测试计划的监控167定期跟踪，实际完成情况与计划对照，并提交报告分析实际执行与计划不一致的原因如果计划不合理，则及时调整否则，采取补救措施测试计划的监控168除了进度要关注风险变化情况测试计划的监控了解测试计划的重要性。掌握测试计划的主要内容。了解组织编写测试计划的方法。了解测试计划的评审、执行和监控。能够根据理论开展项目测试计划的制订。169小结完成项目实践作业四谢谢观看171软件测试管理与实践ch05-软件测试用例设计和管理172理解测试用例的概念。掌握测试用例的属性和设计方法。了解测试用例的评审和管理要点。能够根据理论组织编写并管理项目的测试用例。学习目标173174什么是测试用例测试用例的设计方法组织编写并评审测试用例测试用例的执行管理测试用例的统计分析测试用例管理工具什么是测试用例1176测试用例（TestCase）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。其本质是从测试角度对被测对象的功能和各种特性的细节展开。测试用例=输入(数据+步骤)+输出+执行条件(环境等)软件测试用例177输入：包括输入数据以及操作步骤。数据尽量模拟用户输入，操作步骤要清晰简洁。执行条件：指测试用例执行的特定环境和前提条件。预期结果(输出)：在指定的输入和执行条件下的预期结果。注意：预期结果并不只是程序的可见行为。测试用例的组成178测试用例举例测试用例实例测试用例编号测试项目测试标题重要级别预置条件输入执行步骤预期输出ZCGL-ST-SRS001-001登录功能测试登录界面文字正确性验证低登录页面正常显示打开登录页面打开登录页面界面显示文字和按钮文字显示正确179将软件测试活动进一步转化为可实施、可管理的行为跟踪测试需求，避免测试遗漏提升测试的复用率(不同人，同一项目，同类项目)测试用例的重要性测试用例的设计方法2测试方法有黑盒测试和白盒测试两大类，每类又有不同的测试用例设计方法。测试用例的设计方法黑盒测试被称为功能测试或数据驱动测试。在测试时，把被测程序视为一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下进行。黑盒测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表法等。黑盒测试等价类划分法：把所有可能的输入数据，即程序的输入域划分为若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例。边界值分析法：边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。因果图法：一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。黑盒测试用例设计方法(1-3)决策表(判定表)法：决策表法适用于分析和表达多逻辑条件下执行不同操作的情况，它能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。因此，利用决策表能够设计出完整的测试用例集合。错误推测法：基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。黑盒测试用例设计方法(4-5)白盒测试也称结构测试或逻辑驱动测试，是针对被测单元内部是如何进行工作的测试。它根据程序的控制结构设计测试用例，主要用于软件或程序验证。白盒测试又有静态测试和动态测试之分。白盒测试方法静态测试主要是指代码走查和分析。静态方法是指不运行被测程序本身，仅通过分析或检查项目的需求文档、设计文档、源程序的语法、结构、过程、接口等来检查程序的正确性。对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析来发现错误。静态方法通过程序静态特性的分析，找出欠缺和可疑之处，例如不匹配的参数、不适当的循环嵌套和分支嵌套等。静态测试动态测试主要是对代码的运行测试，包含多种覆盖方法：语句覆盖：要求设计足够多的测试用例，使得程序中每条语句至少被执行一次。判定覆盖(分支覆盖)：它要求设计足够多的测试用例，使得程序中每个判定至少有一次为真值，有一次为假值，即：程序中的每个分支至少执行一次。每个判断的取真、取假至少执行一次。条件覆盖：要求设计足够多的测试用例，使得判定中的每个条件获得各种可能的结果，即每个条件至少有一次为真值，有一次为假值。动态测试1判定/条件覆盖：设计足够多的测试用例，使得判定中每个条件的所有可能结果至少出现一次，每个判定本身所有可能结果也至少出现一次。组合覆盖：要求设计足够多的测试用例，使得每个判定中条件结果的所有可能组合至少出现一次。路径覆盖：设计足够的测试用例，覆盖程序中所有可能的路径。动态测试2189测试用例具有代表性测试结果具有可判定性测试过程具有可再现性测试用例具有有效性测试用例设计和生成原则3组织编写并评审测试用例测试用例的设计主要根据测试需求，设计出的测试用例要按照规范的模式描述出来。测试用例的设计和编写是测试过程中的重要工作之一根据测试需求编写测试用例测试用例编写编写测试用例，首先要明确测试用例的属性。测试用例的属性有很多，除了最基本的前提条件，测试环境，输入数据，执行步骤，预期结果之外，为了管理方便还包括测试用例的编号、标题、所测需求、执行方式等。不同工具测试用例的属性大同小异，每个团队要根据自己的实际需要确定要使用的测试用例属性。测试用例的属性193根据测试需求编写测试用例涉及测试用例步骤描述的详细程度测试用例的属性提供测试用例编写的模板组织编写测试用例194测试用例的属性编号属性属性描述1用例编号一般为需求编号后紧跟001，002……2标题(测试目的)对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。比如“测试用户登录时输入错误密码时，软件的响应情况”。3预置条件测试的前提条件，比如先用管理员登录。4测试环境测试的软件、硬件以及网络环境。5输入数据描述测试用例的输入数据6执行步骤测试用例的执行步骤7预期结果测试用例的预期结果8附件辅助附件文档，比如要输入的文档、图片等9对应的脚本[可选]测试执行时的脚本10优先级用例的优先级，一般核心功能或基础功能涉及的用例为高优先级11涉及到的需求用例能测试到的需求点12实施类型自动化、手工、半自动化13测试类型UI测试、功能测试、接口测试、性能测试、兼容性测试、文档测试等14参考信息需要参考的需求文档，相关标准等。15创建人测试用例的创建者16创建日期测试用例创建的日期17历史记录测试用例修改的历史记录备注其他说明根据实际情况进行增减测试用例样例1测试用例样例2测试用例的详略把握197在编写测试用例时会面临一个问题，测试用例步骤描述得详细程度要如何把握？理想的情况应该是测试用例详细记录所有的操作步骤，使一个没有接触过系统的人员也能执行该测试用例。测试用例描述的详略199描述过于详细：会大大增加测试用例的编写和维护时间，一旦测试环境、需求、设计或者实现发生了变化，测试用例都需要及时进行更新。过于简单：除了用例的编写者没有人能够看明白并执行。最终目的：只要能交代清楚，达到沟通的目的就可以了。测试用例的详细程度详细粗略200测试用例详细程度举例“作业管理系统”测试需求之作业提交功能：学生用户登录后，可以为自己的“等待提交”状态作业提交答案，提交答案时可以输入文本描述，可以上传附件，附件支持Word，Ppt，Excel，Txt，JPG，Png，Gif格式。

为该功能设计的一个测试用例可以描述得很详细也可以粗略描述.说明输入步骤输出详细描述文本描述.txt作业答案.doc输入用户名和密码,登录系统；单击左侧导航栏中“我的作业”按钮；选择一个状态为“等待提交”的作业，打开作业所在页面；单击”提交答案”按钮；输入答案文本描述；单击“添加附件”按钮，选择相应Word文档；单击“确定提交”按钮；弹出”作业答案已提交！”作业状态变为“等待批改”作业浏览可以看到提交的答案粗略描述文本描述.txt作业答案.doc选择并打开“等待提交”状态的作业提交作业答案，输入文本描述，并选择Word文件作为附件单击“提交”按钮同上201测试用例详细程度举例“作业管理系统”测试需求之作业提交功能：学生用户登录后，可以为自己的“等待提交”状态作业提交答案，提交答案时可以输入文本描述，可以上传附件，附件支持Word，Ppt，Excel，Txt，JPG，Png，Gif格式。

为该功能设计的一个测试用例可以描述得很详细也可以粗略描述.说明输入步骤输出过简描述文本描述.txt作业答案.doc选择一个作业,输入文本描述,选择答案附件,为作业提交答案.作业答案能够正确提交测试用例的编写模板202编写测试用例可以通过Excel、Word或者专门的测试管理软件测试流程中应该定义测试用例的编写模板以及测试用例编写指南如果团队没有专门的测试流程，则在测试计划中应该约定测试用例的编写模板以确保整个团队的测试用例格式统一。测试用例编写模板204测试用例编写模板1-ALM205测试用例编写模板2-某企业测试用例编写模板3XX系统测试用例用例编号测试模块标题重要级别预置条件输入执行步骤预期输出SRS01-001登录功能登录界面正确性验证低登录页面正常显示打开登录页面打开登录页面界面显示文字和按钮文字显示正确

测试用例的评审207测试用例设计完毕后，最好能够增加评审环节。参与人：需求人员、测试人员、开发人员可能发现：错误、遗漏、冗余、不充分测试用例评审可以参考：《测试用例评审检查单》评审并不容易开展测试用例数量比较多，内容比较细致，评审起来要花费的时间也比较多，以及对评审的重视不够往往不能达到预期的效果只评审核心模块测试用例、将评审时间加入工作计划中只评审测试要点加强测试用例的评审测试用例评审检查单测试用例的组织维护211组织方式应该方便跟踪、分配和管理：按照功能模块组织将属于某模块的功能测试用例、性能测试用例、兼容性测试用例等一起编号、管理。按照测试类型组织将所有功能模块的性能测试、兼容性测试分别编号、管理。实际项目中也可以依靠对测试用例的编号去管理测试用例的管理测试用例完成后不是一成不变，不是一劳永逸需要不断更新和维护，逐步完善：需求发生变化－维护用例与需求之间关系设计发生变化－维护用例与设计之间的关系发现测试遗漏发现设计错误测试用例的更新214假如有一个windows系统上应用的单机版应用软件，让你负责测试该软件的安装卸载，你应该测试哪些内容，写多少测试用例？安装卸载测试思考不是一蹴而就的测试用例的执行管理4216建立测试任务，为测试任务指定测试用例集合：设置测试任务的基本信息(开始结束时间、人员)设置任务的汇报周期以及异常处理为任务指定测试用例集管理测试项的状态管理测试执行的日期和时间测试用例的执行管理测试用例的统计分析5218可以通过分析统计参数观察测试的效率、合理性：自动化比例功能测试和非功能测试用例比例测试通过率正面和反面测试用例的比例各模块测试用例分布测试用例的分析统计

测试用例的自动化比例

功能测试和非功能测试的比例

测试用例通过率正面测试用例与反面测试用例的比例：通过这一比例可以评估测试用例设计的完备性，如果比例过高则说明反面测试用例可能考虑不充分正面测试用例与反面测试用例的比例各模块测试用例分布：对各功能模块测试用例分布进行统计，可以根据经验和模块规模大小评估测试用例数量的合理性，一般可以通过表格、柱状图或饼状图来进行分析。各模块测试用例分布测试用例管理工具6225Excel/word：适合小型项目专门的测试用例管理工具：一般集成在测试管理工具和项目管理工具中支持的功能：用例的录入、更新用例的统计分析用例的执行和结果记录测试用例管理工具理解测试用例的概念。掌握测试用例的属性和设计方法。了解测试用例的评审和管理要点。能够根据理论组织编写并管理项目的测试用例。226小结完成项目实践作业五谢谢观看228软件测试管理与实践ch06-软件测试缺陷管理229了解软件缺陷概念以及缺陷产生的原因。掌握软件缺陷的生命周期。掌握提交一个好的缺陷报告的要点。掌握常见的缺陷分析统计方法。能够根据理论开展测试缺陷的报告和统计分析。学习目标23012软件缺陷及其产生软件缺陷的属性3软件缺陷的生命周期4软件缺陷的统计度量5软件缺陷的管理工具软件缺陷及其产生1233软件缺陷-SoftwareDefect-Bug缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。IEEE729-1983对缺陷的标准定义：从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题；从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。软件缺陷软件存在的问题在软件的开发测试过程中项目组会特别关注软件缺陷的状况，这是因为一方面软件缺陷状况是项目质量和状态的重要指示数据，另一方面越到软件生命周期的后期修复软件缺陷的成本越高。软件研发中对缺陷的关注235功能没有实现或与需求规格说明不一致界面、消息、提示、帮助不够准确或误导用户屏幕显示、打印结果不正确软件无故退出或没有反应;边界条件未做处理，输入错误数据没有提示和说明运行速度慢或占用资源过多与常用的交互软件不兼容有时把尚未完成的小功能也归属于软件缺陷常见的典型的件缺陷在软件开发的过程中，软件缺陷的产生是不可避免的，”零缺陷”是软件产品很难达到一个状态。导致软件缺陷产生的原因也是多种多样的，软件工程过程中的人、过程、工具都有可能导致产生软件缺陷，过程中的每一个环节都有可能产生缺陷，概括来说这些原因可以归结为四大类。软件缺陷产生的原因237软件缺陷软件本身技术人员管理软件缺陷产生的原因软件本身的复杂性和抽象性在产品真正完成之前，每个人对软件的理解都不完全相同，这种复杂和抽象使得软件容易出现缺陷软件本身的原因软件技术在某些领域应用不成熟，使得某些功能或性能无法达到应用要求，也会导致软件缺陷的产生。技术方面的原因如果软件开发流程不完善，存在太多的随机性，缺乏严谨的评审机制，则容易产生软件缺陷。目前软件行业对项目管理和软件过程的研究实践已经有很多成果，比如全流程质量管理、CMMI模型等软件工程方法。管理方面原因软件团队的成员能力水平不足也会引起软件缺陷的产生。比如编码人员能力不足，会产生很多算法错误和语法错误导致软件不能正常工作或者性能低下。人员方面的原因软件缺陷的属性2为了方便引用、理解、解决、测试、回归，跟踪、分析软件缺陷，软件缺陷有很多属性，比如编号ID，解决人，测试人、状态、所属功能模块、严重程度等等。这些属性并不是在缺陷录入的时候就全部指定的，而是随着软件缺陷的流转根据需要不断完善的。一个完整的缺陷报告应该清楚的描述BUG的症状和其他基本信息。不同的团队根据缺陷管理的需要使用的缺陷属性不同。软件缺陷的属性244一个完整的BUG报告应该包含的内容序号属性项是否必须说明1标题是Bug的标题，应该尽量精炼。2关键字是识别这个缺陷的几个关键字，用于搜索、消重等3功能模块是Bug的功能性分类，要结合具体的产品特性来定义,一般按照功能模块划分。比如:安装卸载问题、帮助文档问题、打印问题、功能模块1问题……4缺陷状态是用于缺陷的跟踪，描述缺陷的状态，比如新建、解决待测、测试通过、测试失败、已解决等。5问题复现步骤是复现问题的具体步骤6期望结果是操作的正确结果（期望结果）7实际结果是操作的实际结果8附件否附加的文件、图片和录制的可播放文件9版本号是发现bug时的产品版本号(大部分产品都是不断升级维护的，而且是不同版本使用同一个bug库)10优先级是问题解决的优先级,处理和修正软件缺陷的先后顺序的指标11严重性是问题的严重性12分类否Bug的特征分类，可以根据团队需要特别关注的类别划分，比如效率问题、死机问题、易用性问题、兼容性问题等。13客户信息否列出反馈该问题的一个或多个客户的相关信息，方便对客户进行支持14报告人是报告缺陷的人员，一般缺陷系统自动根据账号生成15报告时间是报告提交的时间，一般系统自动生成软件缺陷属性245优先级是处理和修正软件缺陷的先后顺序的指标，即哪些缺陷需要优先修正，哪些缺陷可以稍后修正。缺陷的优先级级别描述1—最高优先级主要指软件的核心功能错误或者造成软件崩溃，数据丢失的缺陷2—较高优先级影响软件功能和性能的一般缺陷3—中等优先级对客户影响不大的缺陷4—低优先级对软件的质量影响非常轻微或出现几率很低的缺陷；

软件缺陷优先级的四级划分理论上来说，确定软件缺陷优先级，更多的是站在软件开发工程师的角度考虑问题，因为缺陷的修复是个复杂的过程，有些不是纯粹技术问题，而且开发人员更熟悉软件代码，能够比测试工程师更清楚修复缺陷的难度和风险。但是实际上，企业在确定缺陷优先级并不只站在开发工程师角度，而是对解决的难度、缺陷对产品销售的影响、客户的重要性等方面综合考虑确定的。软件缺陷的优先级严重性(Severity)是软件缺陷对软件质量的破坏程度，即此软件缺陷的存在将对软件的功能和性能产生怎样的影响。在软件测试中，软件缺陷的严重性的判断应该从软件最终用户的观点做出判断，即判断缺陷的严重性要为用户考虑，考虑缺陷对用户造成的后果的严重性。软件缺陷的严重性248缺陷的严重程度级别描述1Trivial轻微软件产品的小缺陷，比如词语拼写错误、控件没有对齐、控件相互遮挡等，不影响用户完成工作。2-Medium中等重要但是不会导致用户不能完成功能，可以绕过或影响效率。3-Major重要核心功能缺失或不能正常工作，导致客户无法完成工作4-Critical严重导致死机、无反应、数据丢失、严重的内存泄漏等问题。软件缺陷严重性的一般划分严重性和优先级的关系？团队在开展测试工作时会根据团队管理和产品的实际需要定义缺陷的字段，少则六七个字段，多则可达十几二十个。缺陷报告模板缺陷报告模板-Excel注意一般缺陷管理工具中，由于每个产品的功能模块不同，可以自行配置“功能模块”字段。ALM缺陷报告提交模板软件缺陷的生命周期3253缺陷处理的五个阶段缺陷报告缺陷验证缺陷解决缺陷测试缺陷关闭254缺陷生命周期状态图255缺陷的状态缺陷状态描述New当缺陷被第一次提交的时候，它的状态即为“新建”。这也就是说缺陷未被确认是否真正是一个缺陷。Open在测试者提交一个缺陷后，缺陷验证人员确认其确实为一个缺陷的时候便会把缺陷状态置为“打开”，表示该缺陷还未解决。Assigned一旦缺陷被置为“打开”，项目负责人会把缺陷交给相应的开发人员或者开发组。这时缺陷状态变更为“已分配”。Deferred缺陷状态被置为“延迟的”意味着缺陷将会在下一个版本或后续的其他版本中被修复。Invalidate如果开发人员不认为其是一个缺陷，他会将缺陷状态置为“无效”或者“拒绝”（Rejected）Resolved程序员处理完BUG的时候，将该BUG的状态改为Resovled，等待测试人员进行回归测试。解决人可能通过代码修改解决问题，也有可能这个问题与另一个问题相同，一次解决了多个相同的问题。开发人员需要在备注中说明清楚解决的方式。Verified测试人员对Resolved的BUG进行回归测试,如果缺陷不再出现，这就证明缺陷被修复了同时其状态被置为“已核实”。Reopened测试人员在进行回归测试时，发现问题没有得到解决，则将BUG的状态修改为Reopened.Closed确认该BUG通过回归测试后,关闭BUG,将其状态变更为Closed.软件缺陷的统计度量4软件缺陷作为软件质量的重要指标变量，对其进行统计分析以明确项目质量情况，帮助管理者进一步做决策意义重大。软件缺陷统计分析意义258缺陷密度Dd：Dd=缺陷数量/代码行或功能点的数量，其单位为每千行代码的缺陷数(Defects/KLOC)。遗留缺陷密度：遗留缺陷数/代码行或功能点数缺陷探测率DDP：发布前发现的缺陷数/缺陷总数缺陷趋势分析统计缺陷分布分析统计缺陷根源分析统计常用的缺陷分析项软件缺陷的管理工具5260软件缺陷管理指南软件缺陷报告录入模板和指南软件缺陷管理系统自主开发、购买、开源单独的缺陷管理工具、集成在研发管理系统中Bugzilla：https:///禅道项目管理软件中的缺陷管理子系统JIRA：https:///software/jiraALM中的缺陷管理子系统软件缺陷的管理工具和指导文档如何选择缺陷管理工具？软件缺陷管理系统分类自主开发、购买、开源单独的缺陷管理工具、集成在研发管理系统中典型的软件缺陷管理系统Bugzilla：/禅道项目管理软件中的缺陷管理子系统JIRA：/software/jiraALM中的缺陷管理子系统软件缺陷工具的分类如何选择缺陷管理工具？工具是理论的载体，理解了理论才能灵活运用工具，一般的缺陷管理系统有如下功能:字段配置缺陷跟踪添加缺陷修改缺陷关联缺陷和测试用例统计分析功能软件缺陷管理工具的功能了解软件缺陷概念以及缺陷产生的原因。掌握软件缺陷的生命周期。掌握提交一个好的缺陷报告的要点。掌握常见的缺陷分析统计方法。能够根据理论开展测试缺陷的报告和统计分析。263小结谢谢观看264软件测试管理与实践ch07-软件测试执行265了解测试执行的主要任务。了解测试执行中的监控要点。掌握测试报告的主要内容。能够根据理论开展测试执行并完成测试总结报告。学习目标266267测试执行的任务测试执行的监控测试执行的结束软件测试执行的任务1268269测试执行是执行所有或部分选定的测试用例，并对结果进行分析的过程。测试执行活动是整个测