本文5088字，阅读约需13分钟

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

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

1. 对需求要明确，对需求的优先级也要明确，在项目的过程中就可以少做变更的工作。减少测试的工作量。
2. 由资深测试工程师对测试用例进行设计，并进行用例评审。
3. 用例要重点覆盖主要功能和主要流程，重点关注存在的严重死机或数据严重丢失等BUG。尽量把所有最严重的问题都能找出来。
4. 对以往的BUG进行分析，关注容易出现BUG的模块，例如在程序中有耦合关系的模块等等。
5. 与开发团队合用，督促开发尽快关闭已知BUG，加快BUG的收敛。
6. 开发人员实现的内容要及时充分印证和验证, 比如需求验证、单元自测、结对编程、同行评审、和需求测试人员加强沟通等等
7. 适度的测试工具引入, 鼓励测试人员作一些创新和尝试，在实践中不断借助工具的力量提高效率。

二、说说你印象最深的bug?

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

• 了解你平时工作中的测试能力, 考察你平时工作中遇到问题是如何定位的.
• 考察你的表达能力及平时测试工作中如何与团队沟通协作.
• 也许就是想抛一个问题给你，自己好有时间继续看你的简历。

某BUG，数据精度相关, 比如用户在下单的时候，购物车的结算金额的会出现xx.xxxxxxxxxx这样的金额

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

• 责任感

• 沟通能力

• 耐心

• 怀疑精神

• 善于自我总结、自我督促

• 测试分析（包括测试需求与风险分析）能力

• 缺陷定位与分析能力

• 文档总结能力

四、如何评估测试用例的有效性?

1)从测试用例的形式分析

• 首先，每个公司有每个公司的测试用例模板，如包括模块、子模块、优先级、前置条件、操作步骤、操作数据、预期结果、用例状态、缺陷严重级、概率、实际测试结果、备注；字体格式以及字体大小；测试用例的设计是按照之前约定的按流程来设计还是按照模块设计；测试用例放置的位置以及执行的先后顺序，上面执行过的测试用例是否可以作为下面测试用例执行的输入数据，也就是说测试数据是否具有连贯性等等，这是我们判断测试用例有效性的首要条件。
• 再则，查看各个用例对应的各个列的编写是否有效，如操作步骤是否简洁，优先级设置是否合理（当然优先级的设置跟实际项目的版本次数的测试策略也有很大关系），预期结果是否明确，之前查看过好多测试用例的预期结果都很含糊，如修改设置项后点击【保存】，预期结果“保存成功”，我感觉这样的预期结果跟没写一样；我们可以优化为：数据库数据更新与修改设置一致且页面显示与数据库数据保持一致。这样测试用例完成后交给另一个人来测试就能有一个明确的判断标准。
• 用例格式的评估方法：采用同行用例评审的方式进行。

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

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

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

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

② 测试用例的覆盖率

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

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

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

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

软件测试报告的组成：

一、概述

包括项目背景、需求分析

二、测试时间、测试环境

三、测试过程

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

四、功能实现清单。

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

五、缺陷统计

测试缺陷统计；

测试用例执行情况统计

六、测试统计情况

资源统计

执行情况

问题统计

问题列表

遗留的问题

七、测试总结

测试结论；（是否通过）

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

八、测试风险

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

• 需求文档质量: 需求描述详尽,无缺漏，无歧义，无重复，没有无法实现的，没有巨大风险

• 需求指标明确：前提条件明确，数据指标精确。
• 优质的框架设计：根据项目的实际情况选择合适的技术栈，底层设计容错性高、健壮性好、可扩展性好，前端兼容性好、性能好
• 编码规范：参考阿里巴巴的 java 编码规范制定
• 代码走查：开发人员自己或者结对进行代码走查，考虑逻辑是否完备，数据处理是否到位，场景是否缺漏，算法性能是否最优
• 代码评审：评价代码是否还有改进的空间等
• 单元测试：开发人员自行编写单元测试，测试函数方法是否满足要求，随着代码版本的迭代，能否保持原来的功能

测试用例质量

