软件测试功能测试+自动化测试面试题（含答案）_功能测试面试题(2)

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化的资料的朋友，可以戳这里获取

1测试策略

相似问法：测试包括哪些？测试要涵盖哪些方面？

功能：各个功能是否完善 性能：确定系统的性能级别和承受压力的能力（负载测试、并发测试、峰值测试、稳定性测试…) 安全性 兼容性 可靠性 易用性 安全卸载 UI

**2.用例要素是什么

相似问法：用例里面包含什么内容？

答：用例编号、模块名称、功能点、用例标题、前置条件、测试步骤、期望结果、优先级、实际结果、备注

**3.为什么写用例

1、理清思路，避免漏测和重复测； 2、提高测试效率； 3、跟进测试进度； 4、更好的发现问题，记录问题，复现问题； 5、跟进重复性工作； 6、告诉领导：我做过； 7、接口测试流程中的一个产物（测试用例） 　　上面7点，有用例，自己心中有数，不用一个测试点重复测好多次，也避免漏测。

**4.设计测试用例有哪些方法

我是用等价类、边界值、错误推测法、场景法等测试用例设计方法来编写测试用例的。 1.等价类分为有效等价类和无效等价类，符合需求的就是有效等价类，不符合需求的就是无效等价类。 2.因为大量错误都是发生在输入和输出的边界上，而不是发生在输入输出范围的内部，所以就有了边界值分析法，边界值是选取正好等于、刚刚大于和刚刚小于边界的值，它一般是跟等价类一起用的。 举个例子：设置密码要求是6-12位的数字和字母的组合，那有效等价类就是长度在6-12之间，数字和字母的组合；无效等价类就是长度小于6（取5）的数字字母组合，长度大于12（取13）的数字字母组合，长度在6-12之间的纯数字，长度在6-12之间的纯字母，长度在6-12之间的除了数字和字母以外的字符，等等。 3.错误推测法是指凭借经验推测程序可能出现的错误，比如新建和修改的名称要唯一，不唯一的话没办法提交成功。 4.场景法是根据业务流程来写的，有基本流和备选流，然后考虑异常流情况下是否出现bug。比如一个商品加入购物车、提交订单后超时不支付，会出现什么情况。

**5.写测试用例的思路

首先要熟悉熟悉需求文档，不要着急下手，先理清楚“项目是怎么使用的”、“是给谁用的”、“干什么用的”，然后根据业务流程来写，提取功能点，再根据等价类、边界值、错误推测法、场景法进行测试用例的编写，在Excel表格中填写。 功能点的话，每个系统的模块中都有一些共有的功能，比如：增删改查等，所以在测试中我们要先把这些功能过一遍。 先走正常流，正常流通过之后，再对异常情况进行测试。 另外，熟悉业务流程是非常重要的，模块与模块、功能和功能之间是相互联系的，不能只是单独测它的功能正不正常，还要把他们的关系全部走通。比如我测的电商系统中，要先添加商户、品牌和分类，然后才能添加商品。 需求分析===》提取功能点（测试点）==》测试用例编写

**66.常见测试关注点

登录：

1、账号框：正确、错误（错误、中文、特殊字符、超长）、空 2、密码框；正确、错误（错误、中文、特殊字符、超长）、空、密文显示并且不能复制粘贴、是否区分大小写、请求加密 3、用户未注册 4、用户已注销，再次登录 5、验证码：有效时间、输入错误、过期、是否容易识别、点图片是否更换验证码 6、用户名、密码输入“sql注入攻击”字符串 7、账号是否互斥 输入正确的用户名和密码登录成功； 用户名正确，密码错误，是否提示输入密码错误； 用户名错误，密码正常，是否提示输入用户名错误； 用户名和密码都错误，是否有相应提示； 用户名密码为空时，是否有相应提示； 如果用户未注册，提示请先注册，然后进行登录； 已经注销的用户登录失败，提示信息友好； 密码框是否加密显示，并且不能复制粘贴； 用户名是否支持中文、特殊字符；用户名是否有长度限制； 密码是否支持中文，特殊字符；密码是否有长度限制； 密码是否区分大小写；密码为一些简单常用字符串时，是否提示修改； 密码存储方式，是否加密；登录功能是否需要输入验证码； 验证码的有效时间； 验证码输入错误，登录失败，提示信息是否友好； 输入过期的验证能否登录成功； 验证码是否容易识别；验证码换一张功能是否可用； 点击验证码图片是否可以更换验证码； 用户名和密码的输入框中分别输入典型的“SQL 注入攻击”字符串，验证系统的返回页面；同一用户先后在多台终端的浏览器上登录，验证登录是否具有互斥性。

