测试bug。
我要测试百度知道的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”另一会用“成功”,总之要统一。
软件测试提交bug时包括哪些内容
1. Bug的标题(Title)和详细描述(Descriptions):标题是对你所提交的Bug进行简明描述;详细描述是对Bug进行详细描述,例如在什么情况下发生等;也可以直接将标题作为描述部分。
2. 回归(Regression): 是测试前一个版本有没有此类bug(称为回归测试)。
3. Bug测试环境(Environment):发现的这个bug的环境,例如:什么系统,哪个版本等。
对于bug环境的描述可以通过简单的罗列即可。
4. 复现的详细步骤(Repro Steps):将测试的过程简单的写一下,从你开始测试软件的最开始到你发现bug的时为止。
5. 实际结果(Actual Results)和预期结果(Expected Results):实际结果是在测试软件的过程中,软件所表现出来的特征或者行为;预期结果就是软件需要设计所要求达到的结果或者目标。
6. 备注(Notes):对bug的一些补充,例如:其它系统也发生,上个版本不发生等需要补充的内容。
7. 内容还包括bug的严重等级、优先等级等,对于不同的bug,要做出相应的提交内容
一条软件缺陷(或者叫Bug)记录都包含了哪些内容?如何提交高质量...
缺陷管理的作用在于,一是记录以便以后满足统计分析等需要,二是有助于重现问题以便定位及解决问题。
从这个角度出发,缺陷报告自然是能够记录越多的细节越好,包括测试环境、软件版本、所用工具及版本号、测试用例的信息、出错前所执行的操作步骤、出错时相关信息和日志,等等很多。
但是要真正做到捕获的都是有用的信息是非常困难的,因为我们只能从故障现象入手去记录相关信息,而问题的根源可能与之相隔甚远,来回折腾其实是非常耗时、耗资源的。
最好的办法就是发现问题之后马上debug,开发测试在一块来解决问题,这是最经济实惠的办法。
我个人非常喜欢敏捷软件开发的方式,开发测试在同一个团队里面。
发现缺陷后可以即刻查看、定位、调试修复问题。
而后在不得已的时候,例如短时间内无法解决此问题,再进行记录。
软件测试流程和bug生命周期?
软件测试记录的话,看具体要求,不知道这个测试记录到底是指什么,一般来讲,测试完毕后都会出一份测试报告。
包括测试需求点,安装包地址,用例执行粒度,测试覆盖的系统,机型,发现的Buglist,延期的Buglist(这些是需要产品,研发,测试三方共同确认的),测试达到发版条件,可以发版
软件测试人员遇到发现的bug不能重现怎么办
展开全部 1、在A版本发现的bug应该在A版本进行重现我们知道,有很多原因会导致A版本的bug可能不能在B版本重现:1)开发人员自己偷偷解了bug,以免受到KPI考核;2)环境差异,可能B版本的代码在A版本的环境也会出问题,但是在开发环境可能就不能复现;3)代码变更,也许是其他的代码引起的bug,B版本时其他开发已经修改,此类可以归纳为相关联功能引起的bug;4)AB两版本进行复现的前置条件及步骤已不同。
既然有这么多可能性,那我们就应该排除影响,让问题简单化,保持环境和代码一致的情况下进行复现。
A版本的bug如果在B版本不能复现,时间和条件允许的话,那就回退代码到A版本,有个前提不用回退,那就是已准确定位问题了,并且确定在B版本已经解决它了。
2、项目时间允许的情况下,开发人员应大力协作复现bug对于”疑难杂症“,开发人员应大力配合测试人员进行复现:1)如果对于不好调试的代码就打印更多log;2)可以通过连接测试环境数据库并回滚代码到A版本,根据获悉的已有情况添加断点调试代码;3)做更细致的code review等等方式。
在自己负责的那部分代码确定完没有问题,这时候就需要考虑到接口,是否在接口数据处理上的问题,就需要其他开发人员配合。
而测试人员需要尽最大努力来还原当时的场景:环境,数据,前置条件及测试步骤等。
3、测试人员要再次确认用例设计的覆盖度及周密性有几种情况会导致不可复现:1)环境;2)代码;3)数据。
而数据又可以归纳到代码容错性处理上,环境其实是可以很好还原的,那出现不容易复现的bug就大多数是归于代码和数据上了,对于测试而言,用例设计的覆盖不够,不够严谨就会导致bug不在我们的掌握中。
这个时候,我们有两种情况:一是原本用例就没有好好设计过,未经评审过,大家测试时就很随意,勿容置疑,赶紧把用例好好琢磨琢磨,再叫上项目相关人员进行评审,这么做的目的也是为了保证测试用例得到了项目相关人员的认可,各种情况大家都讨论过,保证在需求上大家的一致性,保证软件覆盖度能满足本次项目需求的要求,做到需求100%覆盖,开发人员若再提出更多建议,那也可以弥补一些黑盒测试时可能遗漏的情况;二是该项目已经经过严格的需求评审及用例评审了。
当然,即便如此也不能避免漏测以及对特殊情况的考虑。
当然,要这么做的前提是这个bug很严重,影响了版本的发布,有必要召集大家协力解决掉它。
4、绞尽脑汁,它仍然不能复现时,保持关注我相信,通过以上步骤的努力,仍然不能复现的bug一定是优先级不高的,那就再评估重要度,若通过项目组决定不影响版本发布,就密切关注此bug,在发布后验证时也重点关注下。
而且该bug不能关闭,依次往以后版本中顺延,并且每轮测试时都要尝试再次复现。
那何时可以关闭呢?也许3,5个版本发布后,没有出问题就可以决定关闭它了。
5、思考测试流程及测试规范,及时更正走过的弯路,制定提交bug的规范,便于开发及我们自己复现有一次,就会有第二次,我们应该及时响应,即便不能亡羊补牢,也要防患未然。
提交bug的规范,这个可能每个公司情况不一样,有些公司木有限制,提交的bug也是千人千面,这对于开发人员理解bug和复现bug无疑增加了难度。
而规范了bug提交,若记录了此bug的前置条件,使用的数据及操作步骤,可能会大有益处。
当然,此处不是说每个bug都这么详细。
希望能帮到你,望采纳!
软件测试中如何提交高质量bug
1、唯一性。
一个bug说明一个问题,如果有能力的话,一个bug说明一类问题,这一类问题一定要能判断出是一条代码错误引起。
2、可重现。
提供这个bug的精确步骤,使开发人员容易看懂。
3、一致性。
bug描述及所有信息要前后一致,不可有歧义。
4、完整性。
最好能抓图,一目了然;测试环境和特定条件一定要描述清楚,许多软件功能在通常情况下没有问题,而是在某种特定条件下会存在缺陷,所以软件缺陷描述不要忽视这些看似细节但又必要的特定条件。
5、简洁性。
通过使用关键词,可以使软件缺陷的标题描述短小简练,又能准确解释产生缺陷的现象。
6、跟踪性。
也许随着版本的变化,或者测试的深入,对bug有了新的认识或者新的判断,及时补充相关信息,能够提供给开发更有用的信息。
7、客观性。
软件缺陷描述不要带有个人观点,不要对开发人员进行评价,软件缺陷报告是针对产品的。
其实在平时测试中,经常会遇到不能重现的bug,这些问题有不能提交bug,如果放过往往上线后出现的概率很大,问题也一般比较不可接受。
所以我觉得对于重现不可重现的bug是做好测试很重要的能力。
1、保留信息。
遇到问题,最好抓图,搜集错误日志,保留测试现场环境,一旦发现此问题不可重现,这些数据和信息将很重要。
2、提高意识。
很多人在遇到这类问题时,往往觉得后来操作不可重现了,因此就忽视了。
这样往往会把此类bug遗留到产品发布后。
欠的帐总要还得。
3、自我分析。
对于自己分析这类问题,其实对自己的提高是最大的。
分析思路:环境问题和操作顺序。
4、寻求帮助。
如果研发可以帮忙,并且研发是负责任的话,只有信息全,研发分析往往是最快的途径。
如果研发忙或者不乐意做,也是不可厚非的。
但就要寻求组内能力强的人员或者组内讨论分析,集中大家的力量往往可以事半功倍。
在我的经历中,通过上面的方法,几乎能把所有的不可重现的问题变成可重现的并且提交bug.
游戏盒软件测试注意项 怎样找出更多bug
测试一般来讲都是根据测试用例来进行的,这是根本。
但是当一个人面对上千条甚至上W条的用例就可能由于烦操感而导致用例执行的不仔细,认真,这里就是一个非常重要的问题,如何在面对庞大的工作还能保证一个良好的心态就是最重要的,同样跑一份用例,我就见过一个人只能找出10几个Bug,而另外一个找出40多个Bug,而且他们都是按照测试用来进行的,有的公司没有测试用例,那么你就需要按照界面的顺序,,对于每个显示的内容,及可点击的功能点,进行无遗漏的测试,还有BUG发现最多的地方一般就是异常状态,例如你使用软件的时候突然关机,然后在开机软件会不会有什么异常之类的,这个只是个简单的例子,经验也是非常重要的。
游戏测试有些不太一样,游戏经验丰富的玩家可能会相对容易的找出一些Bug,但是根本的东西都相差不多~~ 纯手打,累死了= =
软件测试的流程是什么?
测试流程依次如下:1.需求:阅读需求,理解需求,与客户、开发、架构多方交流,深入了解需求。
--testing team2.测试计划: 根据需求估算测试所需资源(人力、设备等)、所需时间、功能点划分、如何合理分配安排资源等。
---testing leader or testing manager3.用例设计:根据测试计划、任务分配、功能点划分,设计合理的测试用例。
---testing leader, senior tester4.执行测试:根据测试用例的详细步骤,执行测试用例。
--every tester(主要是初级测试人员)5.执行结果记录和bug记录:对每个case记录测试的结果,有bug的在测试管理工具中编写bug记录。
--every tester(主要是初级测试人员)6.defect tracking:追踪leader分配给你追踪的bug.直到 bug fixed。
--every tester7.测试报告:通过不断测试、追踪,直到被测软件达到测试需求要求,并没有重大bug.8.用户体验、软件发布等……