接口测试≠功能测试

接口测试和功能测试的区别:

本文主要分为两个部分:

  第一部分:主要从问题出发,引入接口测试的相关内容并与前端测试进行简单对比,总结两者之前的区别与联系。但该部分只交代了怎么做和如何做?并没有解释为什么要做?

  第二部分:主要介绍为什么要做接口测试,并简单总结接口持续集成和接口质量评估相关内容。

第一部分:

首先,在做接口测试的过程中,经常有后端开发会问:

  1. 后端接口都测试什么?怎么测的?
  2. 后端接口测试一遍 ,前端也测试一遍,是不是重复测试了?

      于是,为了向开发解释上述问题,普及基本的测试常识,特意梳理了接口测试的相关内容以及其与前端测试的区别,使开发团队与测试团队在测试这件上达成基本的共识,提高团队协作效率,从而更好的保证产品质量。

然后,我们试着回答上面的问题:

问题1.1、后端接口都测试什么?

  --回答这个问题,我们可以从接口测试活动内容的角度下手,看一下面这张图,基本反应了当前我们项目后端接口测试的主要内容:

问题1.2、我们怎么做接口测试?

  --由于我们项目前后端调用主要是基于http协议的接口,所以测试接口时主要是通过工具或代码模拟http请求的发送与接收。工具有很多如:postman、jmeter、soupUI、java+httpclient、robotframework+httplibrary等。

问题2、后端接口测试一遍 ,前端也测试一遍,是不是重复测试了?

  --回答这个问题,我们可以直接对比接口测试和app端测试活动的内容,如下图为app测试时需要覆盖或考虑内容:

   从上面这两张图对比可以看出,两个测试活动中相同的部分有功能测试、边界分析测试和性能测试,其它部分由于各自特性或关注点不同需要进行特殊的测试,在此不做讨论。接下来我们针对以上三部分相同的内容再进行分析:

1、基本功能测试:

  由于是针对基本业务功能进行测试,所以这部分是两种测试重合度最高的一块,开发同学通常所指的也主要是这部分的内容。

2、边界分析测试:

  在基本功能测试的基础上考虑输入输出的边界条件,这部分内容也会有重复的部分(比如业务规则的边界)。但是,前端的输入输出很多时候都是提供固守的值让用户选择(如下拉框),在这种情况下测试的边界范围就非常有限,但接口测试就不存在这方面的限制,相对来说接口可以覆盖的范围更广,同样的,接口出现问题的概率也更高。

 3、性能测试:

  这个比较容易区分,虽然都需要做性能测试,但关注点确大不相同。App端性能主要关注与手机相关的特性,如手机cpu、内存、流量、fps等。而接口性能主要关注接口响应时间、并发、服务端资源的使用情况等。两种测试时的策略和方法都有很大区别,所以这部分内容是需要分开单独进行测试的,理论上来说这也是不同的部分。

综论:

      1、接口测试和app测试的活动有部分重复的内容,主要集中在业务功能测试方面。除此之外,针对各自特性的测试都不一样,需要分别进行有针对性的测试,才能确保整个产品的质量。

  2、接口测试可以关注于服务器逻辑验证,而UI测试可以关注于页面展示逻辑及界面前端与服务器集成验证

第二部分:

1、什么是接口测试?

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

2、为什么要做接口测试?

  a) 如今的系统复杂度不断上升,传统的测试方法成本急剧增加且测试效率大幅下降,接口测试可以提供这种情况下的解决方案。

  b)  接口测试相对容易实现自动化持续集成,且相对UI自动化也比较稳定,可以减少人工回归测试人力成本与时间,缩短测试周期,支持后端快速发版需求。接口持续集成是为什么能低成本高收益的根源。

  c)   现在很多系统前后端架构是分离的,从安全层面来说:

        1、只依赖前端进行限制已经完全不能满足系统的安全要求(绕过前面实在太容易), 需要后端同样进行控制,在这种情况下就需要从接口层面进行验证。

        2、前后端传输、日志打印等信息是否加密传输也是需要验证的,特别是涉及到用户的隐私信息,如身份证,银行卡等。

3、接口测试持续集成:

      对接口测试而言,持续集成自动化是核心内容,通过持自动化的手段我们才能做到低成本高收益。目前我们已经实现了接口自动化,主要应用于回归阶段,后续还需要加强自动化的程度,包括但不限于下面的内容:

  a) 流程方面:在回归阶段加强接口异常场景的覆盖度,并逐步向系统测试,冒烟测试阶段延伸,最终达到全流程自动化。

  b) 结果展示:更加丰富的结果展示、趋势分析,质量统计和分析等

  c) 问题定位:报错信息、日志更精准,方便问题复现与定位。

  d) 结果校验:加强自动化校验能力,如数据库信息校验。

  e) 代码覆盖率:不断尝试由目前的黑盒向白盒下探,提高代码覆盖率。

  f) 性能需求:完善性能测试体系,通过自动化的手段监控接口性能指标是否正常。

