软件测试常见的十三个问题

软件测试常见的十三个问题

第一，接口测试的流程是什么样的。

第二，没有接口文档，如何开展接口测试。第三，接口响应常用的状态码有哪些？分别是什么意思？

第四，接口测试怎么设计用例和UI测试用例有什么区别？需要考虑哪些方面呢？

第五，接口测试需要结合数据库数据进行判断时你会怎么做？

第六，接口加密解密以及数字签名这类场景该怎么测试？

第七，接口幂等性有了解过吗？

第八，接口自动化测试过程中如何实现参数化。

第九，接口出现异常错误，该怎么定位和分析问题。

第十，文件上传接口测试有什么注意事项吗？第十一，异步接口该怎么测试？

第十二，接口测试依赖第三方接口时该如何进行测试。

第十三，接口测试中token和session有什么区别呢？

一、 接口测试的流程是什么样的？

接口测试的流程与软件测试整体流程类似，通常分为以下几个阶段：

• 1. 需求评审：参与需求讨论，理解业务逻辑、接口需求文档（PRD）及交互设计，明确接口的输入输出、业务规则和限制条件。

• 2. 接口用例设计：基于接口文档或需求，使用等价类划分、边界值分析、场景法等设计测试用例，覆盖正常流、异常流、权限校验及边界条件。

• 3. 评审接口用例：与开发、产品对齐用例，确保对接口的理解一致，查漏补缺。

• 4. 准备测试数据：准备请求参数、Mock数据以及初始化数据库中的前置数据。

• 5. 执行测试：

  • 冒烟测试：新版本发布后，先对核心接口进行冒烟测试，通过后再进行全面测试。

  • 功能测试：使用 Postman、Apifox、JMeter 等工具发送请求，检查响应数据（状态码、响应体、字段类型、业务逻辑）是否正确。

  • 异常与安全测试：验证非授权访问、参数篡改、SQL注入、并发控制等。

• 6. 缺陷跟踪与回归：提交 Bug 给开发修复，修复后进行回归测试。

• 7. 自动化测试落地：将核心接口、冒烟接口编写为自动化测试脚本，集成到 CI/CD 持续集成流水线中（如 Jenkins）。

二、 没有接口文档，如何开展接口测试？

在敏捷开发或文档缺失的情况下，可以通过以下几种方式来开展接口测试：

• 1. 抓包分析（最常用）：

  • 使用Fiddler、Charles、Burp Suite或浏览器自带的DevTools (F12)。

  • 在前端页面进行实际业务操作（如登录、下单），拦截并观察前端发出的请求和响应，记录请求地址（URL）、请求方法（GET/POST）、请求头（Headers）、请求参数（Payload/Query）及返回格式。

• 2. 与开发沟通协作：

  • 直接找开发人员索取代码逻辑、内部接口定义，或者让开发配合梳理核心接口。

• 3. 代码走查（白盒辅助）：

  • 如果有权限，可以直接阅读后端代码（如 Controller 层、路由配置），明确接口路径、入参字段及校验规则。

• 4. 逆向推导与补充文档：

  • 通过抓包和沟通的结果，边测试边记录，反向整理出属于自己的“接口测试清单”，并在测试过程中逐步完善。

三、 接口响应常用的状态码有哪些？分别是什么意思？

HTTP 状态码大体分为 5 大类，接口测试中常见的具体状态码如下：

• 2xx（成功）：

  • 200 OK：请求成功，服务器已成功处理了请求。

  • 201 Created：请求成功并且服务器创建了新的资源（常用于 POST 或 PUT 请求）。

  • 204 No Content：请求成功，但响应头或响应体中没有返回具体内容（常用于 DELETE 请求）。

• 3xx（重定向）：

  • 301 Moved Permanently：永久重定向，请求的资源已被永久移动到新 URI。

  • 302 Found：临时重定向。

  • 304 Not Modified：协商缓存生效，客户端有缓存的资源，服务器允许使用缓存，未发生修改。

