对于刚入行的软件测试新手迅速找出软件中的Bug思路如下:
1、
尽快熟悉公司的产品业务比如你们公司做ERP软件的,你肯定要迅速熟悉EPR的业务流程;比如你们公司是做法院软件的,那么你一定要熟悉法院审判案件的流程,只有熟悉了产品的业务流程、你才能迅速找出软件中存在的一些重要的缺陷,你发现的软件缺陷才是有价值的。否则即使你能找到一些软件缺陷,那也是纯软件的缺陷,价值不大。
2、
把自己当成是用户把自己当成是用户去使用该系统,比如在使用该系统过程中是这样操作的吗?
(1)比如在大量要求用户输入的软件界面中,有一些用户喜欢使用Tab键采用全键盘的输入;此时的正确的接口应该采取从左到右,从上到下的顺序。
(2)比如有的用户喜欢使用快捷键操作等(Ctr+C,Ctr+V,Ctr+F),但是实际情况下一些开发出来的软件的快捷键却根本不起作用。
(3)比如软件在需要用户输入的信息的时候(特别是在填写个人资料的时候),必填项后面一律要用*等醒目的标示,要让用户知道这个地方时必须填写的。
(4)下拉框不选值的时候,应该有个默认值;并且要多检查程序中的多处下拉框,因为很多情况下下拉框取不到值。
3、
善于怀疑,不要迷信高手世界上没有绝对正确的,总有错误的地方,具有叛逆心理,别人认为不可能发生的事,我却认为可能发生。别人认为是对的,我却认为不是对的。如果你认为某个或者某些程序员水平很高,他写的这个地方应该没问题吧,那么我要说你错了,这样很容易遗漏软件中的Bug。因为程序开发人员毕竟是普通的人,只要是人就会犯错误的。
4、
不要让程序开发人员的观点:“用户不会进行这样的操作”而说服自己遇到这样的情况,你要坚持你自己正确的想法,以后对方会明白你的。比如在一个录入员工基本信息的系统中,系统中对员工的年龄作为负值、而没有作为判断、也可以保存到数据库中,此时你不要被程序员的用户不会进行这样操作的观点说服自己,你要坚持你正确的观点,把这种现象作为一个Bug吧,勇敢点!你的选择不会不错!
5、
在软件测试过程中要跟踪一条数据完整的流程在软件测试的时候要跟踪一条数据完整的流程,保证数据的正确性这个真的是太重要了:假如你在测试一个销售的类型的软件的时候:你应该先做订货-à入库-à盘点-à销售-à查询。首先你要保证这个数据的流向是正确的无误的。假如你在测试法院审判软件的时候,你要先收案-à立案-à发送审批-à排期---审理审判-à结案判决-à归档-à查询。总之跟踪一条数据的流程,保证数据的正确性。如果经过你测试的软件在用户使用过程中业务流程上都走不通的话,那么这样的软件你说经过你的测试,但是在比人看来与没有测试有什么区别呢?
6、
回归测试要注意的细项程序员提交新的程序版本后,作为测试人员应该立即与程序员沟通这个修改的功能、并且这个新修改的功能影响哪些功能。举个简单的例子来说明一下:比如在一款软件中,程序开发人员修改了某个“会员”的某个字段信息。作为测试人员首先你要测试“会员”的功能这个是你首先需要做的。另外你还要和程序员沟通询问他们新修改的这个会员的字段,会影响会员的销售功能吗?会对会员以前的销售记录的查询有影响吗?如果对这些功能有影响,那么这些功能都是你在回归测试的时候重点测试的地方,也是最容易产生Bug的地方了。
7、
与使用者互动的缺陷
(1)如填写资料错误应的时候,应该能够提示错误的位置,让用户知道是这个地方输入数据不对。
(2)删除数据之前给一定要给出是否删除确认提示。
(3)不要在软件中使用中英文混合的提示比如:比如对于用户某个操作的错误提示,不要一会用“error”、一会用“错误”;一会用“succeed”另一会用“成功”,总之要统一。
当然要想简单省事并全面定位分析BUG,也可以直接交给成熟的第三方测试,TestBird的测试很全面,可以进一步了解下!
软件测试新手如何快速找出软件中的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,分析bug,这些区别是什么呢
找bug就是把软件的错误给找出来,哪里有问题;定位bug就是用一种合理合适的方式把这个bug描述出来,以便修复的时候好再次重现;分析bug就是去找这个bug出现的原因,是什么导致
软件测试的流程是什么?bug具体是什么?怎么提交?
简单跟你讲下吧,
1.软件测试流程,一般是这样:需求了解——测试计划——测试设计——测试用例编写——测试执行——bug管理跟踪——测试报告生成
2.bug就是测试过程中发现的程序缺陷,可以指需求上的,也可以指功能、性能上的
3.bug提交有多种方式,可以通过测试管理工具来管理bug,比如QC等
4.bug的生命周期: 发现bug(open)——修复bug(fixed)——关闭bug(closed)
在软件测试中,如何以最快的速度找到一个项目中的BUG;
如果你的重点是在快的话,
那就是加强对系统项目的了解,对开发实现人员情况的了解,
了解这些,可以让你清楚项目的重点难点在哪里,bug往往就是在这些重点难点模块功能上。
加强测试经验的积累,经验丰富,就能更了解哪些地方会容易出现bug。
但是在软件测试中,快不快并不是一个很重要的指标,关键对软件项目测试覆盖程度,bug的发现率和遗漏率。要提高软件质量,被遗漏的bug要少。
软件测试发现bug怎么处理
一是项目经理通过和客户的交流,完成需求文档,由开发人员和测试人 员共同完成需求文档的评审,评审的内容包括:需求描述不清楚的地 方和可能有明显冲突或者无法实现的功能的地方。项目经理通过综合 开发人员,测试人员以及客户的意见,完成项目计划。然后sqa进入项目,开始进行统计和跟踪。
二是开发人员根据需求文档完成需求分析文档,测试人员进行评审,评审的主要内容包括是否有遗漏或 者双方理解不同的地方。测试人员完 成测试计划文档,测试计划包括的内容上面有描述。
三是测试人员根据修改好的需求分析文档开始写测试用例,同时开发人 员完成概要设计文档,详细设计文档。此两份文档成为测试人员撰写 测试用例的补充材料。
四是测试用例完成后,测试和开发需要进行评审。
五是测试人员搭建环境
六是开发人员提交第一个版本,可能存在未完成功能,需要说明。测试 人员进行测试,发现 bug 后提 交给 bugzilla。
七是开发提交第二个版本,包括 bug fix 以及增加了部分功能,测试人员进行测试。
八重复上面的工作,一般是 3-4 个版本后 bug 数量减少,达到出货 的要求。
九是如果有客户反馈的问题,需要测试人员协助重现以及回归测试。
在传统的 bugzilla 中,bug 描述应该包括以下的信息:① 和 bug 产生对应的软件版本;② 开发的接口人员;③ bug 的优先级;④ bug 的严重程度;⑤ bug 可能属于的模块,如果不能确认,可以用开发人员来判断;⑥ bug 标题,需要清晰的描述现象;⑦ bug 描述,需要尽量给出重新 bug 的步骤;⑧ bug 附件中能给出相关的日志和截图。
高质量的 bug 记录就是指很容易理解的 bug 记录, 所以,对于描述的要求高,能提供的信息多且准确,很好的帮助开发人员定位。
如何保证软件测试过程中,发现的BUG深度的问题?
先给深度做个定义吧,或者说认为什么样的问题才算是有深度的呢??比如发现架构问题算有深度,那么你要了解结构;发现代码隐形问题算是深度,你要了解代码;发现内存泄露算是深度问题,要了解什么是内存泄露,什么引起内存泄露……
转载请注明出处51数据库 » 软件测试怎么定位bug 软件测试如何定位bug