软件测试与质量保证课件 第4章 软件测试管理

第4章软件测试管理本章内容软件测试流程软件测试制品测试用例软件测试环境软件测试团队软件测试计划缺陷管理测试管理工具2本章内容软件测试流程软件测试制品测试用例软件测试环境软件测试团队软件测试计划缺陷管理测试管理工具3软件测试流程4软件测试管理51任务书2测试计划3测试规范4问题报告5测试报告启动计划执行、控制收尾组建测试组制定测试计划测试设计开发测试执行测试结果处理软件测试管理的整体目标：跟踪、监测团队在整个软件开发工作中计划、开发、执行并评估所有的测试活动。软件测试管理有助于系统地、规范地管理各种测试资源和测试活动，以提高测试的效率和质量。6软件测试管理内容四类管理内容：测试计划的管理测试制品的管理测试过程的管理测试人员及组织的管理7测试计划测试计划通常写成文档，描述要进行的测试活动的范围、方法、资源和进度，确定测试项、被测特性、测试任务、谁执行任务、各种可能的风险。8TestCenter中的添加计划9本章内容软件测试流程软件测试制品测试用例软件测试环境软件测试团队软件测试计划缺陷管理测试管理工具10软件测试制品常见测试制品（TestArtifact）：测试用例（TestCase）测试脚本（TestScript）测试套件（TestSuite）测试计划（TestPlan）测试评估总结（TestEvaluationSummary）11本章内容软件测试流程软件测试制品测试用例软件测试环境软件测试团队软件测试计划缺陷管理测试管理工具12测试用例测试用例是为特定目标开发的测试输入、执行条件和预期结果的集合，一般还规定测试的开始条件、测试过程的条件和结束条件。测试用例示例：13测试用例要素（1）标识符Identification，指编号，为整型。此项必须有，用于不同文档间的相互引用。（2）测试项TestItem，用来准确描述待测试的项目及其特征，为字符型。此项必须有，作用是指明具体的测试对象/具体测试特性要求。（3）测试环境要求TestEnvironment，指特殊的环境要求，为字符型。此项可选，在一般软硬件环境可以不必给出。（4）输入标准InputCriteria，准确描述输入需求，包括数据、文件或操作步骤，必要时罗列数据库和文件，为字符型。此项必须有，作用是指明执行测试时具体的数据及输入步骤。（5）输出标准OutputCriteria，指按照指定的环境和输入标准执行后所期望的输出结果，为字符型。此项必须有，要求描述清楚无异议，必要时尽量提供适当的系统规格说明来证明期望的结果。（6）测试用例之间的关联，用来表明本测试用例与其他测试用例之间的依赖关系，为字符型。14测试用例设计思想（1）设计测试用例的准备工作。（2）测试用例命名细则（3）测试用例编号规则。（4）测试用例划分（5）测试用例的设计原则（6）测试用例的粒度。15测试用例设计方法（1）常规的测试用例设计。（2）初始化的测试用例设计（3）边界的测试用例设计（4）空值的测试用例设计（5）格式错误的测试用例设计（6）溢出的测试用例设计（7）关联的测试用例设计（8）唯一值的测试用例设计（9）权限不足的测试用例设计（10）角色权限的测试用例16测试用例覆盖要求（1）正确性测试。输入用户实际数据以验证系统是满足需求规格说明书的要求；测试用例中的测试点应首先保证至少覆盖需求规格说明书中的各项功能,并且正常。（2）健壮性测试。程序能够接收正确数据输入并且产生正确（预期）的输出；输入非法数据（非法类型、不符合要求的数据、溢出数据等）,程序应能给出提示并进行相应处理。（3）安全性测试。是指对未经授权的人使用软件系统或数据的企图,系统能够控制的程度,程序的数据处理能够保持外部信息（数据库或文件）的完整。（4）接口间测试。测试各个模块相互间的协调和通信情况、数据输入输出的一致性和正确性。（5）数据库测试。依据数据库设计规范对软件系统的数据库结构、数据表及其之间的数据调用关系进行测试。（6）边界值分析法。确定边界情况（刚好等于、稍小于和稍大于和刚刚大于等价类边界值），针对我们的系统在测试过程中主要输入一些合法数据/非法数据，主要在边界值附近选取。（7）压力测试。例如先输入10条记录运行各个功能，再输入30条和50条记录进行测试。（8）等价类划分。将所有可能的输入数据（有效的和无效的）划分成若干个等价类。（9）错误推测。主要是根据测试经验和直觉，参照以往的软件系统出现错误之处。（10）效率。完成预定的功能，系统的运行时间（主要是针对数据库而言）。（11）可操作性。理解和使用该系统的难易程度。（12）可移植性。在不同操作系统及硬件配置情况下的运行性。（13）回归测试。按照测试用例将所有的测试点测试完毕，测试中发现的问题开发人员。（14）比较测试。将已经发版的类似产品或原有的老产品与测试的产品同时运行并做比较，或与以往的测试结果相比较。17性能测试用例实例18TestCenter中的添加测试用例19测试脚本测试脚本是自动执行测试过程的计算机可读指令。不同工具使用不同的测试脚本语言。Robot工具使用的脚本语言类似于VBScript和JavaScript；LoadRunner使用的脚本语言是类C和类JavaScript的TestComplete工具使用的脚本语言是类似Delphi的脚本语言。测试脚本示例（LoadRunner）：20测试套件测试套件是一组相关的测试，一个测试套件实现了一个或多个包含测试脚本和测试数据的测试思想或测试用例。Junit的测试套件示例：21测试评估总结测试评估总结用于整理并展示复审与评估的测试结果及测试的主要评测方法。测试评估总结的主要内容包括：测试结果摘要基于需求的测试覆盖基于代码的测试覆盖缺陷分析建议措施......22本章内容软件测试流程软件测试制品测试用例软件测试环境软件测试团队软件测试计划缺陷管理测试管理工具23测试环境的重要性测试环境是测试的基础测试环境的定义软件测试的设计环境、实施环境管理环境测试环境配置的原则软件测试环境的组成与要求影响测试环境的因素主测试环境与辅测试环境24属性不同阶段的测试环境单元测试集成测试系统测试验收测试人员开发者开发者/测试人员测试人员测试人员/用户硬件O/S程序员的工作台程序员的工作台系统测试机器或区域产品的镜像共存软件无无无/实际的实际的接口无内部的模拟的/实际的产品测试数据源手工生成自动生成产品/手工生成产品测试数据集小小大大策略单元单元组整个系统模拟产品25表4-2测试环境因素表测试环境的要素硬件环境测试必需的服务器、客户端、网络连接设备，以及打印机/扫描仪等辅助硬件设备所构成的环境软件环境

