作者：hacker发布时间：2022-09-01分类：黑客教程浏览：153评论：2
详细回答如下：
对于测试人员来说，bug的生命周期一般分为：发现bug—提交bug—验证bug，那在这三个阶段中如何体现测试的专业度呢？、
第一阶段：发现bug
场景：
“测试不就是发现bug吗，有什么技术含量？”
思考:
当发现一个bug，除了尽快报告问题以外，我们还能做哪些事情？
回答：
测试人员发现bug，花些时间细细品味
1、这个bug复现的必要条件是什么？
2、除了发现bug的这条路径，是否还有更多的路径也会导致相同的问题？
3、bug是否存在可能影响其它数据或者其它应用的副作用？
4、其它功能模块是否也存在类似问题？
5、bug的复现路径是否在用户可达之路上？
6、复现bug的路径是否在测试用例中？有没有可借鉴性？
通过以上分析，我们可能获得以下额外收获：
1、通过bug的定位，确认必现路径、可能的原因，帮助开发快速定位、解决问题
2、通过bug的路径、影响范围等分析，发掘更多的隐藏bug
《探索式测试》-恶邻测试法：重灾区往往会有更多的bug
3、通过分析操作路径，补充测试用例，扩展测试用例范围、思路
第二阶段：提交bug
场景:
一个阳光明媚的下午，小白正在测试一个用例的时候，突然app异常退出了，再重复进行以上步骤，问题没有复现。他意识到这是个bug，于是他赶紧提交给开发。没过一会，开发大神怒气冲冲的过来说“你这bug也没必现步骤，也没日志，这怎么修改！”。小白心里一阵嘀咕“本来就是一个bug，你应该想办法解决呀，我怎么知道”
思考：如何才能提交一个有效的bug？
回答：
1、确保bug有效。
1)不要因为环境问题或者是操作错误引起“bug”
2)不要提交一些重复的bug
2、写好bug描述。
1)bug描述精确、没有歧义，详细简洁的测试步骤。
2)保证各个字段内容与实际现象一致。比如：版本、复现率等
3)对于复现率低的问题，尽可能提供一些可参考信息：截图、视频、日志、可能的步骤、可能原因等(如果你能通过各种手段定位到问题的原因，开发大神也会对你刮目相看的)
4)对于特殊的测试场景，附带相关的数据，比如1024kb的图片等
第三阶段：验证bug
场景：
当我还是一个测试新手的时候，对于bug验证，往往是按照步骤验证复现，如果没有问题就关闭了(不知道现在还有多少人跟我当初一样~)
思考：如何做好bug的回归验证？
回答：
1、确认好bug的复现前提及操作步骤。
2、确认bug产生的原因及修复方法。
游戏的BUG主要还是在大家“游戏”的过程中，对游戏的每个功能进行游玩时发现的问题，因为游戏是经过编程制作的，每个动作和功能对应着相应的程序，发现BUG去找程序即可发现编程的问题。
1、需求分析、需求评审需求分析和评审就是分析客户的需求可不可行，需要怎么进行测试。
2、编写测试计划编写测试计划通俗一点讲就是什么人在什么时间做什么事，最后产出什么东西。那也就是测试人员要测试哪些模块、在什么期限内，提交哪些文档。
注意事项：
执行测试、提交bug、回归测试Bug就是缺陷，发现bug之后，要提交给开发人员让他们去修改，然后进行回归测试，验证开发人员有没有改好。编写测试总结报告Bug都改好了之后，要编写测试总结报告，这款软件的质量如何。
对于刚入行的软件测试新手迅速找出软件中的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的测试很全面，可以进一步了解下！
写写我的经验吧。其实很简单：分析log
测试客户端或web功能时，打开抓包工具，跟踪自己的操作路径。
当涉及到server功能时，就依赖于开发了，有经验的开发会在自己的代码中打很多的log，去log文件里按时间找自己的操作即可。通过分析log，可以：
1. 方便的回溯随机bug，出现问题直接查错误日志、定位原因、告知开发，就不需要再绞尽脑汁的重现bug了，提高测试质量。
2. 查log能够准确的定位问题。特别是比较复杂的系统，一环套着一环，通过查log剥茧抽丝逐步定位问题所在。提高工作效率。
3. 查log的过程也是对系统实现细节的深入学习过程，通过了解到的技术实现，完善测试用例，避免漏测。
但在实际的测试中，可能会有很多意想不到的情况，比如开发忘记在出错点打log了，你分析半天发现没哟，浪费时间所以测试之前一定要提醒开发在关键点打好log：
1、异常处理。系统各层次都要显式处理异常，任何可能出现的错误都能在日志中找到原因和地点。
2、重要的逻辑处一定要有日志。能够通过日志看出是哪个文件的哪个方法出了问题。
后台的bug与逻辑、性能和安全性有关。当bug出现时，一般来说分大致3种情况。
1，数据库层面的。
可能少某个字段，或者字段值为空等等，这些可能在设计数据库时就埋下了错误的种子，导致程序调用数据库错误的数据产生bug，这一类问题不算普遍，但也是最容易忽视的一种情况，有时候从数据库入手定位bug说不定还能发现数据库的设计缺陷呢。
2，网络层面的。
通常这种都是网络情况较差的时候产生的，比如手机的移动网络信号不好，又或是公司网络不稳定，导致js/css未加载完全或者请求超时等等，这种问题其实非程序bug造成的，可以不用提交bug，也不用让开发毫无头绪的去查代码的问题。
当然如果可以的话也可以当优化建议提给开发，让他优化代码，比如压缩js/css，增加超时时间，超时后的重试机制。
3，代码层面的。
普遍的bug基本都是代码有问题造成的，排除掉1和2剩下后就可以确定是程序bug了。对于了解网络架构的人来说，其实程序也分前端和后端的，一般对于界面显示有问题直接可以判断是前端的问题，比如系统兼容性，浏览器兼容性。
bug是一个英文单词，本意是指昆虫、小虫、损坏、犯贫、缺陷、窃听器等意思。现在一般是指在电脑系统或程序中，隐藏着的一些未被发现的缺陷或问题，简称程序漏洞。另外bug还有一种引申意义，用来形容某事物厉害的超乎想象。
所谓"(Bug)"，是指电脑系统的硬件、系统软件(如操作系统)或应用软件(如文字处理软件)出错。硬件的出错有两个原因，一是设计错误，一是硬件部件老化失效等。
软件的Bug，狭义概念是指软件程序的漏洞或缺陷，广义概念除此之外还包括测试工程师或用户所发现和提出的软件可改进的细节、或与需求文档存在差异的功能实现等。
1.软件测试流程，一般是这样：需求了解——测试计划——测试设计——测试用例编写——测试执行——bug管理跟踪——测试报告生成 2.bug就是测试过程中发现的程序缺陷，可以指需求上的，也可以指功能、性能上的 3.bug提交有多种方式，可以通过测试管理工具来管理bug，比如QC等 4.bug的生命周期： 发现bug（open）——修复bug（fixed）——关闭bug（closed）
标签：测试中怎么定位bug
已有2位网友发表了看法：
访客 评论于 2022-09-01 14:45:21 回复
个销售的类型的软件的时候：你应该先做订货-à入库-à盘点-à销售-à查询。首先你要保证这个数据的流向是正确的无误的。假如你在测试法院审判软件的时候，你要先收案-à立案-à发送审批-à排期---审理审判-à结案判决-à归档-à查询。总之跟踪一条数据的流程，保证数据的正确
访客 评论于 2022-09-01 17:35:38 回复
功能、性能上的3.bug提交有多种方式，可以通过测试管理工具来管理bug，比如QC等4.bug的生命周期： 发现bug（open）——修复bug（fixed）——关闭bug（closed）