《软件测试计划》PPT课件.ppt

第二章 测试计划,主要内容,1,2,3,4,5,软件测试计划在测试流程中所处的地位？,测试计划制定的关键步骤？,如何制定有效的测试计划？,如何防止测试计划被束之高阁？,如何定义测试环境？,软件测试阶段组成,测试计划,测试开发,测试执行,中国有句古话：凡是预则立，不预则废,做事情时事先计划的重要,管理学中的计划,指对我们如何能达到目标的描述,计划,做什么？,怎么做？,IEEE定义的测试计划,测试计划： 一个叙述了预定的测试活动范围、途径、资源及进度安排的文档。 它确定了测试项、被测特征、测试任务、人员安排以及与计划相关的风险。 三要素： 时间 资源 范围 其他方面 策略 风险控制,计划的作用,计划能给管理者和被管理者指明前进的方向 计划可以减少不确定性对组织的影响和冲击 计划可以减少无序和浪费 计划有利于管理和控制,1. 为什么要编写测试计划？ 领导能够根据测试计划做宏观调控，进行相应资源配置等； 测试人员能够了解整个项目测试情况以及项目测试不同阶段的所要进行的工作等； 便于其他人员了解测试人员的工作内容，进行有关配合工作 2. 什么时间开始编写测试计划？ 需求分析后，在整个测试工作过程中，不断修改 3. 由谁来编写测试计划？ 具有丰富经验的项目测试负责人,关于测试计划,测试计划的核心活动,1.确定测试策略 2.确定测试系统（软件和硬件） 3.预估工作量（资源和时间进度计划） 4.评估事件进度风险并准备风险缓解计划 5.准备并复查测试计划文档,测试计划的设计与实现,取得需求文档,确定测试策略,确定测试系统,测试设计和实现,复查测试计划,预估测试工作量,需求规格说明书,1.测试的范围（将要测试什么） 2.测试方法（如何完成测试） 3.测试入口/退出条件和质量检查点 4.自动化策略,1.测试构架 2.测试环境 3.测试配置,1.确定任务 2.预估工作量 3.确定时间进度计划,1.编写策略、系统、工作量和时间进度文档 2.与项目团队一起复查测试计划,需求分析过程 收集用户需求 编写需求定义文档 编写软件功能说明 审核软件需求文档,测试软件需求（1/8）,测试软件需求（2/8）,如何确定测试需求 确定测试内容 或是确定测试的具体对象,确定测 试需求,软件需 求规约,用户手册,软件设 计文档,测试软件需求（3/8）,功能测试需求： 一个明确的功能特性可以生成一条测试需求 性能测试需求 通常包含在“补充需求”中的“非功能性需求”,非功能性需求,软件需求规约,执行某项业务 时的相应时间,资源占用率,功能性需求,可靠性测试需求,易用性测试需求,安全测试需求,兼容性测试需求,需求分析中测试人员工作 理解需求，参与审核需求文档 理解项目的目标、限制，了解用户应用背景 编写测试计划 准备资源,测试软件需求（4/8）,测试需求文档： 具有清晰的格式和文档结构 需求的内容正确 需求的内容完整 需求具有可行性 必要性 对不同的需求的优先级进行定义 描述明确、无歧义、上下文一致 可证实和可靠性 可修改性 可追踪 需求文档被及时更新,测试软件需求（5/8）,需求测试的内容： 需求文档是否符合公司的格式要求？ 需求是否正确？ 要保证需求文档中所描述的内容是真实可靠的 这是“真正的”需求吗？描述的产品是否就是要开发的产品？ 需求是否完备？列出的需求是否能减去 一部分？ 需求是否可实现？ 需求是否合理？ 需求是否可测？,测试软件需求（6/8）,需求测试的方法： 复查 (Review) 复查一般是让工作中合作者检查产品并提出意见。同级互查可以面对面进行，也可以通过E-Mail实现，并没有统一标准。发现文档缺陷同级互查的能力是三种方法中最弱的。 走查 (Walkthrough) 相比较审查走查较为宽松，其事先需要收集数据，也没有输出报告的要求。 审查 (Inspection) 审查是为发现缺陷而进行的。关键组件的审查通过会议进行，会前每个与会者需要进行准备，会议必须按规定的程序进行，缺陷被记录并形成会议报告。审查被证明是非常有效的发现缺陷的方法。,测试软件需求（7/8）,定义测试需求,定义,测 试 需 求,根据用户需求定义并完善测试 需求，以作为整个测试的标准,测试软件需求（8/8）,测试计划的设计与实现,取得需求文档,确定测试策略,确定测试系统,测试设计和实现,复查测试计划,预估测试工作量,需求规格说明书,1.测试的范围（将要测试什么） 2.测试方法（如何完成测试） 3.测试入口/退出条件（测试标准） 4.自动化策略,1.测试构架 2.测试环境 3.测试配置,1.确定任务 2.预估工作量 3.确定时间进度计划,1.编写策略、系统、工作量和时间进度文档 2.与项目团队一起复查测试计划,测试策略（1/5）,确定测试范围 问题： 测试过度 测试不足 某些阶段的测试或者某些内容的测试可以简化 当对原有系统进行修改升级时，某些测试不需要 某些测试根本不可能进行,测试策略（2/5）,确定测试顺序 先测优先级最高的需求 对新功能和修改功能的代码进行测试 运用等价划分技术和边界值分析技术减少测试工作量 测试那些最有可能出现问题的地方 关注用户最常使用的功能和配置情况等,测试策略（3/5）,确定测试方法,测试策略（4/5）,测试标准 入口标准：描述在开始之前需要做哪些工作 出口标准：描述在怎样的情况下可以结束测试 暂停/继续测试： 描述如果缺陷妨碍测试进行下去，会发生什么事情。如果情况很糟，无法执行计划的测试，则应暂停测试，等完成修复工作后，再完成测试工作。 通过/失败标准 执行每项测试应该有一个明确的预期结果。如果得到了预期的结果，测试就通过。否则表示测试失败。,测试策略（5/5）,自动化测试工具的选择 是否使用自动化测试工具，哪个阶段用什么工具 好处： 能够很好进行性能测试和压力测试 能够改进回归测试 能够缩短测试周期 能够提高测试工作的课重复性 测试软件的编写,测试计划的设计与实现,取得需求文档,确定测试策略,确定测试系统,测试设计和实现,复查测试计划,预估测试工作量,需求规格说明书,1.测试的范围（将要测试什么） 2.测试方法（如何完成测试） 3.测试入口/退出条件（测试标准） 4.自动化策略,1.测试构架 2.测试环境 3.测试配置,1.确定任务 2.预估工作量 3.确定时间进度计划,1.编写策略、系统、工作量和时间进度文档 2.与项目团队一起复查测试计划,确定测试系统,确定测试系统 测试系统不仅指用于测试的硬件，也包括测试架构以及测试配置 测试架构：测试用例的组织形式 测试配置：软硬件环境,测试计划的设计与实现,取得需求文档,确定测试策略,确定测试系统,测试设计和实现,复查测试计划,预估测试工作量,需求规格说明书,1.测试的范围（将要测试什么） 2.测试方法（如何完成测试） 3.测试入口/退出条件（测试标准） 4.自动化策略,1.测试构架 2.测试环境 3.测试配置,1.确定任务 2.预估工作量 3.确定时间进度计划,1.编写策略、系统、工作量和时间进度文档 2.与项目团队一起复查测试计划,预测工作量（1/2）,预测工作量 确定要完成的任务：测试用例的组织形式 确定每个任务的所需工作量 确定完成每个任务的时间 为测试工作建立详细的时间进度计划和里程表,预测工作量（2/2）,评估进度风险 开始测试时，所需硬件没有到位 开始测试时，测试的系统还没有布置好 开始测试时，测试用例还没有准备好 测试过程中，需求发生变更 测试过程中，用户界面发生变更,测试计划的设计与实现,取得需求文档,确定测试策略,确定测试系统,测试设计和实现,复查测试计划,预估测试工作量,需求规格说明书,1.测试的范围（将要测试什么） 2.测试方法（如何完成测试） 3.测试入口/退出条件（测试标准） 4.自动化策略,1.测试构架 2.测试环境 3.测试配置,1.确定任务 2.预估工作量 3.确定时间进度计划,1.编写策略、系统、工作量和时间进度文档 2.与项目团队一起复查测试计划,复查测试文档,详细描述工作的范围 估计定义测试用例和实施测试所需工作 确定所需资源（人、硬件、软件和工具） 为各个人物分配资源 制定进度表 确定进度安排或质量风险 制定解决风险的应急计划 追踪项目进展并采取纠正措施 在适当的时候重新定制 向整个项目提供测试状态的可视性 对失败或堵塞测试纠正后重新测试,测试计划是一份描述软件测试工作的目标、策略、方法和重点的文档 测试计划的准备过程是思考检查并确认一个软件产品的可接受性的一个有用的方法,测试计划测试计划文档,测试计划的目的,尽早地明确测试工作内容（范围）、测试工作的方法以及测试工作所需要的各种资源。 所有涉及到测试工作的人员，尽快将下一步测试工作需要考虑的问题和准备的条件落实。 测试计划工作的重点在于：对当前工作任务的准备和规划以及信息的交流。,增强测试计划的实用性 坚持“5W1H”规则，明确内容与过程 采用评审和更新机制，保证测试计划满足实际需求 测试计划和测试策略,测试计划注意事项,测试计划编写6要素？（5W1H）,where,what,when,why,为什么要进行这些测试,相应文档，缺陷的存放位置，测试环境等,测试不同阶段的起止时间,测试哪些方面，不同阶段的工作内容,who,项目有关人员组成，安排哪些测试人员进行测试,how,如何去做，使用哪些测试工具以及测试方法进行测试,测试类型和目的,测试阶段,可以用表格明确测试的执行情况 不同测试阶段对测试内容和测试方法考虑不同 如：单元测试考虑代码的覆盖 系统测试考虑需求的满足情况,测试方法,通过程序界面执行程序，还是直接从代码中找缺陷？,是否需要导入自动化测试工具来改善测试策略？,如果需要导入测试工具，哪些测试仍需要手工测试？,如何判断测试工作完毕？,测试的目标是什么，哪些可能对测试执行产生影响？,功能测试（1/2）,测试目标 确保所有的被测对象功能正常 测试方法 至少为每条测试需求设计两个测试用例，一个用来验证是否实现了应有的功能，一个用来检查功能的实现是否存在问题 符合业务规则的操作和数据是否可以得到预期的结果？ 不符合业务规则的操作和数据是否都被拒绝接受，并提供出正确的、容易理解的提示信息。 所有的业务规则的实现是否同需求中的描述相互一致 系统测试阶段所有的测试用例均采用手工方式通过对用户界面的操作来执行。,功能测试（2/2）,完成标准： 对系统测试阶段：必须保证所有准备执行的测试用例全部被执行，并且保证所有提交的缺陷全部被正确地解决。 特殊事项的考虑 如果由于某项原因导致测试时间被缩短，将会考虑按照测试用例的优先级重新选择测试用例,性能测试,测试目标 确保系统在一般状态和极限状态下，都可以保持正常的响应速度和最大用户连接数量 测试方法 关于极限的模拟，将考虑使用以下几个方法实现： 在服务器端启动大量事务以模拟服务器端系统资源被大量占用的情况 使用某软件模拟网络拥挤的情况 启动数据库事务来模拟数据库端对数据进行修改时的竞争情况 使用某软件录制性能测试脚本，虚拟50个用户同时操作的情况，并在10台计算机上连续运行7天 准备超过100万条数据，验证对大量数据进行查询和汇总的时间,确定测试资源（1/4）,确定测试资源,确定测试资源（2/4）,人力资源 测试工作完成需要多少人？ 参与者都需要哪些技能？ 每个人的工作准备如何分配？ 是否需要专门的硬件工程师来协助网络和系统维护？ 是否需要其他部门的同事共同参与？,确定测试资源（3/4）,硬件和软件资源 测试工作共需要多少计算机？ 计算机从何处调配？ 有没有为测试环境的搭建单独准备一台服务器？ 是否准备了不同配置的测试用例执行机器？ 如果需要介入internet专线，是否可以提供？ 如果测试不同硬件的兼容性，是否有足够多的硬件资源可以使用？ 常用的系统软件和软件工具在哪里可以找到？ 是否需要把测试用机的操作系统统一？,确定测试资源（4/4）,其他资源 文档的存放位置？ 项目参与者的角色如何？ 项目参与者的联系方式？,时间表（1/3）,某项工作的开始时间？ 可以写相对时间，如，从开发部门提交可供测试的版本开始，而非具体的年月日 某项工作需要多少时间完成？ 评估工作量+测试效率评估=确定测试用时间 评估工作量 被测对象的数量 业务复杂度等 测试效率的评估 测试活动参与者的数量 可以投入的工作时间 参与者的技术水平和工作效率 测试资源和支持工作是否到位,时间表（2/3）,某项工作需要多长时间完成？ 一个简单的方法：参考过去的经验 查找过去的测试计划和日志 找到工作量相仿的产品 参与者多少？ 工作用时多少？ 单位工作效率如何？ 根据上述历史数据，可以估算出本次的工作用时,时间表（3/3）,逐步提高测试计划制定者对工作效率和时间的把握,词汇表,生成测试计划文档,讨论文档的可能性,使用文档模板,相关人员,分发,如何不让测试计划束之高阁（1/2）,原因：测试计划缺乏参考价值 措施： 上面讲的完成测试计划的方法并不是完成该项工作的全部方法 放那些会对测试计划产生影响的因素发生变化时，要及时跟新测试计划的相关内容 软件需求和软件设计发生变化 同时调离项目 测试西苑的配备无法达到要求 测试计划发生重大调整，要考虑工作量是否需要重新估算，是否应调整测试用时间,如何不让测试计划束之高阁（2/2）,措施： 计划不是用来应付领导或客户的，而是用来指导实际工作的，因此，计划的内容要正确、详实、具有可行性 若项目过于庞大，可以尝试着把工作阶段分几个更小的阶段来设计完成。把测试工作控制在自己的能力范围内。,风险评估（1/6）,确定测试需求,风险评估,1.确定测试对象的优先级 2.确定测试实现的先后顺序,把注意力集中到最关键、最有意义和优先级最高的测试对象上,风险评估（2/6）,风险评估的考虑要点 重要性、严重性 原因 可能性,风险评估（3/6）,重要性和严重性 从实际业务考虑 确定测试对象的重要性和严重性 如：这个测试对象在系统中起到什么样的作用；如果该测试对象失效，其所带来的后果？ 重点考虑后果：可以设置级别和分值，以帮助分析,风险评估（4/6）,原因 如果某个测试对象失效，那么导致其失效的原因是什么？ 分析失效产生的原因，原因如何出现 分析失效对系统其他部分的运行是否会产生影响 对导致被测对象失效的原因进行风险评估,风险评估（5/6）,可能性1 如果一个被测对象失效，那么出现该情况的几率多大？出现几率越大，风险越大。 对于频繁发生的业务或经常使用的功能，发生问题的几率同样会提升。 对于低版本中出现的问题，在高版本中发生的几率也会比较高。,风险评估（6/6）,可能性2 需求 变更，带来的软件改动，可能导致问题的出现 业务关系复杂，交叉多，可能导致问题的出现 使用了大量的第三方软件、空间，或直接移植代码，可能导致问题的出现,测试的优先级（1/4）,确定优先级的三项指标,风险,用户协议,开发部门的 进度安排,测试的优先级（2/4）,风险,测试的优先级（3/4）,用户协议 如果在同用户签订的软件开发合同中，明确了系统各个部分发布的时间，则可以将其作为测试优先级的一个指标,测试的优先级（4/4）,开发部门的进度安排 具体测试开始要求开发部门提交可测试的程序，方可开始测试 没有必要把所有工作全部都第一时间完成 对开发部门优先提供的程序，可优先考虑。对于需要其他业务辅助支持的功能，而该辅助功能未完成的情况下，可降低其优先级,确定测试策略（1/2）,1.需要扎实的测试和开发技术为基础,2.对被测软件系统业务流程要熟悉,确定测试策略（2/2）,测试策略的描述内容 不同的测试阶段需要考虑的测试类型和具体目标 需要哪些测试技术，不同测试阶段结束的标准是什么？ 一些对测试工作可能产生影响的因素,内容1：描述测试工作中采用的测试方法,内容2：描述测试的目标,测试计划的编写模板