• 4xx（客户端错误）：

  • 400 Bad Request：客户端请求语法错误或参数有误，服务器无法理解。

  • 401 Unauthorized：请求未经授权，缺少 Token 或 Token 校验失败。

  • 403 Forbidden：服务器收到请求，但拒绝提供服务（权限不足）。

  • 404 Not Found：请求的资源不存在（URL 拼写错误或接口未发布）。

  • 405 Method Not Allowed：请求方式不被允许（例如将 GET 接口写成了 POST）。

• 5xx（服务端错误）：

  • 500 Internal Server Error：服务器内部错误，通常是代码抛出未捕获的异常。

  • 502 Bad Gateway：网关或代理服务器尝试执行请求时，从上游服务器收到了无效的响应。

  • 504 Gateway Timeout：网关超时，服务器过载或后端服务响应时间过长。

四、 接口测试怎么设计用例和UI测试用例有什么区别？需要考虑哪些方面呢？

1. 接口测试用例与 UI 测试用例的区别

2. 设计接口测试用例需要考虑的方面

• 参数校验（字段级别）：

  • 必填项检查（参数为空、为 null、不传）。

  • 数据类型检查（String、Int、Boolean、Array 等类型错误）。

  • 边界值检查（数值过大/过小、字符串超长、数组越界）。

  • 特殊字符与格式（如邮箱格式、手机号格式、HTML/SQL注入字符）。

• 业务逻辑校验：

  • 正常业务流程是否能跑通。

  • 业务限制条件（如：余额不足能否下单、优惠券是否过期、库存是否扣减）。

  • 状态转换逻辑（如：订单从“未支付”到“已支付”再到“已发货”的状态流转是否正确）。

• 安全与权限校验：

  • 未登录状态下是否能访问敏感接口（401）。

  • 普通用户越权访问管理员接口（403）。

  • Token 过期、篡改或伪造的情况。

• 响应结果校验：

  • 状态码、错误码、错误提示信息（Message）是否准确。

  • 返回的数据结构（JSON 格式、字段完整性、嵌套层级）是否符合文档。

五、 接口测试需要结合数据库数据进行判断时你会怎么做？

接口与数据库的结合主要用于前置数据准备和后置结果校验：

• 1. 前置数据准备（Setup）：

  • 在执行测试前，通过 SQL 脚本或测试框架（如 Python 的 PyMySQL、Java 的 JDBC）向数据库中插入特定状态的数据。例如：测试“查询用户详情”接口时，先在数据库插入一个指定 ID 的用户记录。

• 2. 后置结果校验（Assertion）：

  • 当接口执行了“写”操作（如注册、修改密码、下单）后，不能只看接口返回的code: 200，必须直接去数据库查询对应的表和字段，校验数据是否真实准确地落盘。

  • 示例：调用“扣减库存”接口后，查询数据库中该商品的stock字段值是否正确减去了购买数量。

• 3. 数据清理（Teardown）：

  • 测试完成后，清理掉测试过程中产生脏数据，保证测试环境的独立性和可重复性。

六、 接口加密解密以及数字签名这类场景该怎么测试？

针对加密、解密和数字签名的接口，测试时需要厘清加解密逻辑并在测试中进行针对性覆盖：

• 1. 常见加密与签名机制：

  • 对称加密（如 AES、DES）：加解密使用同一个密钥，用于敏感数据传输（如密码）。

  • 非对称加密（如 RSA）：公钥加密、私钥解密（或反之），常用于登录或敏感信息交换。

  • 数字签名（如 MD5、SHA256、HMAC）：将参数按规则排序、拼接并加上密钥（Secret）计算出签名值（Sign），用于防止请求被篡改。

• 2. 测试策略与方法：

  • 正向测试：使用正确的算法、密钥或签名规则发送请求，验证后端能否正常解密并处理。

  • 篡改测试（验证防篡改）：故意修改请求体中的某个参数值，但保持签名不变，验证接口是否报错（如“签名无效”）。

  • 缺失测试：发送请求时故意不传签名参数或加密密文，验证接口的校验拦截机制。

  • 时效性/重放攻击测试（Timestamp）：如果签名中带有时间戳（Timestamp），测试时间戳过期（如超过 5 分钟）后接口是否拒绝响应。

  • 自动化加解密处理：在自动化测试框架（如 JMeter 的 JSR223 脚本、Python 的 requests hooks）中编写加解密函数，在发送请求前自动加密/生成签名，在收到响应后自动解密，从而不影响业务逻辑的自动化断言。

