短网址统计_敦煌网网站推广方式_湖北百度推广电话_推广普通话手抄报图片

性能

全链路压测

1.明确压测的目标：确定系统容量的上线，发现性能瓶颈

2.环境准备：搭建和生产环境一致的压测环境

3.业务场景梳理：识别核心业务流程，确定每个环节的流量比例

4.设计压测方案：并发量，持续时间，递增策略，测试数据

5.压测工具的选择：jmeter

6.监控和数据收集：

系统指标： cpu，内存，磁盘

中间件：数据库，缓存，消息队列

业务指标：错误率，响应时间，tps

项目

在项目中遇到的最困难的bug是什么？

门店侧操作收货，会先调拨单状态为已入库，再去更新补货域的总仓补货单状态

同时也会去更新总仓补货单的入库数量

1.流程长，造数难

2.难以发现

3.难以复现

介绍业务上印象深刻的bug？

tc退换货的功能，有个页面展示供应商名下待交接售后单，按照以往的经验，这个页面也不用做分页，数据量不大

结果实际操作的时候，业务累计了一个礼拜几百条没有交接的售后单，但是进入这个页面直接卡住了

后来的一个处理就是：增加分页逻辑，

经验：在不确定的需求细节的情况下，一定要找产品核对需求点的限制情况，不要自己想当然

打印卡板码

有紧急需求怎么办？

1.评估目前手上在测试的需求工作量，告知产品和项管可能存在风险，确认可延期

2.确定紧急需求的上线时间，安排编写用例的时间，和测试时间

3.组建沟通群：拉相关人员进群沟通，明确每个人的分工和时间节点

4.保持同步进度，优先解决阻碍流程的问题

跨部门协作如何和对方沟通，如果有个需求对方配合

1.项目管理人员会参与迭代会，知道需求要跨域，告知这个需求的紧急程度，以及我们这边的预计上线时间

2.会由项管人员和对方的项管，产品进行沟通，安排对应的开发人员和测试人员

3.开跨部门的需求评审会议：让两个域对需求达成一致

4. 建立沟通群：日常的需求交流和疑问点在群里沟通，同步双方的测试进度

测试资源怎么分配，怎么协调？

1. 评估测试任务，要测试的功能模块大小

2.合理的安排任务，保证每个人的任务量饱和度

3.协调方面：定期开沟通会，比如每日站会，同步测试的进度

4.建立清晰的沟通渠道：拉群进行沟通

5.使用项目管理工具：可以清楚看到任务的进度，人力资源的安排

测试在项目中做哪些工作？

1.参与需求评审会议

2.制定测试计划

3.编写测试用例

4.执行用例跟踪线上bug

测试数据一般是哪里获得？

1.测试人员自己造数据

2.运维从生产环境导入相关的数据，当然这里安全性的数据，他们不导

负责的项目，如何确保测试的完整性？

1. 指定测试计划： 考虑多个维度的测试：功能测试，兼容性测试，弱网测试，性能测试，安全测试

2.确定测试的模块范围： 功能要测试哪些模块，无需测试哪些模块，以及功能影响到的范围

3.保证测试用例的覆盖率：每个需求点都要有对应的用例，通过代码覆盖率保证代码的分支都有测试到

项目上线因为开发延迟，测试时间被压缩怎么做？

1. 评估自己的工作量，是否存在风险，若存在，则需要提出来告知产品和开发，以及领导

需要协助

2.申请加班，看能否完成

3.若手上还存在其他的工作，那就和领导确认，是否可以先完成优先级高的工作，其他工作排到下个迭代完成

给你一个需求，具体讲下如何测试？

1. 熟悉需求，看需求文档是否完整：需求背景，改动点，对历史数据是否有处理，是否需要跨域，流程图，状态图是否完整，权限开放

2.拿到需求，先确认上线时间，大致阅读一遍需求，确定大致工作量，需要多少测试资源

3.对用例编写，测试时间进行预估时间，和开发对齐提测时间

4.接下来就是编写用例，用例评审，测试和bug跟踪，每日同步测试进度

5.最后告知是否可上线，是否存在上线风险，没有问题的化就发布上线

敏捷测试

通过持续，快速，协作的测试方式，在快速迭代中保证质量上线

核心原则：

1.持续测试：测试贯穿整个周期

2.团队协作：比如每日站会同步进展，测试人员，开发和产品紧密合作

项目的qps为多少？

我们的bms项目是一个接单生产计费流水单，计费单，主要是服务于总仓，日均请求在几十 - 几百的，平均qps =1500 / 86400 =0.017

峰值：（1500*70%）/2小时* 3600 = 0.146

