2024最新软件测试【测试理论+ 接口自动化测试】面试题（内附答案）

一、测试理论

3.1 你们原来项目的测试流程是怎么样的?

我们的测试流程主要有三个阶段：需求了解分析、测试准备、测试执行。 

1、需求了解分析阶段 我们的 SE 会把需求文档给我们自己先去了解一到两天这样，之后我们会有一个需求澄清会议， 我们会把不明白不理解的需求在会议上说出来，包含需求的合理性还有需求的可测性等， 产品这边解答，目的是让我们测试这边和开发对需求的理解达到一致。

2、测试准备阶段 会议结束之后我们开始准备测试工作，我们测试这边会写一个测试计划，分配每个人负责的模块， 然后我们就根据自己负责的模块用 xmind(思维导图)进行测试需求分析，分析测试点， 以及编写测试用例，之后我们会在自己的组内先进行评审，评审修改之后还会在我们的项目组评审， 评审完后进行修改测试用例。

3、测试执行阶段 开发人员编写好代码之后，我们会把代码包通过 Jelkins 部署到测试环境提测，进行 SIT 测试， 在正式测试之前我们会先做一个冒烟测试，冒烟测试通过之后我们才转测，在执行测试的过程中， 我们如果发现 bug 就会用 tapd(或者禅道)记录并且提交 bug，也会进行 bug 复测，以及回归测试， 每一轮测试结束之后我们都会写一个测试报告，一般情况下，测试 4-5 轮之后会达到上线要求， 当达到上线的标准后，测试报告会认为测试通过，上线前我们会做预发布测试，预发布通过后， 由项目组与产品决定时间上线，上线完成，一周左右我们会写一个项目总结测试报告， 总结我们在上一个版本中遇到的问题以及今后有哪些地方需要改进，在产品选代过程中， 我们会跑自动化用例来进行回归测试。

3.2 如果需求不明确的话你怎么办?

需求不明确的话我会在需求澄清会议上面提出来，问清楚这个需求只有明确需求， 才能更好的完成工作，后续工作中还是不清楚，可以找产品再去确认这个需求。

3.3 有哪些需要评审，哪些人在

1、 xmind 思维导图评审，主要是测试人员 2、测试用例需要评审，测试人员，开发人员，产品人员 3、需求文档，项目组所有的人员，都会到场

3.4 有没有写过测试计划，具体包括哪些内容?

参考答案 1： 测试计划内容： (1)目的和范围 (2)规程 (3)测试方案和方法 (4)测试的准入和准出 (5)测试计划(流程、时间安排、对应人员) (6)测试的环境配置和人员安排 (7)交付件 华测教育专属 华测教育专属 华测教育专属 华测教育专属 华测教育专属 华测教育专属 华测教育专属 华测教育专属 华测教育专属 15 参考答案 2 我们公司之前按照考核要求写过测试计划，不过后面老大觉得太耽误工作进度， 后面一般都不再写测试计划，而是写版本计划，这个在版本计划，每个人的任务列出来， 负责人列出来，自己根据自己的情况分配时间，然后汇总，大家一起开个小会评审就可以了。

3.5 用例包含哪些部分，哪些用例设计方法，你一般常用哪些方法?

