软件测试总结.docx

上传人:b****0 文档编号:12854635 上传时间:2023-04-22 格式:DOCX 页数:11 大小:20.87KB
下载 相关 举报
软件测试总结.docx_第1页
第1页 / 共11页
软件测试总结.docx_第2页
第2页 / 共11页
软件测试总结.docx_第3页
第3页 / 共11页
软件测试总结.docx_第4页
第4页 / 共11页
软件测试总结.docx_第5页
第5页 / 共11页
点击查看更多>>
下载资源
资源描述

软件测试总结.docx

《软件测试总结.docx》由会员分享,可在线阅读,更多相关《软件测试总结.docx(11页珍藏版)》请在冰豆网上搜索。

软件测试总结.docx

软件测试总结

软件测试总结

测试经验总结本人做过两年的软件测试。

现总结这两年的工作经验并分享给大家。

希望对于想进入软件行业的朋友有所帮助。

如果您对本文档不满意,希望批评指正;本文档是随笔所写,没有顺序可言。

;本文档适合想进入软件测试行业的朋友,或进入软件行业时间不长的朋友,如果您是多年的软件高级测试员或软件开发人员,则没有必要看这个文档(免得浪费您的时候,到最后看完没觉得有什么帮助,然后…狂骂)。

本文档是个人总结,难免有所错误,如发现错误,希望发邮件(aibaiqifengdou@)指正。

集体的智慧永远都是无穷的

一.心态

软件测试员,首先要心态好。

什么叫心态好。

就是你要有耐心,有细心,有责任心。

不要三天打鱼两天晒网的。

经验是日常点点滴滴积累的。

这是句实话,也是句屁话。

时不时的想想这句所谓的屁话,你会受益匪浅的;

既然选择了,那就坚持。

但是:

如果你有机会成为国家的人,那我就要告诉你的是:

干什么软件测试啊,傻啊,哪有国家公务员爽呢,公务员是一辈子的。

打工做测试哪年是个头啊。

打工只是没有办法的办法,仅此而已!

幻想着想创业,阿弥陀佛。

哥们,现实点吧。

那都是骗人的。

就那么几个人成功了而已,而且社会环境也变了。

不好混啊。

软件测试刚开始你会学一些东西,等到了一定阶段的时候,你会发现自己学的东西越来越少,工作总是重复(黑盒测试这种情况居多)。

二.要命的细节

做软件测试员,心细是肯定要有的,不然你就无法升级到高级软件测试员,无法拿更高的工资;

任何bug都是从点点滴滴的细节中发现的。

特别是一些不容易发现的bug。

比如:

记得当时我测试一个软件的时候,在测试的过程中,突然发现软件居然变得很迟缓(就是软件反应速度慢),重新启动软件后,还是很迟缓,只有刚开机测试的时候,软件响应速度快,后来在测试的过程中发现,在重复登陆软件的时候,相应的进程并没有关闭,登陆次数越多,相应进程也就越多,可用内存越来越少,导致软件越来越慢。

这就是我认为的细节之一;

我这么说不是让大家在测试软件的时候,没事就看进程。

我只是说:

在测试的过程中如发现软件突然出现异常情况,抓住这个细节,然后一点一点的分析,在什么样操作下出现的这个问题;一旦能够复现这个问题,那么及时的做好文档并与开发进行沟通;

再比如:

上一版本的程序,某模块的功能是正常的,下个版本这个模块的功能却出现了bug。

(这是很正常的),因为软件中关联的东西很多。

开发人员改动了软件,可能影响到了相关联功能,导致新的bug出现;

再比如:

几个相关软件进行测试的时候,有的时候软件之间是有影响的,即:

如果出现bug的话,很难测试出来;必须一步一步的细心耐心的测试;当时我在测试两个想关联的软件的时候,发现数据库中的某个表的字段数据突然不对了。

当时我只是单独的去测试这个两个软件,没有把两个软件关联起来测试,怎么测试都没测试出来,后来我整理下思路发现,可能是第二个软件影响了第一个软件得数据。

后来经过多次的验证,2确实如我所想的那样。

所以细心是根本;你比别人细心那么你就有可能会比别人走的更远;三.理论

软件测试理论没多少东西。

买本书花一星期或者几天你就能搞定;什么黑盒测试。

白盒测试。

灰盒测试;功能测试,性能测试。

有什么样的测试方法了,如何进行测试了。