被测软件运行时的操作系统、数据库及其他应用软件构成的环境，还涉及共存的软件网络环境被测软件运行时的网络系统、网络结构及其他网络设备构成的环境数据准备数据准备得越充分，种类越丰富，就更有利于测试的进行测试工具26测试环境的建立和维护建立测试实验室论证建立实验室的必要性选择和规划实验室场所制定测试实验室配置清单集成和配置测试设备27测试环境的建立和维护几种常见测试环境的搭建单机版应用程序的测试环境搭建B/S系统的测试环境搭建C/S系统的测试环境搭建28测试环境的建立和维护实验室通常会设置管理员来维护和管理测试环境，管理员的主要工作是对测试环境进行备份和恢复。测试过程中会遇到多种不可预测的事情，一旦发生系统崩溃，则会造成测试数据丢失、测试过程中断或者测试环境的重新搭建，所以经常对测试环境进行备份是一个必备的预防措施和比较好的习惯。对测试环境的备份可以挽回不必要的损失、节省测试的时间、保持测试的连续性。一旦测试环境遭到破坏，就可以还原最近备份的系统，实现测试环境的恢复，包括恢复测试数据和测试环境的当前状态，维持测试环境的一致性。常用的测试环境备份与恢复的工具有Ghost、Partimage等。将对测试环境备份获得的Image文件复制到其他硬件配置相同的计算机上，一旦出现问题，就可以利用备份恢复工具快速恢复的测试环境，实现多台机器同样的测试环境的快速搭建，从而节省时间。29本章内容软件测试流程软件测试制品测试用例软件测试环境软件测试团队软件测试计划缺陷管理测试管理工具30团队定义一：由员工和管理层组成的一个共同体，该共同体合理利用每一个成员的知识和技能协同工作，解决问题，达到共同的目标。定义二：由两个或者两个以上的相互作用、相互依赖的个体，为了特定目标而按照一定规则结合在一起的组织。31软件测试团队被分配到某个软件测试项目中工作的一组人员，相互依赖、齐心协力的进行软件测试工作，以实现软件项目的测试目标。32软件测试团队的任务：建立测试计划设计测试用例搭建测试环境执行测试报告测试结果评估测试效果...33测试团队组织模式以开发经理为核心的组织模式以项目经理为核心的组织模式三足鼎立的组织模式以开发经理为核心的组织模式开发经理测试人员开发人员文档人员管理人员测试团队组织模式以项目经理为核心的组织模式项目经理测试组长测试人员测试人员开发组长开发人员开发人员文档人员测试团队组织模式三足鼎立的组织模式项目经理测试经理开发经理测试团队组织模式团队结构38程序员业务分析人员测试人员程序员业务分析人员测试人员职能团队结构敏捷团队结构有效的测试团队具有以下特征：对软件项目的测试目标有清晰的理解对每位测试工程师的角色和职责有明确的期望以目标为导向高度的互助合作高度的信任39测试团队的基本职责尽早地发现软件产品中的尽可能多的缺陷督促和帮助开发人员尽快解决产品中的缺陷协助项目管理人员制定合理的开发计划和项目测试计划对缺陷进行跟踪、分析和总结评估软件产品的当前质量状态培养测试工程师的测试技能40测试团队角色41工作角色具体职责测试经理管理监督测试项目，提供技术指导，获取适当的资源，制定基线，技术协调，负责项目的安全保密和质量管理测试分析员确定测试计划、测试内容、测试方法、测试数据生成方法、测试环境、测试工具，评价测试工作的有效性测试设计员设计测试用例，确定测试用例的优先级，建立测试环境测试程序员编写测试辅助软件测试员执行测试、记录测试结果测试系统管理员对测试环境和资产进行管理和维护配置管理员设置、管理和维护测试配置管理数据库软件测试经理招聘职责要求岗位职责：负责日常测试工作，功能测试设计和执行；分析产品需求，制定与评审系统级整体测试计划与方案；组织前后台模块的系统级联调测试，发现问题并协调相关测试、开发人员，推进问题的解决，确保交付质量。总结测试过程，分析缺陷与风险，编写测试报告。能准确地理解需求文档，并能在需求评审中站在用户的角度提出建议和意见；从测试角度对系统设计给予建议，实现高度的解藕，并有利于后续更好的测试自动化执行；根据需求文档和产品原型编写测试用例，梳理测试场景及功能点能按要求执行测试用例；运用黑盒测试、接口测试、性能测试、安全测试等执行测试场景；负责公司自主研发的软件系统和迭代系统的所有测试工作；对系统出现的bug与负责与开发工程师积极交流并督促其改正，并和产品经理沟通对生产缺陷对提出的bug开发人员是否修复优化进行验证，根据软件测试的测试环境、测试内容、测试方法、测试结果、系统风险进行总结；42软件测试经理招聘职责要求工作职责：参与互联网软件产品测试的全流程，包括参与需求分析、设计评审，指定测试计划，设计和执行测试用例，进行缺陷跟踪和软件质量分析等带领其他测试工程师执行项目测试，包括：制定测试计划，分配测试资源，构建测试环境，执行集成测试，回归测试等按照产品架构和业务要求，制定和推进测试策略，测试计划和测试方法参与产品需求和架构设计评审，保证产品的可测试性通过测试相关流程、策略、方法和工具等创新，努力提升测试的质量和效率解决测试过程中复杂技术问题负责测试团队的测试方法和技术培训，领导团队测试技术的发展43软件测试经理招聘职责要求岗位职责：软件测试流程、体系的梳理和建立；制定、编写软件测试方案与计划；根据产品测试需求完成测试环境的设计与配置工作；负责软件产品的集成测试与系统测试，按时完成软件测试工作任务；编写测试文档，测试报告，提交测试结果并进行分析确认、缺陷跟踪；改进软件测试流程、工具、和质量；参与测试结果评审；测试团队的人员管理工作。44软件测试工程师招聘职责要求岗位职责:根据项目计划制定项目测试用例并实施，保证项目质量和进度