原来我们用例包含 测试项目，用例编号、测试标题、优先级、预置条件、操作步骤、测试数据、预期结果 黑盒测试用例设计方法：主要是等价类、边界值、错误推测法、判定表、因果图、正交表、 流程分析法、状态迁移法、异常分析法。 常用的：等价类、边界值、判定表、流程分析法、错误推测法。 等价类是指某个输入域的子集合，在该子集合中， 各个输入数据对于揭露程序中的错误都是等效的， 并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试，因此，可以把全部 输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件， 就可以用少量代表性的测试数据取得较好的测试结果， 等价类划分可有两种不同的情况有效等价类和无效等价类。 边界值的话就是对等价类划分方法的补充。测试工作经验告诉我，大量的错误往往是发生在输入或输 出范围的边界上而不是发生在输入输出范围的内部，因此的话针对各种边界情况来设计测试用例，可 以查出更多的错误，使用边界值分析方法设计测试用例的话，首先应该确定边界情况，通常输入和输 出等价类的边界，就是应着重测试的边界情况应当选取正好等于，刚刚大于或刚刚小于边界的值作为 测试数据，而不是选取等价类中的典型值或任意值作为测试数据。 对于错误推断法，这个是基于经验和直觉推测程序中所有可能存在的各种错误， 从而有针对性的去设计测试用例的方法的，主要就是列举出程序中所有可能有的错误和容易发生错误 的特殊情况去根据这些情况来选择测试用例，例如，在单元测试时曾列出的许多在模块中常见的错误 以前产品测试中曾经发现的错误等，这些就是经验的总结。还有，输入数据和输出数据为 0 的情况。 输入表格为空格或输入表格只有一行。这些都是容易发生错误的情况，可选择这些情况下的例子作为 测试用例。 前面介绍的等价类划分方法和边界值分析方法都是着重考虑输入条件但都没有考虑输入条件之间的 联系，相互组合等等的情况。考虑输入条件之间的相互组合，可能会产生一些新的情况， 但是要检查输入条件的组合并不是一件容易的事情，即使把所有输入条件划分成等价类， 他们之间的组合情况也相当多，因此的话可以考虑采用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例，这就需要用到因果图(逻辑模型)。 因果图方法最终生成的就是判定表它适合检查程序输入条件的各种组合情况。

3.6 TestLink 工具使用?

(1)创建用户，并给新创建的用户指定权限。 (2)创建测试用例，对测试用例进行增、删、改、查 (3)把测试用例关联到对应的测试计划中。 (4)把测试用例指派给对应的测试人员。 (5)对应的测试人员，查看被指派的测试用例，并执行测试用例。

3.7 如何提交一个好的 BUG

对 BUG 有一个清晰明了的描述； 详细描述 BUG 重现的步骤 对于产生 BUG 的环境进行描述； 提交 BUG 相关的图片和日志; 定位好 BUG 的等级； 将预期结果与实际结果进行对比。

3.8 提 bug 需要注意哪些问题?

1) 不要急着提交，先跟开发说明 bug 的情况，定位分析下 bug。 是前端问题还是后端问题再去提交 bug。 2) 简单明了的概括 bug 标题，清晰的描述 bug 重现步骤，分析 bug 和预期正确结果，附加 bug 的截 图或者日志。描述 bug 的时候。 3) 在不能确认该情况是否为 bug 的时候，可以请教其他人。 4) 提交完 bug 以后，后面还要跟踪 bug 修复情况。

3.9 bug 怎么管理的，bug 的生命周期或者是 bug 的状态

原来 bug 是用禅道来管理的 原来我们公司 bug，提交 bug 直接给对应的开发人员，对应开发人员修复完成，交给测试复测， 复测通过关闭 bug，不通过打回给对应开发。 提交-开发人员(已激活未确认)-开发进行确认，状态变成已激活，已确认，开发修复完成， 标注状态是已修复，测试人员复测通过，已关闭，打回给对应开发，已经激活。

3.10 提交 bug 包含哪些内容

所属产品、所属模块、所属项目、影响版本、指派人员 截止日期、严重程度、优先级、bug 类型、bug 环境 Bug 标题、重现步骤、附件

3.11 你提交的 bug，开发不认可怎么办?

首先我会再看需求文档，是不是我的理解有误，如果是我对需求理解错的话我就去关闭 bug。 如果是 bug 再去让其他测试人员看看听下他们的意见，然后自己先再三去复测，并目保存好截图和日 志，确定这是一个 bug 之后我就去跟开发说明白，并且给他看 bug 重现的截图以及日志，如果开发还 是不认可的话我就跟产品或项目经理说明白情况。

3.12 对应无法重现 bug，应该怎么处理?

首先，我会多测几次，测了好多次都无法重现的话我就先把 bug 挂起，并且留意一下，看看往后的测 试中，如果在后面的测试中重现 bug 就激活，如果经过几个版本都还没发现的话就关闭 bug。

