工具测试工作指导.docx
- 文档编号:26863178
- 上传时间:2023-06-23
- 格式:DOCX
- 页数:31
- 大小:199.97KB
工具测试工作指导.docx
《工具测试工作指导.docx》由会员分享,可在线阅读,更多相关《工具测试工作指导.docx(31页珍藏版)》请在冰豆网上搜索。
工具测试工作指导
六.系统测试计划
6.1测试简介
6.1.1测试职责和主要工作
主要职责是与开发组沟通和协调,保证系统产品在发布出去之时有好的质量(包括功能和性能)。
主要的工作如下:
⏹制定测试计划,设计测试用例
⏹执行测试计划,按照测试用例进行测试。
(有一部分需要借助测试工具)
⏹建立测试环境
⏹及时报告发现的错误
⏹分析错误的成因,估计错误的重要程度,评估系统质量,完成测试报告
⏹对项目测试作项目总结,为日后的工作提供经验和教训
6.1.2好的测试人员应具备的素质
⏹沟通能力——既要和开发人员,又要和客户交流
⏹技术能力——有几年编程经验的测试工程师能在测试领域的多方面发挥潜力
⏹自信心——开发人员可能会指责测试人员测错了,但测试者必须自信自己的观点。
⏹外交能力——当告诉开发者他出错时,适当的外交手法有助维护和开发人员的协作关系
⏹强的记忆力——因为许多新发现的问题其实和我们已经发现的问题相差无几。
⏹耐心——识别和分析一个错误也可能要大量时间,坐不住的人是无法完成这些工作的。
⏹怀疑精神——开发者会尽最大努力将所有错误解释过去。
测式者必须听每个人的说明,但他
必须保持怀疑直到他自己看过以后。
⏹自我督促——测试工作只有自我督促才能使自己每天正常的工作,学到更多知识。
⏹洞察力——好的测试工程师具有“测试是为了破坏”的观点,捕获用户观点的能力,强烈的
质量追求,对细节的关注能力。
6.1.3测试人员的培训
对新加入测试组的同事进行培训,使他们了解到整个系统的架构,测试在项目中的作用,使他们了解测试的工作流程、工作规范、并介绍各种经验。
基本教会他们在测试中常用软件和操作系统等的使用,培训要基本能支持他们投入到正常的测试工作中去。
6.2系统测试技术
6.2.1测试的重要性
软件危机曾经是软件界甚至整个计算机界最热门的话题。
为了解决这场危机,软件从业人员、专家和学者做出了大量的努力。
现在人们已经逐步认识到所谓的软件危机实际上仅是一种状况,那就是系统中有错误,正是这些错误导致了系统开发在成本、进度和质量上的失控。
有错是系统的属性,而且是无法改变的,因为系统是由人来完成的,人做的工作都不会是完美无缺的,给系统带来错误的原因很多,具体地说,主要有如下几点:
⏹交流不够、交流上有误解或者根本不进行交流
⏹系统复杂性
⏹程序设计错误
⏹需求变化
⏹时间压力
⏹代码文档贫乏
⏹软件开发工具
事实上,对于系统来讲,不论采用什么技术和什么方法,系统中仍然会有错。
采用新的语言、先进的开发方式、完善的开发过程,可以减少错误的引入,但是不可能完全杜绝系统中的错误,这些引入的错误需要测试来找出,系统中的错误密度也需要测试来进行估计。
测试是所有工程学科的基本组成单元,是系统开发的重要部分。
自有程序设计的那天起测试就一直伴随着。
统计表明,在典型的系统开发项目中,系统测试工作量往往占系统开发总工作量的40%以上。
而在系统开发的总成本中,用在测试上的开销要占30%到50%。
因此,测试对于系统生产来说是必需的。
6.2.2系统测试的目标
测试目标作了如下的归纳:
⏹测试是程序的执行过程,目的在于发现错误;
⏹一个好的测试用例在于能发现至今未发现的错误;
⏹一个成功的测试是发现了至今未发现的错误的测试。
换言之,测试的目的是:
⏹想以最少的时间和人力,系统地找出系统中潜在的各种错误和缺陷。
如果我们成功地实施了测试
我们就能够发现系统中的错误。
⏹测试的附带收获是,它能够证明系统的功能和性能与需求说明相符合。
⏹实施测试收集到的测试结果数据为可靠性分析提供了依据。
⏹测试不能表明系统中不存在错误,它只能说明系统中存在错误。
6.2.3系统测试的原则
⏹应当把“尽早地和不断地进行系统测试”作为系统开发者的座右铭。
⏹程序员不应测试自己设计的程序。
⏹测试用例应由测试输入数据和对应的预期输出结果这两部分组成。
⏹测试用例的设计不仅要有合理的输入数据,还要有不合理的输入数据。
⏹除了检查程序是否做完了应做的事之外,还要检查它是否做了不应做的事。
⏹经验表明,测试后程序中残存的错误数目与该程序中已发现的错误数目成正比。
⏹妥善保存测试计划,测试用例,出错统计和最终分析报告,为维护提供方便。
6.2.4系统测试信息流
⏹系统配置:
系统需求规格说明、系统设计规格说明、源代码等;
⏹测试配置:
测试计划、测试用例、测试程序等;
⏹测试工具:
测试数据自动生成程序、静态分析程序、动态分析程序、测试结果分析程序、以及
驱动测试的测试数据库等等。
⏹测试结果分析:
比较实测结果与预期结果,评价错误是否发生。
⏹排错(调试):
对已经发现的错误进行错误定位和确定出错性质,并改正这些错误,同时修改
相关的文档。
⏹修正后的文档再测试:
直到通过测试为止。
⏹通过收集和分析测试结果数据,对系统建立可靠性模型
利用可靠性分析,评价系统质量:
⏹系统的质量和可靠性达到可以接受的程度;
⏹所做的测试不足以发现严重的错误;
⏹如果测试发现不了错误,可肯定,测试配置考虑得不够充分,错误仍潜伏在系统中。
6.3系统测试的过程
⏹单元测试—集中对用源代码实现的每一个程序单元进行测试,检查各个程序模块是否正确地
实现了规定的功能。
⏹组装测试—把已测试过的模块组装起来,主要对与设计相关的系统体系结构的构造进行测试。
⏹确认测试—是要检查已实现的系统是否满足了需求规格说明中确定了的各种需求,以及系统
配置是否完全、正确。
⏹系统测试—把已经过确认的系统纳入实际运行环境中,与其它系统成份组合在一起进行测试。
6.3.1两种常用的测试方法
⏹黑盒测试—这种方法是把测试对象看做一个黑盒子,测试人员完全不考虑程序内部的逻辑结构
和内部特性,只依据程序的需求规格说明书,检查程序的功能是否符合它的功能说明。
黑盒测试又叫做功能测试或数据驱动测试。
黑盒测试方法是在程序接口上进行测试,主要是为了发现以下错误:
Ø是否有不正确或遗漏了的功能
Ø在接口上,输入能否正确地接受,能否输出正确的结果
Ø是否有数据结构错误或外部信息(例如数据文件)访问错误
Ø性能上是否能够满足要求
Ø是否有初始化或终止性错误
黑盒测试的测试用例设计
Ø等价类划分
Ø边界值分析
Ø因果图
⏹白盒测试—此方法把测试对象看做一个透明的盒子,它允许测试人员利用程序内部的逻辑结构及有关信息,设计或选择测试用例,对程序所有逻辑路径进行测试。
通过在不同点检查程序的状态,确定实际的状态是否与预期的状态一致。
因此白盒测试又称为结构测试或逻辑驱动测试。
软件人员使用白盒测试方法,主要想对程序模块进行如下的检查:
Ø对程序模块的所有独立的执行路径至少测试一次;
Ø对所有的逻辑判定,取“真”与取“假”的两种情况都至少测试一次;
Ø在循环的边界和运行界限内执行循环体;
Ø测试内部数据结构的有效性。
白盒测试的测试用例设计方法
逻辑覆盖—又称白盒子测试,是以程序内部逻辑为基础的测试技术。
目前常用的一些逻辑覆盖测试,按覆盖的程度不同,有语句覆盖、分支覆盖、条件覆盖、分支/条件覆盖和多重覆盖。
6.3.2系统测试的种类
测试种类主要有以下的几种
⏹功能测试—是在规定的一段时间内运行软件系统的所有功能,以验证这个软件系统有无功能
上的严重错误。
⏹性能测试—检查系统是否满足在需求说明书中规定的性能。
特别是对于实时系统或嵌入式系统。
常常要求同时进行硬件和系统检测。
通常,对系统性能的检测表现在以下几个方面:
响应时间、吞吐量、辅助存储区,例如缓冲区,工作区的大小等、处理精度,等等。
⏹可靠性分析—MTBF(平均无故障时间),MTTR(平均修复时间)
⏹压力测试—检查在系统运行环境不正常乃至发生故障的情况下,系统可以运行到何种程度的
测试。
⏹安全性测试—检验在系统中已经存在的系统安全性、保密性措施是否发挥作用,有无漏洞。
⏹文档测试—这种测试是检查用户文档(如安装手册和用户手册)的清晰性和精确性。
用户文档中所
使用所有的例子必须在测试中试过,确保叙述正确无误。
⏹环境测试;
⏹维护性测试;
⏹功能测试;
⏹稳定性测试;
⏹大数据量测试;
⏹仿真测试。
⏹接口测试
6.4测试流程
6.4.1与开发组的沟通和合作
概述合作流程图
在项目开发前期,即开发主管在完成需求分析进入代码设计的时候,应该向测试主管提供需求分析、系统功能图等设计文档及资料,经过一些必须的交流会议后,测试主管应根据设计文档组织制定相应的测试计划,并且与开发主管一起制定相应的测试时间安排表。
在项目的实际测试之前,测试组将会根据设计文档编写测试计划和设计测试用例。
开发主管提供给测试主管的设计文档包括以下内容:
⏹需求分析:
分析客户或市场的需求,阐述开发本系统的原因。
⏹产品原理简介:
简单介绍产品的主要功能和原理,帮助测试人员尽快了解该产品。
⏹功能分布图:
图中列出了系统各个功能模块及其从属关系,使测试人员更清楚系统的功能结构,
并且避免测试时发生遗漏。
⏹功能流程说明:
一连串的动态动作,测试前必须知道。
功能流程的表示形式可以流程图或PDL
语言写。
⏹数据库设计文档:
该文档列出所用到的数据库的各个表的各个字段的资料,比如长度、类型、是
否可为空等等。
⏹界面设计风格:
界面设计风格以及各个界面里的输入框、按扭、链接等元素。
开发组在编码的过程中,在做好某一部分功能的时候会向测试组提出测试要求,测试组测试后提交测试结果给开发组;开发组修正错误/增加新功能后向测试组提出新的测试要求,测试组再测试;如此循环交流直到开发周期结束。
如图
具体合作流程
⏹开发主管TRD文档给测试主管,向测试组提出测试要求。
⏹测试主管收到TRD后,根据TRD安排人员进行相应测试,并尽早告诉开发主管该TRD结果的提交时间预计。
测试员在测试过程中填写Buglist文档,详细记录在测试过程中出现的问题的位置、现象和重现步骤等。
完成实际测试后,测试主管或指定测试员填写测试结果统计表。
⏹测试结束后,测试主管发Buglist简表、总表和TRD,提交测试结果给开发主管。
6.4.2测试计划
实际上整个开发流程和测试过程基本上是平行进行的。
测试计划应在需求分析阶段就开始制定。
充分的准备工作可以有效地克服测试的盲目性,缩短测试周期,提高测试效率。
简要讲述测试计划。
测试计划的架构大体如下:
1.产品简介
主要是对项目或产品的简介,让大家有个初步的了解。
2.系统和业务概要
主要讲述相关的业务及其流程,让大家对相关的业务有大概的了解。
3.测试范围
1)测试系统需求
要将系统运行的环境清楚的描述出来,如软件、硬件的环境,如果要求有特有的网络环境也要描述出来。
从这一项可以看出系统运行的环境,测试工程师就可以在前期先准备好这些设备和软件。
2)测试先决条件
说明要进行测试的先决条件,例如“能准确安装和配置服务器”,从这一项中可以看到,如果这些条件还没有满足,就还不能进行测试。
3)相关文档
列出相关的开发文档,如需求分析,系统分析,数据库设计等文档,这些文档无论对测试工程师熟悉系统还是实际的测试工作都有一定的帮助。
测试工程师可以只看这里所说的开发文档,避免了参考文档的盲目性,提高了一定的工作效率。
4)测试工具需求
列出测试中需要用到的测试工具,并说明测试工具的相应测试范围。
如果没有说明这一项,在测试的实际过程中,测试工程师可能不知道是否应该用测试工具。
5)测试人员概况
列出关于该系统的测试团队成员。
4.需要测试的领域
1)测试类型
列出已知的必须的测试种类,如功能测试、性能测试、安装测试、文档测试等。
测试工程师可以从这里获知大概会有什么类型的测试,从而可以做进一步的测试计划。
2)如果知道具体的测试类型,需要详细列出详细描述各种测试,如性能测试,会做什么样的测试啊,怎么样去测试?
如果是已知的在这里就要描述出来。
5.系统测试评估
1)测试进度安排
列出测试的时间安排,在什么时间进行什么样的测试,什么阶段的测试。
这里的时间安排是由开发主管和测试主管共同协商得来的。
在没有特殊情况下,开发和测试两方都会按照这里的时间安排来分配和计划工作。
2)测试风险评估
风险预估,这里列出可能的影响测试计划的事情,让大家都明白存在什么样的风险,预先有个心理准备,同时可以考虑风险出现时的对策。
6.4.3系统错误管理(BUGLIST)
6.4.3.1Bug的分类
(1)目前BUG的严重性分为3种程度:
高,中,低
(2)目前BUG的状态有以下几种:
⏹NEW新发现的,而且上一个测试用的版本也没有出现的BUG
⏹MISSED新发现的,但在上一个测试用的版本可以重现,是上次测试中测试员遗漏的
⏹FIXED开发人员在这次测试前声称已经修正(FIX)了,而且测试员确认情况属实
⏹UNFIXED开发人员在这次测试前声称已经修正了,且测试员确认发现不是
⏹PENDING暂缓处理的BUG
⏹CLOSED测试人员测试后认为是BUG或提出建议,但开发人员认为不是BUG或开发人员认为可以不必理会,经说明后测试人员认为可以接受的问题
6.4.3.2Buglist总表和简表
⏹Buglist简表:
记录这次测试中发现的存在问题,包括新发现问题的和至今未修正的旧问题。
Buglist简表有简表编号和总表编号,总表编号和Buglist总表里的相同,简表编号只是为了方便查看简表和统计数字而设。
⏹Buglist总表:
记录这个项目至今所有问题,包括已修正和尚未修正的问题。
Buglist总表只有总表编号,在一张总表里(一个项目的一个版本里),每个bug记录由总表编号确定其唯一性。
6.5项目测试的工作流程规范
6.5.1概述
一个完整的项目测试过程包括以下阶段:
1.制定测试计划。
在项目开发周期前期,即开发主管在完成需求分析进入代码设计的时候,向测试主管提供需求分析、系统功能图等系统说明文档。
这时测试主管应该制定相应的测试计划。
测试计划的目的是提供一个验证的计划,保证通过对系统的测试,确保系统实现系统设计(需求分析等)。
因此测试计划的制定是以项目开发的需要为依据的。
测试计划应表明该项目测试的整体目标声明,将要进行哪个层次的测试,将要应用到那些方法、技巧和工具等。
还要进一步表明有什么单项将要测试、他们的测试程度分别到哪、他们测试的先后顺序是什么,以及描述测试环境等。
2.一旦测试计划定下来后,就应该开始根据系统说明文档来设计测试用例。
测试用例是TSD(TestSpecificationDocument)文档的主要组成部分。
3.开始进行实际测试。
不断完善自动测试脚本。
4.实际测试结束后写项目总结。
6.5.2实际测试过程
在每一轮的实际测试中,我们要遵循以下工作流程
(1)测试主管
⏹接到测试要求。
⏹仔细阅读TRD。
分配测试任务,指出测试要点。
⏹根据实际情况组织修改自动测试脚本和测试数据。
⏹收集各测试员的测试需时预计,然后对TRD返回预计提交时间。
⏹在测试员测试过程中,抽查部分功能模块或直接参与测试。
⏹测试结束后,把各测试员的测试结果整理汇总,审查、修改测试报告)。
⏹在预计时间内提交测试结果给TRD发出者。
(2)测试员,当测试主管分配任务后,测试员按照以下步骤进行工作:
⏹仔细阅读TRD。
计划个人测试进度,尽快返回预计完成时间给测试主管。
⏹系统安装完毕后,首先进行SMOKINGTEST。
ØIFSMOKINGTEST不通过THEN提交测试结果给测试主管
ØELSE结合自动测试进行详细测试
⏹根据测试用例进行实际测试。
运行自动测试脚本。
记录并跟踪测试缺陷,即填写测试记录Buglist表,复查总表,重点是相应的上一份简表。
⏹测试结束后,检查测试结果(现存错误和上一份简表修正情况)有无错漏。
⏹按时提交测试结果给测试主管。
及时完善测试脚本和测试数据库。
测试用例,当测试人员收到项目测试要求和产品说明文档后,应该
⏹阅读系统说明文档(产品需求分析,原理简介,功能分布图,功能流程说明,数据库设计等),熟悉系统。
⏹根据说明文档编写测试用例(包括测试流程和测试数据)。
⏹交叉复审测试用例,完善测试用例。
⏹对需要自动化的测试用例做成本效益分析(cost/benefitanalysis)。
⏹如果可行,则根据测试用例制作相应的自动测试脚本和数据库文件。
测试用例。
测试用例文档的架构大体如下:
1.功能测试矩阵
功能测试的矩阵,因为考虑到测试用例比较多,需要对各个测试用例编号标识。
这个矩阵就是对测试用例编号,首先在最左边一列按功能模块列出各个用例,右边的列就是对应的用例的测试用例编号。
如”UserLogin”的测试用例有五个,分别是UL01,UL02,UL03,UL04,UL05。
测试用例编号的原则是前缀加后缀,后缀就是按顺序的两位数,不足10的都在前面补0。
前缀一般是由用例的各个单词的首字母组成。
如”DataSourceManagement”有三个测试用例,分别是DSM01,DSM02,DSM03。
BusinessFunction
TestCase
1
2
3
4
5
UserManagement
UserLogin
UL01
UL02
UL03
UL04
UL05
UserLogout
ULO01
ULO02
ULO03
ULO04
CreateNewGroup
CNG01
CNG02
CNG03
CNG04
DeleteGroup
DG01
DG02
EditGroup
EG01
EG02
EG03
EG04
CreateNewUser
CNU01
CNU02
CNU03
CNU04
EditUserDetail
EUD01
EUD02
EUD03
DeleteUser
DU01
DU02
DataSourceManagement
DataSourceManagement
DSM01
DSM02
DSM03
SelectDataSource
SDS01
RecipientListManagement
RecipientList
RLM01
RLM02
RLM03
RLM04
RLM05
RLM06
RLM07
RLM08
RLM09
RLM10
RLM11
RLM12
RLM13
RLM14
RLM15
CheckE-MailList
CEL01
CEL02
CEL03
CEL04
CEL05
CEL06
CEL07
CEL08
CEL09
CheckQuery
CQ01
CQ02
CQ03
CQ04
CQ05
CQ06
CQ07
MessageContentManagement
CampaignManagement
CreateNewCampaign
CNC01
CNC02
CNC03
CNC04
SearchCampaign
SC01
SC02
SC03
SC04
ReportManagement
SearchCampaign
RSC01
RSC02
RSC03
CampaignSummary
RCS01
RCS02
RCS03
PersonalReport
RPR01
RPR02
RPR03
Undeliverable
RU01
RU02
RU03
CampaignCompareReport
RC01
RC02
RC03
CampaignRedirectReport
RR01
RR02
RR03
SystemHistoryReport
HM01
HM02
2.功能测试用例
这是关于每个用例的测试用例,对于某个测试用例,可以作出它的测试用例流图,和列出测试用例的表格。
1)测试流程图
从这个图可以看出,从一个界面出发,不同的输入会得到不同的输出,有正确的界面输出,也有表示你出错的界面输出,在设计测试用例的时候就是企图要把所有可能的输入都包含进去,画出测试用例流图,所以一个功能用例的测试用例可能会有很多,复杂一点的甚至二、三十个测试用例都不奇怪。
如编辑用户资料的时候,因为输入项的无效和有效性都会产生不同的输出。
2)测试用例设计
上面已经说了,一个功能用例对应多个测试用例,这一部分就是详细的描述每个测试用例了,每个功能用例对应一个表格,表格的每一行对应一个测试用例,每个测试用例,要写出将要使用的数据,预期的结果,还有一项备注,主要是说明该测试用例的目的。
3.单项测试用例
单项测试是指针对程序中一些需要提交的表单中某些输入项所做的测试。
例如在登录界面中,一般要求输入帐号和密码,然后提交。
这里就要对帐号和密码的输入框分别做单项测试了。
对应于每一个输入元素(可能是文本输入框,可能是Checkbox,可能是下拉框等),都有一个表格的单项测试用例与它对应。
表格前首先要声明该输入框可输入的正确形式。
6.6测试的实施
6.6.1项目测试准备阶段
一个项目实际开始测试之前,我们可以接触到的有关文档包括:
需求分析、安装手册、数据库设计说明等。
6.6.1.1需求分析说明
需求分析是项目测试工作的依据,也是项目开发工作的依据。
我们可以根据需求分析中的功能分布图和功能流程来了解系统的具体功能及其分布,并以此为依据设计测试用例。
6.6.1.2安装手册
如果项目测试要求测试员搭建测试环境的话,我们还会得到系统安装手册。
安装手册内容一般包括产品及附件清单、软硬件配置要求、系统具体安装步骤等等。
我们要求安装步骤的内容是详细、可执行的。
另外,如果环境搭建还涉及其他系统的安装,我们要求提供相应的安装说明。
6.6.1.3数据库设计文档
该文档详细描述了系统数据库的资料,数据库包含的各个表,每个表的字段的类型,大小都给出了详细的说明。
数据库设计文档是我们测试中的重要依据,我们的许多测试用例都是围绕文档中的内容而设计出来的。
6.6.2项目测试实施阶段
进入测试实施阶段,测试组与开发人员的交流将是通过TRD(TestReleaseDocument)的形式。
开发人员项目完成了某个阶段,认为实现了某个功能或修正了某一部分错误,需要测试人员进行确认,那么他们将向测试组发出TRD,要求测试。
一个典型的TRD的包括:
1.测试要点
该表格描述了开发人员对本轮测试的具体要求,指明了哪些部分需要测试,哪些部分不需要测试。
2.BugFix情况报告
除了第一个TRD外,每一个TRD都应该有对上一轮测试所发现错误(bug)的修正情况的报告。
如下表
处理方法
数目小计
其他
FIXED
3
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 工具 测试 工作 指导