测试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有哪些呢?
在得到一个详尽的测试程序后,剩下的工作就是执行测试计划了。
但是由于任何由人编写的程序都不可避免的存在着不符合测试需求的错误,也就是 bug。
因此需要一个方法来跟踪、分析和展示那些测试活动,避免偏离最小。
这种方法称之为错误跟踪系统。
它主要是有效的管理缺陷,实现以下作用: 1)减少由于缺陷报告不明确而被开发组驳回的情况; 2)加快缺陷的处理速度; 3)提高测试的可信度; 4)加强测试组与开发组在整个项目过程中的团队合作 3、如何才能提交好的测试bug 在有些组织里,程序员几乎会把一半的测试bug返回给测试组,因为那些错误不可再现、没有发现错误、同设计要求一致,或者错误报告根本无法操作。
如果错误报告有如此高的返回率,基本可以认为是过程崩溃,需要立即解决:因为编写这些报告浪费了时间;会影响程序员和测试人员之间的团队凝聚力;最糟糕的是失去改进产品质量的机会。
软件测试的流程是什么?bug具体是什么?怎么提交?
展开全部 简单跟你讲下吧,1.软件测试流程,一般是这样:需求了解——测试计划——测试设计——测试用例编写——测试执行——bug管理跟踪——测试报告生成2.bug就是测试过程中发现的程序缺陷,可以指需求上的,也可以指功能、性能上的3.bug提交有多种方式,可以通过测试管理工具来管理bug,比如QC等4.bug的生命周期: 发现bug(open)——修复bug(fixed)——关闭bug(closed)...
软件测试中如何提交高质量bug
1、唯一性。
一个bug说明一个问题,如果有能力的话,一个bug说明一类问题,这一类问题一定要能判断出是一条代码错误引起。
2、可重现。
提供这个bug的精确步骤,使开发人员容易看懂。
3、一致性。
bug描述及所有信息要前后一致,不可有歧义。
4、完整性。
最好能抓图,一目了然;测试环境和特定条件一定要描述清楚,许多软件功能在通常情况下没有问题,而是在某种特定条件下会存在缺陷,所以软件缺陷描述不要忽视这些看似细节但又必要的特定条件。
5、简洁性。
通过使用关键词,可以使软件缺陷的标题描述短小简练,又能准确解释产生缺陷的现象。
6、跟踪性。
也许随着版本的变化,或者测试的深入,对bug有了新的认识或者新的判断,及时补充相关信息,能够提供给开发更有用的信息。
7、客观性。
软件缺陷描述不要带有个人观点,不要对开发人员进行评价,软件缺陷报告是针对产品的。
其实在平时测试中,经常会遇到不能重现的bug,这些问题有不能提交bug,如果放过往往上线后出现的概率很大,问题也一般比较不可接受。
所以我觉得对于重现不可重现的bug是做好测试很重要的能力。
1、保留信息。
遇到问题,最好抓图,搜集错误日志,保留测试现场环境,一旦发现此问题不可重现,这些数据和信息将很重要。
2、提高意识。
很多人在遇到这类问题时,往往觉得后来操作不可重现了,因此就忽视了。
这样往往会把此类bug遗留到产品发布后。
欠的帐总要还得。
3、自我分析。
对于自己分析这类问题,其实对自己的提高是最大的。
分析思路:环境问题和操作顺序。
4、寻求帮助。
如果研发可以帮忙,并且研发是负责任的话,只有信息全,研发分析往往是最快的途径。
如果研发忙或者不乐意做,也是不可厚非的。
但就要寻求组内能力强的人员或者组内讨论分析,集中大家的力量往往可以事半功倍。
在我的经历中,通过上面的方法,几乎能把所有的不可重现的问题变成可重现的并且提交bug。
...
软件测试中bug数量一般为多少
展开全部 这个是不会有一个明确的定义的也没定义说一个产品测试出多少BUG之后就发布了所以按照BUG数量来判断产品是不对的一般产品发布公司都有要求比如:严重等级的BUG必须修正、影响用户使用的BUG必须修正但是有一些是是很难复现的、你在测试中发现了BUG但是却不能复现出来、或者是有的BUG能复现 但是项目组讨论却认为不一定要修改。
我现在的这个产品、我在做第一个版本的是有2000多个BUG之后在做第二个版本的时候只有100个左右、第三个的版本时候有70多个 现在已经更新到第五个版本了也都差不多是70个左右...
软件测试提交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吗?
摘要:当前用户对软件企业开发出来的软件质量提出了越来越高的要求了。
所以在这种大的环境背景下,催生了一个新兴的职业——“软件测试工程师”的职业。
尤其是最近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怎么找
展开全部 写写我的经验吧。
其实很简单:分析log测试客户端或web功能时,打开抓包工具,跟踪自己的操作路径。
当涉及到server功能时,就依赖于开发了,有经验的开发会在自己的代码中打很多的log,去log文件里按时间找自己的操作即可。
通过分析log,可以:1. 方便的回溯随机bug,出现问题直接查错误日志、定位原因、告知开发,就不需要再绞尽脑汁的重现bug了,提高测试质量。
2. 查log能够准确的定位问题。
特别是比较复杂的系统,一环套着一环,通过查log剥茧抽丝逐步定位问题所在。
提高工作效率。
3. 查log的过程也是对系统实现细节的深入学习过程,通过了解到的技术实现,完善测试用例,避免漏测。
但在实际的测试中,可能会有很多意想不到的情况,比如开发忘记在出错点打log了,你分析半天发现没哟,浪费时间所以测试之前一定要提醒开发在关键点打好log:1、异常处理。
系统各层次都要显式处理异常,任何可能出现的错误都能在日志中找到原因和地点。
2、重要的逻辑处一定要有日志。
能够通过日志看出是哪个文件的哪个方法出了问题。
...