根据项目设计与实现有关自动化测试的代码与用例根据项目特点，开发合适测试工具或自动化解决方案，提高测试效率

参与程序架构和代码的评审工作，并提出改进意见设计与执行测试用例，跟踪定位产品软件中的缺陷或问题

与项目相关人员就项目进度和问题进行沟通

45软件测试工程师招聘职责要求岗位描述：编写产品的测试计划和测试用例。执行功能测试和性能测试。编写相关的测试报告。岗位要求：熟悉软件的开发流程。精通软件测试的各个环节。能良好地在用户和开发工程师之间进行沟通。能担当部分文档编写工作和客服支持。46软件测试工程师招聘职责要求岗位职责：完成公司项目、产品的所有相关测试工作；根据产品需求和设计文档，制定测试计划，并分析测试需求、设计测试流程；根据产品测试需求完成测试环境的设计与配置工作；执行具体测试任务并确认测试结果、缺陷跟踪，完成测试报告以及测试结果分析；在测试各环节与开发、产品等部门沟通保证测试输入和输出的正确性和完备性；完成产品缺陷验证和确认，对于难以重现的缺陷，需要完成可能性原因分析与验证；定期提交产品缺陷统计分析报告并完成产品测试总结报告；完成测试团队的管理考核及业务培训工作。47测试人员职业发展图48管理方面技术专家质量保证技术支持测试组长测试经理行业测试专家自动化测试专家白盒测试测试分析师\测试数据挖掘人员UE研究专家项目经理SQA质量经理初级测试工程师测试工程师中/高级测试工程师技术支持、咨询师或培训师，如给大公司提供自动化测试或培训、资源支持本章内容软件测试流程软件测试制品测试用例软件测试环境软件测试团队软件测试计划缺陷管理测试管理工具49管理学中的计划指对我们如何能达到目标的描述50什么是测试计划？测试计划是项目计划的组成部分。测试计划依赖于软件组织过程、质量文化和方针。测试计划是指导今后一系列测试活动的文件。测试计划是一个过程，随项目的进展不断更新。51

子曰：凡事预则立，不预则废，预即是计划。要想成功完成软件测试这项工作，必须首先建立测试计划。什么是测试计划？52测试计划项目背景测试范围测试策略使用资源进度安排测试组织可能风险测试计划的内容测试计划编写包括6要素（5W1H）53

wherewhat

when

why为什么要进行这些测试相应文档，缺陷的存放位置，测试环境等测试不同阶段的起止时间测试哪些方面，不同阶段的工作内容

who项目有关人员组成，安排哪些测试人员进行测试

