测试工作流程.ppt

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,2005-5-31,*,测试工作流程简介,本,PPT,将介绍如何结合使用,Rational,工具管理整个测试工作流程,(RUP,定义的,5,个主要的测试活动,),测试的计划,测试的设计,测试的实施,测试的执行,测试的评估,2005-5-31,1,流程简介,一、测试计划,二、测试用例设计,三、测试准备,四、测试执行,五、缺陷管理,六、测试停止,七、测试总结,2005-5-31,2,一、测试计划,测试工程师根据测试组长在版本库中位置为,emed4managementplantestplaning,下的,emed4-plan-test.mpp,文档中规定的关键活动来制定测试计划,2005-5-31,3,测试计划,根据测试项目的要求，使用,testmanager,制定测试计划，制定测试计划的目的是确定和描述要实施和执行的测试，这是通过生成包含测试需求和测试策略的测试计划来完成的。,2005-5-31,4,测试计划,创建测试计划：,在,testmanager,中的测试资产,planning tab,中可以通过,new test plan,来创建测试计划,在创建测试计划的时候，我们要确定测试计划的所有人，测试计划的配置关联和迭代关联,2005-5-31,5,测试计划,2005-5-31,6,二、测试用例设计,在testmanager,里进行测试用例的设计,testmanager,使用测试用例文件夹来分层次的管理测试用例，我们可以通过这种方式对我们的,4.0,的系统功能按照一层层的关系来建立，例如：,标准数据,基础数据、机构数据、产品数据,药品信息、产品信息这样的结构,这样的结构和我们的需求文档是相对的，查找起来比较方便,2005-5-31,7,测试用例设计,创建测试用例文件夹的方法是在,TestManage,右面的窗口点击测试计划的右键选择,Inster,Test Case Folder,我们按照系统的层次来创建测试用例文件夹，一般第一层是子系统的名称，下一层是一级功能菜单的名称，再下一层是二级功能菜单的名称，再下面是对应的功能按钮的名称，功能按钮下挂的才是各个场景的测试用例。,2005-5-31,8,测试用例设计,2005-5-31,9,测试用例设计,根据项目的要求，配置测试用例文件夹的配置关联和迭代关联,在最后一层测试用例文件夹下要加入测试用例，选中该文件夹点击右键选择,Instert,Test Case,在,Test Inputs Tab,中可以关联选择该测试用例对应的需求文档的部分（测试输入），在,Implementation Tab,中选择该测试用例所对应的手工脚本，此外前置条件，后置条件，和测试用例的验收标准也是必须要填写的。,2005-5-31,10,测试用例设计,2005-5-31,11,测试用例设计,手工测试脚本的编写：,通过,Rational,ManualTest,实现,在,ManualTest,中我们要描述出每个用例场景的操作步骤和检查点,操作步骤即我们通常所说的测试步骤，检查点可以认为是期望结果。我们在这里可以利用检查点来验证链接页面，页面数据项名称，系统提示等的正确性。并将手工脚本和测试用例进行关联，一个测试用例只编写一个测试脚本，当一个测试用例关联一个自动化脚本和一个手工脚本时，自动化脚本将默认被执行。,2005-5-31,12,测试用例设计,步骤,查证点,2005-5-31,13,三、测试的准备,对测试用例和测试文档的学习（考核点）,对所要使用的测试工具的学习和操作（考核点）,所需环境的搭建,测试数据的准备（特别的项目中考虑）,2005-5-31,14,四、测试的执行,测试用例的运行,测试结果的查看,2005-5-31,15,测试用例的运行,选择要运行的测试用例，点击右键选择,run,2005-5-31,16,测试用例的运行,在,run test cases,窗口中，可以配置要运行的测试用例列表，和运行测试用例的计算机，默认为本地计算机,完成对运行测试用例的配置后，点击,ok,会弹出,Run Manual Test Script window,窗口,2005-5-31,17,测试用例的运行,测试结果,执行手工测试脚本生成日志,2005-5-31,18,测试用例的运行,这就是我们在,Rational,ManualTest,中编写的手工测试脚本，在脚本的,result,列对于步骤描述行显示,check box,选择框，对于查证点行显示下拉选择框，下拉框中可以选择,pass,、,fail,、,none,我们在运行手工测试脚本进行测试时,根据实际测试时每一步的执行情况,把实际的测试结果记录在,Run Manual Test Script window,这个页面，这样我们在日志中就可以清楚的看到每个测试用例的执行情况，是通过还是出错，点击,Done,按钮，系统自动弹出,Test Log,界面，显示执行的结果,2005-5-31,19,测试结果的查看,执行一组,suite,，测试用例，测试脚本之后,TestManager,写结果到一个测试日志中，测试日志记录在,Results Tab,的,Builds,目录下，日志名称和测试用例的一致。双击后在窗口的右侧可以显示,Test Log,2005-5-31,20,测试结果的查看,2005-5-31,21,测试结果的查看,TestManager,中的,TestLog,窗口包含了测试日志摘要（,Test Log Summary,）区域，测试用例结果（,Test Case Results,）标签，和细节（,Details,）标签。在,Test Log,窗口中可以通过点击,Test Case Results,标签来获得每个测试用例总的结果,是通过还是失败？,Test Case Results,标签展现一个测试用例的执行结果。首次打开一个测试日志并点击,Test Case Results,标签时，这里显示的,Interpreted Result,是系统执行后产生的结果，但我们根据实际的分析情况可以修改结果。修改后要,promoted,该结果，指明该结果有意义,2005-5-31,22,测试结果的查看,Test Log,窗口中的,Details,标签包含日志事件，事件对应了我们手工测试脚本的每一个步骤和检查点。如下图：,2005-5-31,23,测试结果的查看,Details,里的结果只能查看不能修改。对于,Result,为,Fail,的记录可以点击右键选择“,Submit,Defedt,”,就可以直接关联到,clearquest,中的提交,BUG,功能中了。点击右键选择“,Properties”,可以查看详细信息。,2005-5-31,24,五、缺陷管理,Rational,使用,CQ,进行缺陷的管理。,Details,里的结果，对于,Result,为,Fail,的记录点击右键选择“,Submit,Defedt,”,将出现,CQ,登陆界面，这时可以使用,CQ,登陆帐号登陆,CQ,提交缺陷。,2005-5-31,25,五、缺陷管理,2005-5-31,26,五、缺陷管理,系统会自动分配一个,ID,相关人员在填写、增加、修改、删除,Bug,管理系统信息时，应按照,Bug,提交规范,中的规定进行。,Bug,的状态、优先级、产生阶段等按照在,CQ,中定义的选项执行。,2005-5-31,27,五、缺陷管理,缺陷管理流程,2005-5-31,28,五、缺陷管理,2005-5-31,29,五、缺陷管理,回归测试,2005-5-31,30,回归测试,回归测试测试的步骤：,当更改完一批,Bug,或测试完一阶段，均可进行测试版本更新，进入下一阶段的回归测试，程序更新需项目经理发,mail,通知测试组统一进行。回归测试先验证已修改的,Bug,，再进行相关测试：,1),对于,Fixed,状态的,Bug,验证通过后将,Bug,状态置为,“,Close,”,，未成功修改的,Bug,状态置为,“,Reopen,”,；,2),Rejected,状态的,Bug,由测试人员和实施人员协商后确定,Bug,类型，若确认为,Bug,需要进行,Debug,的，将状态置为,“,Reopen,”,；,3),Deferred,状态的,Bug,须得到项目总控或客户确认，,Deferred,状态的,Bug,一旦确定开始,Debug,的，将状态置为,“,Reopen,”,。,2005-5-31,31,六、测试停止,项目测试的结束,2005-5-31,32,项目测试的结束,测试结束后，测试负责人应编制,测试报告,，内容须包括以下几个方面：,1,）对该阶段工作进行综合评价，包括测试工作效率、资源消耗情况、测试技术和工具的采用以及测试用例的质量等；,2,）对测试结果进行概述，对该版本软件质量进行综合性的评价；,3,）对测试过程中的经验、教训进行总结。,2005-5-31,33,七、测试总结,项目结束后，测试人员需要对测试项目进行总结：内容须包括以下情况：,1,）项目阶段历时,2,）实际测试工作是否与预想的进度一致,有多少差异,如何使进度差异减小，有哪些好的测试经验或方法有哪些需要改进地方,3,）测试新需求的过程与预想的是否一致，在测试过程中吸取到什么教训,4,）沟通和协调管理上的是否存在问题,5,）时间上的观点,6,）对测试流程的建议和发现的问题,2005-5-31,34,