3.13 界面中的乱码可以是哪里导致的?

(1)数据库中的编码设置 (2)前端页面编码 (3)后台代码也会编码

3.14 bug 的级别有哪些，级别如何判断

1、致命：对业务有至关重要的影响，业务系统完全丧失业务功能，无法再继续进行， 或业务系统丢失了业务数据且无法恢复，影响公司运营的重要业务数据出错。 2、严重：对业务有严重的影响，业务系统已经丧失可部分的重要的业务功能，或业务系统 丢失了业务数据且可以恢复，一般业务数据出错。 3、一般：对业务有较小的影响，业务系统丧失了较少的业务功能， 例如：界面错误，打印或显示格式错误。 4、提示：对业务没有影响，不影响业务过程正常进行， 例如：辅助说明描述不清楚，提示不明确的错误提示。

3.15 测试中，如何判断是前端的 bug 还是后端的 bug 呢?

通常可以利用抓包工具来进行分析。可以从三个方面进行分析：请求接口、传参数、响应。 1）请求接口 un 是否正确如果请求的接口 ur 错误，为前端的 bug 2）传参是否正确如果传参不正确，为前端的 bug 3）请求接口 u 和传参都正确，查看响应是否正确如果响应内容不正确，为后端 bug 4）也可以在浏览器控制台输入 js 代码调试进行分析

3.16 项目上线后发现 bug，测试人员应该怎么办

看严重级别：严重还是不严重 严重的：紧急变更上线  不严重：修复好后跟下个版本一起上线 用户会通过运维反馈到项目组这边，项目经理会根据功能模块的负责人，分给对应的开发与测试。 测试人员：编写对应的测试用例、测试环境中重现 bug、提交 bug、 交给开发进行修复、修复完成 bug、进行 bug 的复测。 如果测试环境无法重现，可以导入生产环境的包到测试环境中测试， 还是不能复现，查看生产环境的日志去定位问题。

3.17 如何保证质量

(1)需求要吃透，多问，多去了解。 (2)严格按照测试流程去执行：多考虑用户测试场景，使用测试用例设计方法，多评审。 (3)要有良好的测试执行：要求用例执行率达到 100%，多轮测试，进行探索性测试， 需要测试之间交叉测试，用工具来管理我们的测试工作(禅道， testlink， excel，tapd) (4)不断的反思与提升。

3.18 产品是怎么上线的?

一般我们会选择晚上上线，开发测试还有产品全部到场，进行上线测试。 首先，开发将代码打包到生产环境的服务器中，如果数据表有变化，就会运行 sql 文件， 对表的一些操作，接着，我们测试就开始先测试主体业务功能以及新增的功能模块; 测试通过之后，我们会在界面上把上线测试的数据删除，正常上线。 如果发现 bug，开发人员当场修复 bug，修复成功之后我们测试再复测，通过就可以正常上线 如果发现了 bug 开发人员在上线规定时间之前都还没有修复好的话，就看问题的严重性， 如果严重就延期上线，如果我们是迭代版本的话我们还需要版本回滚。 如果不严重，产品跟客户觉得可以上线，就正常上线。

二、接口自动化

10.1 接口自动化怎么测试