若qps涨10倍，如何处理？

测试阶段如何确保质量把控到位？

1.测试计划：明确测试范围，测试的重点

2.执行测试时：严格按照用例执行，不要有用例遗漏；考虑并发，异常场景，大数据量，兼容性的测试

3.bug解决：及时跟进bug进度，对bug进行验证，看问题是否有解决，以及会不会影响到其他的功能

3.进行回归测试：对可能影响到的主流程进行回归测试

4.邀请业务人员或者产品进行功能验收

在写用例的时候如何提高用例的覆盖度？

1. 针对每个需求点，使用等价类划分，边界值法，错误推断法等进行考虑

2.参考以前项目的经验，考虑比较容易出现问题的点

3.询问开发：本次修改的功能点可能影响到哪些模块，进行覆盖，参考开发的技术文档

3.用例评审

上线通过标准是如何制定的？

功能上：所有的需求点都要实现

用例：用例要100%全部执行

兼容性：在safari ，chrome上都要验证通过

性能:大数据量的情况，并发的情况

部分功能需要产品和业务进行验收

如果在上线前发现严重bug，该如何处理？

1.评估bug的影响范围，判断需要修改的bug的时间，以及它的一个临时解决方案

2.测试人员准备测试用例，督促开发人员修改bug

3.测试的时候重点回归bug的影响范围

4.随时在群里同步bug的修复进度

5.记录下bug的详细原因，方便后续复盘

为什么想做测试？

1. 测试人员作为软件质量的守门人，直接关系到用户的最终体验，在这个过程中发现和预防缺陷带来的成就感

2.作为测试需要同时具备技术能力和业务理解能力

3.作为测试要有独特的思维：享受破坏性思维的乐趣，思考各种可能会出现的情况，同时培养细致入微的分析能力

前端发送数据到后端，服务器会做什么操作？

一、请求接收阶段

Web服务器接收请求
- Nginx/Apache等Web服务器最先接收到HTTP请求
- 进行基础验证（IP限制、大小限制等）
- 静态资源直接返回，动态请求转发给应用服务器
负载均衡分配（分布式系统）
- 将请求分配到合适的应用服务器节点
- 可能根据负载情况、会话保持等策略进行分配

二、请求处理阶段

请求解析
- 解析HTTP请求方法（GET/POST/PUT/DELETE等）
- 解析请求头（Headers）
- 解析请求体（Body）

三、业务处理阶段

路由到控制器
- 根据URL路径匹配对应路由
- 示例（Node.js Express）：
```
app.post('/api/login', authController.login)
```
参数验证
- 验证必填字段是否存在
- 验证数据格式（邮箱、手机号等）
- 验证业务规则（如用户名是否已存在）
- 常用验证库：Joi（Node）、Validator（Python）、Hibernate Validator（Java）
业务逻辑处理
- 数据库操作（通过ORM或原生SQL）

四、响应准备阶段

构造响应
- 设置状态码（200成功、400客户端错误、500服务端错误等）
- 设置响应头
- 生成响应体

五、响应返回阶段

返回前端
- 通过HTTP协议返回响应

接口测试中有没有测试出什么问题？

参数校验必填/非必填

参数的边界条件

代码逻辑问题

你是如何做接口测试的？

1.罗列需要测试的场景，分p0，p1

2.走一边流程，确定场景的接口

3.拿接口文档，编写测试用例：包括正常请求，异常请求，边界值测试

3.选择工具：jmeter/ pytest

4.执行测试

5.验证测试结果：检查响应码，响应数据，接口的响应时间等

平时工作中是怎么去测的？

1.看需求文档，理解需求

2.确定需求要上线的时间，拆分任务，进行排期

3.编写用例

4.进行测试用例评审

5.测试中同步测试进度

6.测试工作完成之后，报告遗留问题，是否能上线，以及具体的上线时间

7.进行线上环境的跟踪

测试的策略有哪些？

1.冒烟测试

2.功能测试

3.兼容性测试

4.性能测试

如何制定测试计划？

1. 需求分析，确定测试模块和范围

2.明确需求的上线时间点，确认测试资源，拆分任务，确定每个任务的时间节点

3.进行风险评估，识别潜在的风险，并和产品开发讨论应对措施

接口测试中，哪些参数适合设置为环境变量？

基础的url

数据库连接的host

用户id和密码

问题排查

app无响应或者是闪退如何分析问题？

1.看是不是特定的页面，操作导致的

2.adb查看日志：场景的比如空指针

4.检查app版本和设备是不是不兼容

系统出现了500，如何分析问题？

先看服务器日志

再由开发检查代码

服务器资源，或者内存不足导致的

