软件测试工作流程个人版Word文件下载.docx
- 文档编号:14314941
- 上传时间:2022-10-22
- 格式:DOCX
- 页数:10
- 大小:29.53KB
软件测试工作流程个人版Word文件下载.docx
《软件测试工作流程个人版Word文件下载.docx》由会员分享,可在线阅读,更多相关《软件测试工作流程个人版Word文件下载.docx(10页珍藏版)》请在冰豆网上搜索。
输入输出文档,产品描述,软件主要功能
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结束,
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 测试 工作 流程 个人版