什么是软件的Bug
Bug的管理是个琐碎而且麻烦的事情,用EXCEL会耗费大量时间在表格制作,使用传统的Bug管理软件又会在反人类的功能设计上提高使用成本。
所以,我们要选择人性化的Bug管理工具,以强大、方便的分类,筛选等功能,对Bug进行管理,可将管理Bug的时间成本降低50%。
我们公司之前有自己的bug管理系统,如果不考虑用户体验要素,这套系统基本上能够满足正常流程:纪录、审查、跟踪、分配、修改、验证、关闭、整理、分析、汇总以及删除。
自己开发bug管理系统虽然投入成本相对较高,但可以根据团队工作习惯定制化。
不过有一点麻烦:这个bug管理系统并不是团队每个成员经常登录的系统,这就导致遇到bug时,需要经过“找出收藏的网址→登陆→依照指标输入详情→阶段性查看最新进展”,如果遇到这个bug是用户向你反馈而后你输入到bug系统时,你还需要等几天后给出反馈。
这冗长的环节和时间等待,让我有点失去耐心,等到后来遇到用户反馈的bug我往往直接找技术反馈、处理而绕过bug管理系统。
这样做肯定会影响到技术人员的开发效率,打断其思路,是非常不好的工作习惯。
我们团队现在直接在日事清内进行“bug管理”,提bug人员将bug输入到“收集”状态,由产品助理集中处理,视bug具体情况将bug拖拽到其他集中状态。
如果拖拽到“确认”,在该bug下添加相应技术人员让其处理,技术人员会在日事清协作系统内收到通知并且bug同步到其收纳箱,方便技术人员集中处理,解决后由技术人员拖拽到“已解决”状态卡片,大大提高了工作的效率。
功能bug,什么是需求bug,什么是设计bug
漏洞,就是BUG,所谓“(Bug)”,是指电脑系统的硬件、系统软件(如操作系统)或应用软件(如文字处理软件)出错。
硬件的出错有两个原因,一是设计错误,一是硬件部件老化失效等。
软件的错误全是厂家设计错误。
那种说用户执行了非法操作的提示,是软件厂商不负责的胡说八道。
用户可能会执行不正确的操作,比如本来是做加法但按了减法键。
这样用户会得到一个不正确的结果,但不会引起bug发作。
软件厂商在设计产品时的一个基本要求,就是不允许用户做非法的操作。
只要允许用户做的,都是合法的。
用户根本就没有办法知道厂家心里是怎么想的,哪些操作序列是非法的。
从电脑诞生之日起,就有了电脑BUG。
第一个有记载的bug是美国海军的编程员,编译器的发明者格蕾斯·哈珀(GraceHopper)发现的。
哈珀后来成了美国海军的一个将军,领导了著名计算机语言Cobol的开发。
1945年9月9日,下午三点。
哈珀中尉正领着她的小组构造一个称为“马克二型”的计算机。
这还不是一个完全的电子计算机,它使用了大量的继电器,一种电子机械装置。
第二次世界大战还没有结束。
哈珀的小组日以继夜地工作。
机房是一间第一次世界大战时建造的老建筑。
那是一个炎热的夏天,房间没有空调,所有窗户都敞开散热。
突然,马克二型死机了。
技术人员试了很多办法,最后定位到第70号继电器出错。
哈珀观察这个出错的继电器,发现一只飞蛾躺在中间,已经被继电器打死。
她小心地用摄子将蛾子夹出来,用透明胶布帖到“事件记录本”中,并注明“第一个发现虫子的实例。
”[1]从此以后,人们将计算机错误戏称为虫子(bug),而把找寻错误的工作称为(debug)。
就像衣服烂了就要打补丁一样,软件也需要,软件是人写的,而人是有缺陷的,所以也就免不了软件会出现BUG,而补丁是专门修复这些BUG做的
如何调试低概率复现bug
相信大家在测试过程中肯定遇到过这种Bug,不少这种不可复现的 Bug定位起来非常困难,可能很长时间都不能得到解决。
能否复现这些不可复现的Bug成为大家关注的一个话题,最近国外的测试专家James Bach、Jonathan Kohl等对这个话题进行了一些探讨,这里把他们的一些思路理出来和大家分享。
要想复现不可复现的Bug,需要先提到一个概念就是ET(Exploring Test),也就是探索式测试,这种测试方法是由James Bach首先提出来的,在所掌握的被测对象的信息不是很充分的情况下,这是一种很有效的测试方法,如果大家感兴趣,我再整理一篇ET的文章出来。
在给大家阐述的思路之前,先说说为什么要复现这些不可复现的Bug(废话两句^_^)。
对于整个项目或者产品而言,如果这些不可复现的Bug是很严重的Bug,比如导致系统崩溃等,如果不能及时、准确的定位和解决,最终发布出来的软件到达用户手中后,一旦出现势必会影响软件已经公司在用户心中的形象,严重的会“迫使”用户选择竞争对手的产品,这些显然都是公司所不愿看到的。
而对于测试人员而言,出现了这些不可复现的Bug,实际上是一次很好的锻炼和提高机会,如果只是提交缺陷报告将这个大皮球踢给开发人员,不仅丧失了一次提高测试水平的机会,还有可能破坏和开发人员之间的关系。
1、被测对象的版本信息我测试的到底是哪个版本,这主要是有两个作用:一是确认我测试的是正式的软件版本,如果不是就先记录下该问题,然后选择正式的版本进行测试(开发人员基于尝试的一次非正规的修改可能会导致不可复现的Bug);二是可以和其它版本进行对比,如果其它的版本没有类似的问题,就可以去对比这两个版本之间的区别。
2、环境这里的环境是指出现不可复现的Bug时所对应的测试环境等,比如测试所用的计算机,如果出现不可复现的Bug,那我换一台机器是不是还会出现类似的问题,也就是说通过环境的改变来进一步搜集不可复现Bug的相关信息。
4、人这里提到的人有两个含义:一是测试是由人来进行的,人的操作、人的思维方式会有不同,通过分析这些信息也有可能找到这些不可复现的Bug的蛛丝马迹;二是想复现不可复现的Bug,往往需要多个人之间的相互协作,比如测试人员、开发人员等,通过大家的沟通和协作就能更容易去复现了。
5、测试工具通过一些debug工具或者log工具等搜集内存等信息,根据这些信息来进行分析,找出不同信息之间的共同点,比如某一块内存始终都会被改写等,通过这种方式来去复现Bug。
上面的五个方面都是和ET的思想紧密相关的,通过不断的测试和不断的信息收集和分析,逐步的把模糊的、不确定的测试变成清晰的、确定的测试,这样就能复现那些不能复现的Bug了。
考虑信息时可以从以上五个方面来进行考虑。
相应的文章链接:
谁有做手机软件测试经验比较丰富的分享一下经验, 主要讲一下手机软...
楼主指的是手机的第三方软件测试吧如果是,那么我略谈一些关于这方面的东西。
首先测试一般是把流程走通,这是最基本的,你的软件需要实现什么功能和实现了什么功能,严格按照需求,即使是可用的功能,需求没有的话,那也是Bug。
软件的可用性和体验性交互性:这一块的Bug应该是最多,举一个简单的例子,使用软件的过程中来短信和来电,如果你的软件是基于网络的,这一块肯定会有很多问题。
而且,手动的将网络断开再恢复,请求会不会重新发送,这一点也是需要考虑的。
将软件中的控件和手机的按键结合起来测试。
还有你要明确软件的平台,兼容性需要考虑,如果是一个平台的,但是分辨率不一样,会使得界面元素丢失等,如果是键盘和触屏,那又要分情况考虑了。
找Bug就是要把软件玩死,就要充分考虑异常的操作,测试不是找开发的错误,而是想开发没想到的东西,场景是否面面俱到,错误处理是否健全。
午休时间到....
转载请注明出处51数据库 » 软件bug的考虑方面