接口测试之what、why、how(一)

本文从接口测试的概念出发,深入探讨其重要性和测试策略,并详细介绍了如何进行接口测试,包括参数输入、逻辑处理、接口返回等多个方面的考量。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

毕业后就开始做软件测试工作,一直想把自己工作中遇到坑、实践以及经验进行总结,但苦于知识、能力有限,无法深入,就一推再推,至今也没开始。“不管你怎么准备,永远都不会有准备好的那一天。所以准备好了再做其实是一个很坑爹的思维。不管你如何准备,如果没有行动,永远都不会都准备的那一天”,开始一点一点的做,去完善。

主要摘自(https://blog.csdn.net/jiary5201314/article/details/51429347)

从what、why、how去梳理接口测试

什么是接口测试(what)

        接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换,传递和控制管理过程,以及系统间的相互逻辑依赖关系等。

为什么要做接口测试(why)

 前端+接口测试双保险 
    安全层面:
            a、现在很多系统前后端架构是分离的,从安全层面来说,只依赖前端进行限制已经完全不能满足系统的安全要求(绕过前端太容易了), 需要后端同样进行控制,在这种情况下就需要从接口层面进行验证。
            b、前后端传输、日志打印等信息是否加密传输也是需要验证的,特别是涉及到用户的隐私信息,如身份证,银行卡等。
 
   测试前移:如今系统越来越复杂,传统的靠前端测试已经大大降低了效率,而且现在我们都推崇测试前移,希望测试能更早的介入测试,那接口测试就是一种及早介入的方式。例如传统测试,你是不是得等前后端都完成你才能进行测试,才能进行自动化代码编写。 而如果是接口测试,只需要前后端定义好接口,那这时自动化就可以介入编写接口 自动化测试代码,手工测试只需要后端代码完成就可以介入测试后端逻辑而不用等待前端工作完成。
 
        自动化测试: 接口测试相对容易实现自动化持续集成,且相对UI自动化也比较稳定,可以减少人工回归测试人力成本与时间,缩短测试周期,支持后端快速发版需求。接口持续集成是为什么能低成本高收益的根源。
接口测试的策略
  接口测试也是属于 功能测试,所以跟我们以往的功能测试流程并没有太大区别,测试流程依旧是:1.测试接口文档(需求文档) 2.根据接口文档编写 测试用例(用例编写完全可以按照以往规则来编写,例如等价类划分,边界值等设计方法) 3. 执行测试,查看不同的参数请求,接口的返回的数据是否达到预期。
接口测试常用抓包工具: Fiddler、Charles、Firebug、开发者工具等等

怎么进行接口测试(how)

下面来说说时间测试过程中系统的接口测试从哪些方面进行考虑:

1、参数输入(入参)

特殊字符
参数类型
参数为空格、空、NULL
非必填参数组合
边界值校验(字符长度极限值验证、数值型边界值、枚举值超范围验证)
……等等

2、接口逻辑处理:

    2.1约束条件分析:

        枚举值限制:

        数值限制:分数限制、金币限制、等级限制

        状态限制:登录状态、失效等

        权限限制:管理员、权限绑定关系、主从关系等

        关系限制:好友关系、绑定换下

    常见问题和风险:约束条件判断不足,导致用户可以通过特殊手段获取利益

    2.2操作对象分析:操作通常是针对对象的,例如用户绑定手机号码,手机号码就是操作对象,二这个手机号码的信用等级、流量、话费,套餐余量也是对象

    常见问题和风险:用户可以访问非权限内的其他对象的信息、敏感信息,从而利用这些信息谋取利益

    2.3状态转换分析:如已提交,未审核,已审核,正常态:提交后,转为未审核,未审核的审核后转换为已审核;异常状态切换,未提交就可以审核

    2.4处理时序分析:如某流程要先登录,刷新,再变更;若数据顺序打乱后,导致其他系统或业务异常,从而谋利

3、接口返回(出参):接口正确处理的接口只有一个,而错误异常返回的结果却有很多种情况,甚至奇葩、出乎意料的的返回,比较不同开发人员有不同的书写习惯;返回状态码和信息

4、性能测试:响应时间(time)、并发数、吞吐量(--)、服务器资源使用情况(cpu、内存、io、)

        超时处理(未做超时处理;阻塞)

5、安全性测试:敏感信息加密(sign签名、时间戳、token机制、验证码、)

6、兼容性测试:(废弃接口、老接口、新接口)

接口测试中发现的典型问题:

1、传入参数处理不当,导致程序crash

2、类型溢出,导致写入如读取的不一致

3、对象权限未进行校验,可以访问其他敏感信息

4、状态处理不当,导致逻辑处理错乱

5、逻辑校验不完善,可利用漏洞获取利益

一、接口参数数据类型:
1. 数值型
2. 字符串类型
3. 数组或者 链表类型
4. 结构体
二、接口测试常见bug:
1. 特殊值处理不当导致程序异常退出或者崩溃
2. 类型边界溢出,导致数据读出和写入不一致
3. 取值边界外值未返回正确的错误信息
4. 参数 为null或空字符串“”等
5. 权限未处理,可以访问其他用户的信息
例如:无权限可以访问,或者 一般用户可以访问管理员权限)
6. 逻辑校验不完善,可利用漏洞获取非正当利益
例如:某网站兑换1块钱需要100币,当小于100币时调用后台 接口是否可以兑换
例如:购物结算时为100元,调用 后台接口设为0元,哈哈
7. 状态处理不当,导致逻辑出现错误(可能程序员123都搞懵了)
8. 数组类型item个数为0或者item重复时程序异常退出
9. 超时问题,超时后处理
10. 潜在性能问题(后台提交处理或者把性能风险提前提出)

 

 