新建：

必填项要有红色的*号提示 正确输入所有字段的信息，点击提交； 只输入必填字段，点击提交； 不输入必填字段，点击提交； 不输入任何信息，点击提交； 输入各字段信息，点击取消； 输入字符串长度不符合规定的字符串长度，点击提交； 输入不符合规定的字符类型，点击提交； 输入重复的数据，点击提交； 新增内容前后加空格，检查是否有去空格处理； 新增之后，列表默认倒序； 点击输入框的关闭图标。

查询：

不输入任何条件； 进入页面般显示全部； 输入部分有效条件查询； 输入全部有效条件查询； 输入无效条件查询； 输入条件，点击重置； 前后输入空格，要有去空格处理； 输入条件，点击查询后，查询输入不清空；

删除：

单选数据，点击删除，弹出删除提示，点击确定； 单选数据，点击删除，弹出删除提示，点击取消； 多选数据，点击删除，弹出删除提示，点击确定； 多选数据，点击删除，弹出删除提示，点击取消； 不选择任何数据，直接点击删除； 确认是逻辑删还是物理删，逻辑删只是把状态改变，数据库还是有的，物理删是从数据库中删除了，数据库中没有的相应的信息；删除后添加一样的数据。

**7.如何保证测试用例的质量

1.测试用例的需求覆盖率是100%； 2.测试用例的可执行； 3.测试用例的可读性； 4.测试用例的评审； 5.及时的维护测试用例，也许一个功能的变更，或者场景的添加，就需要考虑更多的情况，保证测试用例的完整性。

**8.测试用例是根据什么写的

主要还是根据需求文档来写的，有疑问的地方我会及时问产品经理

**9.之前用什么写测试用例

我们是根据需求文档提取测试点，然后根据等价类、边界值、错误推测法、场景法来编写测试用例，用excel表格来写测试用例的，发现bug后用禅道提交bug，指派给对应的开发。

***10.***没有需求文档怎么开展测试工作

1.问：没有需求文档，但是有需求，也就有需求提出者。可以与需求人员进行沟通。 2.问：只要懂需求的人，我们都可以问。也可以问开发，项目经理，测试经理等。 3.分析：结合一些业务资料和百度等进行分析 4.对比：对比竞争对手产品，分析得到合适的需求 5.经验：可以借助原来的经验 6.合理：一切的需求都要符合常理

**11.软件开发过程的常见模型

1、瀑布模型：线形的、顺序的软件开发模型 2、V模型： 需求分析、概要设计、详细设计、编码、 单元测试、集成测试、系统测试、验收测试 3、W模型：测试和开发同步进行，可以尽早发现问题 需求分析、需求测试 概要设计、概要设计测试 详细设计、详细设计测试 编码实现、单元测试 模块集成、集成测试 系统构建、系统测试 系统安装、验收测试

**12.软件上线标准

所有测试用例执行完毕，所有的bug都回归测试完毕，当然如果遗留的一些小的优化性的问题，可以汇报给产品经理、项目经理，决定是否上线； 然后产品经理进行验收后，就可以上线了。

**13.单元、集成、系统、验收测试

1、单元测试属于白盒测试，是对代码中的函数和方法进行测试； 2、集成测试属于灰盒测试，也可以称作接口测试，测试对象是模块之间、子系统之间的接口 3、系统测试是对整个系统进行测试，属于黑盒测试 4、验收测试分为a验收和贝塔验收，a验收是在开发者环境下进行测试，贝塔验收是在真实环境下由真实用户体验，有问题再反馈给开发人员 补充：α测试的关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作并尽最大努力涵盖所有可能的用户操作方式。

