程序测试依据测试范畴可分为功能测试，性能测试；又可根据测试等级分为单体测试，结合测试等等，但是无论作为哪种测试，其基本的测试流程都如下所示。
作为一名程序测试员，在发现一个疑似BUG时，需要做到哪些步骤呢？
发现疑似BUG
↓
确认是否为BUG
↓
分析类型
↓
分析原因
↓
交予开发者修改
↓
确证修改点
看起来解决一个BUG似乎很简单，可也更加概念化。虽然在工作中会遇到各式各样的问题，但是限于自身的水平以及时间的制约，很多时候我只是在简单得确认完BUG之后，就随手交给开发人员解决。这样看起来似乎测试很简单，只需要遵循最基本的黑盒测试手法，通过不断地确认程序的功能，在发现不符合要求的地方后，只需转给其他人解决便可。但是这种测试方法毕竟过于简单，在职业上不利于我们的成长，在工作上则显得相当不负责任。软件程序地开发，本来就是开发与测试相互并重的一个过程。
开发者的水平保证了软件产品的生产，而测试者的水平则决定了这个产品的质量。虽然在工作流程上看，测试者找BUG，开发者对应BUG本来就是理所应当的事情。但是就工作量而言，开发者首先承担了很大了编码任务，在完成一个机能之后，往往不是停留下来等待测试者的确认，而是紧接着进行下一个机能的开发任务。
对应BUG对于开发者来说，只是穿梭在编码过程中的一个插曲，如果这个插曲反客为主，占据了开发者大量的时间，一方面不利于工程的进度，一方面有可能干扰正在进行中的技能的编码质量，从而导致恶性循环。
虽然编码的质量首先取决于开发者的认真程度，但是测试者的作用是毋庸置疑的。低级测试员当然只能从功能上寻找程序的不良之处，但是就功能测试之上的整合测试，性能测试，很大程度上就依靠测试者的能力。
作为一个低级测试员，在面对固有的测试流程时，想必都乐于将问题抛给开发者解决。长期以往，如此做法只会加重开发者的负担，从而拖累了整个项目。而另一方面，测试者一味地逃避困难，不断地将工作重点抛给开发者，只会不断地削弱测试者在整个团队中的作用和影响。
因此真正要完成作为测试者的职责，其工作手法就不能仅限于以上的几点步骤，而需要对其中进行补充和加强。
个人认为，找出BUG固然很重要，丹最重要的是要学会分析BUG的原因，而不是简单的确认BUG的类型。
我先举个简单的实例来具体解释在发现一个BUG时，测试者应当完成的工作。
1画面上的一个值没有正确SET到DB中
↓
2.确认确实存在错误
↓
3.分析原因：DB值未SET
↓
4.利用以往经验寻找原因：INSERT SQL不正？
↓
5.分析SQL
↓
6.INSERT SQL正确，分析其他原因：相应变量不正？
↓
7.查看相应变量出处以设置方法
↓
8.确认原因
↓
9.向开发者提出BUG并解释原因
↓
10.开发者完成BUG对应后确实画面相应值已正确SET
无论是开发和测试，都不过是为了完成项目而做出的暂时分工而已。孰重孰轻，不应该取决于所在的岗位，而在于在岗位上所能发挥的能力。
我入司一年有余，一直担任测试者一职。以上的一些小结不过只是测试过程中遇到的诸多问题的其中之一，自身技术水平低下，工作上依然有许多不足之处。在整个职业生涯中，即便测试者是起步的最初阶段，但在其位而谋其政，只有通过反省，发现问题，才能实现真正的进步。
