来一套自动化测试面试题（答案版）

1、自动化怎么测试？

本题结合自己公司实际情况说，下面的内容可参考：

1）开展自动化测试之前，最好先做个测试计划，明确测试对象、测试目的、测试的项目内容、测试方法、测试的进度要求，确保测试所需人力硬件数据等资源准备充分，制定好测试计划后，下发给用例设计人员

2）分析测试需求

用例设计者根据测试计划和需求说明书，分析测试需求，设计测试需求树，以便用例设计时能够覆盖所有的需求点。一般来讲，基于Web功能测试需要覆盖一下几个方面：

①页面链接测试，确保各个链接正常；

②页面控件测试，确保各个控件可靠；

③页面功能测试，确保各项操作正常；

④数据处理测试，确保数据显示准确、处理精确可靠；

⑤模块业务逻辑测试，确保各个业务流程畅通。

3）设计测试用例

通过分析测试需求，设计出能够覆盖所有需求点的测试用例，形成专门的测试用例文档。由于不是所有的测试用例都能用自动化来执行，所以需要将能够执行自动化测试的用例汇总成自动化测试用例。必要时，要将登陆系统的用户、密码、产品、客户等参数信息独立出来形成测试数据，便于脚本开发。

4）搭建测试环境

自动化测试人员在用例设计工作开展的同时即可着手搭建测试环境。因为自动化测试的脚本编写需要录制页面控件，添加对象。测试环境的搭建，包括被测系统的部署、测试硬件的调用、测试工具的安装盒设置、网络环境的布置等。

5）编写测试脚本

根据自动化测试用例和问题的难易程度，采取适当的脚本开发方法编写测试较薄。一般先通过录制的方式获取测试所需要的页面控件，然后再用结构化语句控制脚本的执行，插入检查点和异常判定反馈语句，将公共普遍的功能独立成共享脚本，必要时对数据惊醒参数化。当然还可以用其他高级功能编辑脚本。脚本编写好了之后，需要反复执行，不断调试，知道运行正常为止。脚本的编写和命名要符合管理规范，以便统一管理和维护。

6）分析测试结果、记录测试问题

应该及时分析自动化测试结果，建议测试人员每天抽出一定时间，对自动化测试结果进行分析，以便尽早地发现缺陷。如果采用开源自动化测试工具，建议对其进行二次开发，以便与测试部门选定的缺陷管理工具紧密结合。理想情况下，自动化测试案例运行失败后，自动化测试平台就会自动上报一个缺陷。测试人员只需每天抽出一地你该时间，确认这些自动上报的缺陷，是否是真实的系统缺陷。如果是系统缺陷就提交开发人员修复，如果不是系统缺陷，就检查自动化测试脚本或者测试环境。

7）跟踪测试BUG

测试记录的BUG要记录到缺陷管理工具中去，以便定期跟踪处理。开发人员修复后，需要对此问题执行回归测试，就是重复执行一次该问题对应的较薄，执行通过则关闭，否则继续修改。如果问题的修改方案与客户达成一致，但与原来的需求有所偏离，那么在回归测试前，还需要对脚本进行必要的修改和调试。

8）自动化脚本的维护

如果系统发生变更时，对自动化测试脚本和相关文档包括《自动化测试用例》、《自动化脚本设计说明书》进行维护，以适应变更后的系统。

2、接口怎么测试？

1）接口的入参，先考虑正常的入参，以及异常的入参，异常情况包括：参数异常和数据异常

正常的入参：根据接口设计文档的入参标准，输入正常的参数，响应按接口设计文档的约定条件正常返回

参数异常包括：参数为空，多参或少参，错误的参数

数据异常包括：数据类型错误、非空参数为空，长度不符合设计，不在范围内的数据，特殊字符或敏感字符，存在关联关系的参数数据异常等

2）分析业务处理逻辑

根据限制条件分析：金额限制、订单状态的限制、数据操作权限的限制（管理员、普通用户）

根据操作对象分析：主要是对合法和不合法的对象进行操作，比如银行卡用户对卡进行充值，则可能存在：用户A使用非用户A的卡充值；用户A使用自己的卡进行充值，卡已过有效期；用户A使用自己的卡进行充值，卡为黑名单或挂失等。

根据状态转换的分析：比如支付类业务，先支付成功，撤单后会退款，再次支付如果支付未成功，则是支付失败，状态之间的切换是否正常，未按正常业务顺利进行操作时，状态怎么显示，是否可控，是否出现异常状态，空状态业务怎么处理等

根据业务操作顺序分析：按照某个顺序来执行，才能等到预期的结果，那么在执行过程中发生的其他分支动作程序会作何处理

3）输出

在考虑异常时，通常我们都会想到正常情况，无效的情况，但是不一定能覆盖所有错误码，而接口定义返回的错误码可以帮助我们补充这一部分的用例，比如网络异常，无效的规则，无效的参数，无效的业务ID，无效的任务，服务器异常等，把errorcode的值都补充上去可以设计更多的用例

这种根据输出进行设计用例，可以发现前后端是否正常输出结果，提示是否友好，提示是否出现敏感信息等

4）数据库操作

业务数据入库是否正常，是否有重复数据入库，是否出现乱码

数据更新是否正常，尤其是时间类字段，时间是否为24小时制的格式

表中各个字段是否符合预期

5）安全性

敏感信息是否加密（如用户名、银行账号，密码，转账金额）

6）性能

接口最大支持多少并发数

接口每秒能处理多少次业务（TPS）

接口的平均响应时间（RT）

接口对服务器资源的消耗（CPU、内存、网络、磁盘）

7）兼容性