有时候下订单成功，有时候下单失败是什么原因？

抓包对比数据

看前端请求，若请求不同，则前端问题

若返回数据不同，则后端代码有问题，去看日志，数据库，提交对应信息给到开发，进行处理

返回数据有问题，如何排查？

1. 抓包，看前端请求url，参数

2.和接口文档对比，看是否哪个字段有问题

3.查看数据库，看是否数据库本身的值就有问题

4.如果数据库没有问题，那可能就是后端代码问题，看对应的日志

测试用例

给你一个数据量很大的表格，里面有字段一个是下拉框，一个是文本框，设计用例

1. 基础功能测试

用例编号	测试场景	操作步骤	预期结果
TC-001	下拉框基础选择	1. 点击下拉框 2. 选择任意选项	选中项正确显示，值正确存储
TC-002	文本框基础输入	1. 在文本框输入合规数据 2. 提交表单	输入内容正确显示和存储
TC-003	下拉框默认值验证	1. 加载表格页面	下拉框显示预设默认选项
TC-004	文本框默认值验证	1. 加载表格页面	文本框显示预设默认值或为空

2. 下拉框专项测试

用例编号	测试场景	操作步骤	预期结果
TC-101	下拉框选项完整性	1. 展开下拉框 2. 滚动检查	所有选项完整显示，无缺失
TC-102	大数据量选项性能	1. 下拉框含1000+选项 2. 展开选择	在3秒内完成渲染，选择流畅
TC-103	选项搜索功能	1. 在下拉框输入关键字搜索	正确过滤显示匹配选项
TC-104	选项分页加载	1. 滚动下拉框到底部	新选项自动分页加载
TC-105	选项选择后联动	1. 选择特定下拉选项	可能触发： - 文本框禁用/启用 - 文本框默认值变化

3. 文本框专项测试

用例编号	测试场景	操作步骤	预期结果
TC-201	输入长度限制	1. 输入超过最大长度字符	自动截断或阻止输入
TC-202	格式验证	1. 输入不符合格式的数据 2. 移出焦点或提交	显示明确错误提示
TC-203	特殊字符处理	1. 输入<>'"&等特殊字符	正确存储和显示
TC-204	粘贴操作验证	1. 从外部复制文本粘贴到文本框	内容正确解析和显示
TC-205	多语言输入	1. 输入中文/日文/阿拉伯文等	字符正确显示和存储

4. 组合交互测试

用例编号	测试场景	操作步骤	预期结果
TC-301	下拉选择影响文本框	1. 选择下拉框特定选项 2. 检查文本框状态	文本框可能： - 变为必填 - 改变输入规则 - 显示默认值
TC-302	文本框输入后下拉状态	1. 在文本框输入特定内容 2. 检查下拉框选项	下拉框选项可能动态过滤
TC-303	组合条件提交	1. 选择特定下拉选项 2. 输入关联文本框内容 3. 提交	组合数据正确存储

5. 大数据量性能测试

用例编号	测试场景	操作步骤	预期结果
TC-401	万级数据加载	1. 打开含10万行数据的表格	首屏在2秒内完成渲染
TC-402	带条件筛选性能	1. 选择下拉框特定选项 2. 在文本框输入筛选条件	筛选结果在1秒内显示
TC-403	分页操作响应	1. 点击下一页/末页按钮	页面切换流畅，无卡顿
TC-404	大数据量编辑保存	1. 批量修改100行数据 2. 保存	保存操作在5秒内完成

6. 异常情况测试

用例编号	测试场景	操作步骤	预期结果
TC-501	下拉框选项为空	1. 模拟空选项情况 2. 尝试选择	显示"无选项"提示
TC-502	文本框SQL注入	1. 输入SQL注入代码	被安全拦截或转义存储
TC-503	网络中断时操作	1. 断网后尝试选择/输入	有友好提示，数据不丢失
TC-504	并发修改冲突	1. 两人同时修改同一行	后提交者收到冲突提示

给你四个按钮，134有业务逻辑必填，2为选填，设计测试用例

ui	必填项有* 标识，选填无*号标识
基础功能测试	1不填，提示必填 3不填，提示必填 4不填，提示必填 134都填，提交成功 1234都填，提交成功
边界值测试	按照需求文档，分别验证1，2，3，4的最大值，最小值
异常情况测试	按照需求文档，分别验证1，2，3，4非法格式
必填项校验	遗漏必填项，点击提交，提示失败，补全必填项，再次提交，能提交成功
数据存储验证	验证提交后数据的正确存储
用户体验测试	验证错误提示的友好性和明确性
	确保必填验证是后端校验，而不仅仅是前端校验

