第8章 测试计划与测试文档

第8章测试计划与测试文档对测试进行组织和管理的意义：建立软件管理体系的主要目的是要确保软件测试能把好软件质量的关。为了达到这一目标，必须把测试工作看作一个系统，采用系统的方法，对测试中的各个过程进行监管和控制。主要内容一、团队建设（组织结构、人员组成、规模、人员培训）二、过程规划（软件过程、测试过程、测试的阶段、规划自己的过程）三、测试过程实施（计划、设计、实施、执行、评估、缺陷跟踪）一、团队建设•测试部门的组织形式•测试组的人员组成•测试组的规模•测试人员的培训1、组织形式•一个好的组织结构，可以更好的发挥人员的能动性，使工作更有效率，也使工作的质量更高。•在一个单位内测试人员处于什么位置？属于那个部门？部门之间的隶属关系？人员的职责？–质量管理？–开发组？–测试组？•适用的就是最好的。组织形式－常见测试组组织结构•烟囱测试组（小型）•烟囱测试组（大型）•集中测试组•IV&V（独立验证与确认）测试组•SMT（系统方法与测试）组组织形式－烟囱测试组•小型的组，测试人员由临时人员组成，通常有2-5人组成，直接向项目经理负责。大型的组可以划分为几个小组，设测试经理。项目经理负责制定测试计划文档。企业没有正规的方法将测试程序、方法、相关的知识经验传递下去，测试质量难以保证。优点是成本低，不需要对测试人员提供培训、生活保障等服务。组织形式－集中测试组•企业成立专职、独立的测试部门，通常由10－30人组成。集中测试组为每个项目配备几个全职的测试人员。部分企业中可能还负责执行项目中软件质量管理和性能规范制定的工作。可以将相关的知识、经验传递下去。组织形式－IV&V（独立验证与确认）组•通常由软件开发组织之外的人员或其中的独立人员组成，如转包商。其参与检查、验证是否遵循标准、进行软件文档的质量保证检测，主要完成系统测试。组织形式－SMT（系统方法与测试）•通常作为企业的内部顾问组的方式存在。主要负责方法及标准的知识交流、编制开发和测试指南、开发测试方法、测试工具评估与培训，其同不同的项目组进行协作，对其进行指导。通常不负责具体测试工作的执行。由软件专家组成。组织形式－企业或项目组织结构样例•微软的项目组织产品组经理项目经理开发经理质量保证经理开发工程师测试人员流程经理设计经理组织形式－企业或项目组织结构样例•一种常见的组织软件开发组织客户服务项目管理质量管理开发规范、CMM、质量保证测试软件开发组织客户服务项目管理质量管理开发规范、CMM、质量保证测试•首先是一个专业“悲观主义者”,不轻易相信所交付测试的软件中不存在错误,并会将精力集中在查找错误上面。•其次,他们应具备适度的好奇心,勇于并善于发现问题。开发测试用例所使用的方法,如同勘探专能编写出导致错误出现的测试用例,这就是好奇心。测试者若没有好奇心并对要达到的目标缺乏强烈兴趣,只能写出肤浅的测试用例。•第三,测试者必须会阅读规格说明,与开发人员一起讨论“假设分析”的场景,并在大脑中反复思考被测系统,从所有的角度去检查问题,知道如何集中注意力并跟踪问题。•第四,要有相当数量的骨干技术人员。虽然测试团队中不可能都是经验丰富的骨干人员，很有可能在测试团队中引入新人。但从实际经验来看，骨干测试人员至少应该占测试团队人数的50%。低于这个标准，测试的质量将无法得到保证。2、人员组成－选择测试工作的合适人选人员组成－测试组组成•测试经理（10年左右经验）：负责测试流程、沟通、测试工具的引入、人员管理、测试计划/设计/开发及执行。•测试组长（5年左右经验）：沟通、测试工具引入、人员管理、费用/过程状态报告、测试计划/设计/开发及执行。•测试工程师（普通和高级1-4年经验）：执行测试计划，进行设计/开发及执行。•软件测试员(毕业生等)3、测试组规模－影响因素•企业文化或测试成熟度•测试需求范围•工程师技能水平•测试工具及应用水平•业务知识•组织形式•测试工作介入时间测试组规模－确定方法（一）•开发比例法：根据开发人员数量按照一定比例来确定测试工程师的数量。开发人员指进行设计、开发、编译以及进行单元测试的人员。开发类型开发人员比例测试组规模商业产品（大型市场）30人3:220商业产品（小型市场）30人3:110单个客户端的应用开发30人6:15政府部门应用开发（内部）30人5:16公司应用开发（内部ERP）30人4:17测试组规模－确定方法（二）•百分比法：根据测试人员应该占到项目组中人员的百分比数量。开发类型项目人员数量测试组规模比例测试组规模商业产品（大型市场）50人27％13商业产品（小型市场）50人16％8单个客户端的应用开发50人10％5政府部门应用开发（内部）50人11％5公司应用开发（内部）50人14％74、人员培养－人员要求•适应各种环境的知识背景•学习速度快•组织能力•解决问题的能力•创造性•分析/编程能力•业务领域的知识•交流与协调能力•测试经验•关注细节•书写文档的技能一个好的测试人员很难得人员培养－成长的路径•初级测试工程师－测试工程师－高级测试工程师－测试组负责人－测试负责人－测试经理－产品/业务经理。•技术技能：测试工具\测试自动化编程\编程语言\操作系统\网络、数据库\测试生存周期（1-2年）•测试过程：评审、制订和改进过程，指导初级工程师工作，了解业务领域。（3-4年）•测试组工作：任务安排、跟踪和报告，监管测试工程师，掌握测试周期支持工具。（4-6年）•项目管理：管理项目，与客户交流，管理测试人员。（6-12年）•产品管理：项目或产品研发指导、促进产品销售、确定业务机会、承担盈亏责任。（12年以上）返回二、测试过程规划•软件过程•测试过程•测试的阶段1、软件过程－定义•目的：测试过程是软件过程的组成部分，明确自己的软件过程，才能明确自己的测试过程。•软件生存周期指软件从出现一个构思之日起，直到最后决定停止使用之时止。包括可行性与计划研究、需求分析、设计、实现、测试、运行与维护等阶段。•软件过程是指开发和维护软件及相关产品（如项目计划、文档、代码、手册等）的一套行为、方法、实践及变换过程。软件过程是软件生存周期的框架。2、测试过程－开发过程与测试过程并行开发过程与测试过程并行测试过程－与开发过程的关系•都是软件过程的有机组成部分。•与开发过程同步进行。•与开发过程相互依赖，又相互独立。‘•开发过程、测试过程、项目管理过程以及其他支撑过程相互交织共同组成了软件过程。测试过程－注意事项•测试工作开始于需求分析之后。•测试经过评估后，达到了结束的标准后才能结束。•测试也是迭代过程。•测试需求来自于软件需求。三、测试过程•制订测试计划：确定测试范围、划分测试任务、配置软硬件测试环境、确定测试日程表和组织测试团队等核心问题。编制测试日程表等等。•测试设计：主要是设计测试用例或者测试大纲。•执行测试：主要任务是执行测试用例。•缺陷跟踪•测试的总结：主要由管理人员依据测试报告模板撰写测试报告。制订测试计划－定义•什么是测试计划：测试计划包含项目范围内的测试目的和测试目标的有关信息。此外，测试计划还将确定实施和执行测试时所使用的策略以及所需资源。测试计划包括测试主计划和阶段计划。•项目开始时制订测试主计划。根据开发的迭代过程和测试主计划对测试计划进行细化，制订各个阶段的测试计划。制订测试计划－内容•1.简介(目的、背景、范围、使用的文档）•2.测试需求（确定被测试的对象、内容和范围，来源于用户需求，包括功能性需求和非功能性需求。）•3.测试策略（测试的项目、测试的主要方法、完成标准、使用的工具、特殊事项等）•4.资源（人员组成、任务和职责、环境、人员培训等）•5.项目进度表（阶段）•6.可交付工作（测试模型、测试记录、缺陷报告等等）制订测试计划－步骤（一）•确定测试需求：确定测试对象以及测试工作的范围和内容。测试需求应是可核实的。测试需求可来源于软件需求列表、用例、用例模型、用例实现、补充规约、设计需求、商业理由、法规、标准、最终用户访谈以及对现有系统的复审。•被确定的测试需求项必须是可核实的。即，它们必须有一个可观察、可评测的结果。无法核实的需求不是测试需求。制订测试计划－步骤（二）•评估风险：测试工作需要平衡资源约束和风险，以确定测试的优先级。从三个方面分析：–影响：失效后将造成的影响或后果–原因：失效所导致的非预期结果–可能性：用例失效的可能性•根据风险分析情况，确定测试执行的优先级。通常分为高、中、低三种。进而安排测试的先后顺序。制订测试计划－步骤（三）•制定测试策略：描述测试活动的一般方法和目标。包括测试的阶段、类型、技术、测试完成的标准、特殊要求、可能存在的影响等。•确定资源–人力资源（人员数量和技能）–测试环境（包括硬件和软件）–工具–数据•创建时间表：估计测试工作，制订时间进度。参考软件开发进度、项目工作计划等。•生成测试计划：复审相关材料，确定交付的内容，将计划提交相关的人员。制订测试计划－主计划和阶段计划•阶段计划的测试需求应是对主计划中的测试需求的分解。•阶段计划的工作进度安排应尽可能同主计划相一致。•阶段计划的制订应能保证主计划能够完满执行。测试设计（一）•分析程序工作流程。目的在于确定并说明系统与外部交互时的操作和步骤。以进一步用于确定与描述测试用例。•确定并说明测试用例–详细分析应用程序工作流程与操作步骤。–确定并说明测试用例–确定测试用例数据测试设计（二）•确立并结构化测试执行过程–确定本测试执行过程与其他测试执行过程（或生成的测试脚本之间）的关系或顺序。–确定本测试执行过程的起始条件/状态与结束条件/状态。–指明本测试执行过程（或生成的测试脚本）要执行的测试用例。–结构化的方式固化测试执行过程。测试设计（三）•复审并评估测试覆盖–确定测试覆盖评测方法：基于代码覆盖和基于需求的覆盖。基于代码覆盖的方法只有在代码完成后才能进行。–生成测试覆盖报告测试准备•记录、生成或通过编程创建测试脚本•确定软件设计与实施模型中的专用于测试的功能。•建立外部数据集•桩模块与驱动模块设计•执行前的准备工作执行测试•单元测试和集成测试时有开发人员的参与可能更有效，但应避免开发人员测试自己的程序。•验收测试应由测试组、用户和相关的专家完成。•测试的执行应该遵循如下的过程：设置测试环境，执行测试过程，核实测试结果，评估测试的执行情况。评估测试结果•分析测试结果并提交变更请求•评估基于需求的测试覆盖•评估基于代码的测试覆盖•分析缺陷•确定是否达到了测试的完成标准和成功标准•生成测试评估摘要缺陷跟踪•缺陷等级（严重、主要、次要、轻微等）与优先级（高、中、低等）分类•缺陷修改应遵循一定的流程（提交－任务分配－修改－回归测试）•缺陷趋势分析•不易修改的缺陷的处理配置管理主要实现软件版本控制和软件变更管理测试过程中形成的文档、用例、数据、测试用程序等也存在配置管理的问题应和开发中的配置管理共同进行，并互相关联。某系统第三方测试日程表（部分）流行的软件缺陷生命周期定义•定义软件缺陷的状态如下：•新错误(New)—测试中新报告的软件缺陷。•更多新信息(NewMoreInfo)——开发工程师认为报告的缺陷信息不完整,要求缺陷报告者添加更准确的缺陷信息。•打开(open)——缺陷被确认并分配给相关开发工程师处理。•拒绝(Declined)——拒绝修改缺陷。包括两种情况:1)拒绝-不是错误(Declined-NotBug)——报告的缺陷不属于缺陷。2)拒绝-重复(Declined-Duplicated)——以前已经报告过这个缺陷,需要指出已经报告过的缺陷标识编号。•修正(Fixed)—开发工程师已完成修正,等待测试人员验证。•重新打开(Reopen)——没有正确修复的缺陷,需要进一步修复。•延期(Deferred)——不在当前版本修复的缺陷,以后的版本修复。包括两种情况:1)延期-下个版本(Deferred-NextBuild)——本项目的下一个新版本修复。2)延期-下个主要版本(Deferred-NextMainRelease)——本项目不修复,本软件下一个项目的版本修复。•关闭(Cl