软件测试面试题（4）——二面

是二轮，线上笔试后的约的线下面试，这里我记录一下面试过程中大概遇到的问题。

        1、设计测试用例的主要方法：流程图法，等价类划分，边界值分析法，因果图法等等

这里他问我熟悉哪种方法，给他讲一下：（我说的流程图，问我用什么画图，我回答是亿图图示）

（1）流程图法

1. 定义：

   • 根据软件的业务流程或程序流程图来设计测试用例。通过分析流程图中的各个节点、分支和路径，确定可能的输入和预期输出，从而设计出全面覆盖流程的测试用例。

2. 步骤：

   • 绘制流程图：根据软件的需求规格说明书或程序的逻辑结构，绘制出详细的流程图。流程图应包括所有的主要功能模块、分支条件、循环结构等。
   • 确定节点和路径：分析流程图中的各个节点和路径，确定关键节点和可能的执行路径。关键节点可以是输入节点、判断节点、循环节点等，执行路径可以是基本路径、分支路径、异常路径等。
   • 设计测试用例：针对每个关键节点和执行路径，设计相应的测试用例。测试用例应包括输入数据、预期输出、执行步骤等。对于不同的路径，可以考虑边界值、等价类划分等方法来设计输入数据。
   • 执行测试用例：按照设计好的测试用例执行测试，记录实际输出结果，并与预期输出结果进行比较。如果发现差异，应及时进行问题定位和修复。

3. 优点：

   • 直观地展示软件的业务流程和程序逻辑，便于理解和分析。
   • 可以全面覆盖软件的各种执行路径，提高测试的覆盖率。
   • 有助于发现流程中的错误和缺陷，如死循环、非法跳转等。

例如，对于一个在线购物系统，绘制流程图可以包括用户登录、浏览商品、加入购物车、结算、支付等步骤。针对每个步骤，可以设计不同的测试用例，如输入错误的用户名和密码进行登录测试、在购物车中添加和删除商品测试、选择不同的支付方式进行支付测试等。

总的来说，流程图法是一种有效的测试用例设计方法，可以帮助测试人员更好地理解软件的业务流程和程序逻辑，提高测试的质量和效率。

（2）等价类划分

1. 定义：

   • 把所有可能的输入数据，即程序的输入域划分成若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例。

2. 划分原则：

   • 有效等价类：是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。
   • 无效等价类：与有效等价类的定义恰巧相反，无效等价类指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。

3. 步骤：

   • 确定等价类：根据需求规格说明书，分析输入数据的类型、范围、格式等，确定等价类。
   • 划分等价类：将输入数据划分为若干个等价类，可以采用以下方法：
     • 按区间划分：例如输入数值的范围，可以划分不同的区间作为等价类。
     • 按数值集合划分：如果输入数据是一组固定的值，可以将这些值分别作为不同的等价类。
     • 按限制条件或规则划分：根据输入数据的限制条件或规则进行划分。
   • 确定测试用例：从每个等价类中选取一个或多个代表性的数据作为测试用例。

4. 优点：

   • 可以用较少的测试用例覆盖较多的输入情况，提高测试效率。
   • 可以避免测试的盲目性，使测试更加有针对性。

（3）边界值分析法

1. 定义：

   • 对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，因为在很多情况下，边界情况往往是容易出错的地方。

2. 边界值的选择：

   • 对于输入数据，选取正好等于、刚刚大于和刚刚小于边界的值作为测试用例。
   • 例如，如果输入数据的范围是 [1, 100]，那么边界值可以选择 1、2、99、100。

3. 步骤：

   • 确定边界：根据需求规格说明书，确定输入数据的边界值。
   • 选取边界值：选取正好等于、刚刚大于和刚刚小于边界的值作为测试用例。
   • 设计测试用例：根据选取的边界值设计测试用例，包括输入数据和预期输出。

4. 优点：

   • 可以有效地发现输入或输出边界处的错误。
   • 对于一些复杂的系统，边界值分析法可以快速定位可能出现问题的地方。

（4）因果图法

1. 定义：

   • 因果图法是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法。它适合于检查程序输入条件的各种组合情况。

2. 因果图的基本符号：

   • 恒等：若原因出现，则结果出现；若原因不出现，则结果也不出现。
   • 非：若原因出现，则结果不出现；若原因不出现，则结果出现。
   • 或：若几个原因中有一个出现，则结果出现；若几个原因都不出现，则结果不出现。
   • 与：若几个原因都出现，结果才出现；若其中一个原因不出现，则结果不出现。