七、 接口幂等性有了解过吗？

• 1. 什么是幂等性：

  • 幂等性是指任意多次执行所产生的影响均与一次执行的影响相同。也就是说，同一个接口被发起一次或多次，对系统产生的影响是一样的，且不会发生副作用。

  • 典型场景：用户重复点击支付按钮、网络延迟导致前端重复提交请求、消息队列重复消费。GET、PUT、DELETE通常具备天然的幂等性，而POST（如创建订单）通常是非幂等的。

• 2. 常见解决方案：

  • Token 机制（防重令牌）：客户端请求前先获取一个全局唯一的 Token，提交时携带该 Token，服务端校验 Token 存在则执行并删除，重复提交时因为 Token 已不存在而拦截。

  • 唯一索引（Unique Constraint）：利用数据库表字段的唯一性约束（如订单号、业务流水号），重复插入时数据库直接报错拦截。

  • 分布式锁（Redis）：通过分布式锁，在并发请求时锁定某个业务 ID，只允许第一个请求通过，其余请求直接返回或等待。

• 3. 如何进行幂等性测试：

  • 使用自动化测试工具（如 JMeter 的多线程并发组）或编写脚本，模拟高并发或高频连续多次发送完全相同的请求。

  • 验证后端系统是否只处理了一次：检查数据库是否只生成了一条记录、余额是否只扣减了一次、接口是否对重复请求返回了友好的提示或相同的成功响应。

八、 接口自动化测试过程中如何实现参数化。

参数化是指将测试数据与测试脚本分离，通过外部数据源多次驱动同一段测试脚本运行。不同工具实现方式如下：

• 1. Postman / Apifox：

  • 使用 CSV 或 JSON 格式的数据文件。

  • 在集合（Collection）运行器中导入数据文件，在请求体或环境变量中使用{{变量名}}进行引用。

• 2. Python (pytest + requests)：

  • 使用@pytest.mark.parametrize装饰器直接传入列表或元组。

  • 通过读取外部文件（如 YAML、JSON、CSV、Excel）或连接数据库获取数据，传给测试函数。

• 3. Java (JMeter / TestNG)：

  • JMeter：使用“CSV Data Set Config”（CSV 数据文件设置）组件，将数据读取到变量中，在取样器中通过${变量名}调用。

  • TestNG：使用@DataProvider注解提供数据源。

九、 接口出现异常错误，该怎么定位和分析问题？

当接口出现异常（如返回 500、404、超时或数据错误）时，可以按以下步骤排查：

• 1. 查看响应结果与状态码：

  • 如果是404，检查 URL 路径、接口版本号、请求方式（GET/POST）是否正确。

  • 如果是401/403，检查 Token 是否失效、缺失或权限不足。

  • 如果是500，说明后端报错，需配合日志进一步分析。

• 2. 检查请求报文（Payload/Headers）：

  • 检查传参格式是否符合 JSON/Form 要求、必填字段是否遗漏、数据类型是否匹配。

• 3. 查看后端服务日志（Log）：

  • 登录服务器或通过日志平台（如 ELK、Graylog）查看对应时间戳的后端错误日志。

  • 重点看Stack Trace（堆栈信息），定位具体是哪一行代码、哪个类抛出了异常（如 NullPointerException、SQLSyntaxErrorException）。

• 4. 抓包与网络层分析：

  • 使用 Charles 或 Fiddler 确认请求是否真正到达了服务器，或者是否在中途被网关（Nginx）拦截（如 Nginx 502、504 超时）。

• 5. 联合排查：

  • 如果是数据库异常，检查连接池是否耗尽或 SQL 语句语法问题；如果是第三方接口异常，检查下游服务的状态。

十、 文件上传接口测试有什么注意事项吗？

文件上传接口除了常规的入参校验，还需关注文件本身的特性：

