软件测试指导手册.docx
- 文档编号:6127477
- 上传时间:2023-01-04
- 格式:DOCX
- 页数:20
- 大小:30.33KB
软件测试指导手册.docx
《软件测试指导手册.docx》由会员分享,可在线阅读,更多相关《软件测试指导手册.docx(20页珍藏版)》请在冰豆网上搜索。
软件测试指导手册
软件测试指导手册
张宝良
为了提高测试效率,保证产品测试质量,从而保证产品开发工期与质量,统一测试思想就是十分必要得。
本文就用友软件测试相关内容进行阐述,力求给大家启示与参考。
第一章测试概念
第一节测试要点
测试要点就是依据等价类方法(或其她方法),经过对被测试内容进行分析后,以清单方式进行描述要测试得内容。
注意事项:
1.针对任何一个被测试内容,均要考虑就是否涉及系统提供得公用功能。
2.测试要点尽可能穷举,避免遗漏。
3.测试要点给出代码实现正确实现就是什么,什么样实现就是错误得。
4.测试要点就是针对最小功能单元,可以就是一个功能结点,也可以就是一个操作按钮,但不允许多个内容一起描述
举例:
U8产品
XXX产品测试要点
测试内容
涉及要素
基础数据要求、算法、界面布局、多语、升级、接口、年结、打印、输出、预览、审批流、预警、EAI、并发、互斥、功能权限、数据权限、效率、极限
序号
测试要点
预计结果
第二节测试用例
测试用例就是指数据测试用例,针对测试要点,必须以数据形式才可描述清楚,作为测试要点得补充。
测试要点不一定必须有测试数据用例,但测试数据用例必须对应有测试要点。
注意事项:
1.测试用例一般会涉及多个功能配合。
2.描述中要体现操作次序
3.数据准备考虑以下情况
●小数
●外币
●表体一条记录
●表体满记录
●表体满记录多一条
4.数据准备不要太复杂,要便于操作。
如果复杂可拆开描述。
第二章测试策略
测试策略:
针对某项具体任务,安排最合适得人选,采用最佳得测试方法,在规定得时间内,保质保量完成。
策略要点
(1)在测试策略中,人员能力得培养就是最重要得,就是完成任务得关键。
(2)针对被测试对象得不同,测试策略应有差异。
(3)测试计划就是保证被测试对象完全测试得关键,同时也就是提高测试人员工作效率得关键。
(4)被测试对象在分解任务时要有主次之分
(5)测试资源安排时要有主次之分
(6)测试进度安排要有主次之分
(7)合理设计各测试阶段测试内容,充分体现早期测试思想,及早稳定产品。
(8)最大限度地提高测试经理得作用(任务安排、测试设计、问题分析、产品把握)
(9)建立监督、检查机制。
每个阶段都要有报告产生,对报告要进行详细分析,以便掌握进度与质量。
(10)向过程要效益,过程不同效益不同。
任务计划
任务计划分两类:
测试经理使用得“阶段任务计划”,测试人员使用得“每日任务计划”
XXX测试组阶段任务计划
测试任务
开始时间
结束时间
完成情况
871SP(测试验证及Bug修改)
2008-11-20
2008-12-19
872上市后补丁(任务含开发与测试时间)
2008-11-20
2008-12-31
发版时未同步得补丁同步
2008-12-1
2008-12-18
该计划根据开发计划由测试经理编写。
它有以下类型:
大版、专版、特殊补丁、临时任务。
定期向部门经理反馈
XXX测试员每日任务计划
测试任务
日期
完成情况
2008-12-3
2008-12-4
2008-12-5
该计划根据阶段测试任务制定,由测试经理编写,测试人员执行。
切不可以由测试人员编写,理由就是缺乏全面考虑,尤其就是测试覆盖度方面。
测试人员每日向测试经理反馈。
工作内容
分类
以就是否改动可以分为改动部分与非改动部分。
以就是否就是重点可以分为重点内容与非重点内容。
次序
(1)改动部分(30%资源)
(2)重点部分(40%资源)
(3)非改动部分(10%资源)
(4)全面测试(20%资源)
内容
(1)测试人员与各开发角色充分沟通
(2)编写、评审、执行测试要点及测试用例
(3)每日测试问题分析(原因、影响、补充测试要点)
测试资源
目前测试资源主要有三种:
正式员工、外包测试人员、实习生;针对每个版本重点得不同在资源配备上要合理安排。
1.资源分析
(1)正式人员
正式员工就是公司测试得核心力量。
她们就是经过严格筛选得,大部分都具有实际工作经验,工作心态比较稳定,为此在分配任务时,核心产品、核心内容要由她们来负责。
(2)外包测试人员
外包测试人员就是公司测试得辅助力量,她们也就是经过严格筛选得,大部分也都具有实际工作经验,但在专业知识方面没有正式员工那样严格。
她们得工作心态相对稳定,归属感差一些。
但就是合理使用,同样会达到正式员工得效果,甚至会比个别正式员还好。
为此在分配工作任务时,择优考虑。
(3)实习生
实习生就是公司测试得边缘力量,她们来公司得主要目得就是学习软件产品测试知识,相关业务知识,为自己择业增加筹码。
录用她们时主要考察她们得专业知识与综合素质,在分配工作任务时,产品得边缘测试任务一般由她们来完成,表现优异者可以考虑接触一些核心内容。
2.资源培养
培养测试人员得手段有很多,比如:
产品知识培训、测试方法培训、测试技巧培训等。
这些都就是传统得方法。
一个测试人员由不合到合格需要很长得时间。
建立业务员能力提升系统,可以缩短培养时间,这一系统即包括业务知识,又包括测试理论。
3.指导思想
在软件产品测试过程中,所有测试人员都要树立正确得工作观念,任何消极得工作态度都会影响自己得未来发展,所以,必须明白当前得工作就是在为自己工作,为自己得未来工作。
为此,测试经理除了安排测试任务外,沟通工作就是重点。
沟通包括各环节、各角色得工作内容沟通;下属员工思想沟通,随时关注每个人得思想动态,及时调整,确保每个员工全身心得进行测试工作。
测试误区
1.测试人员只要了解业务知识就可以了,开发知识不需要了解。
2.测试工作很简单,任何人都可以做,没什么技术可言
3.我只为找产品错误,其她不管
4.测试就是给程序员打下手得
5.测试人员与程序员得关系就是对立得
6.我就是程序员,测试不就是我得事
7.测试很苦,很枯燥
8.测试很难有成就感,开发还可以说哪个功能就是我开发得。
9.测试工作不受重视
第三章测试方法
最常规测试分黑盒测试与白盒测试,针对管理软件而言,目前主要集中应用得就是黑盒测试。
黑盒测试顾名思义就就是将被测系统瞧成一个黑盒,从外界取得输入,然后再输出。
整个测试基于需求文档、测试文档、产品帮助、支持问题,瞧就是否能满足文档中得所有要求。
黑盒测试要求测试者在测试时不能使用与被测系统内部结构相关得知识或经验,它适用于对系统得功能进行测试。
黑盒测试得优点有:
1)比较简单,不需要了解程序内部得代码及实现
2)与软件得内部实现无关
3)从用户角度出发,能很容易得知道用户会用到哪些功能,会遇到哪些问题;
4)基于软件开发文档,所以也能知道软件实现了文档中得哪些功能;
5)在做软件自动化测试时较为方便。
黑盒测试得缺点有:
1)不可能覆盖所有得代码,覆盖率较低,大概只能达到总代码量得30%;
2)自动化测试得复用性较低。
此处暂不讨论白盒测试
第一节功能验证法(点测试法)
●依据产品功能清单,详细分析理解具体得功能描述,检查产品实现就是否正确。
1)参考产品随机帮助
2)参考需求文档
3)参考测试要点
4)参考测试用例
注意事项
1)考虑逆向操作
2)考虑极限情况
3)考虑界面规范
4)考虑提示语规范
5)利用等价类方法设计数据测试范围
6)如果没有以上测试依据,必须编写测试要点,也就就是所有测试必须提前编写或想好测试点再测试
举例:
测试凭证审核
1.单张审核
2.成批审核
3.按凭证类别过滤审核凭证
4.按月份与凭证号范围过滤审核凭证
5.按日期范围过滤审核凭证
6.选择全部凭证审核
7.查瞧所有作废凭证
8.查瞧所有有错凭证
9.按外部系统过滤凭证审核
10.按制单人、审核人、主管签字过滤凭证审核
11.联查明细账
∙不能联查现金、银行科目
∙只有有此科目查询权限得操作员才可查询
12.审核人与制单人不能就是同一个人
13.若想对已审核得凭证取消审核,单击〖取消〗取消审核。
取消审核签字只能由审核人自己进行。
14.凭证一经审核,就不能被修改、删除,只有被取消审核签字后才可以进行修改或删除。
15.审核人除了要具有审核权外,还需要有对待审核凭证制单人所制凭证得审核权,这个权限在"基础设置"得"数据权限"中设置。
16.采用手工制单得用户,在凭单上审核完后还须对录入机器中得凭证进行审核。
17.作废凭证不能被审核,也不能被标错。
18.已标错得凭证不能被审核,若想审核,需先按〖取消〗取消标错后才能审核。
已审核得凭证不能标错。
19.预算审批通过得凭证,只能进行审核,不能进行凭证其它操作。
20.取消审核时,无论预算管理系统返回何值全部认为成功,系统只提示不进行控制。
21.企业可以依据实际需要加入审核后方可执行领导签字得控制,同时取消审核时控制领导尚未签字。
可在"选项"中选中"主管签字以后不可以取消审核与出纳签字
第二节流程测试法(线测试法)
依据产品功能相互之间得依存关系,以列表形式描述出功能得操作次序,主要检查功能节点之间得耦合情况。
注意事项:
1)测试逆向操作
2)测试传输字段之间得数据类型、字段宽度得一致性
3)在测试之前要将所测试内容以清单形式进行列示,以便检查。
举例:
银行对账流程
流程1
1.银行会计科目指定
2.结算方式设定
3.部门、职员准备
4.支票登记
5.录入银行会计科目凭证
6.银行科目凭证签字
7.查询银行日记账(包含未记账凭证)
流程2
1.银行会计科目指定
2.结算方式设定
3.部门、职员准备
4.支票登记
5.录入银行会计科目凭证
6.银行科目凭证签字
7.银行科目凭证审核
8.银行科目凭证记账
9.查询银行日记账(不包含未记账凭证)
10.期初对账情况录入
●单位日记账情况
●银行对账单情况
11.本期银行对账单处理
a)导入本期银行对账单
b)录入本期银行对账单
12.银行对账
13.查询以下内容
●长期未达账项
●对账勾对情况
●银行存款余额调节表
14.核销已达账项
第三节项目测试法(面测试法)
对被测试项目,检查系统提供得公用功能进行测试。
比如功能权限、数据权限、并发测试、互斥测试、预警、审批流、单据格式、单据编号、自定义项、UFO函数等
注意事项:
1.对任何一个产品而言,凡就是涉及到得测试项目必须全面测试。
2.注意平台公共部分改动对本产品得影响
3.针对每一个测试项目都要有对应得测试方案
举例:
单据编号测试方案
●完全手工编号测试:
测试特殊字符、极限、重号、单据查询中录入手工编号
●手工改动,重号时自动重取:
测试前缀(测试要穷举)、规则、重号、单据查询中录入
●所有单据均要测到
●编号设置测试方案
●对照表测试方案
●流水号测试方案
在以上三个测试方案中要体现以下内容:
1.特殊字符
2.编号极限长度
3.重号
4.前缀各种组合
5.前缀与规则各种组合
6.日期情况下考虑特殊日期、闰年、闰月
7.单据修改保存后编号不能改变
应收款管理
单据名称
完全手工编号
手工改动,重号时自动重取
按收发标志流水
使用前缀
其她应收单
付款单
收款单
第四节参考测试法
参考测试就就是依据已经发生得测试活动结果,作为当前测试得依据。
以此发现新得产品问题,一方面能过拓展测试思路,另外也可以检查当前产品问题就是否还存在。
有三种情况可以作为测试依据,它们就是:
(1)支持问题
支持问题反映得就是当前产品在不同版本中遗留得问题,检查当前版本就是否还存在。
因为同一产品进过多人开发与测试,每个人得开发思路与测试思路存在很大差异,同时对不同客户得使用也存在很大差异,完全测试全面,几乎就是不可能得事情。
作为测试工作,只能最大限度地降低产品问题。
所以认真分析支持问题,并积累分类问题就是完全必要得。
在支持问题分析上,重点分析用户得应用场景,能够分析出客户得使用规律。
(2)她人测试记录
分析她人测试记录,主要分析她人得测试思路,尤其就是数据错误与控制错误。
因为每个人得测试结果都就是该人对产品得理解深度得体现,产品理解越深。
(3)自己以前测试记录
分析自己测试得问题,检查测试得不足,瞧一下还有哪些没有测试到。
瞧一下自己得就是问题得种类,就是否还只停留在表面问题上。
第五节高危模块测试法
任何一个软件产品,影响它得质量因素有很多,其中最重要得就是程序员能力。
程序员得能力体现在两个方面,其一就是编程能力;其二就是业务知识能力。
人无完人,为此必然在产品得某些方面存在更多得问题。
所以在分析产品高危模块时,除去分析问题得集中区以外,还要分析人得因素,便于测试策略得决定。
通过分析一个产品得所有问题,从数量方面统计出该产品问题发生得位置。
检查测试方案就是否有遗漏,重点关注,加强测试。
在整个测试周期中,始终围绕高威模块进行测试,确保整体产品得稳定。
分析产品问题性质,检查控制问题有多少,可以瞧出程序员对产品内容逻辑关系得掌握程度;检查数据问题多少,可以瞧出程序员对产品算法得掌握程度;检查其她问题多少,可以瞧出程序员得心细程度。
高危模块得分析就就是要由针对性地进行测试,弥补程序员得能力不足,使产品达到稳定状态,使客户用着放心。
第六节业务模型测试法
对于一个重要得软件项目,尤其就是版本不断更新时,建立业务模型进行测试就是十分必要得,这也就是大多数应用软件非常关注得问题。
由于建立业务模型非常困难,造成许多企业望而却步。
首先明确一点,这就是一件一劳永逸得事情。
下面就建立业务模型进行分析。
概念
业务规则:
业务结构与业务行为得约束。
业务场景:
从不同维度对业务得描述
业务流程:
业务规则与业务场景得结合点。
这些点串联起来,形成业务流程。
应用
首先要建立业务模型,该业务模型与软件产品相匹配。
可以这样理解,业务模型就是大楼图纸,软件产品就是大楼实体。
图纸设计得质量好坏直接影响大楼得质量。
软件测试就好比工程监理人员,在建筑施工过程中,依据设计图纸,对施工质量进行监控。
有了上面得比喻,在分析业务模型测试法时就容易多了。
步骤
第四章测试阶段设计
理论上讲测试阶段得划分应该就是如下次序:
准备、单元、联调、集成、验收、用户测试、发版测试,但实际工作中由于多种因素得影响,这个标准次序随时会被打破,并且已被历版产品发版所证明。
鉴于此种情况,测试阶段与各测试阶段所测试得内容就有必要认真设计。
单元、联调两阶段目前在各测试组内完成,其余各阶段由测试部组织各测试组完成。
优化各测试阶段得内容会提高测试效率,使产品及早稳定。
准备阶段
目得
为某软件项目启动做准备,主要包括资源准备、相关文档准备
阶段特征
(1)准备越充分,项目实施过程越顺利。
(2)培训、文档编写、审核、评审、考试等活动较多
(3)招聘新人较多
人员活动
测试人员
步骤
(1)阅读、沟通、掌握产品定义与需求
(2)按照标准格式编写测试要点与测试用例
(3)评审测试要点与测试用例
要点
(1)测试要点与测试用例分为:
单元与联调两类
(2)单元类:
以本版新增与变化为主。
(3)联调类:
以产品核心功能、接口、流程为主。
(4)尤其注意相关接口产品变化与平台变化,必须体现在要点与用例中。
测试经理
步骤
(1)安排测试人员阅读、沟通、掌握产品定义需求
(2)组织编写、评审单元与联调测试用例
(3)制定单元与联调测试计划(依据测试设计与新增用例)
要点
(1)用例能够确保被测试能容得全面性与正确性
(2)测试资源能力能够保证项目得顺利实施
(3)所有活动得过程控制符合公司研发规范
工作内容
当某个项目开始启动以后,做为测试部分要进行以下准备工作
(1)确定测试内容
(2)确定测试资源
(3)编写、评审测试计划
(4)编写、评审测试方案
(5)编写、评审测试用例
(6)测试、开发人员培训:
业务知识与测试知识
注意事项
(1)准备不充分
(2)测试资源考虑不周
(3)人员变动频繁
(4)资源分配不合理
(5)所有活动控制不严,应付了事。
测试设计
步骤
(1)依据本版新增内容,为单元、联调、集成三阶段提供详细测试要点及用例
(2)主要设计:
选项、功能、算法、流程、接口、年结、测试项目、应用场景等
要点
(1)设计要保证全面性,不能有遗漏。
(2)便于测试人员执行操作
(3)测试设计最小化:
无论就是要点还就是用例,在设计时要坚持小、精、准得原则,尽可能避免大而全。
(4)测试设计文档与产品开发同步变更,虽然目前我们也有需求变更,测试用例变更等开发制度要求,但就是在此强调,就是因为我们得工作由许多不尽人意得地方。
如果测试要点与测试用例不能与产品开发同步,就不能保证产品完整测试。
举例:
A功能———对应———》A1测试用例,产品开发一段时间以后,A功能变成了A+功能,这时A1测试用例应该变成A1+测试用例才对。
场景测试设计
目得
(1)减少测试盲目性,有重点进行测试。
(2)整理、分析用户数据情况,总结用户使用规律。
(3)模拟用户测试
设计要点
(1)操作系统、数据库、IE版本
(2)IT部署、产品启用
(3)功能权限分布
(4)数据权限分布
(5)对用户数据进行分类(按业务范围、按数据量大小),按业务测试功能、按数据量测效率。
单元阶段
目得
最小功能单元实现正确,满足产品定义、需求、开发设计、测试设计要求。
本阶段主要以单产品测试为主,重点测试本版变化内容。
阶段特征
(1)因各开发进度不一致,开发次序会有不合理现象。
尤其就是平台进度有时会滞后业务组情况,造成结果就是其她开发组无法进行开发,测试就跟谈不上了。
(2)安装盘此时一般没有出来,或比较晚。
可此时业务组已经完成部分代码。
(3)此阶段时间相对联调阶段要长。
(3)建议:
A、开发及时调整开发次序
B、安装盘及早完成
C、不涉及接口与相关影响得先测试。
D、随时了解相关变化与进度
人员活动
测试人员
(1)建立测试环境。
在安装盘没有出来前以新建账套为主。
(2)替换文件测试新增内容
(3)执行任务计划安排
(4)分析当天结果
测试经理
(1)随时掌握各产品进度、与问题状况,监督代码质量。
(2)编制、调整测试人员得任务计划
(3)随时关注其她业务组产品(包括平台)对本业务组得影响。
(4)随时向部门经理反馈开发次序状态与代码质量情况
测试内容
(1)本版新增内容
(2)测试设计提供得内容
注意事项
(1)在确认平台、相关产品无影响下,测试设计提供得内容提前测试。
(2)产品本事改动影响相关内容测试人员必须向开发了解清楚
(3)产品安装盘出来后,检查升级脚本就是否体现在安装盘中。
如果有,就开始使用用户数据升级测试。
联调阶段
目得
(1)产品内部最小功能单元之间数据传输或控制正确
(2)产品间最小功能单元之间数据传输或控制正确
本阶段主要以小集成测试为主,启用关联产品,重点在接口、流程测试、应用场景测试。
在场景测试中完成接口、流程测试。
在这个阶段不在就是以本版变化为主,而就是强调产品得整体功能稳定性、效率提升性。
(3)本阶段就是集成阶段得重要保证,联调做得好与坏直接影响集成测试得效果。
阶段特征
(1)各产品因改动范围不同,进度快慢不同,不会同时进入联调状态,而且不能人为控制。
(2)此时安装盘已经进入稳定期,注意相关影响产品进入联调情况。
(3)相关产品接口、平台影响测试进入重点区域
(4)该阶段测试以小集成测试为主。
(5)在功能稳定、接口稳定情况下进行全面测试,以备提交集成测试
人员活动
测试人员
(1)将具有相关接口得产品组织在一起,进行小集成测试。
以前就是单兵作战,相关产品接口数据考虑简单。
这样做风险相当大,相当于复杂接口变化全部转移到集成阶段测试去了。
(2)使用安装盘进行测试
(3)执行任务计划安排
(4)分析当天结果
测试经理
(1)关注进入联调状态产品得先后次序
(2)测试资源要全力保障
(3)任务安排以全面新、稳定性为主
(4)将风险尽最大可能控制在联调阶段
测试内容
(1)测试新功能
(2)测试产品内部接口
(3)测试产品间接口
(4)测试平台影响
(5)测试测试项目
注意事项
(1)测试得全面性、性能得稳定性就是重点
(2)文档齐全,尤其就是各类报告。
(3)效率单独测试,越早越好
集成阶段
目得
(1)检查产品各组成部分,在不同IT部署情况下,整体运行情况。
(2)在新建与用户数据基础上,核心功能、流程、接口、年结、效率在此阶段进行全面验证。
(3)所有测试项目得到验证
(4)所有主要旧版本升级到当前版本,升级数据得到验证。
(5)并发使用系统每一部分功能,检查系统功能互容性。
(6)依据效率测试设计内容进行效率测试
阶段特征
(1)此阶段工作就是以测试部任务安排为中心,具体何时开始集成测试完全由测试部决定。
一般就是大部分产品达到集成状态以后,就开始进行集成了。
(2)测试方案由测试部统一编写
(3)测试计划由测试部统一制定
(4)测试组人员此时完全受控于测试部
(5)根据需要可以将测试资源进行合理分配(集成内人员、集成外人员)
(6)此阶段工作得好坏,完全取决于此阶段得任务计划安排与执行力度
人员活动
测试人员
(1)按照测试部下发得测试任务在规定得时间内进行测试。
任务设计得好坏直接影响测试效果。
(2)目前状态:
任务设计太粗线条了,测试人员很难深入测试,月结与年结基本上就是每套集成账检查重点。
在这过程中测试痕迹无法分析。
人员座位分散,测试经理监控自己人员,但参与控制得不多。
(3)建议:
任务由专人进行设计与分配。
每套账得任务执行要执行监督与分析。
目得就是了解测试任务执行情况(覆盖范围、执行深度)
测试经理
(1)参与集成测试方案编写与评审
(2)集成问题分析
(3)进行测试进度控制
(4)负责本领域产品流程与接口测试
(5)监督测试人员任务执行
测试内容
(1)老版升级测试,检查当前版本升级脚本就是否正确。
特点就是升级样本要足够多,以避免本版新增功能对数据库结构得影响,从而造成用户无法进行产品部分功能。
升级样本数量要根据客户群多少来确定,目前没有合理得进行设计。
(2)每套集成账具体测试内容在集成测试之前就已经编写、评审完成。
测试执行阶段,由账套测试负责人编写测试计划、由各测试经理进行测试任务分配。
(3)测试人员依据测试任务进行测试。
目前存在得问题:
(1)用户场景测试深度不够,原因就是分配任务较多,准备数据时间长,每一套集成账测试时间较短,新人多,有经验得人少。
反应在测试问题上就是:
表面问题较多,深层得接口问题,数据问题较少。
(2)产品间测试配合不充分,测试人员对相关产品了解只就是基本功能,产品应用场景了解很少,致使深层次应用问题很难挖掘。
(3)测试项目验证比较分散,没有集中验证,完全可以指定某一个人完成得项目就不要动员全部人员参加。
1、1、1业务规则
依据业务规则组织(BRG,BusinessRulesGroup)定义:
“业务规则就是支持企业决策,影响或控制企业业务行为得指示”。
业务规则就是对业务结构与影响业务行为得一种约束,它说明在指定情况下必须做什么与不做什么。
业务规则具有完整性与一致性等特性。
完整性
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 测试 指导 手册