• 良好的用例设计方法：等价类划分、因果图法、场景分析法、正交分析法、路径覆盖、逻辑覆盖、语句覆盖
• 用例评审：保证测试的广度（界面、接口、数据库、日志）和深度（测试要点的精细程度）
• 测试用例维护：测试过程中补全缺漏的和思路有问题的用例，记录线上故障并添加到测试用例中缺陷质量
• 缺陷记录：bug 管理系统，bug 的生命周期理论
• 缺陷反思：bug 评审，开发避免类似错误，测试在设计测试用例的时候考虑类似

风险控制

• 项目风险：需求变动，开发环境不能满足，人员缺失，技术自身风险，安全风险
• 风险预测：根据项目实际情况和自身的软件开发经验，找到薄弱环节和不确定的环节，这些往往都是风险高发处

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

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

bug编号；

bug严重级别，优先级；

bug产生的模块；

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

bug对应的版本；

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

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

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

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

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

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

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

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

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

九

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

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

十

登录功能怎么进行测试？

一、界面测试。

查看界面上的所有元素是否齐全；

没有输入内容时，是否有相应的提示语；

验证码是否能够显示；

移动鼠标，【登录】按钮默认不能点击；

【忘记密码】是否有个小问号“？”（其他都有）；

二、功能测试

输入正确的用户名、密码、验证码，点【登录】能登录；

输入正确的用户名、错误的密码、正确的验证码，提示用户名或密码错误；

输入错误的用户名、正确的验证码，提示用户名或密码错误；

输入正确的用户名、密码，错误的验证码，提示验证码错误；

输入不符合规则的手机号或者邮箱应该提示错误；

页面长时间不登录和操作，验证码会不会过期；

点【记住密码】，登录后退出，再次登录是不是可以不输入密码；

点【忘记密码】能够跳转到密码设置页面（至于是什么不用管，就是能不能跳转）

只点击验证码图案，验证码能不能刷新；

页面刷新，验证码图案能不能刷新；

输入栏是否设置快速删除按钮；

用户名和密码是否大小写敏感；

用户名和密码前后有空格的处理；

登录成功，是否有记住密码功能；

登录失败后，不能记录密码的功能；

新用户第一次登录成功，是否有修改密码提示；

用户登录过程中log中是否有个人信息明文打印；

是否支持第三方登录；

刷新页面时是否会刷新验证码；

输入密码的时候，大写键盘开启的时候要有提示信息  ；

不同级别的用户，比如管理员用户和普通用户，登录系统后的权限是否正确；

三、业务安全测试

有没有登录错误次数的限制；

每次登录错误之后有没有限制再次登录的时间间隔；

是否支持一个账号多地登录；

不同机型登录，异地登录是否有提醒  ；

不登录的情况下，在浏览器中直接输入登录后的URL地址，验证是否会重新定向到用户登录界面；

四、兼容性测试

在相同浏览器的不同版本上打开登录页面，效果是否一致；在不同浏览器上打开登录页面，效果是否一致；在不同操作系统的不同浏览器打开登录页面，效果是否一致；在不同的屏幕分辨率下打开登录页面，效果是否一致；

五、代码安全性测试

用户输入登录信息登录时，个人信息是不是会显示在浏览器地址栏；

用户登录的时候，通过抓包工具抓数据，密码是否加密；

查看页面源代码，验证码是否直接显示在代码中；

密码在后台储存时是否加密；

是否可以使用登录的API发送登录请求，并绕开验证码校验；

用户名和密码的输入框中分别输入典型的“SQL注入攻击”字符串，验证系统的返回页面；

用户名和密码的输入框中分别输入典型的“XSS跨站脚本攻击”字符串，验证系统行为是否被篡改；

六、页面性能测试

单用户登录的响应时间是否小于3秒；

通过工具向登录页发起大量请求，查看页面响应时间的变化；

通过工具对登录功能进行并发测试；通过工具向登录页发起大量请求，查看页面何时崩溃；

通过工具向登录页发起大量请求，查看页面崩溃后有没有良好的提示信息；

通过工具向登录页发起大量请求，查看页面崩溃后多长时间能够恢复服务；

弱网，不同网速时登录的时间，网络切换和网络延迟时登录界面是否正常；

七、易用性测试

页面是否美观；

功能是否都可以使用；

页面速度快不快；

页面元素加载是否耗费网络流量；

能不能第三方登录；

为什么不使用手机验证码登录；

输入框能否可以以Tab键切换。

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

以上

That‘s all

更多系列文章

敬请期待