• 1. 文件格式（MIME 类型）限制：

  • 上传支持的格式（如.jpg,.png,.pdf），验证成功。

  • 上传不支持的格式（如.exe,.sh,.bat），验证后端是否能拦截并报错。

  • 防范恶意文件上传（如将木马文件后缀名改为.jpg），测试后端是否会检查文件头（Magic Number）或内容。

• 2. 文件大小限制：

  • 上传小于限制的文件（成功）。

  • 上传刚好等于限制边界的文件（成功或边界处理）。

  • 上传超过最大限制的文件（如限制 2MB，上传 5MB），验证接口是否正确报错（如“文件过大”）。

• 3. 文件名与特殊字符：

  • 测试中文文件名、超长文件名、包含特殊字符（如空格、#、?）的文件名，验证系统是否会乱码或报错。

  • 测试重名文件上传，验证系统是自动覆盖、重命名还是报错。

• 4. 并发与传输异常：

  • 多用户同时上传大文件，测试服务器性能和带宽压力。

  • 网络中断、上传一半取消，验证系统是否会产生垃圾文件（服务器端是否有临时文件清理机制）。

十一、 异步接口该怎么测试？

异步接口（如发送短信、生成大型报表、视频转码）通常是请求发出后，后端立即返回一个“受理成功”的响应，但实际业务在后台慢慢执行。测试要点如下：

• 1. 验证即时响应：

  • 检查请求发送后，接口是否能秒级返回，且响应状态码和业务状态码表示“处理中”或“已受理”（通常返回一个任务 IDtaskId或流水号）。

• 2. 结果轮询与状态查询：

  • 通过返回的taskId，调用另外的“查询任务状态”接口，验证状态是否从“处理中”流转为“成功”或“失败”。

• 3. 回调通知（Webhook）测试：

  • 如果系统支持异步回调，需配置接收回调的测试服务，验证当后台任务完成后，第三方或后端是否成功向指定回调地址发送了通知，且通知参数准确。

• 4. 数据库与最终一致性校验：

  • 等待后台异步线程执行完毕后，检查数据库中的最终数据状态是否符合预期。

十二、 接口测试依赖第三方接口时该如何进行测试？

在开发或测试环境中，第三方接口（如微信支付、短信验证码、第三方登录）可能存在不稳定、收费、无法在测试环境调用等问题，通常采用以下方案：

• 1. 使用 Mock 服务（最常用）：

  • 使用 Mock 工具（如 Apifox、WireMock、Moco）在本地或测试环境模拟第三方接口。

  • 预设好第三方接口在各种场景下的返回结果（如成功、超时、返回错误码），从而独立开展本系统接口的测试。

• 2. 沙箱环境（Sandbox）：

  • 如果第三方（如支付宝、微信支付）提供沙箱环境，可以直接配置沙箱环境的密钥和 URL 进行联调测试。

• 3. 白名单与网络打通：

  • 如果必须调用真实的第三方测试接口，需确保测试环境的外网 IP 已加入第三方的防火墙白名单中。

十三、 接口测试中 token 和 session 有什么区别呢？

Token（令牌）和 Session（会话）都是用于用户身份认证的机制，它们的核心区别在于状态存储的位置和扩展性：

• 1. Session（基于服务端）：

  • 存储位置：存储在服务端（如内存、Redis 或数据库中）。

  • 工作原理：用户登录成功后，服务端生成一个 Session ID，通过 Cookie 传给客户端。后续请求客户端自动带上 Cookie（包含 Session ID），服务端去内存/缓存中比对。

  • 缺点：服务端需要消耗内存存储会话；在分布式集群环境下，需要做 Session 共享（同步）处理，否则横向扩展服务器会出问题。

• 2. Token（基于客户端/JWT 常见）：

  • 存储位置：存储在客户端（如浏览器的 LocalStorage、SessionStorage 或移动端的沙盒中），每次请求通过请求头（Headers）传给服务端。

  • 工作原理：用户登录成功后，服务端根据用户信息通过秘钥签名生成一个加密的 Token 字符串返回。后续请求客户端带上该 Token，服务端通过解密/验签来验证身份，服务端本身不存储会话状态。

  • 优点：无状态、易于扩展，天然支持分布式集群和移动端跨平台应用。