2024最新软件测试【测试理论+ UI 自动化】面试题（内附答案）(2)

1、 xmind 思维导图评审，主要是测试人员 2、测试用例需要评审，测试人员，开发人员，产品人员 3、需求文档，项目组所有的人员，都会到场

3.4 有没有写过测试计划，具体包括哪些内容?

参考答案 1： 测试计划内容： (1)目的和范围 (2)规程 (3)测试方案和方法 (4)测试的准入和准出 (5)测试计划(流程、时间安排、对应人员) (6)测试的环境配置和人员安排 (7)交付件 华测教育专属 华测教育专属 华测教育专属 华测教育专属 华测教育专属 华测教育专属 华测教育专属 华测教育专属 华测教育专属 15 参考答案 2 我们公司之前按照考核要求写过测试计划，不过后面老大觉得太耽误工作进度， 后面一般都不再写测试计划，而是写版本计划，这个在版本计划，每个人的任务列出来， 负责人列出来，自己根据自己的情况分配时间，然后汇总，大家一起开个小会评审就可以了。

3.5 用例包含哪些部分，哪些用例设计方法，你一般常用哪些方法?

原来我们用例包含 测试项目，用例编号、测试标题、优先级、预置条件、操作步骤、测试数据、预期结果 黑盒测试用例设计方法：主要是等价类、边界值、错误推测法、判定表、因果图、正交表、 流程分析法、状态迁移法、异常分析法。 常用的：等价类、边界值、判定表、流程分析法、错误推测法。 等价类是指某个输入域的子集合，在该子集合中， 各个输入数据对于揭露程序中的错误都是等效的， 并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试，因此，可以把全部 输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件， 就可以用少量代表性的测试数据取得较好的测试结果， 等价类划分可有两种不同的情况有效等价类和无效等价类。 边界值的话就是对等价类划分方法的补充。测试工作经验告诉我，大量的错误往往是发生在输入或输 出范围的边界上而不是发生在输入输出范围的内部，因此的话针对各种边界情况来设计测试用例，可 以查出更多的错误，使用边界值分析方法设计测试用例的话，首先应该确定边界情况，通常输入和输 出等价类的边界，就是应着重测试的边界情况应当选取正好等于，刚刚大于或刚刚小于边界的值作为 测试数据，而不是选取等价类中的典型值或任意值作为测试数据。 对于错误推断法，这个是基于经验和直觉推测程序中所有可能存在的各种错误， 从而有针对性的去设计测试用例的方法的，主要就是列举出程序中所有可能有的错误和容易发生错误 的特殊情况去根据这些情况来选择测试用例，例如，在单元测试时曾列出的许多在模块中常见的错误 以前产品测试中曾经发现的错误等，这些就是经验的总结。还有，输入数据和输出数据为 0 的情况。 输入表格为空格或输入表格只有一行。这些都是容易发生错误的情况，可选择这些情况下的例子作为 测试用例。 前面介绍的等价类划分方法和边界值分析方法都是着重考虑输入条件但都没有考虑输入条件之间的 联系，相互组合等等的情况。考虑输入条件之间的相互组合，可能会产生一些新的情况， 但是要检查输入条件的组合并不是一件容易的事情，即使把所有输入条件划分成等价类， 他们之间的组合情况也相当多，因此的话可以考虑采用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例，这就需要用到因果图(逻辑模型)。 因果图方法最终生成的就是判定表它适合检查程序输入条件的各种组合情况。

3.6 TestLink 工具使用?

(1)创建用户，并给新创建的用户指定权限。 (2)创建测试用例，对测试用例进行增、删、改、查 (3)把测试用例关联到对应的测试计划中。 (4)把测试用例指派给对应的测试人员。 (5)对应的测试人员，查看被指派的测试用例，并执行测试用例。

3.7 如何提交一个好的 BUG

对 BUG 有一个清晰明了的描述； 详细描述 BUG 重现的步骤 对于产生 BUG 的环境进行描述； 提交 BUG 相关的图片和日志; 定位好 BUG 的等级； 将预期结果与实际结果进行对比。

3.8 提 bug 需要注意哪些问题?

1. 不要急着提交，先跟开发说明 bug 的情况，定位分析下 bug。 是前端问题还是后端问题再去提交 bug。 2) 简单明了的概括 bug 标题，清晰的描述 bug 重现步骤，分析 bug 和预期正确结果，附加 bug 的截 图或者日志。描述 bug 的时候。 3) 在不能确认该情况是否为 bug 的时候，可以请教其他人。 4) 提交完 bug 以后，后面还要跟踪 bug 修复情况。

3.9 bug 怎么管理的，bug 的生命周期或者是 bug 的状态

原来 bug 是用禅道来管理的 原来我们公司 bug，提交 bug 直接给对应的开发人员，对应开发人员修复完成，交给测试复测， 复测通过关闭 bug，不通过打回给对应开发。 提交-开发人员(已激活未确认)-开发进行确认，状态变成已激活，已确认，开发修复完成， 标注状态是已修复，测试人员复测通过，已关闭，打回给对应开发，已经激活。

3.10 提交 bug 包含哪些内容

所属产品、所属模块、所属项目、影响版本、指派人员 截止日期、严重程度、优先级、bug 类型、bug 环境 Bug 标题、重现步骤、附件

3.11 你提交的 bug，开发不认可怎么办?

首先我会再看需求文档，是不是我的理解有误，如果是我对需求理解错的话我就去关闭 bug。 如果是 bug 再去让其他测试人员看看听下他们的意见，然后自己先再三去复测，并目保存好截图和日 志，确定这是一个 bug 之后我就去跟开发说明白，并且给他看 bug 重现的截图以及日志，如果开发还 是不认可的话我就跟产品或项目经理说明白情况。

3.12 对应无法重现 bug，应该怎么处理?

首先，我会多测几次，测了好多次都无法重现的话