51Testing软件测试论坛

标题: 一个优秀的测试人员是否需要对缺陷定位负责？(02-06-06）（获奖名单已公布） [打印本页]

作者: lsekfe 时间: 2012-5-21 09:55
标题: 一个优秀的测试人员是否需要对缺陷定位负责？(02-06-06）（获奖名单已公布）

本周的问题为“一个优秀的测试人员是否需要对缺陷定位负责？”
如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

[attach]79123[/attach]

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	TesterChen	50移动充值卡	2#
二等奖	san	300论坛积分	18#
三等奖	ffan1027	100论坛积分	14#

作者: TesterChen 时间: 2012-5-21 11:14
本帖最后由 TesterChen 于 2012-5-30 13:27 编辑

一个优秀的测试人员是否需要对缺陷定位负责？

问题的答案我觉得应该是肯定的。

首先，从字面意思来说，我觉得测试人员应该对缺陷的定位负责，尽量在报告缺陷时将自己对于缺陷的理解（或缺陷产生的原因）写入到缺陷的备注信息（或缺陷主体）中。在个人能力、资源许可的情况下，尽我们所能的去提升我们的工作质量，做到100%的自我负责，因为我们的目标不是做完成就可以，而是追求优秀！！！
其次，软件测试人员的责任角度来说，在测试人员具备这样的个人能力，且通过他们掌握的资源可完成对定位缺陷，那么最好是提供对缺陷的定位给开发人员或产品人员。这样即方便开发人员去定位问题、解决问题，也便于后期缺陷的追溯与回归。同样，部分缺陷可作为产品人员对产品进行优化的参考。

但是，如果对缺陷的定位很困难，通过测试人员所掌握的资源与知识在短时间（如一个小时、半天）内无法完成对缺陷的定位，我们最好是向开发人员反映，并表示期望得到他们的帮助，共同对发现的缺陷进行定位，定位后要记录在缺陷的描述中；
如果在交流过程中测试人员和开发人员一致认为此问题很复杂，需要开发人员内部进行排查的问题，那么此时测试人员可以终止缺陷定位，交由开发组人员进行处理，测试人员只需要对后期缺陷产生的原因进行了解、对缺陷进行回归测试即可，测试人员可考虑参加他们的讨论。
将问题的定位转至开发人员层面之后，如果涉及到更加深层次的问题，开发经理（项目经理）会向他们的上级或同行请求协助，测试人员可考虑参加他们的讨论。

另外，我们要考虑的一个问题就是具体问题具体分析、能随机应变。如果测试组的成员有很重的测试任务，在规定的时间内对所有内容完成测试任务的可能性都不大，那么我想测试人员也没太多时间去找寻缺陷出现的具体原因。但在这里仍然要强调的是缺陷的重现步骤、涉及到的数据等信息一定要记录全面，这样方便开发人员在调试时更快更准确的重现问题、找到问题、解决问题。

同时，我觉得适量的对具体问题进行深入探讨，即有利于我们了解被测系统的业务，也有利于提升测试人员的工作技能。同时也加强了开发人员与测试人员之前的相互沟通和协作。

最后，我认为优秀测试人员不仅要善于找出现在系统已有的缺陷、对发现的缺陷进行问题定位、提出对缺陷的修改意见或建议。更要能预知未来系统可能会出现的缺陷，并提出自己的看法、同时设法对它进行验证。

作者: haoshimeng 时间: 2012-5-21 15:15
既然说是优秀了最好什么都懂什么都能负责

作者: 咚咚宝031102 时间: 2012-5-21 17:22
这个问题有点矛盾：
首先优秀的测试人员是应该对问题进行定位，这是高级和优秀测试人员的体现价值，But 缺陷定位问题是属于开发的工作，要说负责，开发的责任。
当然测试也会在前期提交bug的时候进行bug的定位，但是这是不能说明是定位准确的，因为此问题会提交到开发这边，开发人更清楚问题的所在，也会modified bug，如果你根据测试定位的去更改，更改错了，那我只能对这个开发无语了
还有一个问题就是一般bug会记录定位此bug是由谁定位的，当然也会写定位的原因的，所以呢，根据这个来判断谁负责更有决策性。

但是我还是想说明的是，软件是开发开发的，把错误位置定位扔给测试是不合理和准确的，毕竟不我测试写的，测试的目的和找原因，到了一定阶段的测试会有定位和解决bug的能力，但并不一定代替开发

作者: wacos3gnss 时间: 2012-5-21 19:24
真正要找到root cause

作者: wacos3gnss 时间: 2012-5-21 19:26
真正要找到root cause, 需要看code
感觉让测试工程师去做code 工作,事半功倍.不划算/

作者: ttsly18 时间: 2012-5-22 12:22
发现BUG、重现BUG是测试过程，定位BUG、修复BUG是开发过程。有时候重现BUG的过程跟定位BUG过程很难分辨，那最好是让测试跟开发一起配合来解决

作者: ttsly18 时间: 2012-5-22 12:26
如果定位问题是测试人员的职责，那测试的职责可能还包括给开发人员端茶送水——《完美软件》。这就是职责划分不清了

作者: aspstar 时间: 2012-5-23 11:09
测试人员不应对定位缺陷负责（不管里多优秀），不过可以在定位过程中提供帮助。

作者: mandy.wang 时间: 2012-5-23 17:43
同2#所说
个人认为，测试人员是不需要对缺陷定位负责的，但在自身能力允许的情况下，可以尽可能去定位，这样不但对测试人员自身能力的提升有较大的帮助，同时可以提升缺陷修复与回归的效率。同时，还要看公司资源是否允许，对于比较难定位的缺陷，去定位是很花时间的，但是项目周期都很紧急，测试时间也非常有限，如果为了定位一个很难的缺陷而影响了测试的进展是得不尝试的。

作者: wawx996 时间: 2012-5-23 21:57
好好看看，非常好的帖子

作者: mxxsmile 时间: 2012-5-24 09:48
目前公司实际情况是，测试负责发现并竟可能重现bug，并且协助开发搜集资料去定位bug，如果能力强，也可以将bug定位，交给开发，但是还是得由他们确定，验证。
说到负责，我们可以有我们的立场和建议，但是否被接受？如果是重大问题，会通过会议讨论~~

作者: 生活总会更美的 时间: 2012-5-24 16:42
一个优秀的测试人员是否需要对缺陷定位负责？
这个问题涉及一个团队中各个角色的职责问题，既然定义是测试人员，个人觉得不需要对缺陷定位负责。优秀的测试人员，应该是能够尽可能的发现软件的缺陷，并且能够清晰的描述缺陷重现的场景（包括缺陷出现的前置条件，现象，带了的后续问题等），虽然这类描述尤其是前置条件等，可以帮助开发人员尽可能的定位缺陷，但是缺陷定位不是测试人员的职责。个人愚见，欢迎大家讨论。

作者: ffan1027 时间: 2012-5-24 18:05
本帖最后由 ffan1027 于 2012-5-24 18:06 编辑

以下是我的见解：）

作为一名优秀的测试人员，能够对发现的缺陷进行准确定位，对与产品线或项目组来讲是非常有利的事情，可以给出研发人员修改建议，提高研发人员的工作效率。但是针对此题目“一个优秀的测试人员是否需要对缺陷定位负责？”我认为答案是否定的。测试人员有责任对缺陷问题进行定位，负一部分责任，但是缺陷定位的第一责任人应该是研发人员。

测试人员的职责包含：制定测试计划、撰写测试用例、执行测试用例、总结测试报告、缺陷管理。开发人员的职责包含：制定研发计划、根据需求实现功能开发，使之满足需求定义，并正确的运行。缺陷定位可以划分在缺陷管理中，当我们发现一个bug时，会详细记录bug的复现步骤。如果能找到缺陷的根本原因那是最好的情况，但是有很多情况下，如产品成本控制，不要求测试人员对代码级的分析和测试，无法通过调试代码来定位缺陷问题，那么定位缺陷的就由功能开发者完成，毕竟是自己写的代码，最熟悉的还是自己。测试人员可以针对缺陷给出问题定位建议，对于问题定位是否正确，是否接纳测试人员的修改建议，研发人员有自己的见解，应对自己研发功能的缺陷定位负责，并根据缺陷定位修复bug。

虽然上面我讲由研发人员对缺陷定位负责，但是对于测试人员的自身素质来讲，缺陷定位是非常重要的一项要素。工作时只发现问题表相，描述缺陷仅包含步骤，没有对缺陷的分析，“做了什么操作，系统报了错误，无法进行……”，我们所做的工作缺乏了一些挑战和难度。如果能在发现缺陷后，对缺陷进行定位，如“缺少配置文件x.config”、“执行sql不正确，where条件关联关系错误，xx.id 应与cc.id关联，不是与a.id关联”、“sql语句错误，开头是应该为 like ‘xx%’，现在写为了like ‘%xx’ ，同理’结尾是’sql也错误”。这些是几个简单的例子，开发人员看到bug后，清楚明了，可以直接修改代码，提高了我们测试工作的趣味，同时也提高项目组的工作效率。

作者: lisilin 时间: 2012-5-24 19:47
这个问题我觉得回答是肯定的，一个优秀的测试工程师需要具备这样的能力，一个优秀的测试工程师的不是发现bug最多的那个，而是使更多bug修复的那个。
我们考虑这样一个场景，在测试过程中你发现了系统的数据表会死锁，当重启系统会变好，但是你并不能确定是哪个操作造成了这个问题，你如何描述的bug呢？这个问题在开发的环境中是很难重现的，他们总是开发编译然后会频繁重启很难发现是哪里出了问题，这时测试是否能定位问题就是至关重要的了。
我想作为一个团队，我们把任务划分的如此分明并不好，开发和测试有个共同的目标就是是我们的软件更加的完善，所以不管是开发和测试都对bug的修复有着责任，所以我觉得尽我们所能的定位问题也是工作的一部分，也是我们必不可少的责任。

作者: zhusaisai 时间: 2012-5-24 21:05
本帖最后由 zhusaisai 于 2012-5-24 21:13 编辑

一个优秀的测试人员是否需要对bug定位负责？

我的观点是测试人员不需要做bug的定位工作，所以更谈不上负责。

我们先确定一下，什么是测试？测试的定义我记得是这么说的，通过运行程序发现错误的过程。那测试这个行业的主要工作应该是发现问题，客观的描述问题。也就是说测试人员的主要职责是发现问题。所以优秀的测试人员应该是最少的时间内发现更多的问题。
项目团队有开发有测试，我们的分工本来就是不同。测试人员负责发现问题，客观的描述问题；开发人员负责确认问题、解决问题。这样分工的好处是专业的人干专业的事情，效率会高很多。测试人员在完成本职工作的同时能够定位到问题，帮助开发人员尽快的完成工作，我觉得是个积极的团队成员。但是，前提是本职工作尽职尽责完成，前提是对定位的问题准确。如果这些前提都不存在的话，很可能起到相反的作用，自己的本职工作没有做好，拖后了测试进度，误导了开发人员或者局限了开发人员的思路，很可能影响团队进度。
最后，我个人觉得，可以学一些架构、数据结构和表结构相关知识。目的是更了解项目的内部运行过程，更快速的发现深层次的问题。[/fly]

作者: 123cyli 时间: 2012-5-25 13:37
兴趣所致，心生负责，心有多大，舞台就有多宽！

作者: san 时间: 2012-5-26 00:18
狭义的说，不需要！广义的说，depends。
这个其实以前考虑和讨论过的。

说不需要是从合作分工的效率上来说。专职的测试出现是软件工程化之后，出于提高生产力和提高合作管理效率，必然的结果就是行业分工。这和其他行业工程化的体系框架相似。测试，开发，项目管理，需求，架构师，分别代表和承担着软件开发过程中的不同方面。专职的分工能提高工种的专业性和过程平衡（不至于忽视了某一方面），在绝大多数情况下这是提高效率的有效手段。我们可以定义测试人员的职责是：证明没问题，或者发现问题，或者预防问题。无论从这些传统的任何一个定义，其实都没有必要去定位问题，只是需要确定和重现问题。当然，定位问题的能力，在某些时候能有助于我们发现和分析，但这不是必须的。如果只是为了解决修复，让熟悉代码的SE来，效率会更高。

说depends是因为，分工合作是基于某种工程模式的。也就是我们常说的开发模型。任何工程模型的两个核心都是过程与分工。不同种软件模型都是在解决相同的软件问题：需求的抽象/变更，设计的预见/适度/变更，过程的估计/变更，而波动和变更的体现就是风险。在不同的工程模型中，我们可以设定专门的角色掌控风险，也可以把风险掌控的职能放到其他不同角色中。所以一个角色的职责，需要做什么或者不需要做什么，取决于工程模型的设定。我们的模型一直在发展演变。一些团队在刻意模糊淡化研发测试的界限，一些团队拓展了测试的职责。测试可以不仅仅对产品质量负责，也可以对需求质量负责，可以对过程质量负责，可以对代码质量负责。对代码质量负责的测试团队，或者运用底层测试技术的团队，往往需要进入代码层，或者说他们本身测试的颗粒度就很小，这样不但能更容易捕捉到代码的变化，容易维护，其实也一定层度定位了问题。另外一个特例是性能测试。性能测试最困难的地方其实是场景和分析。这里，分析和定位问题，然后重新设计更有针对性的场景就是QA的职责了。

总的来说，测试是可以定位问题的。但定位和解决问题在分工上真不是测试本来的出发点。如果还有测试这个职业，他依然应该围绕质量这个中心。只是随着分工形式和技术发展的演化，我们运用的方法也能一定程度上能定位问题。最后，从职业发展来看，测试人员的职责定位也会随着工程模型的演变不断发展，提高技能与时俱进还是有益的。

作者: weiweixiaocao 时间: 2012-5-26 15:08
谢谢哦，辛苦辛苦！

作者: tankman119 时间: 2012-5-28 10:55
没有应不应该，想做好测试，让自己乐在其中。就可以去定位问题。跟开发交流。其实是中经验的积累。
我建议测试都这么干。长期的积累你终将受益菲浅

作者: wanhao00 时间: 2012-5-28 12:11
测试应该具有定位问题的能力

作者: 土土的豆豆 时间: 2012-5-28 14:27
好久没来了~
这个问题很纠结，对于一个热爱自己工作岗位的测试人员来说，而更加体现其“优秀”的一方面。
我们要把握关键点，即，优秀，定位，负责！！
发现缺陷是测试人员的本职工作，但是定位却似乎有点牵强。
我们可以这么分析，一个初出茅庐的初级测试人员也许对于业务，对于技术只有学到一部分，所以能在符合需求的情况下，尽可能多的发现缺陷已属于完成任务指标。不过，既然是一位优秀人员，对于常用的业务领域和可能会发现缺陷的场景或业务点应该了如指掌。在日常积累的工作经验中，无论是单元测试人员，亦或是纯黑盒功能测试人员，其实对于某个缺陷发生发现的前置条件，个人认为应该大方向上能够把握住。虽说测试人员不是专业开发人员，但是一个很厉害、很优秀的测试人员，其脚步开发能力，其上下文业务能力，其逻辑判断能力不亚于开发人员，甚至可以说更好，毕竟我们还得站在用户的角度去检测项目或产品。
而最终用户倘若发现软件/项目存在问题，肯定还是从全局的软件质量角度来提出问题和质疑。所以，测试人员永远是保障软件产品/项目/系统质量的最终也是唯一责任关卡。你可以指责开发人员未实现到位，可以埋怨需求分析不够透彻，但无法解释用户验收时发现的缺陷，为什么测试人员未第一时间发现并上报修改？！
综上，若非指定责任人来说，也许测试人员不是主要责任人，但作为热爱这份工作的我们，作为一个“优秀”测试工程师来说，协助缺陷定位责无旁贷！
以上是个人愚见，不足之处还请指正。

作者: teresa_su 时间: 2012-5-28 15:07
一个优秀的测试人员是否需要对缺陷定位负责？

对于这个问题，我的看法是否定的。测试人员是不需要对缺陷定位负责，但可以协助开发人员进行缺陷定位。

在我所经历的项目中，测试人员的主要工作是发现问题、重现问题，尽可能多的暴露软件中的问题，让这些问题在测试的最开始版本中被发现，以减轻开发后期的负担。测试人员会在重现问题的时候去尝试最短路径，即最少的操作步骤重现出问题，这对于缺陷定位来说是非常有用的。
还有一种情况，测试人员熟悉软件的code，并有相关的编程经验，那这个测试人员所做的缺陷定位当然是更加有用的。所以，不能一概而论。测试人员不用负责任，但能做到肯定是有加分的。

呵呵，个人愚见，还请各位指教。

作者: yazi0127 时间: 2012-5-28 16:33
我认为答案对于黑盒测试人员来说，是否定的。
对于黑盒测试人员来说，是看不见code的，最多可以理解程序的设计逻辑，当然，这对于写case是很有用处的。黑盒测试人员首先确认这个问题是不是产品的bug，如果确定是的话，需要提供详细的测试步骤及这个bug发生时测试环境的详细信息，包括产品的build number和screenshot。
当然，如果测试人员对于产品非常熟悉，而且有很强的技术能力，可以对bug进行一定的分析，指出是哪里的code的问题，但这不是必须的。
bug的定位属于开发人员的工作，但是否能提出高质量的bug，确实是衡量测试人员工作质量的一个指标。

作者: 微笑流淌 时间: 2012-5-29 14:53
个人觉得，测试人员不需要对缺陷定位来负责
测试的职责是发现问题，并能重现问题。定位是开发的问题，测试不是专业的开发，并非一定就可以定位出问题；再者，如果定位错了，开发改错了，那是谁的责任呢？

作者: 微笑流淌 时间: 2012-5-29 14:54
个人觉得，测试人员不需要对缺陷定位来负责
测试的职责是发现问题，并能重现问题。定位是开发的问题，测试不是专业的开发，并非一定就可以定位出问题；再者，如果定位错了，开发改错了，那是谁的责任呢？

作者: 千里 时间: 2012-5-30 12:40
在回答这个问题之前，应该先弄清楚一个优秀的测试人员标准是什么？
我认为在定位一个优秀的测试人员时应根据公司/项目实际情况而定。如果测试团队目标是测试人员提交质量高而又定位准确的缺陷，优秀的定义是对缺陷定位准确；如果测试团队的目标是测试人员提交缺陷的速度快而且多，这时候我想缺陷定位的重要性不如前者了。
如果某个同事在求数量的团队中，一心求质量结果导致测试速度非常慢进而影响整个项目进度，我想这人的能力很难在所在团队得到肯定。但是如果换去了一个重视对缺陷定位，也许他就是一位优秀的测试人员了，而只追求数量不分析缺陷的同事便不再有优势了。我的观点是：优秀的测试人员应该是能够适应公司文化。
当然，我认为作为测试执行人员的目标以及优秀的定义应该是既能发现足够多的BUG，又能对BUG做一个相对准确的定位，即做事情又快又好。也许快与好存在一定的矛盾，只要我们明确了当前的重点（偏重质量还是偏重数量）就能快速达到优秀。

作者: ldf326 时间: 2012-5-30 18:45
需要
需要清楚的描述问题出现的步骤，出现之后的日志打印，如果有编程能力，也可以深入到代码级，进行更好的定位问题

作者: niavag1e 时间: 2012-5-31 02:23
顶一下吧~ 很少见的好帖了

作者: lanse_rain 时间: 2012-5-31 20:58
一个优秀的测试人员是否需要对缺陷定位负责?

测试主要工作是尽可能多的发现产品中的bug，复现bug，若开发需要，可以帮助开发定位bug，使其及早修复bug。

作者: msnshow 时间: 2012-6-3 13:14
个人觉得这不是负不负责的问题，而是做为一个优秀的测试工程师，需要去加强这方面的能力

能发现问题有时比较容易，但能找到问题产生的原因并不容易

作者: heporen 时间: 2012-6-4 08:58
受教了。。

作者: ttkk 时间: 2012-6-4 13:44
本帖最后由 ttkk 于 2012-6-4 13:45 编辑

其实，楼主提的这个讨论话题也是我目前工作所要面对的问题。其实有时BUG重现就是为了寻找bug产生的原因，什么操作或环境才会产生这样的bug，这也算是缺陷定位的一部分；至于为什么这样操作或为什么在这样环境下会产生这样的bug，需要测试人员更多的知识和经验才能定位到的。我想如果是优秀的应该多少具备这方面的能力，但是，不应该是负责。具体是什么原因应该开发人员针对分析，或许只是函数名字写错了等问题引起的，非白盒测试人员是无法定位到的。

PS：优秀测试人员是否在招聘时必须具备白盒测试、黑盒测试、灰盒测试、性能测试等一列测试的能力，且必须对问题定位负责，如果是这样的话，那么是应该负责。如若不然可具备能力协助开发，不需要负责的，只需对BUG负责（不可误提，或非业务需求的）。

作者: ttkk 时间: 2012-6-4 13:52
回复 2# TesterChen

你的最后意见是我们测试人员都想做到的。但是实际上，很多测试人员提出的隐蔽隐患，只要不影响系统正常使用的，一般都不会被认可的。除非在用户现场用户反馈了，才会被重视起来。
不过，测试人员有这个意识，也可以保护自己，免得现场提出，倒是反过来问测试为什么没有测试到。呵呵

作者: TesterChen 时间: 2012-6-4 15:01
回复 35# ttkk

"很多测试人员提出的隐蔽隐患，只要不影响系统正常使用的，一般都不会被认可的。"
这种情况在项目中出现是很正常的。。。

“测试人员有这个意识，也可以保护自己，免得现场提出，倒是反过来问测试为什么没有测试到”
应该要测试到的点，还是要测试到的

作者: vgygy 时间: 2012-6-5 09:58
继续支持没话说~ 楼主真强

作者: yangli25 时间: 2012-6-5 11:48
没有开发基础的测试人员，由黑盒测试转白盒测试难吗？

作者: sunlight426 时间: 2012-6-5 14:24
看了这么多的高论，我也提点自己的见解。
我遇到过如下问题，一是性能测试时发现客户端访问某个页面非常慢，响应时间超过了30S,我把这个结果告诉了项目经理和开发，但是他们也要寻找原因。于是我通过LoadRunner中对页面元素的分析，发现了几个上百K的js加载占用了大部分时间，而且并发用户数少的情况他们也占用了大部分时间。
二是最近遇到的一个批量查询的问题，我批量查询200个用户，花了14分钟完成了操作；我查询500个用户，结果查询到91%的时候，突然死掉了，时间超过了30分钟。开发人员一开始并不同意修改bug，否认用户一次会查这么多人。这时我根据以往的经验初步定位肯定是session超时。同时和开发一起分析后台报错，提出要修改这个问题。并且我认为这个问题是设计上的bug。同时通过说服开发经理才决定要改bug。
所以经过以上两个具体问题，我认为测试工作的时间越长，接触项目的相关技术和业务会越深，所以定位问题一方面能够提高你的技术水平，另一方面也让你有了同开发站在同一个高度的筹码，能成为你说服他们的利器。
定位问题对成长中的每个阶段的测试人员不是绝对的要求，但是这种能力我们可以拥有。

作者: ftzFOpz 时间: 2012-6-5 23:29
一楼的位置好啊..

作者: ftzFOpz 时间: 2012-6-6 12:14
不错的~~! 感谢您提供

作者: 布额东 时间: 2012-6-6 13:25
将灌水进行到底

作者: iamr9 时间: 2012-6-13 11:18
我觉得这是两个层次的问题

1、  优秀的测试人员具有问题定位的能力

2、  优秀的测试人员是否在工作中需要进行问题定位？

测试工作往往发生在公司
我们是赢利机构不是教育机构因此不同的公司有不同的特殊规定

我理解的测试流程是
发现疑似问题（或者很肯定是问题）
——迅速通知开发人员确认问题（1、表面现象 2、日志 3、其他辅助信息）
——if （开发认为这是个问题）
   {
      开发自己拿走定位去，如果有需要帮忙定位那另再说（比如场景复现抓日志）
      }
——else
      {
      和开发PK，在讲道理的基础上通过外围手段让开发认错（比如表象、日志）
      }

作者: sdlfjwew1 时间: 2012-8-16 17:43
真正要找到root cause, 需要看code
感觉让测试工程师去做code 工作,事半功倍.不划算/

作者: sdlfjwew1 时间: 2012-8-16 17:44
真正要找到root cause, 需要看code
感觉让测试工程师去做code 工作,

作者: sdlfjwew1 时间: 2012-8-16 17:44
真正要找到root cause, 需要看code
感觉让测试工程师去做code 工作,事半功倍.不划算/

作者: sdlfjwew1 时间: 2012-8-16 17:46
路过学习中

作者: sdlfjwew1 时间: 2012-8-16 17:47
路过学习中

作者: yintianyouqin 时间: 2012-8-17 09:17
我觉得测试人员能够帮助开发人员重现问题就是最大的职责了。没有义务去定位问题究竟出在什么地方。

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)