接口测试不需要考虑客户端的兼容性，主要是数据的兼容性。比如对于老接口的历史数据是否兼容，用新接口去处理老的数据，是否能正常处理。

8）幂等性：就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用。

测试点如下：

①前端重复提交选中的数据或重复点击支付按钮，应该后台只产生对应这个数据的一个反应结果。

②发起一笔支付请求，当遇到网络重发或系统其他问题重发，可以先断网扫码一次再重连扫码，应该也只有一笔订单。

③创建业务订单（提现等），一次业务请求只能创建一个，创建多个就会出大问题；

④对于扫码交易（例如：主被扫）对同一笔订单，不同商户同时扫码，是否会出现重复支付；

⑤使用工具做接口自动化测试，制造相同的订单号，看是否会出现重复支付；

3、你们公司自动化框架是什么？

常用的框架有Robot Framework、Pytest、UnitTest。

Pytest、Robot Framework和UnitTest主要用于功能与单元测试。

4、为什么用jmeter接口测试，不用java直接接口测试呢

jmeter学习成本低，且能实现很多较为复杂的场景，提供了较为直观的UI界面，上手更容易一些，便于测试人员理解接口测试。

但是写代码实现接口测试的各种状态判断等操作，对于测试人员来说就相对难度高一点，需要一定的技术积累。

由于我司测试组人员。。。所以采用jmeter做的接口测试，这里回答时可以灵活一些。

5、接口实现自动化大概有多少？

梳理自己公司的业务即可。

接口自动化的case根据接口的数量而定，比如100个接口，接口自动化case大概在2000-3000之间，接口自动化的覆盖率可以达到100%，WEB自动化测试的case根据业务用例而定，10000个功能测试的用例，WEB自动化的用例在2000-3000左右，覆盖率一般在30%，所有的用例全部执行完大概在半个小时到一个小时左右。

6、接口测试怎么评估你的测试案例

1）业务功能覆盖是否完整

2）业务规则覆盖是否完整

3）参数验证是否达到要求（边界、业务规则）

4）接口异常场景覆盖是否完整

5）接口覆盖率是否达到要求

6) 代码覆盖率是否达到要求

7）性能指标是否满足要求

8）安全指标是否满足要求

7、交易接口是怎么样的？测试点有哪些？

1、补单功能：

自动补单功能通过系统自动查询接口重复查询直到获取订单终态

手动补单单条和批量做

2、风控限额功能：单笔、产品限额、单日限额、渠道限额（此时要进行边界值测试）

3、异步通知功能：支付成功或者分账成功通知，不同的异步通知需要验证订单成功、失败、处理中三种状态的通知内容及格式是否正确；

4、支付产品解约功能：解约后还能否做交易

5、基本状态校验如：支付订单状态、终端显示状态、商户后台等平台状态

6、异常状态订单是否会触发报警系统

7、并发测试，幂等校验

8、非功能指标：看接口并发及响应时间是否在合理范围内

8、后台架构是什么逻辑架构（后台包含拿一些模块？）

按照自己公司业务架构说即可

9、测试开发各占多少？

按照自己公司实际情况说即可

10、如果现在让写加解密会写吗？

刷题解决，这里先不做赘述。

11、跟开发怎么高效沟通的？有没有开发异地的经历

1、要耐心和细心，懂得尊重开发

2、测试工程师需要对产品质量负责，在这一点需要有原则

3、在有能力的情况下可以承担更多一些工作，如：定位bug至代码层级，前提要在自己确有余力情况去承担
4、建立进度定期跟踪机制

12、自动化和功能占比

按照自己公司实际情况说即可，例如：3比7

13、使用 Java 编写测试用例用到哪些库？

平常使用过的注意积累

requests：HTTP 请求库

mysql-connector-python： mysql官方python API

Selenium： Web自动化测试中使用最广泛的库

Mock：一个用于伪造测试的库

responses：伪造 Python 中的 requests 库的一个通用库

faker：生成虚假数据的python库

radar：生成随机的日期/时间

unittest：(Python 标准库) 单元测试框架

14、自动化测试检查点

接口响应码

交易状态

交易金额

请求结果

数据库断言

是否包含某些关键字

15、如何保障测试质量？

1）不同测试类型相结合，功能非功能

2）熟悉所测试系统业务逻辑，理解深挖需求

3）对于复杂模块的功能，做下用例评审

4）执行测试时，别放过任何bug，记得提缺陷系统中，及时跟进bug。注意各模块之间的交叉测试，进一步发现潜在问题

5）最终测试需要评估，对测试结果分析，探讨上线的风险，以及制定发生问题时的应急方案

等等

16、公司有没有高并发高可用？

即：怎么避免两笔重复订单的发生，按照实际情况说即可

回答：一般都是用数据库唯一索引约束，一个appid和商户单号只能有一笔，如果同时来交易的话数据库唯一索引直接就报错了，数据库控制，因为一笔入库另一笔就入不了库了

高并发涉及一些词解释：

高并发相关常用的一些指标有响应时间（Response Time），吞吐量（Throughput），每秒查询率QPS（Query Per Second），并发用户数等。

响应时间：系统对请求做出响应的时间。例如系统处理一个HTTP请求需要200ms，这个200ms就是系统的响应时间。

吞吐量：单位时间内处理的请求数量。

QPS：每秒响应请求数。在互联网领域，这个指标和吞吐量区分的没有这么明显。

并发用户数：同时承载正常使用系统功能的用户数量。例如一个即时通讯系统，同时在线量一定程度上代表了系统的并发用户数。

高可用：

公司引入Sentinel 是面向分布式服务架构的高可用流量防护组件，主要以流量为切入点，从限流、流量整形、熔断降级、系统负载保护、热点防护等多个维度来帮助开发者保障微服务的稳定性