( Python+ requests+pytest 版本) 原来我们接口自动化是用 python+ request+ pytest 执行 接口自动化其实主要就是接口测试的基础上填加了断言，参数化，动态关联 做接口自动化之前，我们也会划分模块，报告，公共的模块，测试数据，测试报告，主要的目的是为 了方便后期的维护 测试数据，一般原来我们就是用的接口测试用例，公共的模块，主要是里面的一些公共的作，比如说 用例 excel 数据的读取  数据库的连接，还有我们封装的每个接口请求 断言的主要是获取访问接口的值判断，用的是 assert，参数化主要用的比较多是 excel 表格，就是 测试用例数据 还有需要调用登录后的 cookies 跟 token 的时候，我们就会用到关联 比如说原来我们写的一个申请借款的接口吧 首先我们会编写测试用例，把每个用例数据保存到 excel 中 再建立一个申请借款的模块 这个时候我们去调用申请借款的功能模块，里面的参数我们是保存在 excel 表格中 我们建立发送请求，通过参数化，去读写 excel 表格中的数据，获取到返回的数据，通过 assert 去 对应返回的数据跟用例中异常的数据。 这个时候也会做数据库断言，去连接数据库去查询数据库中时候存在查询，如果是返回结果 是 json 数据格式，我们还会转化下格式后，再去断言 这个申请借款模块，也会用到登录的 cookie 值 token，我们先建立一个登录的请求，提取 返回的 cookie 值 token excel 表格多个用例，我们就用到循环去运行，读取 excel 中用例总的条数，去循环运行， 这里要注意的是: 就是 excel 表格数据时是 str 我们要 eval 转化成字典格式 把每个接口封装好以后 我们就会调用 pytest 框架去运行所有 test 文件的测试用例 如果只是执行部分用例，也可以通过 pytest 框架来指定 然后用 yagmail,在 pytest 框架运行完 test 文件之后，发送邮件到指定邮箱。 接口自动化，我个人觉得，性价比是比较高的。 实现起来简单、维护成本低，容易提高覆盖率等特点 接口是稳定的，最多是增加一个字段或者新增接口之类的 低成本，有了相对的稳定性，不需要大量重新编写脚本，只需要基础维护包括用例的扩充就可以了 执行的快，反馈的速度快 （jmeter 版本) 原来我们也做了很多接口自动化，接口自动化这块，其实原来我们也是用 jmeter 请求去做的，这个 时候，我们也用到一些工具，http 代理，主要方便编写接口请求，通过录制就行了，我觉得接口自 动化只是在接囗测试中多加了一些参数化、关联、断言参数，主要是函数参数化，自定义变量参数化， 文件参数化，主要文件类型 csv 跟 txt，不过原来 csv 文件用的比较多，还有一些数据库的参数化， 断言，主要响应代码断言，响应文档断言。 比方说，原来我们一个登录接口主要是正常场，异常场票这块，正常场景，主要是用户跟密码正确， 采用数据参数化，把用户名用随机函数进行参数化，随机长度大一些，用户名不存在的情况，原来是 通过文件参数化，设置参数值，密码不正确也是通过文件参数化，接口请求中 host 地址，目录地址， 我们都进行数据化，自定义变量去操作，结果检中，我们主要是用断言来检查，每个请求， 设置了 2 个断言，一个响应代码断言，一般是 200，响应文本断言，登录成功，返回码为 1 状态提示成功，检意是否成功，对应异常场景也是，都需要设置断言，去检查结果原来做的申请借款 接口，需要登录接口 http cookie，我需要建立 2 个接口，一个登录接口，一个申请借款接口，通过 正则表达式去提取登录接口返回 cookie，在申请借款请求接口，设置 http cookie 时，值为登录接 口返回 cookie，还有也要考虑原来我们项目，还有 token 值，提取登录返回 token，提取，当成申 请借款的请求参数，当测试场景的脚本编写完成，执行接口测试用例，我们在察看结果树中，检直， 主要是看颜色这块，红色检查哪些地方失败，绿色表示通过 编写完成后，我们会把脚本添加到 jenkins 里面持续集成运行 原来我们持续集成是半个月运行一次，当然我们也可以手动构建 1，我们一般把写完的 jmeter 的脚本 2，通过 svn 把写好的脚本检入到 svn 服务器 3，在 jenkins 任务下，选择定时构建，或者手动构建，检查 svn 上传最新的脚本，去运行 一般我们项目在修改新的功能模块，上线，转测之前，都会自动去运行脚本 4，运行完成，我们再 jenkins 下，查看脚本运行结果

10.2 为什么做接口自动化?

接口自动化，我个人觉得，性价比是比较高的 实现起来简单，维护成本低，容易提高覆盖率等特点 接口是稳定的，最多是增加一个字段或者新增接口之类的 低成本，有了相对的稳定性，不需要大量重新编写脚本，只需要基础维护包括用例的扩充就 可以了执行的快，反馈的速度快

