测试人员是否有「归纳导致 bug 的范围」的职责？

12-19

例如，测试人员发现在进行“操作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的提交要求也太简单了吧，一句话“在code项中输入中文和英文的混合串会导致bug，重现率100%”就把bug给描述完了？
一般描述这类涉及data的bug，都要求把data的类型，具体data的形式描述出来。如果你们的测试人员没有把这个描述好，要么是这个测试人员的职业操守比较低，要么是你们公司的流程规范做得不好执行得也不好。

第二个部分是如何分析Bug。这个嘛，我觉得你们这位测试人员水平的确不怎么样，不过从另外一个角度来看，你们公司开发跟测试之间的沟估计是鸿的，所以测试无法知道怎么去分析。
现在测试跟开发都分得太开了，测试不懂代码只懂部分业务，开发只懂代码和少许业务，这使得两者之间的沟通存在很多问题。测试的人认为分析是开发的工作，开发的认为部分分析属于测试人员的，难道这不是一个问题么？
所以我觉得，你们还是找个水平高的测试人员或者加强开发跟测试的沟通吧。

不过，我并不赞同你说的测试人员是要有归纳一个bug的能力的，这个取决于你们的开发模式跟业务类型，更加取决于公司中测试的地位：测试到底只是一个bug reporter还是一个质量评价者（注意不是评测，而是评价）。如果是一个bug reporter，他/她的确没什么必要去归纳，因为报告完一个bug就已经是本职了，这类公司认为质量是测出来的，而不是code出来的。但如果是一个质量评价者，他/她就有义务就这个软件的某个bug或者某些功能评价软件的质量如何，因为他/她必须有全局观才可以去评价一个软件，并且他/她必须意识到自己的义务是保证提供足够的软件质量信息，这类公司认为质量是code出来的，所以需要有人评价code跟design的质量。

在我看来，下面这句话近似于借口：

&>&>&>&>&>&>
我个人理解是，测试人员只应负责精确描述导致bug的操作，以便开发人员重现，而在接到要求之前没有必要自己进行归纳。
否则的话非常容易出现归纳错误，例如：测试人员认为是字符串中的“中文”导致的bug，但实际上是“中文”中的某些特定字符导致的bug，从而误导修正bug的开发人员。
&<&<&<&<&<&<

如果因为担心自己出现归纳错误就可以理直气壮地不做分析，作为开发人员，我凭什么认为这是一个bug而不是因为什么网络、操作系统或者任何其他不可控因素造成的环境问题？反过来说，测试人员为什么不能尝试着像开发人员那样对问题作分析？如果只是记录步骤，很多做事认真的志愿者都可以做到，我为什么需要专门雇一个测试人员？

所以最终的问题还是在于你有多看重自己的产品。遇到了问题，负责人的成员做力所能及的分析，不是锦上添花，而是绝对的义务。即使自己的技术能力有限，仅仅从外围也可以做很多分析。拿自己技术水平可能不够作理由，初学者还可以原谅，有工程经验的人说这种话，未免太不专业了。

在知乎的这个帖子（软件测试的魅力何在？您为什么选择测试一行而不做开发？）里有这么一个总结：

从测试中遇到问题采取的行动来看，我观察到的测试人员能达到的层次大概有这么几个级别：

开一个bug；

查找一些额外的资料如设计文档和历史，确定这是一个问题，然后给出详细的bug重现步骤；

对重现步骤做一些精炼，确定能够重现bug的最少步骤；可能的话，将重现步骤做自动化；

尝试通过研究代码确认问题所在；

尝试给出一个fix；

对错误的原因进行分析，提出一些标准化的方法来检测出类似的问题，比如stress，fuzzing等等；

能够对标准化的测试流程定义对应的数据分析方法，可以保证开发和项目主管都能从中得到需要的信息来掌控质量状况。

题主觉得QA做到1-2步就足够了。
但是题主这么认为的原因是，QA做第3步的时候能力不足，导致narrow down最简重现步骤时出错，反而增加了开发的工作量。

所以我认为，QA去做归纳问题这一步时，态度是对的，但是因为能力不足，导致负面效果。从QA的角度，应该继续这么做，但是要提升自己的能力。从开发的角度，了解这个QA的水平，再去判断其归纳总结的可信度。

问题中其实说的是两件事：

先说报 bug 时是否要归纳，我觉得合理的处理方式是：

1. 将 "操作 A" 的精确步骤提交
2. 备注类似操作的现象

发现错误现象后，测试人员需要将现象 narrow down 到一个稳定最简的重现步骤后报 bug。但要检查类似场景后备注供开发人员参考，验 bug 时必须检查类似场景。不要早下结论，不要胡乱归纳，那样只会画蛇添足。