文件上传的测试用例

ui测试：文字描述，按钮位置是否正确，上传区域颜色和大小是否合适

正常场景：支持的文件格式都可正常上传；上传的进度条是否正常；可多文件上传；文件上传后内容正确，文件内容可能要做内容的校验

异常场景：不支持的文件格式要有提示；文字标题过长；重复文件名上传；超大文件上传有提示；取消上传看下能否系统数据

网络测试：验证在不同的网络下能否正常上传；上传过程中网络中断要有提示；恢复网络后能继续上传；

权限测试：不同的用户角色的上传权限，普通用户，系统管理员是否符合设定

兼容性测试：测试在不同的浏览器chrome，safari

并发：多个用户同时上传文件

app的埋点如何测试？

测试维度	检查目标	常见问题示例
数据准确性	埋点参数是否正确（事件名/属性值）	属性值传错（如`gender=1`实际应为`male`)
数据完整性	是否所有关键路径都触发埋点	支付成功事件漏埋
数据一致性	客户端与服务端数据是否一致	客户端记录`click`但服务端未收到
性能影响	埋点是否导致卡顿/耗电	高频埋点引发ANR

基础验证工具

开发工具模式：
- Android: 使用adb logcat过滤埋点日志
```
adb logcat | grep "EventTracker"
```
- iOS: 通过Xcode控制台查看NSLog输出

app测试

一、功能测试

1. 核心测试点

安装/卸载/升级：验证不同安装方式（应用商店/APK/IPA）
注册登录：多种登录方式测试（手机号、第三方账号）
核心业务流程：支付流程、内容发布等关键路径
中断测试：来电、短信、低电量等场景
权限管理：相机、位置等权限的授予和拒绝

二、性能测试

1. 关键指标监控

指标	测试工具	合格标准
启动时间	Android Studio Profiler	<1.5秒
内存占用	Xcode Instruments	无泄漏
CPU使用率	PerfDog	<30%
流量消耗	Network Profiler	优化后降低20%
电量消耗	Battery Historian	无异常耗电

2.启动性能指标

1. 启动时间

指标类型	测量方式	优秀标准	测试工具
冷启动	进程完全关闭到首帧显示	<1.5秒	Android Studio Profiler, Xcode Instruments
热启动	应用在后台到恢复显示	<0.5秒	adb shell am start -W
温启动	部分资源保留的启动	<1.0秒	Firebase Performance Monitoring

测量代码示例：

# Android冷启动测量
adb shell am start -W -n com.example.app/.MainActivity | grep "TotalTime"

二、运行时性能指标

2. 帧率(FPS)

普通页面：≥55 FPS（目标60）
游戏类应用：≥30 FPS（休闲）/ ≥60 FPS（竞技）
帧抖动率：<5%

测试工具：PerfDog, GT, Xcode Core Animation

3. CPU占用率

场景	合理范围	异常排查点
前台运行	≤20%	峰值超过80%
后台运行	≤5%	持续高占用
单核占用	≤70%	核心负载不均

监控命令：

adb shell top -n 1 | grep <package>

三、资源消耗指标

4. 电量消耗

场景	标准	测量方法
前台使用	≤15%/小时	Battery Historian
后台待机	≤1%/小时	iOS Energy Log

3. FPS

FPS（Frames Per Second，帧率/帧每秒）：每秒渲染的帧数（如60FPS=每秒60帧）是衡量APP界面流畅度的核心性能指标，表示屏幕每秒钟刷新画面的次数

人眼感知：
- 30FPS：基本流畅
- 60FPS：非常流畅（多数手机标准刷新率）
- 90/120FPS：高端机型的高刷体验

fps测试方法

1. 专业工具测试

Android平台：

# 使用adb命令获取SurfaceFlinger数据
adb shell dumpsys SurfaceFlinger --latency <window_name>

iOS平台：

# 使用Xcode Instruments的Core Animation模板
1. Xcode → Product → Profile → Core Animation
2. 勾选"Color Hits Green and Misses Red"

2. 核心指标

指标	说明	达标标准
平均FPS	测试期间平均帧率	≥55（目标60）
帧率稳定性	FPS波动标准差	≤5
掉帧次数	FPS<50的帧数	≤3次/分钟
帧耗时	单帧渲染时间	≤16.67ms（60FPS）

3. 测试场景设计

列表滑动测试：
- 快速滑动长列表（200+项）
- 记录惯性滚动阶段的FPS
页面转场测试：
- 反复切换Tab/页面
- 监测过渡动画的帧率
复杂布局测试：
- 加载含多图片/动画的页面
- 检查FPS波动情况