软件测试工作测试作业流程.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测试