how如何去做，使用哪些测试工具以及测试方法进行测试软件测试计划的作用54软测试计划测试管理人员根据测试计划做宏观调控，进行相应资源配置等测试人员了解整个项目测试情况以及项目测试不同阶段的所要进行的工作等其他人员了解测试人员的工作内容，进行有关配合工作软件测试计划的目标55收集并组织测试计划信息将软件细化为可检验的测试需求建立测试计划测试计划的制定过程56分析和测试软件需求定义测试策略定义测试环境定义测试管理编写和审核测试计划测试计划的制定过程57分析和测试软件需求定义测试策略定义测试环境定义测试管理编写和审核测试计划在需求分析阶段，软件测试人员就需要进入。在这个阶段，测试人员需要对需求有完整的理解，还需要对需求文档进行测试。并基于软件需求获得测试需求。分析和测试软件需求需求规格说明书测试团队需要清晰、明确、可测试的需求说明书以便开始测试计划和测试设计工作测试人员通过对需求的分析实现对需求的静态测试，尽量在早期发现问题，减小后期修改的代价测试人员需要在需求分析阶段开始介入测试工作测试人员需要在了解需求的情况下编写测试计划、测试用例、准备测试环境。分析和测试软件需求定义测试需求59用户需求定义测试需求根据用户需求定义并完善测试需求，以作为整个测试的标准什么是测试需求？测试需求主要解决“测什么”的问题，即指明被测对象中什么需要测试。测试需求通常是以软件开发需求为基础进行分析，通过对开发需求的细化和分解，形成可测试的内容。测试需求应全部覆盖已定义的业务流程，以及功能和非功能方面的需求。60制定的测试需求项必须是可核实的。即，它们必须有一个可观察、可评测的结果，无法核实的需求不是测试需求测试案例：水杯测试61按照软件测试的类型，为全面测试，需要做哪些测试？测试案例：水杯测试62功能测试用水杯装水看漏不漏；水能不能被喝到...界面测试外观是否好看，结构是否合理...性能测试能够装100度的水...安全性测试摔碎后是否容易伤到人...可用性测试是否好端、好拿........测试需求分析过程63需求规格说明书测试要点分析功能交互分析质量特性分析测试类型分析测试需求测试需求采集测试需求分析测试需求评审原始测试需求表测试需求跟踪矩阵评审结论输入输出测试需求案例“人力资源管理系统”原始测试需求表序号软件需求标识原始测试需求描述信息来源13.1.1基本信息管理增加员工信息人事部门招聘专员对于新招聘的职员信息可以录入到HRMIS系统中，主要职员信息如下：姓名、性别、出生日期、政治面貌、文化水平、婚姻情况、家庭住址、身份证号、办公电话、移动电话、紧急情况下的联系人和联系方式、毕业院校、入职时间、岗位及职责，其中，性别包含男、女两个类别；婚姻情况包括未婚、已婚、离异三种情况。人力资源管理系统业务需求说明书删除员工信息删除需用户确认，可以逐条删除或多条一次删除GB/T17544-199823.2.2时间特性要求并发15个用户，平均登录时间小于10秒并发50个用户，平均登录时间小于15秒人力资源管理系统业务需求说明书3隐含需求：在使用中操作错误的易恢复性程序应对关键数据的操作给出警告或在执行前确认GB/T17544-1998测试需求分析65原始测试需求表测试要点分析质量特性分析测试类型分析分析后的原始测试需求质量特性对应表测试需求跟踪矩阵下一活动测试要点分析实例—原始需求需求：添加一条员工培训信息一条完整的培训信息包括培训的主题、证书、内容、起止时间、费用、地点、机构，其中培训的主题、内容、起止时间、费用、机构为必填项。培训的起始时间不能晚于截止时间，培训费用精确到圆角分。每一个输入项的数据规格在数据字典中可以得到。66分析质量特性实例67标识测试要点1输入符合数据字典要求的各信息后执行保存，检查保存是否成功2检查每个输入项的数据长度是否遵循数据字典的要求3检查每个输入项的数据类型是否遵循数据字典的要求4检查“培训费用”是否满足规定的精度要求5检查在培训的起止时间早/晚于截止时间时，增加的记录是否保存成功6检查“培训主题”、“培训内容”、“起止时间”、“培训费用”、“培训机构”是否为必填项7验证系统对数据重复的检查8针对页面中文字、表单、图片、表格等元素，检查每个页面各元素的位置是否协调，各元素的颜色是否协调，各元素的大小比例是否协调9页面信息内容显示是否完整10检查是否有功能标识，功能标识是否准确、清晰11最大化、最小化、还原、切换、移动窗口时是否能正常的显示页面12…….一条完整的培训信息包括培训的主题、证书、内容、起止时间、费用、地点、机构，其中培训的主题、内容、起止时间、费用、机构为必填项。培训的起始时间不能晚于截止时间，培训费用精确到圆角分。每一个输入项的数据规格在数据字典中可以得到。测试要点分析实例—测试要点68质量特性对应表标识测试要点质量特性1输入符合数据字典要求的各信息后执行保存，检查保存是否成功功能适应性

/功能适合性2检查每个输入项的数据长度是否遵循数据字典的要求功能适应性

/功能适合性、可靠性/容错性3检查每个输入项的数据类型是否遵循数据字典的要求功能适应性

/功能适合性、可靠性/容错性4检查“培训费用”是否满足规定的精度要求功能适应性

/功能正确性5最大化、最小化、还原、切换、移动窗口时是否能正常的显示页面易用性/用户界面美观度……质量特性质量子特性功能适应性功能完备性功能正确性功能适合性性能效率时间特性资源利用率容量兼容性共存性互操作性易用性……可靠性成熟性可用性容错性易恢复性测试类型功能测试负载测试压力测试容量测试安全性测试完整性测试接口测试用户界面测试恢复性测试疲劳强度测试配置测试安装性测试兼容性测试……质量子特性质量特性保密性安全性完整性不可否认性责任性真实性模块性易维护性易重用性易分析性易修改性易测试性适应性可移植性易安装性易替换性测试类型分析测试要点分析实例—测试要点70质量特性对应表标识测试要点质量特性测试类型1输入符合数据字典要求的各信息后执行保存，检查保存是否成功功能适应性

/功能适合性功能测试2检查每个输入项的数据长度是否遵循数据字典的要求功能适应性

/功能适合性、可靠性/容错性功能测试、安全性测试、接口测试3检查每个输入项的数据类型是否遵循数据字典的要求功能适应性

/功能适合性、可靠性/容错性功能测试、安全性测试、接口测试4检查“培训费用”是否满足规定的精度要求功能适应性

