说来是小而简单的问题，但是当与每天的工作都息息相关，又成了大事，这是一个贯穿测试人员工作过程中必须面对的问题，在工作的不同阶段总有不同的感悟，从刚入门的测试菜鸟到上升到一定层次的技术或管理人员，都需认真去分析和跟踪bug从产生到最终解决的过程。今天心血来潮，说点个人看法。
说这个问题的前提是你已经拥有一个好的bug管理系统，有一个好的bug样板，这样方便大家以正确统一的方式录入问题，开发，产品，测试有这样一个共同的平台，更易于分析解决跟踪问题，也易于对相关问题的统计分析。
总的来说，从bug发现到被录入主要经历三个步骤：
1、发现并重现bug
找到bug100%重现的方法，如果非100%重现，需要分析出重现的几率，若重现比较随机无法分析出几率，那么可以跟开发或测试同事交流，看能否帮忙找到重现的办法
2、定位bug产生原因
对于刚入门的测试人员习惯于发现bug的同时，立马将bug入库，但是最好的方法还是先根据自己的理解分析与开发交流，尝试定位bug产生的原因，将bug的重现步骤简化到最少，bug描述也能一针见血的指明要害。这一切首先建立在对产品功能了解的深度和调试工具的使用程度上。其实这也是对测试人员最难的一点，不能说定位越深入代表测试人员功力越深，但是在一定程度上确实反映了这一点。有效的定位bug，不但能使你更深入的理解产品功能，同时也减少了bug重复的几率，因为往往发现很多bug现象不同其实根源一致。更重要的一点是减少了回归bug的时间，也从一个侧面节省了同一小组的所有人的时间。
3、录入bug
一般来说，开发人员只会根据你的描述来修改bug，所以录入bug时，bug的描述归纳，是否简洁明了，重现步骤清晰很重要。一般来说录入bug分四块：
1）关键字：
首先要标明该bug所属的功能模块以及是否有特殊说明，如属于系统兼容，产品兼容等问题。我们统称其为关键字。这样的关键字可以方便以后在bug管理系统中查询bug，如搜索某一个功能模块在某段时间的所有bug。
2）Bug的详细描述：
主要指全面详细的描述问题现象，以及你的定位分析。关注bug的人更希望从这个描述里能清楚的知道这是个什么样的bug，错在哪里，正确的应该是怎么样，甚至不用看重现步骤就能理解到bug产生的原因。
3）重现步骤：
虽然很多bug开发人员通过详细描述就能定位到问题本质，使bug得以修改，但是写重现步骤也是非常有必要的，因为你需要使任何人即使不理解该功能的人都能通过你的描述重现这个bug，同时也便于你一段时间以后再看这个bug时，清楚的知道这个bug的重现过程。
有些bug重现很容易，有些bug却很难，所以如果能重现一个bug，在重现步骤里面需准确的解释必须的条件，列出所有的步骤。对于发现不能重现的bug，那么需要尽可能多的提供有效信息给开发人员，同时保留环境以给其分析，最好是立刻拉过来调试分析。或者是备份好环境，特别是那种你不能确认一定重现的bug。对于不能重现的bug是否需要报的问题其实一直很纠结，对于开发人员确认是问题并找到原因的bug是一定要报的，那么对于无法定位到原因的bug呢，如你描述：安装XX环境下，不知名原因死机一次，这样的bug提交给开发，人家也只能傻瞪眼，因为没有任何有用的信息。这样的bug还是不报，记下来继续关注为妙。
所以这里需涉及到一个bug证据问题，界面问题不好描述，就要截图，难重现的问题更要截图保留环境，崩溃蓝屏死机等问题要想尽办法得到dump。
4）其他bug产生的相关信息
经过前面几个步骤，说明你已经确认是bug存在，那最后还需提供相关信息以使大家明确bug产生的时间，环境等。主要包括，产生bug模块所属的项目，版本信息，bug类型，bug发现环境，这些信息属于每个bug'都必须具备的信息，可以以多选框的信息选择填入，也方便查询和管理。