《软件测试计划》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：描述测试的目标,测试计划的编写模板GB/T8567-2006计算机软件文档编制规范,从软件的编码、测试到用户实际使用，存在着：开发环境、测试环境和用户环境。“环境”，指的是被测试软件所运行的软件环境和硬件环境。测试环境是测试人员为进行软件测试而搭建的环境，一般情况下，将包括多种典型的用户环境。,测试环境（1/2）,测试环境的环境项计算机平台操作系统浏览器软件支持平台外部设备网络环境其它专用设备,测试环境（1/2）,确认工作任务工作任务可以分为两类：一类是可以直接和需求文档对应起来的，另外一类和需求文档没有直接的关联。在需求文档中，对需求中的每一个条目，都应该有相应的测试工作与之对应起来。确认好测试任务后，还应该排列这些任务的优先级。,定义工作进度（1/3）,与需求文档没有直接关联的任务：开发和安装专用测试工具学习使用测试工具将测试用例编写为脚本或数据文件重新运行以前没通过的测试用例编写测试计划人员培训与程序员之间的交流与客户之间的交流,定义工作进度（2/3）,估算工作量工作量可以使用“人*日”、“人*月”、“人*年”这样的单位。测试工作量的估算可以采用以下方法：建立详细的工作分解结构分析以往项目，寻找历史数据,定义工作进度（3/3）,