测试指导手册可编辑范本Word下载.docx
《测试指导手册可编辑范本Word下载.docx》由会员分享,可在线阅读,更多相关《测试指导手册可编辑范本Word下载.docx(20页珍藏版)》请在冰豆网上搜索。
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
7.银行科目凭证审核
8.银行科目凭证记账
9.查询银行日记账(不包含未记账凭证)
10.期初对账情况录入
●单位日记账情况
●银行对账单情况
11.本期银行对账单处理
a)导入本期银行对账单
b)录入本期银行对账单
12.银行对账
13.查询以下内容
●长期未达账项
●对账勾对情况
●银行存款余额调节表
14.核销已达账项
第三节项目测试法(面测试法)
对被测试项目,检查系统提供的公用功能进行测试。
比如功能权限、数据权限、并发测试、互斥测试、预警、审批流、单据格式、单据编号、自定义项、UFO函数等
1.对任何一个产品而言,凡是涉及到得测试项目必须全面测试.
2.注意平台公共部分改动对本产品的影响
3.针对每一个测试项目都要有对应的测试方案
举例:
单据编号测试方案
●完全手工编号测试:
测试特殊字符、极限、重号、单据查询中录入手工编号
●手工改动,重号时自动重取:
测试前缀(测试要穷举)、规则、重号、单据查询中录入
●所有单据均要测到
●编号设置测试方案
●对照表测试方案
●流水号测试方案
在以上三个测试方案中要体现以下内容:
1.特殊字符
2.编号极限长度
3.重号
4.前缀各种组合
5.前缀与规则各种组合
6.日期情况下考虑特殊日期、闰年、闰月
7.单据修改保存后编号不能改变
应收款管理
单据名称
完全手工编号
手工改动,重号时自动重取
按收发标志流水
使用前缀
其他应收单
付款单
收款单
第四节参考测试法
参考测试就是依据已经发生的测试活动结果,作为当前测试的依据。
以此发现新的产品问题,一方面能过拓展测试思路,另外也可以检查当前产品问题是否还存在.有三种情况可以作为测试依据,它们是:
(1)支持问题
支持问