3. 步骤：

   • 分析需求：理解需求规格说明书，确定输入条件和输出结果。
   • 确定原因和结果：将输入条件作为原因，输出结果作为结果。
   • 绘制因果图：根据原因和结果之间的关系，绘制因果图。
   • 转换为判定表：将因果图转换为判定表，列出所有可能的输入组合和对应的输出结果。
   • 设计测试用例：根据判定表设计测试用例。

4. 优点：

   • 可以考虑输入条件之间的组合关系，发现一些复杂的逻辑错误。
   • 能够清晰地展示输入条件和输出结果之间的因果关系，便于理解和分析。

（5）场景法

1. 定义：

   • 通过场景描述的业务流程（业务逻辑），也包括代码实现逻辑，设计用例来遍历场景，验证软件系统功能的正确性。

2. 场景的组成：

   • 基本流：是经过用例的最简单的路径，无任何差错，程序从开始直接执行到结束。
   • 备选流：在基本流的基础上，出现了各种异常情况或分支情况。

3. 步骤：

   • 分析需求：理解业务流程和需求规格说明书，确定场景的基本流和备选流。
   • 绘制流程图：根据基本流和备选流绘制流程图，清晰地展示业务流程。
   • 设计测试用例：根据流程图设计测试用例，覆盖各种场景。

4. 优点：

   • 可以模拟用户的实际操作场景，更加贴近实际使用情况。
   • 有助于发现业务流程中的错误和缺陷，提高软件的质量和用户体验。

        2、问了我一些excel上的问题，我记得有一个没回答上，最后面试官说是VLOOKUP函数。

在 Excel 中可以使用以下方法标注 A 区和 B 区中的重复内容：

方法一：条件格式

1. 选中要标注重复内容的区域，假设 A 区范围是 A1:A10，B 区范围是 B1:B10，那么可以选中一个较大的区域，比如 A1:B10。
2. 在 Excel 的 “开始” 菜单中，点击 “条件格式”。
3. 选择 “突出显示单元格规则” 中的 “重复值”。
4. 在弹出的对话框中选择一种标注的格式，比如设置为红色填充。点击 “确定” 后，A 区和 B 区中的重复内容就会被标注出来。

方法二：使用函数

1. 在 C1 单元格输入公式=IF(COUNTIF(A$1:B$10,A1)>1,"重复","")，这个公式会判断 A1 单元格的值在 A1:B10 这个区域中出现的次数，如果大于 1 则表示重复，在 C1 单元格显示 “重复” 字样，否则显示为空。
2. 拖动 C1 单元格的填充柄，将公式复制到 C2:C10（假设 A、B 区共有 10 个单元格需要判断）以及更多的单元格，这样就可以将重复的内容在 C 列标注出来。

也可以使用 VLOOKUP 函数结合一些辅助列来解决类似判断 A 区和 B 区重复内容的情况，但相对比较复杂。

以下是一种方法：

1. 在 C1 单元格输入公式=IF(COUNTIF(B:B,A1)>0,"重复","")，将其向下填充至与 A 区数据范围一致的行。这个公式判断 A 区中的每个值在 B 区中是否存在，如果存在则标注为 “重复”。
2. 在 D1 单元格输入公式=IF(COUNTIF(A:A,B1)>0,"重复","")，将其向下填充至与 B 区数据范围一致的行。这个公式判断 B 区中的每个值在 A 区中是否存在，如果存在则标注为 “重复”。

另一种可以考虑的是使用 VBA（Visual Basic for Applications）编写代码来实现，不过这需要一定的编程基础。

        3、问了一些，比如说你发现了Bug后应该怎么做？我回答后又问我，如果这个时候开发跟你说，你说的这个Bug没问题怎么办？

我回答的比较笼统，搜寻来了一些详细的来，大家可以结合实际情况回答。

当发现 Bug 后，可以按照以下步骤进行操作：

（一）确认 Bug

1. 仔细复现问题：多次尝试相同的操作步骤，确保 Bug 不是偶然出现的。
2. 检查环境因素：确认 Bug 不是由于特定的环境设置、网络问题或其他外部因素引起的误报。
3. 对比正常情况：与预期的正确行为进行比较，确定问题确实存在。

（二）记录 Bug

1. 详细描述问题：包括出现问题的操作步骤、输入数据、预期结果和实际结果等。描述要清晰、准确，以便开发人员能够快速理解问题。
2. 截取相关截图或录制视频：如果可能，提供直观的证据，帮助开发人员更好地定位问题。
3. 记录环境信息：如操作系统、浏览器版本、软件版本等，这些信息对于复现和解决问题很重要。

（三）提交 Bug

