软件测试经典面试题，助你面试加分

Hi，大家好，进入金九银十，很多小伙伴有被动跳槽的打算，所以更新一些经典的软件测试面试题，希望能帮到大家！

时间紧迫的情况下，如何做好测试工作？

对需求要明确，对需求的优先级也要明确，在项目的过程中就可以少做变更的工作。减少测试的工作量。

由资深测试工程师对测试用例进行设计，并进行用例评审。

用例要重点覆盖主要功能和主要流程，重点关注存在的严重死机或数据严重丢失等BUG。尽量把所有最严重的问题都能找出来。

对以往的BUG进行分析，关注容易出现BUG的模块，例如在程序中有耦合关系的模块等等。

与开发团队合用，督促开发尽快关闭已知BUG，加快BUG的收敛。

开发人员实现的内容要及时充分印证和验证, 比如需求验证、单元自测、结对编程、同行评审、和需求测试人员加强沟通等等

适度的测试工具引入, 鼓励测试人员作一些创新和尝试，在实践中不断借助工具的力量提高效率。

说说你印象最深的bug?

其实，面试官或许并不关心你描述的这个bug是否真的有价值，或有多曲折离奇？他只是：

了解你平时工作中的测试能力, 考察你平时工作中遇到问题是如何定位的.
考察你的表达能力及平时测试工作中如何与团队沟通协作.
也许就是想抛一个问题给你，自己好有时间继续看你的简历。
某BUG，数据精度相关, 比如用户在下单的时候，购物车的结算金额的会出现xx.xxxxxxxxxx这样的金额

你认为测试人员需要具备什么技能和品质？

责任感
沟通能力
耐心
怀疑精神
善于自我总结、自我督促
测试分析（包括测试需求与风险分析）能力
缺陷定位与分析能力
文档总结能力

首先，每个公司有每个公司的测试用例模板，如包括模块、子模块、优先级、前置条件、操作步骤、操作数据、预期结果、用例状态、缺陷严重级、概率、实际测试结果、备注；字体格式以及字体大小；测试用例的设计是按照之前约定的按流程来设计还是按照模块设计；测试用例放置的位置以及执行的先后顺序，上面执行过的测试用例是否可以作为下面测试用例执行的输入数据，也就是说测试数据是否具有连贯性等等，这是我们判断测试用例有效性的首要条件。

再则，查看各个用例对应的各个列的编写是否有效，如操作步骤是否简洁，优先级设置是否合理（当然优先级的设置跟实际项目的版本次数的测试策略也有很大关系），预期结果是否明确，之前查看过好多测试用例的预期结果都很含糊，如修改设置项后点击【保存】，预期结果“保存成功”，我感觉这样的预期结果跟没写一样；我们可以优化为：数据库数据更新与修改设置一致且页面显示与数据库数据保持一致。这样测试用例完成后交给另一个人来测试就能有一个明确的判断标准。

用例格式的评估方法：采用同行用例评审的方式进行。

2)从测试用例的覆盖率分析

①测试用例的总数和颗粒度

好多理论书上写的设计测试用例的原则：用最少的测试用例完成最大的覆盖率。使用合适的测试用例设计方法完成覆盖率的提升，同时用例总数相对较少，那么我们需要做的就是寻找把握这种平衡。

用例评审时我们的判断标准就可以从以下几个方面去把握：颗粒度是否把握得当，用例是否冗余，对应模块使用的测试用例设计方法是否得当（这个没有对错之分，只有好与更好的区别）等等

② 测试用例的覆盖率

对主要功能的覆盖，不管你颗粒度如何，测试用例总数多少，使用什么测试用例设计方法，只有把必须要覆盖的功能覆盖了这整个测试用例才算真正的有效。那么如何判断有没有覆盖到呢？

首先，对比需求说明书，是否覆盖需求上的所有需求点（包括显性和隐性的，当然这个跟测试目的和测试策略也有关系，如进行功能测试还是验证性测试抑或详细测试等等）

再次，让其他测试同事和开发帮忙评审，查看功能检测点是否覆盖到。

软件测试报告应该包含哪些内容?

软件测试报告的组成：

一、概述

包括项目背景、需求分析

二、测试时间、测试环境

三、测试过程

评审记录、测试范围、测试用例

四、功能实现清单。

列出是否已经按照测试计划实现功能

五、缺陷统计

测试缺陷统计；

测试用例执行情况统计

六、测试统计情况

资源统计

执行情况

问题统计

问题列表

