一、测试用例相关

1、你是怎么设计测试用例的（或是问测试用例是怎么写的）？

（1）根据需求文档，深挖需求文档中的细节进行用例设计
（2）根据自己的测试经验和一些常识补充用例
（3）参考同事曾写过的用例或网上的资料进行一些用例补充

2、测试用例包括哪些元素（或测试用例包括哪些字段，或测试用例包括哪些属性）？

测试序号、测试模块、测试环境、前置条件、操作步骤和数据、预期结果、实际结果、是否通过、备注

3、测试用例有哪些设计方法，每个方法的概念是什么，每种方法可否举个例子？

（1）等价类划分法：把所有可能输入的数据划分为若干个区域，然后从每个区域中取少数有代表性的数据进行测试即可。有效等价类、无效等价类
（2）边界值分析法：输入条件是一个取值范围，对取值范围的边界进行边界值测试；输入条件中规定输入数据是一个有序集合，对有序集合的边界进行边界值测试。
（3）错误推测法：根据经验的补充，如超长混合字符串，全角字符串、数字“0”及单引号
（4）正交表分析法：多个输入框组合的情况，可以借助正交设计助手小工具，有效减少用例设计个数
（5）因果判定法：

• 明确所有的输入条件
• 明确所有的输出结果
• 明确哪些条件可以组合在一起，哪些条件不能组合在一起
• 明确什么样的输入条件可组合产生哪些输出结果
• 通过判定表展示输入条件的组合和输出结果的对应关系
• 根据判定表设计测试用例

4、测试用例是如何进行评审的？

（1）测试用例是否依据需求文档进行编写
（2）测试用例中的执行步骤、输入数据是否清晰、简洁、正确；对于重复度高的执行步骤，是否进行了简化
（3）每个测试用例是否有明确的预期结果
（4）测试用例中是否有多余的用例
（5）测试用例中是否覆盖了需求文档的所有功能点，是否有遗漏

5、如何保证测试用例的质量（或什么样的用例才称得上是一个好的用例）？

（1）要确保测试用例是针对需求文档编写的，确保测试点能覆盖所有的需求点
（2）保证操作步骤、具体数据、预期结果的清晰性、简洁性、明确性，以确保测试用例的可操作性和可复用性
（3）确保有足够多的异常测试用例，同时要确保没有多余的重复用例
（4）对测试用例进行评审

6、如果没有需求文档，直接给你待测软件，你将如何开展测试工作？

（1）大致体验一下软件，对于如边界值、输入数据类型不明确的问题集中反馈给产品经理，待产品经理给出相应的标准后再设计用例。
（2）对于测试 软件的过程中，发现有些模块功能不明确影响用户正常使用的地方，会及时反馈给测试经理，协助解决这类问题
（3）会积极参与项目的各种讨论会议；查看已有的测试用例、bug库中已有的bug、已有的用户手册和帮助文档，咨询产品人员并尽可能多的了解相关需求信息，并以此为基础设计测试用例
（4）参考软件功能，直接设计用例，然后提交给测试组（必要情况下可以提交给整个项目组）进行评审，得到统一意见。

7、请设计ATM取款机的测试用例（或者是请设计ATM取款机的测试点）

（1）根据常识想象出ATM机的功能点：插卡、退卡、输入密码、修改密码、余额查询、取钱、存钱、转账等
（2）根据自己的操作经验，分别制定每个功能点的需求文档。

• 插卡功能的需求文档：只接受带有银联标识的银行卡；
• 退卡功能的需求文档：机子中必须有一张银行卡；
• 密码修改的需求文档：只允许输入6位数的密码；
• 取款规格：一次最多可取5000元
  （3）根据需求文档设计用例

二、bug相关

1、如何确定bug是前端的还是后端的

（1）根据经验判断，像页面显示，布局，兼容性问题都是前端的问题
（2）查后端服务日志，如果日志没有记录，很可能是接口没有调用成功，有可能是这个功能没有与后端进行交互，也就不存在后端的问题。如果有日志输出可以查一下日志信息，进一步分析
（3）如果是前端显示的数据有误，可以查接口，如果接口返回的实际没有问题，就是前端的问题，如果接口返回数据有问题，前端显示的与后端一致，就是后端的问题
（4）查看状态码，404可能是前端传参错误或后台接口改了，500是后端的问题

2、一个完整的Bug包括哪些内容？

（1）bug概述
（2）bug具体描述
（3）bug的严重程度：致命问题、严重问题、一般问题、
（4）bug的处理优先级：立即处理、高优先级处理、排队处理、低优先级处理
（5）bug的指派人
（6）bug的状态
（7）附件截图或日志
（8）其他信息点

3、Bug的处理流程是怎样的？

通常要对修复好的产品进行多轮测试，回归测试，因为即使之前的bug修复好了，在下一轮测试中还有可能发现新bug
（1）回归测试时执行全部用例
（2）选择重要功能点、常用功能点、与bug关联的功能点进行测试
（3）选择性执行关键功能点的测试用例
（4）仅测出现bug的功能点