**14.软件测试的风险

进度风险、质量风险、人员风险、变更风险、成本风险

**15.测试报告有哪些内容

相似问法：你写过测试报告吗？

写过，不过我们写的都是我们自己负责模块的测试报告，整个系统的测试报告由测试经理完成。 一般的话会对项目背景做一个阐述。 1、测试内容：测试内容的大纲。 2、测试环境：测试环境的描述，包括客户端和网络环境。 3、测试工具：测试过程中的测试资源使用。测试的数据：bug数，解决数，遗留数。 4、模块bug分布，bug走势图，缺陷遗留，需要说明的问题。 5、测试数据分析：对于整个过程测试的一个分析，得出结论。 6、遗留问题：对于软件遗留问题有详细说明。 主要就是内容简洁、不罗列详细数据、挑拣一些能说明问题分析数据的：比如缺陷走势图，模块的bug分布等等，突出重点遗留问题，然后得出分析测试结论。

**16.回归测试策略

历史用例（上一个版本的用例）在先版本怎么回归？

回归测试常用的策略有：全面回归测试、选择性回归测试等 像我们一般会进行三轮的测试，第一轮把功能都过一遍，提bug；第二轮做一个全面的回归测试；看具体的情况，第三轮会进行选择性的回归测试，把出现bug的相关模块都测一遍。 1、全面回归测试：所有的测试用例都重新测一遍 2、选择性回归测试：对于出现问题的bug进行验证，没有问题的bug就不进行测试 3、自动化工具回归测试：使用自动化测试工具进行回归测试

**17.提了一个bug，开发不认怎么办

1、首先从我自身找问题，再根据需求文档分析这是不是一个bug，如果确定是bug； 2、再看看测试用例的操作步骤写的够不够详细、可执行性强不强； 3、如果不是以上原因，那就跟开发沟通，可以在开发的电脑上实现给他看，然后跟他好好解释，如果这真是一个bug，开发是不会不认的； 4、如果还是不认，那就要上报给上级，然后开会进行讨论

**18.什么bug是一个好的bug

1、确定与需求不符 2、bug的复现步骤要详细，可读性可执行性强，能够再次复现出来

自动化测试题

写在前面
公司要求招一名自动化测试，能力要求不高，1年左右自动化经验+部分性能经验即可，让我出一份题，我就百度+公司项目遇到的问题，出了一份，出题整体思路是：接口自动化问题+性能问题+规划的ui、app自动化+整体质量体系建设等多方面考虑。下面是正题

岗位JD

| 1、【技术能力】能独立完成产品线中自动化测试工作，根据测试任务，搭建软件测试环境，编写测试脚本，输出报告；
2、【项目管理】熟练开发测试工具、测试脚本，及迭代优化测试框架，使用合理方式进行自动化管理项目；
3、【业务推动】对测试项目的结果负责，使用合理方式推动业务端测试的效率、开发质量；
4、【规范制定】 熟悉CI系统，完善准入/准出标准，持续提升测试效率；
5、【效率提升】根据业务特点，引入新的测试方法和工具，探索新技术。改进测试工具或测试方法，提高效率，培训测试人员并支持技术难题解决 | |

|-1）3年以上测试工作经验，1年以上自动化测试经验或开发经验；
2）至少熟悉一种脚本语言，如Shell、Python、java等；
3）至少熟悉一种测试框架，unittest、pytest、testng等；可独立完成复杂逻辑的接口自动化测试；
4）熟悉appium、selenium可独立完成android和ios的UI自动化测试；
5）熟悉jenkins、svn、git的搭建和使用；
6）熟悉常用性能测试工具的使用，并可进行分析调优：ab、jmeter、loadrunner、locust等，有分布式压测经验优先；
7）熟悉使用django开发框架，可完成web页面和功能的开发（此条可放宽）；
8）具备丰富的系统测试经验，并且能够进行系统级的原因定位与分析；
9）具备较强的计划、组织、协调、沟通及分析能力，优秀的职业素养和团队协作精神、敬业精神，能承受工作压力；
10）学习能力强，对技术有着特别的渴求，在关注的领域有着深入的研究，并不断创新；具备较强的技术培训能力和领导能力-|–|