/功能正确性功能测试5最大化、最小化、还原、切换、移动窗口时是否能正常的显示页面易用性/用户界面美观度用户界面测试………测试需求跟踪矩阵实例71**系统测试需求跟踪矩阵软件需求质量特性对应表软件需求标识软件需求描述标识测试要点测试类型3.1.1基本信息管理增加培训信息一条完整的培训信息包括培训的主题……1输入符合数据字典要求的各信息后执行保存，检查保存是否成功功能测试2检查每个输入项的数据长度是否遵循数据字典的要求功能测试、安全性测试、接口测试3检查每个输入项的数据类型是否遵循数据字典的要求功能测试、安全性测试、接口测试4检查“培训费用”是否满足规定的精度要求功能测试5最大化、最小化、还原、切换、移动窗口时是否能正常的显示页面用户界面测试测试计划的制定过程72分析和测试软件需求定义测试策略定义测试环境定义测试管理编写和审核测试计划测试策略，指的是确定:总的测试范围测试方法测试活动的进入/退出标准自动化测试工具的选择测试软件的编写…测试策略测试策略（测试方案）的内涵：测试策略描述当前测试项目的目标和所采用的测试方法，描述不同测试阶段的测试对象、范围和方法以及每个阶段内所要进行的测试类型。测试策略中需要完成的主要步骤：确定测试范围确定测试方法定义测试标准选择测试工具73确定测试范围某些阶段的测试或者某些内容的测试可以简化例如新系统用到某些原有模块，这些模块无需单元测试当对原有系统进行修改升级时，某些测试不需要例如为某个软件添加打印功能，这个时候文件打开和保存功能就不需要进行很多测试某些测试根本不可能进行新的取款机软件，根本不可能让所有信用卡的持有者在某个时间段去试用，只能模拟74对于一个将被实际使用的软件来说，完全测试是不可能实现的确定测试范围测试过度，则在测试覆盖中存在大量冗余；测试范围过小，则存在遗漏错误的风险。定义测试范围是一个在测试时间、费用和质量风险之间寻找平衡的过程。期望花费更少的时间和费用，就必须承担更大的质量风险。75确定测试范围定义测试范围需要考虑下列一些因素：首先测试最高优先级的需求;测试新的功能和代码或者改进的旧功能;使用等价类划分来减小测试范围;重点测试经常出问题的地方.76确定测试范围定义测试范围需要考虑下列一些因素：首先测试最高优先级的需求;测试新的功能和代码或者改进的旧功能;使用等价类划分来减小测试范围;重点测试经常出问题的地方.77确定测试范围可采用提问单的方式来确定测试范围哪些功能是软件的特色？哪些功能是用户最常用的？哪些功能出错将导致用户不满或索赔？哪些程序是最复杂、最容易出错的？哪些程序是相对独立，应当提前测试的？哪些程序最容易扩散错误？哪些程序是全系统的性能瓶颈所在？哪些程序是开发者最没有信心的？78参与人员:需求分析人员、设计人员、程序员、市场销售人员、公司工程管理人员、客户。选择测试方法在不同的开发阶段，需要选择不同的测试方法：需求分析阶段：静态测试、人工测试概要设计与详细设计阶段：静态测试、人工测试编码和单元测试阶段：静态测试和动态测试、白盒测试、自动化测试集成测试阶段：动态测试、白盒测试、黑盒测试

系统测试阶段：动态测试、黑盒测试验收测试阶段：动态测试、黑盒测试79定义测试标准定义测试标准的目的是设置测试中遵循的规则。需要制订以下几种标准：测试入口标准测试暂停与继续标准测试出口标准80定义测试标准测试的入口标准在什么情况下可以开始某个阶段的测试?测试的入口标准，指的是在开始某个阶段测试之前，需要完成的工作。不同的公司、不同的项目、不同的测试阶段所需要的入口标准是有所差异的，需要测试人员根据实际情况，会同项目组其他成员制定入口标准。81定义测试标准测试的入口标准实例：如在开始系统测试之前，需要完成的工作：完整的软件包(指软件安装光盘和相应的手册)；系统测试计划；系统测试数据；所需要的系统测试环境；软件已经通过了集成测试。82定义测试标准测试暂停与继续标准测试暂停标准就是定义在什么情况下，测试工作需要暂时停止。