4、如何提交一个高质量的Bug？

（1）测试的版本号和测试环境要描述清楚
（2）bug概要：通过bug概要让项目组其他成员知道这个bug单描述的是什么问题
（3）bug具体描述：也就是bug的重现步骤，bug记录的细节越详细越好，包括出错前后执行的操作步骤，涉及的具体数据等
（4）附上相应的截图和日志，特别是截图能为bug提供有力的说明

5、如果你发现的这个Bug的操作步骤在测试用例中没有提到，你怎么处理？

把发现的这个bug操作步骤补充到测试用例中，以便下一次测试的时候能够注意到这个问题

6、如果你和开发人员对Bug发生了争议，你怎么处理？

（1）检查是否是因为bug描述不清楚，造成对bug的争议，确保bug单清晰明确，描述清楚，并且有截图或日志。
（2）如果bug单写清楚了。就要以心平气和的心态和开发人员进行沟通，说明bug对产品的不良影响
（3）如果沟通后还是不愿意修改的话，可以向测试经理反馈这一情况，由测试经理出面解决，或召开三方会议共同商讨定夺。
（4）作为测试人员，一定要坚定自己的立场原则，以产品为出发点，不能经开发的解释后就放弃自己的观点，认为自己找到的不是bug了。

7、如果你发现了一个Bug，但之后再也没法重现，你怎么办？

首先我会截图并搜集日志，保留好测试现场，没有重现可能是因为没有触发到bug产生的点，我会想方设法让这个bug重现，如果实在无法重现，会提交bug、截图和日志给开发人员。如果开发人员要求重现，就后续继续观察，观察到了可以邀请开发来工位进行调试，确定问题；如果最终还是无法重现的话，就把问题反映给测试经理，由测试经理和开发人员进行评审和解决方法，虽然现在没有重现，但不能保证在用户那里不会出现。

8、如果开发人员不修改你发现的Bug，给出的原因是修改的成本比较高，这个Bug只是影响用户体验而已，你怎么办？

首先我觉得凡事影响用户体验的问题都是大问题，如果用户体验不好，会造成大量潜在用户的流逝，对产品的后续发展是非常不利的；其次如果每个问题都因为修改成本高而不去修改的话，就无法提升产品的质量，我认为无论是什么问题，都应该要求开发人员去修改，这是对产品负责，也是对用户负责。

9、你所了解的测试管理工具有哪些，你用的是什么？

之前有用过tapd，也有听说过禅道、TestLink，测试管理工具，主要用于降低产品、开发、测试沟通成本，可以根据公司的具体情况进行使用，应该都差不多，能够很快上手

10、一个软件版本，你们一般要测试多长时间？

一个软件版本一般要测三到五轮，每一轮测试的时间不能确定，受需求规模、测试人员、测试技术、软件质量等多方面因素影响，要视具体的情况确定

三、测试工作相关

1、一份测试报告包含哪些内容？

（1）编写目的
（2）模块功能描述
（3）测试过程：测试时间、地点、人员、版本
（4）测试环境
（5）测试功能点的范围
（6）测试执行结果
（7）风险评估
（8）测试结论
（9）附件

2、软件测试工作结束的标准是什么？

（1）按照测试计划安排完成了所有测试工作
（2）测试用例全部完成，执行通过率达到标准
（3）每个测试人员手上的bug处于关闭状态
（4）回归测试全部执行完毕，没有发现影响产品上线的bug，软件产品达到了上线标准
（5）每个测试人员负责的测试报告已完成，并提交给了测试经理

3、软件的测试流程是怎么样的？

需求评审，测试计划的制定、测试用例的设计、用例评审、测试环境搭建、测试执行（提交BUG、回归测试）、撰写测试报告

4、软件测试是在什么阶段介入的？

对于功能测试人员，是在系统测试时介入的

5、你如何理解测试这份工作

首先测试工作是产品诞生过程中必不可少的环节，对产品质量有明显的改善作用；其次测试能对开发工作起到一定的监督和推动作用，能够加快软件开发周期，加快软件发布的进程

6、如果我们录取了你，你将如何更快地进入工作状态？

首先熟悉项目组成员，包括开发、测试、产品。其次我会从熟悉需求文档开始，依次熟悉测试组的测试用例、bug管理工具以及bug库中已提交的bug。最后我会想测试组的老同事或我的导师请教测试组的基本工作流程等细节问题，并结合测试经理分配的任务，通过这些任务熟悉整个测试流程和工作要点。

7、软件测试能否发现所有的Bug？

受测试时间、测试人员数量、测试人员技术等方面的因素影响，无法发现所有bug。有些bug是需要在特殊环境下长期使用才会发现的。一般情况下，在交付用户后都不应该有影响用户使用和体验的bug出现，万一在用户使用过程中发现了bug，应该迅速打补丁或升级软件。