软件测试是每天都要向各种办法找BUG吗?
摘要:当前用户对软件企业开发出来的软件质量提出了越来越高的要求了。
所以在这种大的环境背景下,催生了一个新兴的职业——“软件测试工程师”的职业。
尤其是最近2-3年来加入这个职业或者即将加入到这个职业的人也越来越多了。
那么作为一名软件测试工程师,我们该如何迅速找到软件中的缺陷Bug呢? 下面结合作者多年的软件测试经验谈谈。
按照作者的观点:凡是不符合用户需求的,或者在使用过程中给用户造成不便的,都认为它是Bug。
话虽然说的有点极端,但是现实就是如此。
那么对于刚入行的软件测试新手迅速找出软件中的Bug思路如下: 1、尽快熟悉公司的产品业务 比如你们公司做ERP软件的,你肯定要迅速熟悉EPR的业务流程;比如你们公司是做法院软件的,那么你一定要熟悉法院审判案件的流程,只有熟悉了产品的业务流程、你才能迅速找出软件中存在的一些重要的缺陷,你发现的软件缺陷才是有价值的。
否则即使你能找到一些软件缺陷,那也是纯软件的缺陷,价值不大。
2、把自己当成是用户 把自己当成是用户去使用该系统,比如在使用该系统过程中是这样操作的吗? 2.1 比如在大量要求用户输入的软件界面中,有一些用户喜欢使用Tab键采用全键盘的输入;此时的正确的接口应该采取从左到右,从上到下的顺序。
2.2 比如有的用户喜欢使用快捷键操作等(Ctr+C,Ctr+V,Ctr+F),但是实际情况下一些开发出来的软件的快捷键却根本不起作用。
2.3 比如软件在需要用户输入的信息的时候(特别是在填写个人资料的时候),必填项后面一律要用*等醒目的标示,要让用户知道这个地方时必须填写的。
2.4 下拉框不选值的时候,应该有个默认值;并且要多检查程序中的多处下拉框,因为很多情况下下拉框取不到值。
3、善于怀疑,不要迷信高手 世界上没有绝对正确的,总有错误的地方,具有叛逆心理,别人认为不可能发生的事,我却认为可能发生。
别人认为是对的,我却认为不是对的。
如果你认为某个或者某些程序员水平很高,他写的这个地方应该没问题吧,那么我要说你错了,这样很容易遗漏软件中的Bug。
因为程序开发人员毕竟是普通的人,只要是人就会犯错误的。
4、不要让程序开发人员的观点:“用户不会进行这样的操作”而说服自己 遇到这样的情况,你要坚持你自己正确的想法,以后对方会明白你的。
比如在一个录入员工基本信息的系统中,系统中对员工的年龄作为负值、而没有作为判断、也可以保存到数据库中,此时你不要被程序员的用户不会进行这样操作的观点说服自己,你要坚持你正确的观点,把这种现象作为一个Bug吧,勇敢点!你的选择不会不错! 5、在软件测试过程中要跟踪一条数据完整的流程 在软件测试的时候要跟踪一条数据完整的流程,保证数据的正确性这个真的是太重要了:假如你在测试一个销售的类型的软件的时候:你应该先做订货-à入库-à盘点-à销售-à查询。
首先你要保证这个数据的流向是正确的无误的。
假如你在测试法院审判软件的时候,你要先收案-à立案-à发送审批-à排期---审理审判-à结案判决-à归档-à查询。
总之跟踪一条数据的流程,保证数据的正确性。
如果经过你测试的软件在用户使用过程中业务流程上都走不通的话,那么这样的软件你说经过你的测试,但是在比人看来与没有测试有什么区别呢? 6、回归测试要注意的细项 程序员提交新的程序版本后,作为测试人员应该立即与程序员沟通这个修改的功能、并且这个新修改的功能影响哪些功能。
举个简单的例子来说明一下:比如在一款软件中,程序开发人员修改了某个“会员”的某个字段信息。
作为测试人员首先你要测试“会员”的功能这个是你首先需要做的。
另外你还要和程序员沟通询问他们新修改的这个会员的字段,会影响会员的销售功能吗?会对会员以前的销售记录的查询有影响吗?如果对这些功能有影响,那么这些功能都是你在回归测试的时候重点测试的地方,也是最容易产生Bug的地方了。
7、与使用者互动的缺陷 7.1 如填写资料错误应的时候,应该能够提示错误的位置,让用户知道是这个地方输入数据不对。
7.2 删除数据之前给一定要给出是否删除确认提示。
7.3 不要在软件中使用中英文混合的提示比如:比如对于用户某个操作的错误提示,不要一会用“error”、一会用“错误”;一会用“succeed”另一会用“成功”,总之要统一。
急求,有没有会软件测试的大神,谁会找个小的软件,并测试找出...
就拿北测教育现在的软件测试工程师培训来说: 1、软件测试应该在需求分析阶段就进入了,完整的测试应该在项目需求完成以后,从需求规格说明书中去分析生成测试需求,接着开始编写测试计划,然后按照测试需求的要求和测试计划的规定,开始去编写测试用例(这个阶段,开发人员的工作可能刚进行到编码初期阶段) 2、具体写多少测试用例,没有一个严格的要求,但最基本的要求是,编写的测试用例,应该覆盖需求中关于软件功能、性能描述的所有点 3、客观上讲,在真实的项目测试周期里,不太可能写完所有的测试用例,但无论用例是否已经全部编写完成,在执行完需求中明确的定义的功能、性能的相关测试后,还可以由经验丰富的测试人员,去进行大范围的随意性测试 4、推荐你到北测教育,让你拥有扎实的技术,丰富的实训经验
离职一个月了,一直没找到工作,软件测试就这么难找吗?
测试需要的是能发现更多的BUG的多年经验和方法,楼下说的什么小算法,才毕业不要说小小的循环了,你给我算法书上任何一个复杂的代码都能写出来,那有个屁用,缺乏经验,测不出来BUG等于0 而有经验的又基本用不上,该忘的都忘了,尴尬的"被等通知" 不是工作难找,是应聘的人无能,只能靠试题检验死人才,还有用人单位心知肚明,想用便宜的应聘生代替有经验的, 自欺欺人,招不到好人才也是活该
软件测试的前景如何?
上面这位肯定是测试培训机构的托,我做测试3年了现在在一家准上市公司做测试主管,中国现在包括腾讯在内测试都不完备,原因无他因为中国网民包容性太强了,软件只要能用,不要好用,软件快餐化愈演愈烈,我们公司每个月至少发布一个产品的软件或定制软件或升级版本,研发近100人测试只有8人,测试都是时间紧,更公司申请多次要招人招OA,招管控,决策层都不予理睬,他们宁可把人力资源用在客服和销售上,因为测试不完备,再好的测试也不能保障软件没bug,还有完善的测试是要消耗大量的研发时间和研发资源的,市场不允许你这么慢吞吞!那公司现在要求就是发布的产品不要有明显bug,出现问题就找客观原因填补,然后再以后的版本中改进。
所以相对来说在中国现阶段软件只是还没有普及到全民的情况,不要想测试会向国外那样、会像培训机构讲的那样!...
找软件测试工作快一个月了,已经快过年了,还有必要继续找吗
这个职位更重视经验和技巧的积累,至于门槛只有一点,那就是你是否喜欢游戏,是否对游戏抱有热情,是否能够全身心地投入游戏。
这并不仅仅意味着你喜欢玩游戏就够了,用娱乐的态度和用测试的态度来“玩”游戏完全是两回事。
你面对的也许是没日没夜走同一张地图,打同一个关卡,反反复复,没有乐趣,你能忍受吗?具体来说,想成为一个合格的游戏测试员还要掌握:1.熟悉电视、电脑、手机等各种类型的游戏;2.有丰富的游戏经验并且对游戏有独特的见解;3.熟悉游戏测试流程,对测试理论有深刻的理解;4.较强的逻辑思维能力及分析对比能力;5.能够很快接受新的技术和测试技巧;6.具备良好文字表达和理解能力,善于文档报告书写;7.能承受在紧迫限期内完成工作任务的压力;8.有较强的团队合作精神、沟通和协调能力,能够有力协调并推动工作的开展;9.有强烈的责任心和敬业精神。
腾讯要求:首先,要有宽泛的计算机基础知识。
微机原理,数据结构,数据库,操作系统原理,编译原理,逻辑,编程语言,网络,等等,都要系统地学习过。
都精通不大可能,因为人的兴趣都不相同,但是,这些功课的基本知识点是应当了解的。
我们在谈到职业的类别的时候,我们可以说C程序员,C#程序员,Java程序员,而没有C测试员,C#测试员,Java测试员,程序员可以只擅长某一门编程语言,测试员却不行。
为什么呢?测试员是代表用户的,在做测试的时候,他(她)需要考虑到方方面面的事情。
例如对于一个用C写的上网拨号程序,测试员需要考虑: (1) 程序的功能是否正确;(要求计算机知识) (2) 是否符合用户的使用习惯;(要求界面设计知识和换位思考能力) (3) 性能是否满足要求,例如长时间使用;稳定性;(要求深入的计算机知识) (4) 是否能够满足用户可能的不同操作系统的要求;(要求计算机知识) (5) 如果在全球发布,是否满足不同语言和文化的需求;(要求软件国际化测试知识) (6) 如何搭建测试环境;(动手能力,硬件知识) (7) 做代码检查;(比较深入的C语言知识) (8) … 所以,各方面都了解一点,你在做测试的过程当中你会感觉顺手的多。
如果某写方面还差一些,没有关系,计算机行业的特点就是边做边学,只要是个有心人,学习是很快的。
其次,要掌握一门编程语言。
有的朋友可能会说,我就是不愿意做编程才来做测试的,怎么测试还有这么一个要求?我要尝试说服你:)。
我的理由有两个: 1. 只有知道怎么做一个软件产品,才能真正懂得这个产品。
而只有真正懂得了产品,才能做好测试。
一行代码不会,你会始终是个门外汉。
不要满足于点鼠标,而去尝试着打开我们面前的黑盒子。
2. 自动化测试技术需要编程技术。
自动化测试是软件测试的一个发展方向,一方面很多测试工具都需要人工干预,编写代码;另一方面在有的情况下需要自己编写测试工具。
对于测试员来说,编程技术不要求精通,但要会。
再次,学好英语。
在现阶段,我们只能承认,在计算机方面,英语国家领先。
有很多的资料都是英语的,如果仅仅局限在中文资料方面,会影响你的渊博程度:)。
举一个简单的例子,Windows操作系统会捕捉到一些程序或者操作系统内部的异常,你可以根据这个异常到微软网站上去查找错误原因和解决办法,其中有很大一部分资料就是英文的,因为还没有翻译过来或者以后也不会翻译的。
以上所说的几点看法,都是在计算机行业里面打转,下面说几个“虚”的要求吧。
1. 锻炼出一双测试的眼睛。
我的一个朋友,她也是做软件测试的,她说,有一次她和她老公去买笔记本电脑,她一眼就看出液晶屏上有几个坏点,而她老公却看不出来。
她说,这要归功于她有一双测试的眼睛。
测试的眼睛,就是对问题特别敏感,能够发现常人发现不了的问题。
测试员就是要找软件中的问题,有了这双眼睛会让你收益非浅。
耐心,细心和经验,会有助于我们到达这个要求。
2.平和的心态。
从心理学上说,每个人都不喜欢别人对自己挑毛病,程序员也是这样。
所以,要以平和的心态去看待发现的软件问题,以平和的心态去和程序员交流。
千万不要以为自己发现了几个问题,就可以责怪程序员,或者冲过去骂他们一顿。
也不要在背后谈论谁谁谁不行,bug太多。
一个项目是大家共同做的,需要举集体之力才能做完。
我们测试员发现的问题多,表明项目的风险又少了一点,应该高兴才是。
如果你的脾气不好,可能这个恶名会掩盖你的真才实学,很可惜的。
如何写一个强大的bug测试报告
在报告中说“不好用”;所报告内容毫无意义;在报告中用户没有提供足够的信息;在报告中提供了错误信息;所报告的问题是由于用户的过失而产生的;所报告的问题是由于其他程序的错误而产生的;所报告的问题是由于网络错误而产生的;简单地说,报告bug的目的是为了让程序员看到程序的错误。
您可以亲自示范,也可以给出能导致程序出错的、详尽的操作步骤。
如果程序出错了,程序员会收集额外的信息直到找到错误的原因;如果程序没有出错,那么他们会请您继续关注这个问题,收集相关的信息。
当您报告bug的时候(既然您已经这么做了),一定是希望bug得到及时修正。
所以此时针对程序员的任何过激或亵渎的言语(甚至谩骂)都是与事无补的——因为这可能是程序员的错误,也有可能是您的错误,也许您有权对他们发火,但是如果您能多提供一些有用的信息(而不是激愤之词)或许bug会被更快的修正。
除此以外,请记住:如果是,作者提供给我们已经是出于好心,所以要是太多的人对他们无礼,他们可能就要“收起”这份好心了。
“程序不好用”程序员不是弱智:如果程序一点都不好用,他们不可能不知道。
他们不知道一定是因为程序在他们看来工作得很正常。
所以,或者是您作过一些与他们不同的操作,或者是您的环境与他们不同。
他们需要信息,报告bug也是为了提供信息。
信息总是越多越好。
本文中提到的都是一些指导方针,没有哪一条是必须恪守的准则。
不同的程序员会喜欢不同形式的bug报告。
如果程序附带了一套报告bug的准则,一定要读。
如果它与本文中提到的规则相抵触,那么请以它为准。
如果您不是报告bug,而是寻求帮助,您应该说明您曾经到哪里找过答案,(例如:我看了第四章和第五章的第二节,但我找不到解决的办法。
)这会使程序员了解用户喜欢到哪里去找答案,从而使程序员把帮助文档做得更容易使用。
“演示给我看”这些可能还不够。
也许他们觉得还需要更多的信息,会请您重复刚才的操作。
他们可能在这期间需要与您交流一下,以便在他们需要的时候让bug重新出现。
他们可能会改变一些操作,看看这个错误的产生是个别问题还是相关的一类问题。
如果您不走运,他们可能需要坐下来,拿出一堆开发工具,花上几个小时来好好地研究一下。
但是最重要的是在程序出错的时候让程序员在电脑旁。
一旦他们看到了问题,他们通常会找到原因并开始试着修改。
如果您必须报告bug,而此时程序员又不在您身边,那么您就要想办法让bug重现在他们面前。
当他们亲眼看到错误时,就能够进行处理了。
“哪儿出错了?在我看来一切正常哦!”如果您给了程序员一长串输入和指令,他们执行以后没有出现错误,那是因为您没有给他们足够的信息,可能错误不是在每台计算机上都出现,您的系统可能和他们的在某些地方不一样。
有时候程序的行为可能和您预想的不一样,这也许是误会,但是您会认为程序出错了,程序员却认为这是对的。
特殊情况下,如果有错误消息号,一定要把这些号码告诉程序员。
不要以为您看不出任何意义,它就没有意义。
错误消息号包含了能被程序员读懂的各种信息,并且很有可能包含重要的线索。
给错误消息编号是因为用语言描述计算机错误常常令人费解。
用这种方式告诉您错误的所在是一个最好的办法。
如果您使用UNIX系统,程序可能会产生一个内核输出(coredump)。
内核输出是特别有用的线索来源,别扔了它们。
另一方面,大多数程序员不喜欢收到含有大量内核输出文件的EMAIL,所以在发之前最好先问一下。
还有一点要注意:内核输出文件记录了完整的程序状态,也就是说任何秘密(可能当时程序正在处理一些私人信息或秘密数据)都可能包含在内核输出文件里。
转载请注明出处51数据库 » 软件测试找bug快吗