例如，发现缺陷数目较多，测试环境未能准备好；测试工具未能准备好或者未完成人员培训。测试继续标准说明的是，当问题被解决，而且能够有方法确认被解决了之后，测试可以继续进行。83定义测试标准测试出口标准定义在什么情况下可以结束某个阶段的测试。以系统测试阶段为例，在测试出口标准中，就会要求所有的测试用例都已经被执行，并且未能通过的测试用例小于某个数值。84问题：一个阶段的出口标准和下个阶段的入口标准是不是一样的？选择测试工具在制定测试计划时，需要确定：在本项目的测试过程中，是否使用自动化测试工具；如果使用，在什么阶段，使用哪种测试工具。在有些情况下，完全的人工测试并不可行，也没有合适的自动化测试工具，就需要编写相应的测试软件。85测试计划的制定过程86分析和测试软件需求定义测试策略定义测试环境定义测试管理编写和审核测试计划测试环境包括软件运行的硬件平台、软件平台，还包括一些特殊的外围设备。在制定测试计划时，需要定义测试工作将在什么样的测试环境中进行。测试环境测试环境贯穿了测试的各个阶段，每个测试阶段中测试环境对测试影响是不一样的。单元测试和集成测试阶段，测试环境通常为开发环境。系统测试和验收测试阶段，测试环境必须模拟并最大限度地接近实际环境。87测试环境测试环境配置的原则：真实干净：不要安装与被测软件无关的软件无毒独立88软件测试环境的要素硬件服务器、客户端、网络连接设备、其它辅助硬件设备软件被测软件运行时的操作系统、浏览器、数据库及其它辅助软件网络网络设备、网络结构、网络系统数据准备测试工具89测试环境因素表90属性不同阶段的测试环境单元集成系统验收人员开发者开发者/测试人员测试人员测试人员/用户硬件O/S程序员的工作台程序员的工作台系统测试机器或区域产品的镜像共存软件无无无/实际的实际的接口无内部的模拟的/实际的产品测试数据源手工生成自动生成产品/手工生成产品测试数据集小小大大策略单元单元组整个系统模拟产品测试计划的制定过程91分析和测试软件需求定义测试策略定义测试环境定义测试管理编写和审核测试计划测试过程中所涉及到的人、活动和工具都很多(特别是在大型软件的测试中)，在制定测试计划时，要对这些因素加以管理。定义测试管理定义测试管理的工作：组建测试小组定义测试进度定义测试里程碑定义检查点管理92定义测试管理93确认工作任务估算工作量编写进度计划定义工作进度的过程：测试计划的制定过程94分析和测试软件需求定义测试策略定义测试环境定义测试管理编写和审核测试计划在上述几项工作完成后，需要编写测试计划文档，并需要被相关人员审核。测试计划阶段的（输入）原始依据是软件需求文档。测试计划阶段的输出是测试计划文档IEEE软件测试计划文档模板95IEEE829测试计划16大纲要1．测试计划标识符一个测试计划标识符是一个由公司生成的惟一值，它用于标识测试计划的版本、等级，以及与该测试计划相关的软件版本。96IEEE829测试计划16大纲要2．简要介绍在测试计划的介绍部分主要是测试软件基本情况的介绍和测试范围的概括性描述。97IEEE829测试计划16大纲要3．测试项目测试项部分主要是纲领性描述在测试范围内对哪些具体内容进行测试，确定一个包含所有测试项在内的一览表。具体要点如下：功能的测试设计的测试整体测试98IEEE829测试计划16大纲要IEEE标准中指出，可以参考下面的文档来完成测试项：

需求规格说明

用户指南

操作指南

安装指南

与测试项相关的事件报告99IEEE829测试计划16大纲要4．测试对象列出了待测的单项功能及功能组合100IEEE829测试计划16大纲要5.不需要测试的功能列出了不测试的单项功能及组合功能并说明不予测试的理由。101IEEE829测试计划16大纲要6．测试方法(策略)测试策略描述测试小组用于测试整体和每个阶段的方法。要描述如何公正、客观地开展测试，要考虑模块、功能、整体、系统、版本、压力、性能、配置和安装等各个因素的影响，要尽可能地考虑到细节，越详细越好，并制作测试记录文档的模板，为即将开始的测试做准备。测试记录具体说明如下:

公正性声明

测试用例

特殊考虑

经验判断

设想102IEEE829测试计划16大纲要7．测试项通过/失败的标准测试计划中这一部分给出了“测试项”中描述的每一个测试项通过/失败的标准。正如每个测试用例都需要一个预期的结果一样，每个测试项同样都需要一个预期的结果。下面是通过/失败的标准的一些例子：

通过测试用例所占的百分比；

缺陷的数量、严重程度和分布情况；

测试用例覆盖；

用户测试的成功结论；

文档的完整性；

性能标准。103IEEE829测试计划16大纲要8．测试中断和恢复的规定测试计划中这一部分给出了测试中断和恢复的标准。

常用的测试中断标准如下：

关键路径上的未完成任务

大量的缺陷

严重的缺陷

不完整的测试环境

资源短缺104IEEE829测试计划16大纲要9．测试完成所提交的材料测试完成所提交的材料包含了测试工作开发设计的所有文档、工具等。

例如，测试计划、测试设计规格说明、测试用例、测试日志、测试数据、自定义工具、测试缺陷报告和测试总结报告等。105IEEE829测试计划16大纲要10．测试任务测试计划中这一部分给出了测试工作所需完成的一系列任务。在这里还列举了所有任务之间的依赖关系和可能需要的特殊技能。106IEEE829测试计划16大纲要11．测试所需的资源

测试所需的资源是实现测试策略所必须的。例如：

人员—人数、经验和专长。他们是全职、兼职、业余还是学生？

设备—计算机、测试硬件、打印机、测试工具等。

办公室和实验室空间—在哪里？空间有多大？怎样排列？

软件—字处理程序、数据库程序和自定义工具等。

其他资源—软盘、电话、参考书、培训资料等。107IEEE829测试计划16大纲要12．测试人员的工作职责测试人员的工作职责是明确指出了测试任务和测试人员的工作责任。有时测试需要定义的任务类型不容易分清，不像程序员所编写的程序那样明确。复杂的任务可能有多个执行者，或者由多人共同负责。108IEEE829测试计划16大纲要13．人员安排与培训需求

