软件测试工作测试作业流程.doc

软件测试工作测试步骤-测试基础阶段划分测试基础阶段划分 1、测试计划阶段 2、测试设计阶段 3、测试实施阶段 4、测试评定阶段 5、测试验收阶段1、测试计划阶段?做测试需要做好准备工作，把做一件事需要做准备工作做好，明确做这件事目标，最终达成目标并验证结果是我们要做事情。这要求我们有一个完善“测试 计划书”。?测试计划内容：1、测试范围：描述此次测试中做测试范围，如：测试软件功效范围、测试种类等2、简单描述怎样搭建测试平台和测试潜在风险。3、项目信息：说明要测试项目标相关资料，如：输入输出文档，产品描述，软件关键功效4、人力资源分配注：计划和设计分开编写，最好安排充足时间去明确测试需求测试需求：笼统说，就是测试中全部设计和需求文档。作为此次测试依据1.1、测试计划考虑问题?1、要充足考虑测试计划实用性，即测试计划和实际之间靠近程度和可操作性（必需对需求有透彻了解）。编写测试计划目标在于充足考虑实施测试时多种资源，包含测试内容、测试标准、时间资源、人力资源等等，正确地说是要分析实施时所能够调用一切资源和受多种条件限制，可能受到多种影响。说 再明确一点就是要“计划”“怎样”去做“测试工作”，而不是“怎样编写测试计划”。（1）测试内容：对一个软件来说测试计划中会明确此次测试做哪些测试？如：系统测试：在整个系统测试中会有（界面测试、功效测试、性能测试、兼容性测试、安装卸载测试、可靠性测试等测试）（2）测试目标：通常多为确保产品质量是否达成预期指标。这个指标也就是在测试中定义结束标准。（3）测试标准：需要考虑此次测试需要输入那些文档，该项目结束标准定义、测试结束标准定义？bug等级定义、优先级定义、bug管理步骤定义。这个全部需要在实施测试事明确。计划中应该包含这些内容。（4）资源分配：这里分为人力资源、软硬件资源等划分。通常会把人力资源利用写入一个测试人员任务分配表里，根据不一样阶段，每个阶段提交对应结果（难度很大）。软硬件资源中关键是在做计划时考虑到需要多少电脑或别工具，列出清单。（5）测试风险：大多考虑到就是项目开发延期、测试人员不足用例无法全方面覆盖测试点、时间不足用例无法全部实施、bug无法立即修改造成无法验证、测试人员技能不足造成测试进度拉长。（6）软件测试策略通常全部是分开来做相关测试方案。?2、要坚持“5W1H”标准，明确测试内容和过程。 明确测试范围和内容（WHAT）； 明确测试目标（WHY）； 明确测试开始和结束日期（WHEN）； 明确给出测试文档存放位置（WHERE）； 明确测试人员任务分配（WHO）； 明确指出测试方法和测试工具（HOW）。1.2、测试策略?这一阶段在于需求、具体设计、测试计划完成以后，关键是此次测试策略阶段。很多企业少这个一个阶段，需要有计划性分出产品功效扣出测试功效点，现阶段大多企业全部是直接拿着文档就开始做用例设计。?对需求进行分析，列出具体功效列表。（通常依据功效交互文档就能明确出此功效大致功效，一层层分下去，一直到没个功效表单。然后考虑到使用那些测试方法？工作一旦做到实施阶段，我们能够愈加好依据这些功效表一点一点覆盖。也能让我们在用例评审时，充足证实我们工作是有效能够确保产品质量。）通常在此之前，部分业务培训和需求评审是有必需是听一下。这么能够更早更熟练了解需求，也能确保产品设计中出现部分误区。?对于一个个测试该怎样进行测试？以下：1、功效测试1.1、功效范围（划分出各自负责功效模块）1.2、使用测试方法（等价类、边界值等测试方法方法）1.3、测试标准（符合设计、需求和规范文档对该功效描述）2、界面测试3、兼容性测试列举出策略中常见测试种类功效测试、界面测试、兼容性测试、性能测试、安装卸载测试、数据库测试、文档测试、安全性测试、可靠性测试等等1.3功效列表功效描述：需求：公告条数上没有限制；公告有两种显示方法：次序排列和随机排列，默认显示方法是次序；每条公告不超出50个汉字字符或100个英文字符；公告在用户端上以次序排列方法显示次序同运行后台页面上从上到下显示次序。新增公告文字如需对应宝贝详情链接，则文字内容必需含有对应宝贝名称，作为公告内关键字链接。新增公告文字如是纯文字公告，不需选择“指定宝贝”。1、实际中我们能够依据设计图形，能够看出内部功效点如：删除、修改、新增、排序2、细分到具体功效表单：（具体设计）如：2.1、结合设计图找出每个测试点（内部表单）2.2、结合测试方法进行细分功效点就是一个个测试集模块名称功效点测试点测试方法测试标准公告管理删除删除无许可正常操作，错误操作给出提醒信息修改公告内容等价类、边界值许可正常操作，错误输入提交给出提醒！新增1.供给商2.宝贝名称3.指定宝贝4.公告内容等价类、边界值和功效图许可正常操作，错误输入提交给出提醒！排序1.上移2.下移无许可正常操作公告显示方法排序在图上极难看出有此功效所以要结合需求说明来分析出来。1.3.1、其它非功效测试?界面测试?兼容性测试后台软件分：IE6.0、IE7.0、Firefox浏览器前端手机分：手机系统、手机品牌?安装测试1、文件安装是否完整2、卸载是否洁净3、安装时停止，是否删除洁净4、安装文件是否散乱?性能测试性能测试应该另外确定需求指标，根据需求设置具体场景和性能参数指标1.3.2、策略附件要求?用例模板、缺点汇报模板?测试环境搭建?缺点管理步骤和缺点等级定义为下一阶段做好准备缺点状态通常分为：新建、打开、已分配、已修复、关闭、重新打开中间会有：延期、反复、拒绝等状态缺点管理步骤1、由测试人员发觉bug后，新建bug。Bug状态为新建2、测试人员直接把bug指派到对应管理者（通常是由测试组长、项目经理等人参与bug分配）（打开）或是在管理者那里就直接关闭bug状态就直接改为关闭3、Bug经过分配给对应开发者手中或是开发组长手中，测试组长能够讲该bug转移给对应开发人员。Bug状态不改变。状态改为 已分配。（拒绝修复、延期修复等）4、测试人员在做验证时，关键关注bug状态为 已修复bug假如bug任然存在或造成了新bug。那么就重新打开然后新建新bug。假如bug修复未修复，那么就重打开5、Bug修复验证完成，就直接关闭缺点等级划分分级Bug等级Bug等级说明分类说明致命问题Blocker造成整个产品无法进行测试。修改优先级为最高，该等级需要程序员立即修改模块无法开启或异常退出其它造成无法测试错误Critical死机，数据丢失，关键功效完全丧失，系统悬挂等错误。修改优先级为最高，该等级需要程序员立即修改运行过程中系统瓦解/死机/重启功效设计和需求严重不符严重花屏内存泄漏影响手机语音或数据通讯等严重数值计算错误严重问题Major关键功效丧失，造成严重问题，或致命错误申明。修改优先级为高，该等级需要程序员立即修改功效未实现或存在错误轻微数值计算错误系统所提供功效或服务受显著影响用户数据丢失或破坏通常问题Normal次要功效丧失，不太严重，如提醒信息不太正确。修改优先级为中，该等级需要程序员修改操作界面错误（包含数据窗口内列名定义、含义是否一致）边界条件下错误功效存在错误，但出现概率很低提醒信息错误（包含未给出信息、信息提醒错误等）长时间操作无进度提醒系统未优化（性能问题）Minor微小问题，对功效几乎没有影响，产品及属性仍可使用。修改优先级为低，该等级需要程序员修改或不修改界面格式等不规范操作时未给用户提醒文字排列不整齐等部分小问题光标跳转设置不好，鼠标（光标）定位错误轻微问题Trivial提醒信息格式不符合要求,违反正常习俗习惯，界面不美观，控件排列、格式不统一辅助说明描述不清楚部分不影响产品了解错别字可输入区域和只读区域没有显著区分标志Enhancement功效性提议，功效使用性、方便性、易用性不够提议2、测试设计阶段在设计测试方案时，首先分解测试内容，对于一个复杂系统，通常能够分解成多个相互独立子系统，正确地划分这些子系统及其逻辑组成部分和相互间关系，能够降低测试复杂性，降低反复和遗漏，也便于设计和开发测试用例，有效组织测试，将系统分析人员开发分析文档加工成以测试为角度功效点分析文档，关键是描述对系统分解后每个功效点逐一校验描述，包含何种方法测试、何种数据测试、期望测试结果等。然后以功效点分析文档作为依据进行测试用例设计， 设计测试用例是关系到测试效果以至软件质量关键性一步，也是一项很细致工作，依据对具体北侧系统分析和测试要求，逐步细化测试范围和内容，设计具体测试过程和数据，同时将结果写成能够按步实施测试文档。每个测试用例必需包含以下多个部分：（1）标题和编号（2）测试目标和目标（3）输入和使用数据和操作过程（4）期望输出结果（5）其它特殊环境要求、次序要求、时间要求等3、测试实施阶段?当测试用例设计和测试脚本开发完成以后，提交测试版本、布署测试环境就开始实施测试。?手工测试；在适宜测试环境上，根据测试用例条件、步骤要求，准备测试数据：对系统进行操作，比较实际结果和测试用例所描述期望结果，以确定系统是否正常运行或正常表现。大多企业测试方法，此阶段需要时间和人力?自动化测试：经过测试工具，运行测试脚本，得到测试结果。对手工测试管理相对要复杂得多，在整个测试实施阶段中，管理上会碰到一系列问题，关键有：?怎样确保测试环境满足测试用例所描述要求?怎样确保每个测试人员清楚自己测试任务?怎样确保每个测试用倒得到百分之百实施?怎样确保所汇报bug正确、描述清楚、没有遗漏信息?怎样跟踪bug处理进度，严重bug立即得四处理?3.1、实施阶段操作?这时候开发就会转版本给我们测试部门进行系统测试了。拿到版本我们首先搭建测试环境?做一个估计试，目标是来评断这个版本是不是可测试。假如估计试不经过，打回开发部返工，假如经过了，就开始我们第一轮系统测试。?第一轮系统测试我们会实施我们所编写全部测试用例，做好测试结果统计，发觉缺点了提交缺点汇报。当第一轮测试结束后，我们把全部bug单提交给开发人员，由她们进行修改。?在她们修复bug期间，我们会对第一轮系统测试做一个测试评定，出一个测试汇报。还要依据实际情况，对我们写测试用例进行修改和增加。开发改bug结束，提交一个新版本给我们，我们重新搭建测试环境开始第二轮系统测试。首先是回归我们提交缺点汇报，然后会在用例中挑选部分优先等级比较高用例来进行测试，发觉问题了继续提交缺点汇报，只到缺点率低于用户要求了，我们就进行最终一轮回归测试，结束系统测试。具体测试轮次是依据版本质量和项目复杂度而决定。重新搭建测试环境：企业每次产品全部公布。第二轮测试时，企业不做挑选择例，用例全部实施。需要时间安排充足?其实估计试在企业内多为开发内部测试（冒烟）4、测试评定阶段?实施阶段结束了进入测试评定阶段，我们会出一个总测试汇报对我们测试这个过程和版本质量做一个具体评定1、需求需要评审那些？2、用例需要评审那些？3、计划应该评审那些？4、缺点评审那些？5、bug评定？测试总结汇报文档输出：1、能够让具体任务责任人对该此次测试中个人负责模快进行评价，提出相关提议。给出总体评定2、整体上bug根据不相同级统计出来、用例数量、用例实施数量3、对项目中测试人力资源统计。（单位：人/天）4、项目中软硬件资源统计。5、提出软件总体评价5、测试验收阶段?最终进入验收阶段，我们会出用户手册，操作指导等文档。我们每一个阶段输出全部有一个严格评审阶段，以确保我们每一步输出全部是有效，确保测试顺利进行。通常分为alpha测试和beta测试