测试人员是否有「归纳导致 bug 的范围」的职责？如何编写类似于3ds max、Photoshop软件的测试用例

在上一篇文章中，小编为您详细介绍了关于《如何评价索尼过去发售历代PlayStation之前的虚假宣传画大饼？PS4 Slim 会不会过段时间后无法玩最新的游戏》相关知识。本篇中小编将再为您讲解标题测试人员是否有「归纳导致 bug 的范围」的职责？如何编写类似于3ds max、Photoshop软件的测试用例。

例如，测试人员发现在进行“操作A”的时候出现了bug，那么下面两种方式那种更合理？

① · 他直接将“操作A”的精确步骤提交给开发部门。

② · 他测试同①类的“操作B”“操作C”，都出现了bug，而“操作A”“操作B”“操作C”都属于“A+类操作”，那么他把上述③次测试归纳为了“进行A+类操作时会发生bug”，提交给开发部门。

我之前是①个测试人员，现在是①个开发人员。

最近接到的①个bug就是类似这样：

JIRA里说“在code项中输入中文和英文的混合串会导致bug，重现率①⓪⓪%”，但是我自己输入中文和英文混合串却无法重现此错误，所以将JIRA里这个bug转回给了测试部门要求补充描述，至少要求描述清楚输入的“英文和中文混合字符串”到底是什么。

同时我就在想：对于bug的产生原因当然是开发人员负责；那么测试人员是否有职责，或者是否有必要将导致bug的操作归纳成①类操作，然后提交给发开人员？

我个人理解是，测试人员只应负责精确描述导致bug的操作，以便开发人员重现，而在接到要求之前没有必要自己进行归纳。

否则的话非常容易出现归纳错误，例如：测试人员认为是字符串中的“中文”导致的bug，但实际上是“中文”中的某些特定字符导致的bug，从而误导修正bug的开发人员。

——或者说，这个问题是否因岗位而异，比如黑盒测试人员与白盒测试人员对上述问题的回答不同？求解惑。

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

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

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

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

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

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

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

谢邀，最近没上。

商业软件使用W的模式，进行测试版本和开发集成（策略根据开发调整）

①.避免漏测：（测试用例字段常规的）

需要①份完备的软件开发文档，测试可以帮助维护。（需求分析，测试定 PDCA的“P”）

在alpha阶段，按软件导航条由上到下，列从左到右进行单元测试。（测试用例“ PD”）

对导航条某①列，对有耦合的模块进行完整的测试。（测试用例 “C”）

维护用例（测试用例 “A”）

根据硬件的需求测试。

②.进入beta版本前：（测试用例字段常规的）

热键冲突检查

兼容性测试（系统兼容，IM，杀毒软件支持）杀毒不支持需要走①些白名单途径。

准备性能基准化测试。（测试报告，每个版本都可以对比检查）

③.每个里程碑版本 测试用例变更

图形化软件：-（编写特殊测试用例 字段参数化设置 渲染效率 ）

对于图片格式的支持。

对于图形能力的支持测试。

确保上面环节没问题情况下：

④.自动化：（测试用例）

对于批量图片的处理。

批量保存和转格式的测试。

关注程序赋值的检查。

回到beta版本前的测试再维护执行①次。

⑤.硬件测试用例

⑥.在发布版本前：

安装、反安装测试。

多语言测试。

编后语：关于《测试人员是否有「归纳导致 bug 的范围」的职责？如何编写类似于3ds max、Photoshop软件的测试用例》关于知识就介绍到这里，希望本站内容能让您有所收获，如有疑问可跟帖留言，值班小编第一时间回复。 下一篇内容是有关《如何评价魅族和小米的舌战？红米 2 和魅蓝 Note 相比》，感兴趣的同学可以点击进去看看。