测试的目的等等;这些都很简单,面试的时候,肯定会问到,所以掌握软件基础知识,是灰常必要的。

不然你都没法忽悠;工资的高低有的时候就靠你的忽悠能力。

如果面试官懂软件测试,那么你就要注意了。

你要把你确定100%的东西要肯定的回答,然后再加上自己的理解,然后开始忽悠。

四.软件测试的目的

如果有人问你:

软件测试的目的是什么?

如果你说:

就是为了测试软件的bug,测试软件存在多少个bug。

那么你要倒霉了。

软件测试的目的并不是测试软件的bug数量。

而是测试软件是否能够满足客户的需要;切记这点。

本人认为:

没有bug的软件是不存在的(客观也是如此)。

只要软件的功能能够得到客户的认可,就o五.动手能力

没有很好的动手能力是不行的。

测试软件的时候,不要怕把软件弄坏。

大胆的干吧。

但是也不能随便的没有目的的进行测试。

测试软件都是有目的的。

你要明白要测试的这部分功能是什么,相关联的功能是什么。

然后想想如何进行测试,然后开始测试;六.文档

在测试的过程中如果公司有bug管理工具,那么就可以省了不少文档。

测试的需要很多文档:

测试用例,测试结果文档,测试总结文档等等;七.描述bug

描述bug一定要把每一步详细操作都要说明,然后再说明在哪一步出现的bug,最好有截图。

当然了如果需要,你要写好软件的版本,和你电脑的环境(什么系统)

在不同的操作系统下,bug不一定都能出现;也就是说:

操作系统会影响到测试的结果。

一定要按照客户的环境来进行测试;这样可靠;八.思路

测试的时候,要明白整体的测试流程。

思路要清晰。

如果思路不清晰的话,软件的很多bug你根本测试不出来,这也就是为什么客户现场出现的bug,测试部为什么测试不出来的原因之一。

测试部的人有的时候不是站在客户的立场上进行测试的,这一点很要命;九.测试特殊业务

如果是给银行项目测试的话,你要规范你的测试文档。

比如:

文档行间距,字体大小,文档说明错别字等等。

因为银行的人不懂业务,他们就懂得看文档,对文档要求特别的高。

谁让人家是客户呢,客户就是上帝。

十.没事翻翻测试书籍,在网上查查测试资料。

时不时的总结下自己的测试经验。

跟同事,

同行交流测试经验,这样进步更快,就好比:

和尚坐火箭,突飞猛进

十一.好的测试员,肯定是要学会用oadrunner,QTor:

1048256HD:

ST380817AS80GHD:

ST380817AS80GSATASATAWindow201*OS:

