测试工作流程

测试工作流程简介本PPT将介绍如何结合使用Rational工具管理整个测试工作流程(RUP定义的5个主要的测试活动)测试的方案测试的设计测试的实施测试的执行测试的评估2005-5-311流程简介一、测试方案二、测试用例设计三、测试准备四、测试执行五、缺陷管理六、测试停止七、测试总结2005-5-312一、测试方案测试工程师根据测试组长在版本库中位置为emed4\management\plan\testplaning下的emed4-plan-test.mpp文档中规定的关键活动来制定测试方案2005-5-313测试方案根据测试工程的要求，使用testmanager制定测试方案，制定测试方案的目的是确定和描述要实施和执行的测试，这是通过生成包含测试需求和测试策略的测试方案来完成的。2005-5-314测试方案创立测试方案：在testmanager中的测试资产planningtab中可以通过newtestplan来创立测试方案在创立测试方案的时候，我们要确定测试方案的所有人，测试方案的配置关联和迭代关联2005-5-315测试方案2005-5-316二、测试用例设计在testmanager里进行测试用例的设计testmanager使用测试用例文件夹来分层次的管理测试用例，我们可以通过这种方式对我们的4.0的系统功能按照一层层的关系来建立，例如：标准数据>根底数据、机构数据、产品数据>药品信息、产品信息这样的结构这样的结构和我们的需求文档是相对的，查找起来比较方便2005-5-317测试用例设计创立测试用例文件夹的方法是在TestManage右面的窗口点击测试方案的右键选择InsterTestCaseFolder我们按照系统的层次来创立测试用例文件夹，一般第一层是子系统的名称，下一层是一级功能菜单的名称，再下一层是二级功能菜单的名称，再下面是对应的功能按钮的名称，功能按钮下挂的才是各个场景的测试用例。2005-5-318测试用例设计2005-5-319测试用例设计根据工程的要求，配置测试用例文件夹的配置关联和迭代关联在最后一层测试用例文件夹下要参加测试用例，选中该文件夹点击右键选择InstertTestCase,在TestInputsTab中可以关联选择该测试用例对应的需求文档的局部〔测试输入〕，在ImplementationTab中选择该测试用例所对应的手工脚本，此外前置条件，后置条件，和测试用例的验收标准也是必须要填写的。2005-5-3110测试用例设计2005-5-3111测试用例设计手工测试脚本的编写：通过RationalManualTest实现在ManualTest中我们要描述出每个用例场景的操作步骤和检查点操作步骤即我们通常所说的测试步骤，检查点可以认为是期望结果。我们在这里可以利用检查点来验证链接页面，页面数据项名称，系统提示等的正确性。并将手工脚本和测试用例进行关联，一个测试用例只编写一个测试脚本，当一个测试用例关联一个自动化脚本和一个手工脚本时，自动化脚本将默认被执行。2005-5-3112测试用例设计步骤查证点2005-5-3113三、测试的准备对测试用例和测试文档的学习〔考核点〕对所要使用的测试工具的学习和操作〔考核点〕所需环境的搭建测试数据的准备〔特别的工程中考虑〕2005-5-3114四、测试的执行测试用例的运行测试结果的查看2005-5-3115测试用例的运行选择要运行的测试用例，点击右键选择run2005-5-3116测试用例的运行在runtestcases窗口中，可以配置要运行的测试用例列表，和运行测试用例的计算机，默认为本地计算机完成对运行测试用例的配置后，点击ok会弹出RunManualTestScriptwindow窗口2005-5-3117测试用例的运行测试结果执行手工测试脚本生成日志2005-5-3118测试用例的运行这就是我们在RationalManualTest中编写的手工测试脚本，在脚本的result列对于步骤描述行显示checkbox选择框，对于查证点行显示下拉选择框，下拉框中可以选择pass、fail、none,我们在运行手工测试脚本进行测试时根据实际测试时每一步的执行情况把实际的测试结果记录在RunManualTestScriptwindow这个页面，这样我们在日志中就可以清楚的看到每个测试用例的执行情况，是通过还是出错，点击Done按钮，系统自动弹出TestLog界面，显示执行的结果2005-5-3119测试结果的查看执行一组suite，测试用例，测试脚本之后TestManager写结果到一个测试日志中，测试日志记录在ResultsTab的Builds目录下，日志名称和测试用例的一致。双击后在窗口的右侧可以显示TestLog2005-5-3120测试结果的查看2005-5-3121测试结果的查看TestManager中的TestLog窗口包含了测试日志摘要〔TestLogSummary〕区域，测试用例结果〔TestCaseResults〕标签，和细节〔Details〕标签。在TestLog窗口中可以通过点击TestCaseResults标签来获得每个测试用例总的结果――是通过还是失败？TestCaseResults标签展现一个测试用例的执行结果。首次翻开一个测试日志并点击TestCaseResults标签时，这里显示的InterpretedResult是系统执行后产生的结果，但我们根据实际的分析情况可以修改结果。修改后要promoted该结果，指明该结果有意义2005-5-3122测试结果的查看TestLog窗口中的Details标签包含日志事件，事件对应了我们手工测试脚本的每一个步骤和检查点。如以下图：2005-5-3123测试结果的查看Details里的结果只能查看不能修改。对于Result为Fail的记录可以点击右键选择“SubmitDefedt〞,就可以直接关联到clearquest中的提交BUG功能中了。点击右键选择“Properties〞可以查看详细信息。2005-5-3124五、缺陷管理Rational使用CQ进行缺陷的管理。Details里的结果，对于Result为Fail的记录点击右键选择“SubmitDefedt〞,将出现CQ登陆界面，这时可以使用CQ登陆帐号登陆CQ,提交缺陷。2005-5-3125五、缺陷管理2005-5-3126五、缺陷管理系统会自动分配一个ID相关人员在填写、增加、修改、删除Bug管理系统信息时，应按照《Bug提交标准》中的规定进行。Bug的状态、优先级、产生阶段等按照在CQ中定义的选项执行。2005-5-3127五、缺陷管理缺陷管理流程2005-5-3128五、缺陷管理2005-5-3129五、缺陷管理回归测试2005-5-3130回归测试回归测试测试的步骤：当更改完一批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-3131六、测试停止工程测试的结束2005-5-3132工程测试的结束测试结束后，测试负责人应编制《测试报告》，内容须包括以下几个方面：1〕对该阶段工作进行综合评价，包括测试工作效率、资源消耗情况、测试技术和工具的采用以及测试用例的质量等；2〕对测试结果进行概述，对该版本软件质量进行综合性的评价；3〕对测试过程中的经验、教训进行总结。2005-5-3133七、测试总结工程