君，已阅读到文档的结尾了呢~~
一套比较完整的软件测试人员面试题(技术和人力资源方面)
扫扫二维码，随身浏览文档
手机或平板扫扫即可继续访问
一套比较完整的软件测试人员面试题(技术和人力资源方面)
举报该文档为侵权文档。
举报该文档含有违规或不良信息。
反馈该文档无法正常浏览。
举报该文档为重复文档。
推荐理由：
将文档分享至：
分享完整地址
文档地址：
粘贴到BBS或博客
flash地址：
支持嵌入FLASH地址的网站使用
html代码：
&embed src='/DocinViewer--144.swf' width='100%' height='600' type=application/x-shockwave-flash ALLOWFULLSCREEN='true' ALLOWSCRIPTACCESS='always'&&/embed&
450px*300px480px*400px650px*490px
支持嵌入HTML代码的网站使用
您的内容已经提交成功
您所提交的内容需要审核后才能发布，请您等待！
3秒自动关闭窗口测试人员是否有「归纳导致 bug 的范围」的职责？
例如，测试人员发现在进行“操作A”的时候出现了bug，那么下面两种方式那种更合理？1，他直接将“操作A”的精确步骤提交给开发部门。2，他测试同一类的“操作B”“操作C”，都出现了bug，而“操作A”“操作B”“操作C”都属于“A+类操作”，那么他把上述三次测试归纳为了“进行A+类操作时会发生bug”，提交给开发部门。我之前是一个测试人员，现在是一个开发人员。最近接到的一个bug就是类似这样：JIRA里说“在code项中输入中文和英文的混合串会导致bug，重现率100%”，但是我自己输入中文和英文混合串却无法重现此错误，所以将JIRA里这个bug转回给了测试部门要求补充描述，至少要求描述清楚输入的“英文和中文混合字符串”到底是什么。同时我就在想：对于bug的产生原因当然是开发人员负责；那么测试人员是否有职责，或者是否有必要将导致bug的操作归纳成一类操作，然后提交给发开人员？我个人理解是，测试人员只应负责精确描述导致bug的操作，以便开发人员重现，而在接到要求之前没有必要自己进行归纳。否则的话非常容易出现归纳错误，例如：测试人员认为是字符串中的“中文”导致的bug，但实际上是“中文”中的某些特定字符导致的bug，从而误导修正bug的开发人员。——或者说，这个问题是否因岗位而异，比如黑盒测试人员与白盒测试人员对上述问题的回答不同？求解惑。
这是一个bug重现的问题，如果任何人按照bug的描述无法重现，这个bug就是invalid。如你举的例子“在code项中输入中文和英文的混合串会导致bug，重现率100%”比较好的描述是1. 在code项输入“中english文”,并提交表单期待的结果：XXXX实际的结果：XXXX附件：截图、logs至于“归纳导致bug的范围”可以verified的时候再做
你的问题实际上分两个部分。第一个部分是如何记录Bug。这个嘛，我觉得你们bug的提交要求也太简单了吧，一句话“在code项中输入中文和英文的混合串会导致bug，重现率100%”就把bug给描述完了？一般描述这类涉及data的bug，都要求把data的类型，具体data的形式描述出来。如果你们的测试人员没有把这个描述好，要么是这个测试人员的职业操守比较低，要么是你们公司的流程规范做得不好执行得也不好。第二个部分是如何分析Bug。这个嘛，我觉得你们这位测试人员水平的确不怎么样，不过从另外一个角度来看，你们公司开发跟测试之间的沟估计是鸿的，所以测试无法知道怎么去分析。现在测试跟开发都分得太开了，测试不懂代码只懂部分业务，开发只懂代码和少许业务，这使得两者之间的沟通存在很多问题。测试的人认为分析是开发的工作，开发的认为部分分析属于测试人员的，难道这不是一个问题么？所以我觉得，你们还是找个水平高的测试人员或者加强开发跟测试的沟通吧。不过，我并不赞同你说的测试人员是要有归纳一个bug的能力的，这个取决于你们的开发模式跟业务类型，更加取决于公司中测试的地位：测试到底只是一个bug reporter还是一个质量评价者（注意不是评测，而是评价）。如果是一个bug reporter，他/她的确没什么必要去归纳，因为报告完一个bug就已经是本职了，这类公司认为质量是测出来的，而不是code出来的。但如果是一个质量评价者，他/她就有义务就这个软件的某个bug或者某些功能评价软件的质量如何，因为他/她必须有全局观才可以去评价一个软件，并且他/她必须意识到自己的义务是保证提供足够的软件质量信息，这类公司认为质量是code出来的，所以需要有人评价code跟design的质量。
问题中其实说的是两件事：先说报 bug 时是否要归纳，我觉得合理的处理方式是：1. 将 "操作 A" 的精确步骤提交2. 备注类似操作的现象发现错误现象后，测试人员需要将现象 narrow down 到一个稳定最简的重现步骤后报 bug。但要检查类似场景后备注供开发人员参考，验 bug 时必须检查类似场景。不要早下结论，不要胡乱归纳，那样只会画蛇添足。至于提问者遇到的实际问题，跟是否归纳无关。他没发现是特定字符导致的问题，怕没去定位是中文还是英文的问题吧？没去换换字符看看是否发生吧？这不是根本没有 narrow down 么？！是基本功的问题了。看到现象就报 bug，不分析不定位，这个测试人员不合格。
测试人员应该做的是，帮助开发人员复现 bug。在这个前提下，是否要归纳原因因复现的难度而定。如果 bug 可以在任意机器上复现，则不必归纳。如果 bug 只能在非常复杂设定的环境下复现，测试人员最好经过归纳，得出在较普通的环境下复现的手段。
我觉得测试在提交问题时第二种。这个还是一个测试基本认识的问题。有个“梗”产生第一种是有原因的，因为一条测试用例只反馈1个问题的原则，因为如果我写abc分别进行A操作，结果ab没出问题，c出了问题，这个问题是算通过还是失败，那么一定算是失败，所以分成3条，可能是因为这个提交问题时也分成了3条。同类问题需要进行归类，等价类划分的方式某种意义就是让用例进行科学的减少数量来尽可能覆盖。至于100%复现，结果不是这样的，打回也是正确的，测试应该更清晰的描述他在code里输入了什么。一旦出现问题，根据经验判断是否会再次出现，做二次检查后在填写100%也是需要的。测试很关键有效性的问题，程序在繁忙的时候可能遇到这类问题会恼火，这个时候打回状态是“不可重现”，这类问题是需要尽可能降低的。
在我看来，下面这句话近似于借口：&&&&&&我个人理解是，测试人员只应负责精确描述导致bug的操作，以便开发人员重现，而在接到要求之前没有必要自己进行归纳。否则的话非常容易出现归纳错误，例如：测试人员认为是字符串中的“中文”导致的bug，但实际上是“中文”中的某些特定字符导致的bug，从而误导修正bug的开发人员。&&&&&&如果因为担心自己出现归纳错误就可以理直气壮地不做分析，作为开发人员，我凭什么认为这是一个bug而不是因为什么网络、操作系统或者任何其他不可控因素造成的环境问题？反过来说，测试人员为什么不能尝试着像开发人员那样对问题作分析？如果只是记录步骤，很多做事认真的志愿者都可以做到，我为什么需要专门雇一个测试人员？所以最终的问题还是在于你有多看重自己的产品。遇到了问题，负责人的成员做力所能及的分析，不是锦上添花，而是绝对的义务。即使自己的技术能力有限，仅仅从外围也可以做很多分析。拿自己技术水平可能不够作理由，初学者还可以原谅，有工程经验的人说这种话，未免太不专业了。
在知乎的这个帖子（）里有这么一个总结：从测试中遇到问题采取的行动来看，我观察到的测试人员能达到的层次大概有这么几个级别：开一个bug；查找一些额外的资料如设计文档和历史，确定这是一个问题，然后给出详细的bug重现步骤；对重现步骤做一些精炼，确定能够重现bug的最少步骤；可能的话，将重现步骤做自动化；尝试通过研究代码确认问题所在；尝试给出一个fix；对错误的原因进行分析，提出一些标准化的方法来检测出类似的问题，比如stress，fuzzing等等；能够对标准化的测试流程定义对应的数据分析方法，可以保证开发和项目主管都能从中得到需要的信息来掌控质量状况。题主觉得QA做到1-2步就足够了。但是题主这么认为的原因是，QA做第3步的时候能力不足，导致narrow down最简重现步骤时出错，反而增加了开发的工作量。所以我认为，QA去做归纳问题这一步时，态度是对的，但是因为能力不足，导致负面效果。从QA的角度，应该继续这么做，但是要提升自己的能力。从开发的角度，了解这个QA的水平，再去判断其归纳总结的可信度。
这是不能复现的问题这种问题直接向办法沟通 让故障重现才能解决
QA首要的工作是帮助Dev reproduce bug，QA根据bug的属性决定在哪些环境下做哪些测试，做完测试后如实反映给Dev就算完成任务。在这个例子里，QA应该写在bug report里面的是，”在A/B/C环境下能够repro“，别的可以不写，因为别的东西不一定在逻辑上对——如果A+类除了A/B/C还有别的情况，怎么知道在别的情况下是否repro呢？这里讨论的所谓的”归纳“我认为只是在逻辑层面上的简单总结。为什么说简单呢？因为大部分情况下QA不了解整个系统的内部原理，只能从外部给出判断。而这种判断，只要QA要把自己做过的test和结果如实的反映给Dev，通常Dev都能自己给出来。因为Dev比QA更了解系统，所以Dev得出的结论一般会更准确。于是，我觉得QA没必要进行归纳。最后说说我自己的经验，我觉得我最喜欢合作的QA就是能帮我在最简单的环境下最稳定的repro出一个bug的QA。
如果说职责，那就非常取决于开发和测试职位各自的工作范围了，而每家公司的要求可能都不同。这种情况下，建议还是找你的上级问问清楚比较好。如果纯粹是从技术层面来探讨这个问题，那我们就应该首先从目的问起：我们为什么要“归纳导致 bug 的范围”？从问题的描述来看，实际上是在发现bug之后，不确定测试的输入和触发这个bug之间是否有着必然的逻辑关系，是特例还是普遍现象。但在只有一个样本的情况下，根本就无法做出这样的判断，所以才会希望更换一些输入，以期触发同样的bug，然后再总结这些输入之间的共性，以求归纳得出输入和bug之间的充分必要的逻辑关系。如果我们把相关功能或相关代码实现看作黑盒，那么梳理这个逻辑关系，无疑需要尝试大量的输入组合，至少得提出导致bug的输入“有哪些影响因子”、“不同因子可分为几个等价类”、“每个因子的不同等价类挑选一个具体的值”，全部尝试过之后，再根据这些输入来判断，“中文”和“英文”是否是影响bug出现的因子，以及是否“所有中文”还是“特定中文字符”会导致bug出现。如果不知道程序代码实现，只能猜测程序可能出问题的地方，绝对是事倍功半的苦逼活儿。那么，谁更懂程序本身可能存在问题的薄弱之处呢？当然是程序员。但是，程序员通常都专注于用代码实现功能，验证一下这样实现的功能有效即可，通常都是happy path随意测试一下，最多sad path也随意测试一下也就完了。不排除牛逼的程序员自测能力超强，测试很充分，但真遇上这种程序员，也不可能到知乎来忧心这种问题了…或者说，漏掉的，就真的是非常难发现的 bug，是个例中的个例，真是这样的话，就不必犹豫，别总结什么范围了，直接把输入输出扔给程序员吧，他们一定能找到原因的。不管怎样，要想有效地解决问题，最好的就是测试员和程序员结对，使用不同的测试输入组合尝试再度触发bug发生，然后再调查可能导致该bug发生的原因，根据对原因的猜测针对性地设计新的输入组合重新进行测试，检查结果，然后再根据结果决定下一步。综上所述，关键在于“协作”，而不是去谈论“职责”。
已有帐号？
无法登录？
社交帐号登录找好工作，快人一步}