(Sa和minor阶段,属于一般性的缺陷,但是测试的时候,出现了68个严重级别的bug,出现严重级别的bug主要表现在以下几个方面

系统主要功能没有实现

添加数据代码重复后,出现的找不到页面的错误多语言处理,未考虑非语种代码的情况

数据库设计未考虑系统管理员角色,导致用系统管理员进行操作的时候出现找

不到页面错误权限控制异常

严重级别bug按版本分布如下:

teting

由严重bug版本分布图可以看出,严重级别的bug版本趋势和bug版本趋势基本是一致的,但是,在B7和B9版本中年,严重级别的bug明显增多,主要原因是B7和B9版本测试了权限控制按钮功能,权限问题出现的严重级别的bug比较多。

权限bug主要表现:

具有相应按钮操作的权限,页面无相应按钮,无法执行该功能无相应按钮操作权限,页面有相应按钮,点击按钮能出现权限异常错误有相应按钮操作权限,有相应按钮,执行该功能出现权限异常错误teting

引入阶段

由上图可以看出,主要为前台编码和页面设计方面的bug,占到了全部bug的2/3。

引入原因

由上图可以看出,主要为前台编码和易用性方面的bug,占到了全部bug的2/3。

teting

状态分布

由bug状态图可以看出,未解决的bug有4个,主要是B8中新提交的bug,是关于用户管理的bug,因为用户权限管理需要重新设计所以,该部分的bug暂时没有解决。

5测试结论

51功能性

系统正确实现了通过数据字典管理基础数据的功能,实现了数据内容的多语言功能,实现了中英文界面。

实现了基础数据管理,酒店集团管理,酒店基础信息管理,渠道管理,代理管理,用户管理的查询,添加,修改,删除的功能,系统还实现了将权限控制细化到菜单

按钮的功能。

系统在实现用户管理下的权限管理功能时,存在重大的缺陷,权限控制不严密,权限设计有遗漏。

52易用性

现有系统实现了如下易用性:

查询,添加,删除,修改操作相关提示信息的一致性,可理解性输入限制的正确性teting

输入限制提示信息的正确性,可理解性,一致性现有系统存在如下易用性缺陷:

界面排版不美观

输入,输出字段的可理解性差输入缺少解释性说明中英文对应的正确性中英文混排

53可靠性

现有系统的可靠性控制不够严密,很多控制是通过页面控制实现的,如果页面控制失效,可以向数据库插入数据,引发错误。

现有系统的容错性不高,如果系统出现错误,返回错误类型为找不到页面错误,无法

回复到出错前的状态

54兼容性

现有系统支持window下的IE浏览器和傲游浏览器,支持inu系统下的IE浏览器和

火狐浏览器。

现有系统未进行其他兼容性测试

55安全性

现有系统控制了以下安全性问题:

把某一个登录后的页面保存下来,不能单独对其进行操作不进行登录直接输入某一页面的Ur能否打开页面并进行操作不应该允许。

现有系统未控制以下安全性问题:

用户名和密码应对大小写敏感登陆错误次数限制teting

6分析摘要

61覆盖率

此次测试,所有测试用例都是在中文界面下执行,未在英文界面下执行,测试不包括英文界面下的测试,也不包括正对英文翻译的测试。

此次测试,部分页面需求描述无明确的定义,对输入限制无详细定义,无明确的测试依

据,在测试过程中,测试是根据输入字段含义,测试人员理解,以及和项目经理,开发人员沟通获得测试依据,无法保证测试依据的正确性和完整性,因此,没有进行完整的,正确的无效数据的测试,测试覆盖率不够,无法保证测试的有效性和正确性

下面为此次测试测试用例覆盖率分析图:

62遗留缺陷的影响

1.缺陷描述:

酒店娱乐项添加页面,“距离”字段无单位,建议增加单位

缺陷影响:

距离字段无单位说明,无衡量标准,用户易用性不好推迟原因:

需求定义无单位定义,统一在升级版本中解决

2.缺陷描述:

酒店基础信息管理模块,默认语言设置不一致。

用中文查询酒店,进入酒店

基础信息模块后,如下模块,语言显示为“请选择”列表页面添加页面取消政策停留政策担保政策teting

机场参照点会议室详情打包促销服务Rate而其他模块语言显示“中文语言”

缺陷影响:

相同功能模块默认语言设置不一致,一致性不好推迟原因:

默认语言设置,目前无统一标准,升级版本中统一

3.缺陷描述:

tomcat日志有乱码,日志无项目名称,查看不方便

缺陷影响:

其他项目日志都有项目名称,日志无项目名称,查看不方便

推迟原因:

目前的日志为了调试方便,显示了很多其它信息,在项目正式发布时会统一处理的。

4.缺陷描述:

取消政策管理要么,取消时间“天/小时”缺少单位补充字段

缺陷影响:

该处因为是两个不同的单位时间,需要有另外一个单位补充字段补充所所填

写内容的单位

推迟原因:

该缺陷单位补充字段本来存在,翻译不够准确,不能理解为补充单位的字段,需要等翻译完毕后再确认。

5.缺陷描述:

数据字典种类修改,默认值设置后,在调用该数据字典种类的数据字典,默

认值无显示

缺陷影响:

数据字典种类的默认值设置后,不能显示设置的默认值,相当于数据字典种类默认值设置功能未实现

推迟原因:

该功能暂时不好实现,需要和和系统的默认语种一起处理。

6.缺陷描述:

担保政策管理页面,“EdoitDue”缺少解释行输入描述信息

缺陷影响:

缺少解释性输入描述信息,用户不理解应该输入什么内容

推迟原因:

需求没有描述,需要解释性说明文字由项目经理整理后,在升级版本中添加7.缺陷描述:

多媒体添加,文件上传功能未实现

缺陷影响:

文件上传功能未实现

推迟原因:

该功能暂时不好完成,在下个版本中完成

8.缺陷描述:

参照点添加权限和修改权限单独控制出现权限异常错误

缺陷影响:

用户执行添加,修改时,出现权限异常,无法完成任务

推迟原因:

B9版本发现该权限,B10版本未通过验证,目前该模块开发人员调休,无法修改bug,

9.缺陷描述:

酒店渠道绑定关系权限控制出现权限异常错误

缺陷影响:

a>权限控制易用性不好,会引起用户误操作;

b>权限控制错误teting

推迟原因:

B9版本发现该权限,B10版本未通过验证。

该模块后台无inert权限,只有Udate权限,与其他模块不同,需要重新设置权限控制方式。

10.缺陷描述:

酒店Rate绑定关系权限控制出现权限异常错误

缺陷影响:

a>权限控制易用性不好,会引起用户误操作;

b>权限控制错误

推迟原因:

B9版本发现该权限,B10版本未通过验证。

该模块后台无inert权限,只有

Udate权限,与其他模块不同,需要重新设置权限控制方式。

11.缺陷描述:

新建业务管理员权限用户,进入打包促销页面出现权限异常错误

缺陷影响:

除系统管理员外,其他用户无法进行打包促销操作

推迟原因:

B10版本发现该bug,目前该模块开发人员调休,无法修改bug

63建议

在项目开始的时候应该制定编码标准,数据库标准,需求变更标准,开发和测

试人员都严格按照标准进行,可以在后期减少因为开发,测试不一致而导致的问题,同时也可以降低沟通成本。

发布版本的时候,正确布置测试环境,减少因为测试环境,测试数据库数据的

问题而出现的无效bug。

开发人员解决bug的时候,填写bug原因以及解决方式,方便bug的跟踪。

开发人员在开发版本上发现人员,因为开发人员发现的

bug

bug,可以通知测试

很有可能在测试版本上出现,而测试人员和开发人员的思路不同,有可能测试人员没有发现该bug,而且,这样可以保证发现的bug都能够被跟踪。

7度量

71资源消耗

测试时间201*年7月2日至201*年8月6日共35天

测试人力1人×7天+1人×35天=42人天服务器:

PC2台硬件资源客户端:

PC2台teting

72缺陷密度

8典型缺陷引入原因分析

测试过程中发现的缺陷主要有以下几个方面:

1.

需求定义不明确

需求文档中,存在功能定义错误,输入输出字段描述错误,输入输出字段限制定义错误,输入输出限制定义缺失这几种类型的缺陷。

使得开发人员根据需求进行设计时,没有考虑相关功能的关联性,以及需求错误的地方,在测试过程中,需求相关的问题表现出来。

需求做改正,设计必须跟着做改动,浪费时间和影响开发人员的积极性,降低开发人员对需求的信任,可能会导致开发人员不按照需求进行设计而根据自己的经验来进行设计。

2.功能性错误

功能没有实现,导致无法进行需求规定的功能的测试。

主要是无法进入酒店

设施管理,会议室管理页面,酒店安全项管理无法保存信息,地区,房型删

除功能缺失。

功能实现错误,实现了需求未定义的功能,执行需求定义的功能时系统出现

错误。

主要是角色拥有不属于自己的权限,酒店联系人删除页面跳转错误等。

3.页面设计和需求不一致

页面设计没有根据需求进行,输入,输出字段文字错误,用户无法理解字段含义。

页面设计没有完成需求规定的输入限制验证,导致用户可以输入错误的或者无效的数据,这些数据有可能会引起功能性错误。

4.多语言数据问题

系统中很多输入字段是通过调用数据字典的方式输入,但是现有系统中,很

多数据字典的多语言信息没有完成,导致使用多语言的时候,显示空白字段。

系统中很多地方使用多语言,由于多语言编码不统一导致页面设计和数据设

计使用语言编码不一致,由此引起的多语言数据无法显示的缺陷。

5.页面设计易用性缺陷

页面设计不友好,系统中很多页面的输入字段无明确的输入提示,用户无法

理解何种输入是正确的,但是用户输入错误后,系统提示出错,增加用户负担。

提示信息错误,不同模块相同结果的提示信息不一致,用户操作后,相应的teting

提示信息不明确,引起用户误解。

提示信息一致性,用户在不同页面执行相同的操作,提示信息不同。

6.开发人员疏忽引起的缺陷

因为开发人员的疏忽,导致系统需要验证的地方,调用了错误的验证,系统需要进行输入控制的地方没有进行相应的控制。

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 高等教育 > 农学

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1