测试应该具有定位问题的能力
好久没来了~
这个问题很纠结，对于一个热爱自己工作岗位的测试人员来说，而更加体现其“优秀”的一方面。
我们要把握关键点，即，优秀，定位，负责！！
发现缺陷是测试人员的本职工作，但是定位却似乎有点牵强。
我们可以这么分析，一个初出茅庐的初级测试人员也许对于业务，对于技术只有学到一部分，所以能在符合需求的情况下，尽可能多的发现缺陷已属于完成任务指标。不过，既然是一位优秀人员，对于常用的业务领域和可能会发现缺陷的场景或业务点应该了如指掌。在日常积累的工作经验中，无论是单元测试人员，亦或是纯黑盒功能测试人员，其实对于某个缺陷发生发现的前置条件，个人认为应该大方向上能够把握住。虽说测试人员不是专业开发人员，但是一个很厉害、很优秀的测试人员，其脚步开发能力，其上下文业务能力，其逻辑判断能力不亚于开发人员，甚至可以说更好，毕竟我们还得站在用户的角度去检测项目或产品。
而最终用户倘若发现软件/项目存在问题，肯定还是从全局的软件质量角度来提出问题和质疑。所以，测试人员永远是保障软件产品/项目/系统质量的最终也是唯一责任关卡。你可以指责开发人员未实现到位，可以埋怨需求分析不够透彻，但无法解释用户验收时发现的缺陷，为什么测试人员未第一时间发现并上报修改？！
综上，若非指定责任人来说，也许测试人员不是主要责任人，但作为热爱这份工作的我们，作为一个“优秀”测试工程师来说，协助缺陷定位责无旁贷！
以上是个人愚见，不足之处还请指正。
一个优秀的测试人员是否需要对缺陷定位负责？
对于这个问题，我的看法是否定的。测试人员是不需要对缺陷定位负责，但可以协助开发人员进行缺陷定位。
在我所经历的项目中，测试人员的主要工作是发现问题、重现问题，尽可能多的暴露软件中的问题，让这些问题在测试的最开始版本中被发现，以减轻开发后期的负担。测试人员会在重现问题的时候去尝试最短路径，即最少的操作步骤重现出问题，这对于缺陷定位来说是非常有用的。
还有一种情况，测试人员熟悉软件的code，并有相关的编程经验，那这个测试人员所做的缺陷定位当然是更加有用的。所以，不能一概而论。测试人员不用负责任，但能做到肯定是有加分的。
呵呵，个人愚见，还请各位指教。
我认为答案对于黑盒测试人员来说，是否定的。
对于黑盒测试人员来说，是看不见code的，最多可以理解程序的设计逻辑，当然，这对于写case是很有用处的。黑盒测试人员首先确认这个问题是不是产品的bug，如果确定是的话，需要提供详细的测试步骤及这个bug发生时测试环境的详细信息，包括产品的build number和screenshot。
当然，如果测试人员对于产品非常熟悉，而且有很强的技术能力，可以对bug进行一定的分析，指出是哪里的code的问题，但这不是必须的。
bug的定位属于开发人员的工作，但是否能提出高质量的bug，确实是衡量测试人员工作质量的一个指标。
个人觉得，测试人员不需要对缺陷定位来负责
测试的职责是发现问题，并能重现问题。定位是开发的问题，测试不是专业的开发，并非一定就可以定位出问题；再者，如果定位错了，开发改错了，那是谁的责任呢？
个人觉得，测试人员不需要对缺陷定位来负责
测试的职责是发现问题，并能重现问题。定位是开发的问题，测试不是专业的开发，并非一定就可以定位出问题；再者，如果定位错了，开发改错了，那是谁的责任呢？
在回答这个问题之前，应该先弄清楚一个优秀的测试人员标准是什么？
我认为在定位一个优秀的测试人员时应根据公司/项目实际情况而定。如果测试团队目标是测试人员提交质量高而又定位准确的缺陷，优秀的定义是对缺陷定位准确；如果测试团队的目标是测试人员提交缺陷的速度快而且多，这时候我想缺陷定位的重要性不如前者了。
如果某个同事在求数量的团队中，一心求质量结果导致测试速度非常慢进而影响整个项目进度，我想这人的能力很难在所在团队得到肯定。但是如果换去了一个重视对缺陷定位，也许他就是一位优秀的测试人员了，而只追求数量不分析缺陷的同事便不再有优势了。我的观点是：优秀的测试人员应该是能够适应公司文化。
当然，我认为作为测试执行人员的目标以及优秀的定义应该是既能发现足够多的BUG，又能对BUG做一个相对准确的定位，即做事情又快又好。也许快与好存在一定的矛盾，只要我们明确了当前的重点（偏重质量还是偏重数量）就能快速达到优秀。
需要
需要清楚的描述问题出现的步骤，出现之后的日志打印，如果有编程能力，也可以深入到代码级，进行更好的定位问题
顶一下吧~ 很少见的好帖了
一个优秀的测试人员是否需要对缺陷定位负责?
测试主要工作是尽可能多的发现产品中的bug，复现bug，若开发需要，可以帮助开发定位bug，使其及早修复bug。
个人觉得这不是负不负责的问题，而是做为一个优秀的测试工程师，需要去加强这方面的能力
能发现问题有时比较容易，但能找到问题产生的原因并不容易
受教了。。
本帖最后由 ttkk 于 2012-6-4 13:45 编辑
其实，楼主提的这个讨论话题也是我目前工作所要面对的问题。其实有时BUG重现就是为了寻找bug产生的原因，什么操作或环境才会产生这样的bug，这也算是缺陷定位的一部分；至于为什么这样操作或为什么在这样环境下会产生这样的bug，需要测试人员更多的知识和经验才能定位到的。我想如果是优秀的应该多少具备这方面的能力，但是，不应该是负责。具体是什么原因应该开发人员针对分析，或许只是函数名字写错了等问题引起的，非白盒测试人员是无法定位到的。
PS：优秀测试人员是否在招聘时必须具备白盒测试、黑盒测试、灰盒测试、性能测试等一列测试的能力，且必须对问题定位负责，如果是这样的话，那么是应该负责。如若不然可具备能力协助开发，不需要负责的，只需对BUG负责（不可误提，或非业务需求的）。
回复 2# TesterChen
你的最后意见是我们测试人员都想做到的。但是实际上，很多测试人员提出的隐蔽隐患，只要不影响系统正常使用的，一般都不会被认可的。除非在用户现场用户反馈了，才会被重视起来。
不过，测试人员有这个意识，也可以保护自己，免得现场提出，倒是反过来问测试为什么没有测试到。呵呵
回复 35# ttkk
"很多测试人员提出的隐蔽隐患，只要不影响系统正常使用的，一般都不会被认可的。"
这种情况在项目中出现是很正常的。。。
“测试人员有这个意识，也可以保护自己，免得现场提出，倒是反过来问测试为什么没有测试到”
应该要测试到的点，还是要测试到的
继续支持没话说~ 楼主真强
没有开发基础的测试人员，由黑盒测试转白盒测试难吗？
看了这么多的高论，我也提点自己的见解。
我遇到过如下问题，一是性能测试时发现客户端访问某个页面非常慢，响应时间超过了30S,我把这个结果告诉了项目经理和开发，但是他们也要寻找原因。于是我通过LoadRunner中对页面元素的分析，发现了几个上百K的js加载占用了大部分时间，而且并发用户数少的情况他们也占用了大部分时间。
二是最近遇到的一个批量查询的问题，我批量查询200个用户，花了14分钟完成了操作；我查询500个用户，结果查询到91%的时候，突然死掉了，时间超过了30分钟。开发人员一开始并不同意修改bug，否认用户一次会查这么多人。这时我根据以往的经验初步定位肯定是session超时。同时和开发一起分析后台报错，提出要修改这个问题。并且我认为这个问题是设计上的bug。同时通过说服开发经理才决定要改bug。
所以经过以上两个具体问题，我认为测试工作的时间越长，接触项目的相关技术和业务会越深，所以定位问题一方面能够提高你的技术水平，另一方面也让你有了同开发站在同一个高度的筹码，能成为你说服他们的利器。
定位问题对成长中的每个阶段的测试人员不是绝对的要求，但是这种能力我们可以拥有。
一楼的位置好啊..
不错的~~! 感谢您提供
