们发现这个缺陷之后，如何进行有效的记录？如何提交一个高质量的Bug
对于第一类可以复现的Bug，比较简单，比如我在我的界面打开一个文件夹，然后进到某一个路径，然后我某一个Excel表格打不开，那么这就是一个Bug，在这里不管我是在我的环境底下还是在开发的环境底下，都存在这个问题。你用同样的这个操作（打开某一个文件夹路径，里面的表格文件打不开）就依次可以复现的，那么对于这一类问题，我们就把它叫做可以复现的Bug。
对于第二一类的问题，比如说我打开某一个文件夹，进到某一个路径之后，有时候进来表格打不开，有时候又可以打开，对于这种出现的概率比较的低，是不稳定的，对于这一类我们就把它叫做偶现的问题。
对于这两类问题我们做为软件测试工程师应该怎么样去处理？
首先第一个点，对于偶现的bug也好还是可以复现的Bug也好，咱们都要提交，只要是一个Bug都要进行提交。只是在提交的时候呢，咱们偶现的Bug你要多提交一些东西，因为对于偶现的bug，开发那边不一定能够复现，开发不修改的几率就大了。
第一个写清楚当时的环境，第二个提供更多的帮助，让开发来复现这个问题
去录一些视频，抓一些日志，你提供的这一些东西，都是能够帮助开发提高修改这个Bug的概率的。
我一个人在测试的时候，这个问题可能就是十分之一的概率，那么如果说是一百万个人来进行同样的操作，那么它可能会出现的概率就大大提高了。
既然它会出现，它就肯定会有一个稳定的路径，只是目前我还没有发现，所以说对于偶现的Bug我们千万不能去忽视。反而要去重视。
第二一个的话呢，我们要去记录这个缺陷的时候，就要把重现这个Bug的步骤写出来，写步骤的时候既不要太啰嗦，也不要太简略。
第四一个，每一份报告中只记录一个缺陷，前面我们提到的我打开一个文档，里面的一个表格打不开，这是一个Bug，如果说我们在同一个路径还发现了另外一个Bug比如文件显示不全，同样的路径同样的操作我发现了两个Bug，那么我们就需要分两个Bug作为提交。
最后一个点就是我们在描述的时候，只要做到陈述事实就可以了，不要去做主观臆断。不要加上的主观的一些情绪，或者说你自己的一些语气助词等等之类。
比如说对于我们产品界面的一个设计，然后你觉得这个界面设计不好看，不符合用户的一个审美。那我们就比如说这个页面什么内容没有居中显示，然后不太符合用户的使用习惯或者整个页面排版不太好看。这样就秒速一个正常的现象，但是你不能写成说你这个页面设计得巨丑，太丑了，简直无法看了，这个就加入了你自己个人的情绪语气助词。
产品或者设计看到提交的内容肯定会很不舒服，所有又会引起一些矛盾。
拓展：测试要不要分析Bug？
对于功能测试工程师来说，你能够去发现这个Bug，并且去进行提交，就OK了。
但是对于对自己有要求，或者说我想要去提升自己的技术，接触到更多的知识面。想让开发尽快的来解决这个Bug的话，那么我们软件测试工程师要具有分析Bug的一个能力。
我们找到这个问题之后，要求专研精神，这个问题是怎么产生的呢？是前端问题还是后台问题，当你开始这样去思考的时候，你的成长就会非常的快。
至少让开发看到这个Bug的时候，他知道怎么样去进行复现。然后他不会第二次第三次第四次来问你，呃，你这个是怎么操作的，你这个是怎么复现的？你这个准备数据是什么？
如果说你提了一个Bug之后，一个开发不断的来跟你沟通，你的操作是什么样子的，你有什么前提条件，你要准备什么样的数据、环境。有这些问题就表示你的Bug提交得不到位。这个肯定会影响开发修改的效率，在这中间他怀疑你提交的Bug不好，你怀疑他的理解能力不够，一来一回就很容易起冲突！
所以对于我们软件测试工程师第二职责就是如何去提交一个高质量的Bug，（第一职责如何去判断一个问题是缺陷，或者说我如何来推动缺陷的修改，可以阅读我往期的文章）
怎样有效记录缺陷，在这里我给大家总结了五个点。
第一个我们要保证这个缺陷是可以重现的，我们常见的Bug我们可以把它分为两大类，一个是可以复现的Bug，第二一类是偶现的Bug，就是说低概率出现的Bug。