至于提问者遇到的实际问题，跟是否归纳无关。他没发现是特定字符导致的问题，怕没去定位是中文还是英文的问题吧？没去换换字符看看是否发生吧？这不是根本没有 narrow down 么？！是基本功的问题了。看到现象就报 bug，不分析不定位，这个测试人员不合格。

如果说职责，那就非常取决于开发和测试职位各自的工作范围了，而每家公司的要求可能都不同。这种情况下，建议还是找你的上级问问清楚比较好。

如果纯粹是从技术层面来探讨这个问题，那我们就应该首先从目的问起：我们为什么要“归纳导致 bug 的范围”？

从问题的描述来看，实际上是在发现bug之后，不确定测试的输入和触发这个bug之间是否有着必然的逻辑关系，是特例还是普遍现象。但在只有一个样本的情况下，根本就无法做出这样的判断，所以才会希望更换一些输入，以期触发同样的bug，然后再总结这些输入之间的共性，以求归纳得出输入和bug之间的充分必要的逻辑关系。

如果我们把相关功能或相关代码实现看作黑盒，那么梳理这个逻辑关系，无疑需要尝试大量的输入组合，至少得提出导致bug的输入“有哪些影响因子”、“不同因子可分为几个等价类”、“每个因子的不同等价类挑选一个具体的值”，全部尝试过之后，再根据这些输入来判断，“中文”和“英文”是否是影响bug出现的因子，以及是否“所有中文”还是“特定中文字符”会导致bug出现。如果不知道程序代码实现，只能猜测程序可能出问题的地方，绝对是事倍功半的苦逼活儿。

那么，谁更懂程序本身可能存在问题的薄弱之处呢？当然是程序员。但是，程序员通常都专注于用代码实现功能，验证一下这样实现的功能有效即可，通常都是happy path随意测试一下，最多sad path也随意测试一下也就完了。不排除牛逼的程序员自测能力超强，测试很充分，但真遇上这种程序员，也不可能到知乎来忧心这种问题了…或者说，漏掉的，就真的是非常难发现的 bug，是个例中的个例，真是这样的话，就不必犹豫，别总结什么范围了，直接把输入输出扔给程序员吧，他们一定能找到原因的。

不管怎样，要想有效地解决问题，最好的就是测试员和程序员结对，使用不同的测试输入组合尝试再度触发bug发生，然后再调查可能导致该bug发生的原因，根据对原因的猜测针对性地设计新的输入组合重新进行测试，检查结果，然后再根据结果决定下一步。

综上所述，关键在于“协作”，而不是去谈论“职责”。

这是一个bug重现的问题，
如果任何人按照bug的描述无法重现，这个bug就是invalid。
如你举的例子“在code项中输入中文和英文的混合串会导致bug，重现率100%”
比较好的描述是

1. 在code项输入“中english文”,并提交表单
期待的结果：XXXX
实际的结果：XXXX
附件：截图、logs

至于“归纳导致bug的范围”可以verified的时候再做

测试人员应该做的是，帮助开发人员复现 bug。
在这个前提下，是否要归纳原因因复现的难度而定。
如果 bug 可以在任意机器上复现，则不必归纳。
如果 bug 只能在非常复杂设定的环境下复现，测试人员最好经过归纳，得出在较普通的环境下复现的手段。

首先，操作A的bug提的不够规范，建议这样：
操作步骤：包括输入内容、操作步骤、操作顺序等
预期结果：
实际结果：
附件：截图或者log日志

其次，不建议将操作B、操作C等A+类问题提交到操作A的jira备注中，应该作为单独的问题提在jira上，原因很简单，许多开发人员粗心大意，不看备注，A+类问题容易被忽视。

第三，建议在测试报告中将问题归类，归纳总结出导致BUG的范围。

第四，好的测试人员应当具备一定的素质，比如排查定位问题的能力，比如归纳总结Bug原因的能力，协助开发解决问题的能力，站在全局的角度评估产品质量的能力等等。

最后，建议题主多去了解一下测试工作，还要提醒一下，测试阶段，发现问题以测试环境为准，开发对bug进行重现时应在开发环境跟测试环境中同时进行。

这是不能复现的问题
这种问题直接向办法沟通让故障重现才能解决

精确的报告bug只是测试人员的一部分，个人认为测试人员的工作应该是“质量保证”，所以归纳是一项很重要的素质。至于会误导开发人员这个问题应该是不存在的。一个真正好的bug应该是不应该带有个人色彩，不带有猜测内容的。里面说的每一句话都是有事实支撑的，这样又怎么会误导开发者呢。
还有测试也分很多重的，想单元测试却是是跟开发联系紧密，但像功能测试则更多从逻辑、业务、功能上进行测试，跟开发差距还是很大的