前面讨论的测试人员的工作职责是指哪类人员(管理、测试和程序员等)负责哪些任务。人员安排与培训需求是指明确测试人员具体负责软件测试的哪些部分、哪些可测试性能，以及他们需要掌握的技能等。实际责任表会更加详细，确保软件的每一部分都有人进行测试。每一个测试员都会清楚地知道自己应该负责什么，而且有足够的信息开始设计测试用例。培训需求通常包括学习如何使用某个工具、测试方法、缺陷跟踪系统、配置管理，或者与被测试系统相关的业务基础知识。培训需求各个测试项目会各不相同，它取决于具体项目的情况。109测试进度是围绕着包含在项目计划中的主要事件(如文档、模块的交付日期，接口的可用性等)来构造的。作为测试计划的一部分，完成测试进度计划安排，可以为项目管理员提供信息，以便更好地安排整个项目的进度。进度安排会使测试过程容易管理。通常，项目管理员或者测试管理员最终负责进度安排，而测试人员参与安排自己的具体任务。14．测试进度表IEEE829测试计划16大纲要软件测试人员要明确地指出计划过程中的风险，并与测试管理员和项目管理员交换意见。这些风险应该在测试计划中明确指出，在进度中予以考虑。有些风险是真正存在的，而有些最终证实是无所谓的，重要的是尽早明确指出，以免在项目晚期发现时感到惊慌。15．风险及应急措施一般而言，大多数测试小组都会发现自己的资源有限，不可能穷尽测试软件所有方面。如果能勾画出风险的轮廓，将有助于测试人员排定待测试项的优先顺序，并且有助于集中精力去关注那些极有可能发生失效的领域。IEEE829测试计划16大纲要下面是一些潜在的问题和风险的例子：

不现实的交付日期

与其他系统的接口

极其复杂的软件

有过缺陷历史的模块

发生过许多或者复杂变更的模块

安全性、性能和可靠性问题

难于变更或测试的特征风险分析是一项十分艰巨的工作，尤其是第一次尝试进行时更是如此，但是以后会好起来，而且也值得这样做。IEEE829测试计划16大纲要16．审批

审批人应该是有权宣布已经为转入下一个阶段做好准备的某个人或某几个人。测试计划审批部分一个重要的部件是签名页。审批人除了在适当的位置签署自己的名字和日期外，还应该签署表明他们是否建议通过评审的意见。IEEE829测试计划16大纲要系统测试计划系统测试中测试人员使用全面集成的整个系统，以查找在各种系统操作中的错误。系统测试计划的主要内容：项目背景参加人员进度表和任务划分缺陷管理与问题处理...114系统测试的主要范围115商业需求测试（依赖于要做多少功能测试）性能测试压力测试（专项）用户文档/Help/功能测试易用性测试/GUI测试操作环境测试配置/安装测试互操作性测试可靠性/适用性测试备份/恢复测试survivability测试保密测试安全测试验收测试计划验收测试是软件正式发布之前的最后一个测试,是以用户为主体进行的。未来的用户要验证软件的功能和性能能够达到预期目的，包括易用性测试、兼容性测试、安装测试和文档测试等。验收测试计划的主要内容：背景知识参与人员和职责工作程序验收前的准备、验收实施、问题处理质量记录116系统测试/验收测试模版案例目录：引言测试方法与策略测试执行设置测试规约测试规程测试工具人力资源测试进度安排117系统测试/验收测试模版案例引言系统描述（例如，对系统的简短描述）目标（例如，测试计划的目标）假设（例如，计算机可能工作的所有时间等）风险（例如，单元测试没有完成的风险）应急准备（例如，备份过程等）约束条件（例如，资源短缺）批准签字（例如，签署文件的权限）118系统测试/验收测试模版案例测试方法与策略测试范围（例如，将要进行的测试）测试方法（例如，测试工具、黑盒测试）测试类型（例如，单元测试、系统测试、静态测试、动态测试、手工测试、自动化测试等）后勤（例如，定位、网站需求等）回归测试的策略（例如，在每个bulid之间）测试设备（例如，对需要进行测试的场所一般描述）测试规程（例如，缺陷修复验收、缺陷优先级等）119系统测试/验收测试模版案例测试方法与策略测试组织（例如，描述QA/测试小组）测试库（例如，定位及描述）测试工具（例如，捕获/回放回归测试工具）版本控制（例如，控制不同版本的流程）配置构建（例如，控制不同版本的流程）变更控制（例如，管理变更需求的流程）120系统测试/验收测试模版案例测试执行设置系统测试规程（例如，开始标准、准备工作等）设置（例如，测试环境、实验室的详细信息）资源（例如，人员、培训、时间限制）工具计划（例如，具体的工具、包、特殊的软件）测试组织（例如，关于人员、角色、职责的详细描述）121系统测试/验收测试模版案例测试规约功能分解（例如，要测试功能规约中的哪些功能）不需要测试的功能（例如，超出范围的）单元测试用例（例如，具体的单元测试用例）集成测试用例（例如，具体的集成测试用例）系统测试用例（例如，具体的系统测试用例）验收测试用例（例如，具体的验收测试用例）122系统测试/验收测试模版案例测试规程测试用例、脚本、数据开发（例如，开发及维护的流程）测试执行（例如，执行测试的流程）修正（例如，对已发现缺陷进行修复的流程）版本控制（例如，控制软件组件版本的流程）维护测试库自动化测试工具的使用（例如，工具标准）项目管理（例如，问题及缺陷的管理）监控及状态报告（例如，临时报告与总结报告）123系统测试/验收测试模版案例测试工具将要使用的工具（例如，具体的工具及性能）安装和设置（例如，使用说明书）支持和帮助（例如，供应商帮助）124系统测试/验收测试模版案例人力资源所需技能（例如，手动/自动化测试技能）角色和职责（例如，什么人什么时候做什么事情）数量和时间需求（例如，资源平衡）培训需求（例如，对人员进行工具培训）125系统测试/验收测试模版案例测试进度安排制定测试计划（例如，开始及结束时间）设计测试用例（例如，由测试类型决定的开始及结束时间）创建测试用例（例如，由测试类型决定的开始及结束时间）执行测试用例（例如，由测试类型决定的开始及结束时间）问题报告（例如，开始及结束时间）开发测试总结报告（例如，开始及结束时间）编写测试总结报告（例如，开始及结束时间）126敏捷开发下的测试计划可选形式轻量级测试计划测试矩阵测试表格白板自动化测试列表127轻量级测试计划轻量级测试计划本章内容软件测试流程软件测试制品测试用例软件测试环境软件测试团队软件测试计划缺陷管理测试管理工具130缺陷管理的目标确保每个被发现的缺陷都能够被解决如何理解缺陷的解决？收集缺陷数据并根据缺陷趋势曲线识别测试过程的阶段收集缺陷数据并在其上进行数据分析，作为组织的过程财富131132缺陷跟踪管理软件应用较广的缺陷跟踪管理软件：IBM公司的ClearQuestCompuware公司的TrackRecord软件Mozilla公司的Buzilla软件RTC也可以实现TestCenter也可以缺陷的属性缺陷的基本信息标题、状态、严重程序、优先级提交人、提交时间所属项目/模块解决人、解决时间处理人、处理结果描述、处理时间、处理工作量产生原因验证人、验证结果描述、验证时间133缺陷的跟踪管理目标（1）确保每个被发现的缺陷都能够被解决。这里解决的意思不一定是修正，也可能是其它处理方式（如在下一个版本中修正或不修正）。总之，对每个缺陷的处理方式必须在开发组织中达成一致。（2）收集缺陷数据并根据缺陷趋势曲线识别测试过程的阶段。确定测试过程是否结束的方式有很多种，其中通过缺陷趋势曲线来确定是常用并且较为有效的一种方式。（3）收集缺陷数据并在其上进行数据分析，这是组织的过程财富。134缺陷的属性135可追踪信息缺陷ID唯一的缺陷ID，可以根据该ID追踪缺陷缺陷基本信息缺陷状态一般分为“初始化”、“待分配”、“待修正”、“待验证”、“待评审”、“关闭”6种状态缺陷标题描述缺陷的标题缺陷的严重程度描述缺陷的严重程度，一般分为“紧急”“致命”“严重”“一般”“建议”5种级别缺陷的优先级描述缺陷的紧急程度，一般分为“紧急”“很高”、“高”“中”“低”5种级别缺陷提交人缺陷提交人的名字缺陷提交时间缺陷提交的时间缺陷所属项目/模块缺陷所属的项目和模块，最好能较精确地定位至模块缺陷指定解决人缺陷指定的解决人，在缺陷处于“待分配”状态时由项目经理指定相关开发人员修改缺陷指定解决时间项目经理指定的开发人员修改此缺陷的截止日期缺陷处理人最终处理缺陷的处理人缺陷处理结果描述对处理结果的描述，如果对代码进行了修改，要求在此处体现出该修改缺陷处理时间缺陷处理的时间缺陷产生原因缺陷产生的根本原因缺陷处理工作量处理缺陷耗费的工作量，单位一般是人时缺陷验证人对被处理缺陷验证的验证人缺陷验证结果描述对验证结果的描述，有“通过”“不通过”两种结果缺陷验证时间对缺陷验证的时间缺陷的详细描述