1. 使用合适的缺陷管理工具：将记录的 Bug 提交到团队使用的缺陷管理系统中，确保信息完整且易于查找。
2. 设置优先级和严重程度：根据 Bug 对系统的影响程度和紧急程度，合理设置优先级和严重程度级别。

（四）跟踪 Bug

1. 关注开发人员的处理进度：及时了解 Bug 是否被分配、正在修复中还是已解决。
2. 协助开发人员复现问题：如果需要，提供更多的信息或协助开发人员复现问题，以加快问题的解决速度。
3. 进行回归测试：当开发人员修复 Bug 后，进行回归测试，确保问题确实得到解决，并且没有引入新的问题。

如果开发人员说这个 Bug 没问题，可以采取以下步骤：

（一）再次确认问题

1. 重新复现 Bug：确保自己的操作步骤准确无误，再次确认问题确实存在。
2. 检查环境一致性：确认与开发人员的测试环境是否一致，可能存在环境差异导致问题表现不同。
3. 对比不同场景：尝试在不同的场景下复现问题，看是否存在特定条件下才会出现的情况。

（二）与开发人员沟通

1. 清晰阐述问题：以客观、专业的态度向开发人员详细描述 Bug 的出现过程、现象以及对业务的影响。
2. 提供证据支持：如截图、视频、日志等，让开发人员更直观地了解问题。
3. 讨论可能的原因：一起分析问题可能的原因，从不同的角度探讨是否存在误解或遗漏的地方。

（三）引入第三方协助

1. 请测试团队其他成员复现：如果有其他测试人员，可以请他们尝试复现问题，以确认是否是个例。
2. 找相关业务人员确认：如果 Bug 涉及到特定的业务流程，可以请熟悉业务的人员确认问题的真实性。
3. 请上级或技术负责人介入：如果与开发人员无法达成一致，可以向上级或技术负责人汇报情况，请求他们进行协调和决策。

（四）持续跟进

1. 保持关注：即使当前问题处于争议状态，也要持续关注该问题，以防在后续的测试中出现新的证据或情况变化。
2. 记录沟通结果：将与开发人员的沟通内容、采取的措施以及各方的观点记录下来，以便后续查阅和追溯。

        4、这里说一下，每次最后面试官问“那你这边还有什么问题吗？”，我就有点不知道问什么。大家可以参考以下：

在这个时候，可以提出一些有价值的问题，既可以展现你对这个职位的兴趣和认真态度，也可以帮助你更好地了解公司和岗位。以下是一些建议的问题：

（一）关于团队和工作环境

1. “我想了解一下测试团队的规模和结构是怎样的？团队成员之间的协作方式是怎样的呢？”
   • 这个问题可以让你了解团队的组成和工作氛围，判断自己是否能够适应团队合作。
2. “公司对于测试人员的职业发展有哪些规划和支持呢？”
   • 表现出你对自身职业发展的关注，同时也可以了解公司是否重视员工的成长。
3. “在工作中，测试人员与开发人员、产品经理等其他部门的沟通协作频率高吗？具体的沟通机制是怎样的呢？”
   • 了解跨部门协作的情况，对于未来的工作协调有重要意义。

（二）关于项目和技术

1. “公司目前正在进行的项目中，测试工作面临的主要挑战是什么呢？”
   • 展示你对项目的思考和解决问题的能力。
2. “公司在软件测试方面采用了哪些先进的技术和工具呢？未来有计划引入新的技术吗？”
   • 体现你对技术的关注和学习热情。
3. “对于这个岗位，公司期望测试人员在哪些方面能够做出突出贡献呢？”
   • 明确岗位的重点和期望，以便你在未来的工作中更好地发挥自己的优势。

（三）关于公司文化和福利

1. “公司的企业文化是什么样的呢？有哪些具体的体现呢？”
   • 了解公司的价值观和文化氛围，判断是否与自己的理念相符。
2. “公司有哪些福利政策呢？例如培训机会、健康保险、带薪休假等。”
   • 关注自身的权益和福利，同时也可以看出公司对员工的关怀程度。

        5、最后说一点，这里面试官问了我项目的需求分析讨论是怎么做的，因为项目也是课程设计的项目，我回答的也很笼统。回答完后面试官说，需求分析在项目中一定是非常明确、非常具体的。（我很喜欢这种当场纠正，给出你正确答案，不墨迹不拖延。这家给我从hr到自研项目到面试官给我观感都很好！）

————————————

面试官问的都是一些很具体实际的问题！

我回来了，这两家都还不错，不过目前最心水的还是一周出结果这个。后面这家说周六前给答复，还有轮复试，不过目前这个岗位只缺一个人了。