10.3 假如公司想要做自动化，让你去做，你会从那些方面考虑入手?

1.测试范围 2.时间进度 3.人员安排 4.框架确定 5.环境的搭建 6.准备好测试数据 数据驱动 7.工程的管理后期的维护

10.4 你写了多少接口自动化用例

自动化用例，也没有具体数过，当时我负责的所有模块的接口的自动用例都是我这边独立完成的， 有模块的用例会多一点，有些会少一点，这具体看接口的参数有多少，参数多限制条件多的， 一般用例会比较多一点，我负责的模块大概有 100 多条用例是有的!

10.5 比如说你接口的请求参数需要加密处理的，你们用的是什么加密方式，你加密怎么处理的?

这个是有做过的，就拿当我们那个项目的登录接口来讲吧，那个登录的密码是需要进行加密 加密之后再进行传输。这里需要问开发要加密算法，我们会把它封装成一个函数，调用这个加密函数 对密码加密，之后再进行传递。我们公司的加密算法，大部分用的都是 MD5 的加密算法(base64)

10.6 你查询出来返回结果是密文，密文你怎么测试

这里首先要搞清楚用的是什么加密算法，问开发要解密算法，对返回的数据进行解密 解密完成之后在与预期结果对比，去进行断言

10.7 http 如何进行代理录制接口

Web 端 1，浏览器设置代理就可以录制，默认 ip 为 localhost，端口 8888 手机端 1，手机设置代理就可以录制 默认 ip 为 pc 机器的 ip 地址，端口 8888

10.8 jmeter 如何进行参数化，参数化类型包含哪些

用户参数自定义变量文件参数化，csv 文件或者 txt 文件 函数助手随机函数，csvread 函数数据库参数化

10.9 jmeter 中对于 json 数据如何提取信息

正则表达式提取或者 JSON Extractor 提取

10.10 jmeter 中如何跨线程组传输参数

正则表达式或者边界值提取器或者 JSON Extractor 提取的值 后置处理器- beanshell 处理器 定义成全局变量 ${_setProperty(newtoken,${access_token},)} 其他线程组，引入变量值 ${_P(newtoken,)}或者${_property(newtoken,)} 

10.11 jmeter 如何进行断言

1，响应断言 添加响应断言：添加-》断言-》响应断言 apply to:是应用范围，设定匹配的范围 Main sample and sub-samples:匹配范围为当前父取样器，及子取样器 Main sample only:仅当前父取样器 Sub samples only:仅子取样器 Meter Variable:变量值进行匹配 要测试的响应文字:针对响应数据不同部分进行匹配 (1)响应文本：响应服务器返回的文本内容，http 协议排除 header 部分 (2)响应代码：匹配响应代码，比如 http 请求中 200 代表成功 (3)响应信息：匹配响应信息，处理成功返回成功”或者“ok”字样 (4) Response Header 匹配响应头中的信息 匹配规则: 包括：响应内容包括需要匹配的内容就算成功 匹配：响应内容要完全匹配内容，不区分大小写 equals：完全相等，区分大小写 substring：响应内容包括匹配内容即为成功 可以通过添加断言结果来查看断言的执行情况 执行结果： 如果接口响应数据可以与断言匹配上，则测试用例通过，否则不通过 可以通过断言结果，查看断言执行情况。 2，大小断言 3，持续时间断言

10.12 jmeter 如间在 cmd 命令下运行

Jmeter -n -t 文件路径\fw-zhuce.jmx -l result.jtl -e -o E:\resultreport 讲解：非 GUI 界面，压测参数讲解 -h 帮助 -n 非 GUl 模式 -t 指定要运行的 JMeter 测试脚本文件 -l 记录结果的文件每次运行之前，(要确保之前没有运行过即 xxx.jtl 不存在，不然报错) -r Jmter.properties 文件中指定的所有远程服务器 -e 脚本运行结束后生成 html 报告 -o 用于存放 html 报告的目录(目录要为空，不然报错) -R 表示选择执行=远程启动 XXX.XXX. XXX. XXX：5174 ，XXX. XXX. XXX. XXX：5172 官方配置文件地址 http：//jmeter.apache.org/usermanual/get-started.html