作为一个经验不算特别丰富的测试人员来说，发现bug并深入思考出现bug的原因已经是一种工作习惯。由于是黑盒测试，做过一阵子开发，所以对bug产生原因有更深入的认识吧。那么对我来说，发现bug，给出足够清晰的bug描述，然后给出自己对于bug的看法（定位bug产生原因）。但自己的看法只是一个建议，并非明确的告知开发一定就是某个地方产生了bug，给出的建议，开发童鞋可以参考，也可以自己去找bug产生原因，这样没毛病。

这bug描述的本身就不完整啊, 还到不了归纳的一步.

测试人员的基本职责时提出bug，并将其重现步骤描述清楚，使开发人员能够准确定位问题，当然这是最基本的。再高点就可以与研发定位问题可能或准确出现的原因。我工作习惯就是尽量给研发提供尽可能多的信息，使其准确定位。必现bug就准确清晰描述其重现步骤，非必现但严重bug就寻找规律，重现率，报错log，甚至是精确到可能操作到某一秒，说到哪句话导致报错。如果是重现率低的崩溃bug就提供log,cpu占用率，内存占用等完整信息。

如果测试能清晰的分析出这个问题的原因和定位，那么干嘛不直接去修改好呢·

Report a bug的时候需要有详细的描述，包括但不限于：
1.Bug title；
2.Description;
3.pre-condition;
4.scenario(steps)
5.logs:picture/video/ system logs.
6.reproduction rate.
7.Tester Analysis.
...
从测试中遇到问题采取的行动来看，我观察到的测试人员能达到的层次大概有这么几个级别：

开一个bug；
查找一些额外的资料如设计文档和历史，确定这是一个问题，然后给出详细的bug重现步骤；
对重现步骤做一些精炼，确定能够重现bug的最少步骤；可能的话，将重现步骤做自动化；
尝试通过研究代码确认问题所在；
尝试给出一个fix；
对错误的原因进行分析，提出一些标准化的方法来检测出类似的问题，比如stress，fuzzing等等；
能够对标准化的测试流程定义对应的数据分析方法，可以保证开发和项目主管都能从中得到需要的信息来掌控质量状况。

我觉得至少在我熟悉的工作范围内，我可以做到5. so，是不是很节省你们开发的时间呀哈^_^

“我个人理解是，测试人员只应负责精确描述导致bug的操作，以便开发人员重现，而在接到要求之前没有必要自己进行归纳。”
---测试人员应该基于事实说话，出现什么就是什么，即尊重事实，在不了解的情况下不要随意归纳。。但是在国内的公司里面不还执行，因为有一种言论是测试对整个生命周期负责，因此他要加上他自己的思考才能证明他做的“好”。。。

因此我认为：
功能型的人员不需要归纳。
白盒型的人员需要。

这个都是跟能力和薪资成正比的。。。

待过3个公司，针对这个问题，其中A鼓励定位问题所在，B不作要求，C要求定位问题。

个人感受，开发解bug效率 C&>A&>B，其中C和A的开发基本都是bug解决了之后再沟通bug解决情况，但是B存在部分bug需要多次往返沟通之后才能着手解决。

就我个人而言，定位不仅能提高bug解决效率，对整个项目有积极作用；另外，在定位的过程中，思考也有利于个人的成长。

最后，这个bug提的真是一点美感都没有。

答案是肯定的，按照岗位分工，测试人员对于bug整个生命周期是要跟进到底，而对于自己提出的bug是需要进行详细步骤描述及发散思考的，提交模块都类似于：

标题：操作步骤：。步骤1 。步骤2... 期望结果：实际结果

一个负责、细心的测试人员会对上面的模版进行详尽描述，甚至对于发现的bug还能举一反三，思考出更多路径，便于开发人员看到bug描述的几条路径都能马上想到问题出在哪里，省去往返沟通成本

我觉得测试在提交问题时第二种。这个还是一个测试基本认识的问题。
有个“梗”产生第一种是有原因的，因为一条测试用例只反馈1个问题的原则，因为如果我写abc分别进行A操作，结果ab没出问题，c出了问题，这个问题是算通过还是失败，那么一定算是失败，所以分成3条，可能是因为这个提交问题时也分成了3条。
同类问题需要进行归类，等价类划分的方式某种意义就是让用例进行科学的减少数量来尽可能覆盖。
至于100%复现，结果不是这样的，打回也是正确的，测试应该更清晰的描述他在code里输入了什么。一旦出现问题，根据经验判断是否会再次出现，做二次检查后在填写100%也是需要的。
测试很关键有效性的问题，程序在繁忙的时候可能遇到这类问题会恼火，这个时候打回状态是“不可重现”，这类问题是需要尽可能降低的。

关于提bug的描述，还是分项目的，之前我在一个大型银行项目做过，因为开发和测试分得很明确，所以写bug需要很详细，因为开发没有时间去和你讨论。而现在的项目比较小，开发和测试做一块，你就算写的很详细，他们还是回来问你让你重现，根本不会仔细看bug的描述。