从事测试工作这么多年来,觉得发现bug这项测试工作是最磨练人意志的一项工作之一，在发现bug的工作中，尤其需要调整好自己的一些测试方法和心态，来发现更多的质量问题。

为什么这么说呢？请看下面总结的有关bug几点：

1．在测试过程中发现问题可能对我们来说觉得是一件开心的事情，但是有些bug往往你跟据之前相同的步骤进去就重现不了了，而此时测试经验告诉我这个bug比较严重，如果没有及时提交出来fix，可能会影响到后面的发布，但是如果我们不能重现开发人员是不会轻信我们去修改的，也不会把时间浪费在这个上面，这就需要我们凭着经验和记忆去耐心的重现这个bug，然后抓住一些所谓的log信息或者video视频。

2．当出现bug时候的反馈的及时性，当我们在测试过程中发现一个问题出现的几率很高，这个bug又很严重时，一般做法为写好测试环境和重现步骤加上一些必要的测试数据一并提交到TT上，我认为对bug的及时性是相当高的，越早让开发知道越有利于解决问题，有些我们这边模块对应的是NJ的开发时，发现一些严重的问题时，就可以先电话通知开发，让他先知道有这个问题，这时往往开发就会配合你下来分析和定位这些问题，等他们分析定位后，我们再提交相关的bug。当然，这里只是针对一些比较严重的bug。

3.测试需要不断调整自己的测试策略和方法，不知道大家有没有这样的感觉，现在我们的测试都是有模块化负责人，比如说Phone谁负责，Phonebook谁负责。但是大家发现没有，要是一个模块给某个人负责久了就会出现思维定势，随着测试版本的不断更新，每天执行case，ad-hoc，发现自己发现的bug越来越少了，要是发现也是一些鸡毛蒜皮的小问题，当然这也要分两方面来讨论，一方面说明你负责的模块已经够稳定了，但是也有一种可能就是

你对自己模块的免疫能力变强了J,这个时候我想经验就起到一定作用了，就需要我们自己不断的改进自己的测试方法和策略，利用的不同的思维模式来保证更好的模块质量。如果没有经验，此时就可以借鉴下面的这种方法了。

4．交叉测试的重要性。交叉测试简单的做法就是测试人员互相交换应用来进行测试，不同的人可以从不同的角度来发现一些关键的问题。这样做一方面可以减少bug的遗漏率，另一方面又可以弥补模块负责人请假时的空缺。

测试流程的介绍并非是本文的重点，在这里我要提一下在熟悉需求阶段并不是只要熟悉你自己的需求就够了，特别要注意一些公共模块的需求，比如说一些系统层面上的需求，更要我们及时地关注，当时有可能这块的测试计划或测试任务没有被scope进来，而有肯能导致后面在这块会是个漏洞，所以这就需要应用负责人有这样的意识把他都scope进来