10.13 jmeter 运行完成后如何去自动发送邮件?

(1)监听器中添加-邮件观察仪 文件名-运行完成，保存运行结果的位置 from 邮件的发送人 isz181xiongmao@126.com addressee 邮件的接收人(多个人用逗号隔开) success subject 运行成功，发送邮件标题 success limit 大于运行请求成功的次数 failure subject 运行失败，发送邮件标题 failure limit 大于运行请求失败的次数 host 邮件服务器地址 smtp.126cm login 邮件服务器登录用户名密码(授权码) 1、文件名：只需要给出路径和保存的文件名称即可，给定之后将会把测试结果的数据写入到文件中 注：它不会将此文件已附件的形式在邮件中，只是将测试结果写入到了定的此目录文件中， 如果你运行完脚本，直接在此路径下打开此文件就可以看到运行结果 2、 Success Limit 与 Failure Limit：当成功数与失败数为几时进行邮件的发送(注意：此处是大 于给定的数值，不是等于)，我写的 1，则失败 2 次后将发送邮件通知我， 3、当测试结果 100%成功时则不会发送邮件 4、写代码 java 编写 beanshell 后置处理器

10.14 pytest 如何做断言?

用 assert 断言 1，断言返回的结果 2，进行逻辑检查，检查数据库产生的数据

10.15 patent 中如何去调取其他用例中返回的参数?

把返回的值定义成全局变量 global a_id #定义成一个全局变量  a_id = incharge_id

10.16 你们做接口自动化，用例数据是怎么组织，管理的?

用例数据这块，当时公司要求使用 excel 表格来进行管理，其实这里主要也是为了实现数据与脚本 的分离，提高整个工程后期的维护与优化，这里把数据封装到 excel 表格之后。 我们在脚本中通过调用封装好的读取 excel 表格的数据函数，对 excel 表格中的用例数据， 我们是这么组织的，会有以下几个字段像用例标题，请求地址，请求方式，请求头，请求参数，响应 结果，这个几个部分，对于请求头跟请求参数，因为脚本中发请求都是通过组装成字典的形式来发送 的所以这里我们也是通过类似于字典的形式文本格式来进行组织，主要就是方便后期脚本的提取与引 用其实我觉得，这样去处理的好处就是，后期如果用例数据有变动，或者需要增加或删除部分 用例直接针对 excel 表格数据进行操作就可以了，不需要改动脚本这也就方便整个项目工程的管理 与维护了。

10.17 requests 中如何进行动态关联

1，如果返回的是 cookies 值，可以直接返回接口的 r.cookies 2，返回的是 str 类型数据，可以导入 re 模块进行正则表达式提取返回数据格式是 json 格式， 导入 json，把 json 数据格式转化 python 对象 json.dumps 将 Python 对象编码成 JSON 字符串 json.loads 将已编码的 JSON 字符串解码为 Python 对象

10.18 你们 python 接口自动化怎么去处理 cookie， session 的?

对于 cookie，session 的处理一般有三种方式: 第一种就是先获取登录请求的 cookie 值，然后发送其他请求的时候，在 requests 提供的 两个方法 get 或 post 方法中有一个 cookies 参数，我们可以通过这个参数来传递 cookies 值 第二种就是通过订制请求头，然后把获取到的 coookies 放在请求头中，通过请求头来进行传递 第三种就是通过创建一个 session 会话对象，后期所有的请求发送都通过调用这个 session 会话对 象来进行发请求，如果是登录请求，它会自动保存 cookies 值，然后其他需要用到 cookies 值的请 求，也通过 session 对象来发送，它会自动把 cookies 发送出去,对于 cookies， session 的处理， 我们差不多都是通过以上三种方式来实现的

行动吧，在路上总比一直观望的要好，未来的你肯定会感 谢现在拼搏的自己！如果想学习提升找不到资料，没人答疑解惑时，请及时加入扣群： 320231853，里面有各种软件测试+开发资料和技术可以一起交流学习哦。

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！