自动化测试面试题1:基础篇

一、前言

最近有童鞋和我抱怨，说网上很难搜到那些全面又合适的自动化测试面试题，这里根据我个人的经验以及收集整理的：

你没看错，不慌，慢慢来。

先从什么是自动化测试开始说起哈！

二、什么是自动化测试？

什么是自动化测试？

当我第一次知道自动化测试的时候，除了知道“自动化”这三个有些高大上的称呼之外，我对自动化测试一无所知，正如谈恋爱一样，找女朋友之前要知道她是谁。

自动测试就是把以人为驱动的测试转化为机器执行的一种过程，它是一种以程序测试程序的过程。嗦嘎！那么…

三、自动化测试常见面试题

1、你会封装自动化测试框架吗？

这个问得最多，甚至有很多公司直接写在招聘要求中！

当然可以，自动化框架主要的核心框架就是分层+PO模式：分别为：基础封装层BasePage，PO页面对象层，TestCase测试用例层。然后再加上日志处理模块，ini配置文件读取模块，unittest+ddt数据驱动模块，jenkins持续集成模式组成。

2、如何把自动化测试在公司中实施并推广起来的？

1.项目组调研选择自动化工具并开会演示demo案例，我们主要是演示selenium和robotframework两种。

2.搭建自动化测试框架，在项目中逐步开展自动化。

3.把该项目的自动化流程、框架固化成文档

4.推广到公司的其它项目组应用

3、请描述一下自动化测试流程？

1.编写自动化测试计划

2.设计自动化测试用例

3.编写自动化测试框架和脚本

4.调试并维护脚本

5.无人值守测试

6.后期脚本维护（添加用例、开发更新版本）

4、自动化测试用例如何编写？以下答案二选一即可：

1.用例是自动化测试工程师自己设计的，一般刚开始已基本业务流程为主（登录–完成一个业务–退出）

2.从系统测试用例中进行筛选或由业务工程师提供

5、上一个项目中自动化测试的执行策略？

上一个项目中是定时执行的，设置的执行时间是晚上12点，执行完毕后会自动发送邮件通知

6、自动化测试发现BUG多吗？

不多，因为之前项目组是把已经测试通过的基本功能再进行自动化脚本编写和在后续版本执行自动化测试，它主要是保证已经测试通过的功能在新版本更新后没有问题。

7、你觉得自动化测试的价值在哪里？你们公司为什么要做自动化测试？

引用自动化测试之后，能代替大量繁琐的回归测试工作，把业务测试人员解放出来，既而让业务测试人员把精力集中在复杂的业务功能模块上，自动化测试一般是对稳定下来的功能进行自动化，保证不会因为产品的更新导致之前稳定下来的功能出现BUG

8、自动化测试有误报过bug吗？产生误报怎么办？

有误报过，有时候自动化测试报告中显示发现了bug,实际去通过手工测试去确认又不存在该bug。

误报原因一般是：

1.元素定位不稳定，需要尽量提高脚本的稳定性；

2.开发更新了页面但是测试没有及时更新维护!

9、自动化测试过程中，你遇到了哪些问题，是如何解决的？

1.频繁地变更页面，经常要修改页面对象类里面的代码

2.自动化测试偶尔出现过误报

3.自动化测试结果出现覆盖的情况：Jenkins根据时间建立文件夹

4.自动化测试代码维护比较麻烦

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化的资料的朋友，可以戳这里获取

]
[外链图片转存中…(img-LbLoXKSJ-1715545322427)]
[外链图片转存中…(img-hjhmUkP1-1715545322428)]

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化的资料的朋友，可以戳这里获取