4、接口测试质量评估标准:

  a) 业务功能覆盖是否完整

  b) 业务规则覆盖是否完整

  c) 参数验证是否达到要求(边界、业务规则)

  d) 接口异常场景覆盖是否完整

  e) 接口覆盖率是否达到要求

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

  g) 性能指标是否满足要求

  h) 安全指标是否满足要求

如果你想学习自动化测试,我这边给你推荐一套视频

进阶Python接口自动化测试必备教程(2023全网最详细)

<think>嗯,用户想了解app功能回归测试的方法、流程和注意事项。我从之前的引用中整理了一些关键点,需要系统地组织这些信息。 用户提供的四个引用都很有价值:引用[1]强调回归测试不仅是修复bug的验证,引用[2]提到自动化测试的应用,引用[3]描述了测试工程师的实际操作流程,引用[4]则特别指出交叉测试的重要性。特别是引用[3]提到的专项测试和引用[4]的交叉事件测试,这些在移动端测试中特别重要。 考虑将回答分为方法、流程、注意事项三个主要部分。方法部分需要涵盖手动测试和自动化测试两种方式,特别强调自动化测试在回归场景中的价值。流程设计准备、执行、报告、部署四个阶段,每个阶段都要突出移动端特性,比如环境准备中的真机云平台使用。注意事项要着重强调测试范围界定、移动端特有场景和自动化策略。 在注意事项部分,需要特别提醒用户关于移动端的三个独特要点:交叉事件测试、安装升级路径和弱网环境。这些在web测试中不太常见,但对app质量至关重要。自动化策略建议采用金字塔模型,基础功能用UI自动化,接口层用API自动化,这样效率更高。 最后的相关问题设计要围绕用户可能延伸的需求,比如专项测试细节、自动化框架选择和持续集成方案,这些都是实际工作中常见的后续问题。特别是引用[2]提到过APP自动化测试可以单独成章,所以也把这个问题列入推荐。 </think>以下是App功能回归测试的详细方法、流程及注意事项,结合移动端特性整理: --- ### **一、回归测试方法** 1. **手动回归测试** - **核心功能验证**:针对主业务流程(如登录、支付、核心交互)进行全路径覆盖 - **缺陷闭环验证**:严格复测已修复Bug(引用[1]) - **交叉事件测试**: - 模拟来电/短信/系统通知打断应用(引用[4]) - 后台下载/音乐播放等并发场景 - 应用切换时的状态恢复(如从后台唤醒) 2. **自动化回归测试**(引用[2]) - **适用场景**: - 高频执行的基础功能(如API接口、核心页面跳转) - 多设备兼容性验证(通过云测平台) - **框架选择**: - Android:Espresso, UI Automator - iOS:XCUITest - 跨平台:Appium(推荐多设备并行) --- ### **二、标准流程** ```mermaid graph TD A[测试准备] --> B[执行测试] B --> C[结果分析] C --> D[版本发布] ``` 1. **准备阶段** - **范围界定**(关键步骤): - 基于风险分析确定核心模块(如支付/数据安全模块必测) - 关联功能影响分析(代码依赖图工具) - **环境搭建**: - 真机云平台(如Sauce Labs) - 多OS版本覆盖(Android 8+ & iOS 12+) - **测试资产更新**: - 同步最新用例库(禅道/Jira) - 自动化脚本适配新控件(ID/XPath更新) 2. **执行阶段** - **分层策略**: ```python # 自动化执行优先级示例 priority = { 'L1': '支付流程/数据持久化', # 每日必跑 'L2': 'UI交互/权限控制', # 每周覆盖 'L3': '埋点统计/文案校验' # 按需执行 } ``` - **专项补充**(引用[3]): - 安装/卸载/覆盖升级路径 - 弱网模拟(Charles限速) - 内存泄漏检测(Android Profiler/Instruments) 3. **报告阶段** - 缺陷聚类分析(如60%崩溃来自Android 10特定机型) - 自动化通过率趋势图(历史对比) 4. **发布决策** - 核心功能阻断性问题 ≤ P2级(零容忍) - 次要功能问题需有降级方案 --- ### **三、关键注意事项** 1. **范围管理误区**(引用[1]纠正) - **≠ 仅验证修复Bug**:必须包含关联功能(如修复登录模块需验证第三方登录) - **规避“地毯式测试”**:通过代码覆盖率工具(如JaCoCo)聚焦变更区域 2. **移动端专属风险点** - **中断恢复**: - 后台进程被杀后数据回滚(引用[4]) - 低电量弹窗导致界面遮挡 - **设备碎片化**: - 重点覆盖厂商OS定制层(如MIUI权限管理) - **升级兼容**: - 旧版本数据迁移至新版本(SQLite结构变更验证) 3. **自动化策略**(引用[2]) - **避免UI过度依赖**: - 优先API层校验(FastAPI/Pytest) - 核心业务流程才用UI自动化 - **动态等待机制**:显式等待替代sleep 4. **效率提升** - **热修复验证**:动态补丁测试单独开辟通道 - **云设备调度**:凌晨自动排队执行(节省真机时间) --- > **典型案例**:某电商App支付回归时,未测试中途切换应用到相册的场景,导致返回后订单状态丢失。此问题通过**交叉事件测试**可提前发现(引用[4])。 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值