<think>好的,我现在要回答用户关于单元测试完整流程和实施步骤的问题。首先,我需要回顾用户提供的引用内容,特别是引用[2],里面提到了单元测试的具体步骤,比如根据《软件设计报告》划分单元,使用测试工具和手动测试,提交测试用例表或报告等。此外,其他引用虽然主要关于接口测试或性能测试,但可能也有通用的测试步骤可以参考。 首先,单元测试的基本流程应该包括需求分析、测试用例设计、环境搭建、执行测试、结果记录和持续集成等。根据引用[2],单元测试需要根据软件设计报告来划分可测单元,然后采用工具或手动测试。同时,引用[5]提到的6W方法(why, what, when, where, who, how)也可能适用于单元测试的规划阶段。 接下来,我需要确保回答的结构清晰,分步骤说明。可能还需要提到单元测试框架,比如JUnit,以及相关的注解,如@BeforeEach、@AfterEach等,这部分可以参考引用[3]中的内容,其中提到了测试生命周期中的各个注解,比如@BeforeAll、@AfterEach等,这些是编写测试用例时的重要部分。 另外,用户提供的示例中,快速排序的回答包含了代码示例,因此在单元测试的回答中也可以加入个简单的测试代码示例,比如使用JUnit的测试用例,这样更直观。例如,如何为个加法函数编写测试用例。 需要注意的是,用户要求回答使用中文,并且数学表达式用$...$格式,但单元测试可能涉及较少的数学内容,不过如果有涉及变量或公式的地方需要正确应用格式。例如,如果提到测试覆盖率公式,可以写成$覆盖率 = \frac{已覆盖代码行数}{总代码行数} \times 100\%$。 最后,生成相关问题,可能需要考虑单元测试的最佳实践、工具选择、与集成测试的区别等,这些问题可以帮助用户进步了解单元测试的相关知识。 现在需要整合这些信息,确保每个步骤都有对应的引用支持,并正确标注引用标识。同时,检查是否符合用户的所有系统级指令,如格式要求、中文回答、问题生成等。</think>### 单元测试的完整流程与实施步骤 单元测试软件测试的最小单元验证环节,主要用于确保代码模块的独立功能符合设计要求。以下是其实施的完整流程和步骤: --- #### **1. 需求分析与单元划分** - **依据设计文档**:根据《软件设计报告》或需求文档,明确被测模块的功能边界和输入输出要求[^2]。 - **划分可测单元**:将系统拆解为独立的可测单元(如函数、类、方法),通常以单功能或逻辑模块为单位。 - **示例**:若实现个计算器模块,可划分加法、减法等独立函数作为测试单元。 --- #### **2. 测试框架与工具选型** - **选择测试框架**:根据编程语言选择对应框架(如Java的JUnit、Python的pytest、JavaScript的Jest)。 - **配置辅助工具**:结合覆盖率工具(如JaCoCo)、模拟框架(如Mockito)和静态分析工具[^5]。 - **示例代码(JUnit)**: ```java import org.junit.jupiter.api.Test; import static org.junit.jupiter.api.Assertions.assertEquals; public class CalculatorTest { @Test void testAddition() { Calculator calc = new Calculator(); assertEquals(5, calc.add(2, 3)); } } ``` --- #### **3. 测试用例设计与评审** - **设计用例原则**: - 覆盖正常输入、边界值(如$n=0$或最大值)、异常输入(如空指针)。 - 结合等价类划分和判定表方法减少冗余。 - **用例评审**:与开发人员、测试团队共同评审用例的完整性和有效性[^2]。 --- #### **4. 测试环境搭建** - **隔离依赖**:使用模拟对象(Mock)或桩函数(Stub)隔离数据库、网络等外部依赖[^3]。 - **配置生命周期钩子**:通过注解(如`@BeforeEach`、`@AfterAll`)管理测试前后的资源初始化与清理。 --- #### **5. 测试执行与结果记录** - **自动化执行**:通过框架批量运行测试用例,生成测试报告。 - **记录与跟踪**:对失败用例记录缺陷,并关联到项目管理工具(如Jira)[^2]。 - **覆盖率统计**:确保覆盖关键路径,目标覆盖率通常设为$80\%$以上[^4]。 --- #### **6. 持续集成(CI)** - **自动化集成**:将单元测试嵌入CI/CD流水线(如Jenkins、GitHub Actions),实现代码提交后自动触发测试。 - **质量门禁**:设置覆盖率阈值,未达标时阻断代码合并。 --- ### 关键方法与最佳实践 1. **测试驱动开发(TDD)**:先写测试用例再编码,确保代码可测性。 2. **断言明确性**:断言应具体(如验证返回值、异常类型)。 3. **用例独立性**:每个测试方法仅验证单场景,避免依赖执行顺序。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值