对缺陷的详细描述。之所以把这项单独列出来，是因为对缺陷描述的详细程度直接影响开发人员对缺陷的修改，描述应该尽可能详细测试环境说明

对测试环境的描述必要的附件

对于某些文字很难表达清楚的缺陷，使用图片等附件是必要的缺陷的严重程度定义在对缺陷进行描述的所有属性中，对缺陷恰当的定义严重程度是最重要的因为严重程度的高低意味着对缺陷进行处理的优先级别以及重视程度。136缺陷的严重程度137严重程度说明现象描述（部分例子）处理优先级紧急致命错误，会导致整个系统失效由于程序所引起的死机,非法退出；死循环；数据库发生死锁；因错误操作导致的程序中断；与数据库连接错误；数据通讯错误；导致测试无法继续执行。可能影响其他模块功能。立即处理或解决缺陷的严重程度138严重程度说明现象描述（部分例子）处理优先级致命很严重错误，会造成系统的部分功能失效程序错误；程序接口错误；数据库的表、业务规则、缺省值未加完整性等约束条件；关键功能完全不能实现；程序运行不稳定，如出现不可继续进行操作的错误；程序运行出现难以捕捉和不可再现的错误；响应其他业务流程的错误。在发现的几天内完成缺陷的严重程度139严重程度说明现象描述（部分例子）处理优先级严重一般严重错误，影响用户的操作操作界面错误；打印内容、格式错误；简单的输入限制未放在前台进行控制；删除/退出操作未给出提示。数据库表中有过多的空字段；功能不完整，如菜单、按钮不响应；对错误没有处理信息。系统上线前必须修复完成缺陷的严重程度140严重程度说明现象描述（部分例子）处理优先级一般一般性错误，可能会影响用户操作界面不规范；辅助说明描述不清楚；输入输出不规范；提示窗口文字未采用行业术语；可输入区域和只读区域没有明显的区分标志。正常排队等待修复或方便时修复缺陷的严重程度141严重程度说明现象描述