遗留的问题

七、测试总结

测试结论；（是否通过）

测试内容、测试用例的覆盖程度、bug的解决程度

八、测试风险

软件测试如何保证软件质量的？

需求文档质量: 需求描述详尽,无缺漏，无歧义，无重复，没有无法实现的，没有巨大风险
需求指标明确：前提条件明确，数据指标精确。

优质的框架设计：根据项目的实际情况选择合适的技术栈，底层设计容错性高、健壮性好、可扩展性好，前端兼容性好、性能好

编码规范：参考阿里巴巴的 java 编码规范制定

代码走查：开发人员自己或者结对进行代码走查，考虑逻辑是否完备，数据处理是否到位，场景是否缺漏，算法性能是否最优

代码评审：评价代码是否还有改进的空间等

单元测试：开发人员自行编写单元测试，测试函数方法是否满足要求，随着代码版本的迭代，能否保持原来的功能

测试用例质量
良好的用例设计方法：等价类划分、因果图法、场景分析法、正交分析法、路径覆盖、逻辑覆盖、语句覆盖

用例评审：保证测试的广度（界面、接口、数据库、日志）和深度（测试要点的精细程度）

测试用例维护：测试过程中补全缺漏的和思路有问题的用例，记录线上故障并添加到测试用例中缺陷质量

缺陷记录：bug 管理系统，bug 的生命周期理论

缺陷反思：bug 评审，开发避免类似错误，测试在设计测试用例的时候考虑类似

风险控制
项目风险：需求变动，开发环境不能满足，人员缺失，技术自身风险，安全风险

风险预测：根据项目实际情况和自身的软件开发经验，找到薄弱环节和不确定的环节，这些往往都是风险高发处

组织技术学习提升团队的技术水平，也能够提升软件产品的质量

一个缺陷一般包含哪些内容?

bug编号；

bug严重级别，优先级；

bug产生的模块；

bug摘要，阐述bug大体的内容；

bug对应的版本；

bug详细现象描述、测试场景，包括一些截图等；

bug出现时的测试环境，产生的条件即对应操作步骤。

当开发人员说不是BUG时，你如何应付？

一、是需求不确定，所以可以参考需求规格说明书或者找来产品经理进行确认，是否需要改动。

二、是开发人员认同是问题但觉得不用修改的bug，这时要尽可能的说出是BUG的依据是什么?如果被用户发现或出了问题，会有什么不良结果?程序员可能会给你很多理由，你可以对他的解释进行反驳。如果还是不行，那我可以把这个问题记录在缺陷管理工具上,跟开发经理和测试经理进行确认,由领导决策。

三、可能是测试人员误操作原因导致的，也有可能是环境因素、数据问题导致的，只要找到原因并协商确认不是bug即可。

四、可能是复现率低的问题，如果这个bug不影响用户使用，先记录下来并一直跟进，并且随时监控线上用户使用情况；如果这个bug影响用户使用，要极力的推动修改的，无非是根据项目紧急程度来决定什么时候修改。

五、是建议优化类的问题，如果产品人员、开发人员等觉得不修改没有太大影响的可以不修改。

如果确定是bug的话，一定要坚持自己的立场，让问题得到最后的确认。

如何测试一个一次性纸杯?

需求测试：查看杯子使用说明书
界面测试：查看杯子外观
功能度：用水杯装水看漏不漏；水能不能被喝到
安全性：杯子有没有毒或细菌
抗破坏性：杯子从不同高度落下的损坏程度
可移植性：杯子再不同的地方、温度等环境下是否都可以正常使用
兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等
易用性：杯子是否烫手、是否有防滑措施、是否方便饮用
用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述
疲劳测试：将杯子盛上水放24小时检查泄漏时间和情况；盛上汽油放24小时检查泄漏时间和情况等
压力测试：用根针并在针上面不断加重量，看压强多大时会穿透
跌落测试：杯子加包装(有填充物),在多高的情况摔下不破损
震动测试：杯子加包装(有填充物),检查产品是否能应对恶劣的铁路\公路\航空运输

以上就是今天的全部内容，希望对大家有所帮助！！

最后分享一下我整理的软件测试面试宝典，有需要的朋友可以文末卡片直接拿走

包括测试理论、Linux基础、MySQL基础、Web测试、接口测试、App测试、管理工具、Python基础、Selenium相关、性能测试、LordRunner相关等

通过大数据总结发现，其实软件测试岗的面试都是差不多的。常问的有下面这几块知识点：