测试方法和理论（含app测试方法）

性能

全链路压测

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

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

一、请求接收阶段

1. Web服务器接收请求

   • Nginx/Apache等Web服务器最先接收到HTTP请求

   • 进行基础验证（IP限制、大小限制等）

   • 静态资源直接返回，动态请求转发给应用服务器

2. 负载均衡分配（分布式系统）

   • 将请求分配到合适的应用服务器节点

   • 可能根据负载情况、会话保持等策略进行分配

二、请求处理阶段

1. 请求解析

   • 解析HTTP请求方法（GET/POST/PUT/DELETE等）

   • 解析请求头（Headers）

   • 解析请求体（Body）

三、业务处理阶段

1. 路由到控制器

   • 根据URL路径匹配对应路由

   • 示例（Node.js Express）：

     app.post('/api/login', authController.login)

2. 参数验证

   • 验证必填字段是否存在

   • 验证数据格式（邮箱、手机号等）

   • 验证业务规则（如用户名是否已存在）

   • 常用验证库：Joi（Node）、Validator（Python）、Hibernate Validator（Java）

3. 业务逻辑处理

   • 数据库操作（通过ORM或原生SQL）

四、响应准备阶段

1. 构造响应

   • 设置状态码（200成功、400客户端错误、500服务端错误等）

   • 设置响应头

   • 生成响应体

五、响应返回阶段

1. 返回前端

   • 通过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和密码

Bug生命周期中的状态

1. 新发现(New)

2. 已确认(Confirmed)

3. 已分配(Assigned)

4. 修复中(In Progress)

5. 已修复(Fixed)

6. 已验证(Verified)

7. 重新打开(Reopened)

8. 拒绝(Rejected)

9. 延期(Deferred)

异步接口如何测试？

测试维度	关键问题
消息触发	接口是否正确触发异步任务（如MQ消息、事件）？
结果一致性	异步处理后的结果是否符合预期（如数据库状态、回调内容）？
时序控制	处理延迟是否在合理范围内？是否存在竞态条件？
错误处理	消息丢失、重复消费、处理失败时是否有重试或补偿机制？

工具：

• 代码日志（如ELK）

• 消息队列管理界面（Kafka/Redis/RabbitMQ）

问题排查

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的埋点如何测试？ 

埋点测试的具体步骤: 

1. 确定埋点需求，明确要记录哪些用户的行为

2.测试埋点功能：

手动测试：通过手动操作app出发埋点事件，验证是否有正确记录用户行为数据

日志分析：收集app的日志

抓包工具 ：监控app和服务器之间的通信

3.兼容性测试：测试app在不同的设备下，不同操作系统版本，不同分辨率埋点是否正常

4.a/b测试： 通过a/b测试，将不同的埋点方案应用到不同的用户群体中 

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

 基础验证工具

• 开发工具模式：

  • Android: 使用adb logcat过滤埋点日志

    adb logcat | grep "EventTracker"

  • iOS: 通过Xcode控制台查看NSLog输出

app测试

一、功能测试

1. 核心测试点

• 安装/卸载/升级：验证不同安装方式（应用商店/APK/IPA）

• 注册登录：多种登录方式测试（手机号、第三方账号）

• 核心业务流程：支付流程、内容发布等关键路径

• 中断测试：来电、短信、低电量等场景

• 权限管理：相机、位置等权限的授予和拒绝

二、性能测试

参考链接：APP 性能测试_app性能测试-CSDN博客

1. 关键指标监控

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

2.启动性能指标

1. 启动时间

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

冷启动，热启动 时间查看： 

方式1 ： 

1. 运行应用：首先，在Android Studio中运行你的应用。

2. 打开Profiler：在Android Studio的底部工具栏中找到Profiler图标，点击打开Profiler。

3. 选择Startup：在Profiler的侧边栏中选择“Startup”选项卡。

4. 查看时间：在Startup选项卡中，你可以看到应用的冷启动和热启动时间。冷启动是指应用首次安装或清除数据后的启动时间，而热启动是指应用已经运行过一次后再次启动的时间

方式2：

Android Studio可以通过日志的方式查看应用冷启动和热启动的时间： 

冷启动：

ActivityTaskManager: Displayed com.example.myapplication/.MainActivity: +1s95ms

热启动： 

ActivityTaskManager: Displayed com.example.myapplication/.MainActivity: +205ms

3.运行时性能指标

帧率(FPS)

• 普通页面：≥55 FPS（目标60）

• 游戏类应用：≥30 FPS（休闲）/ ≥60 FPS（竞技）

• 帧抖动率：<5%

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

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

• 人眼感知：

  • 30FPS：基本流畅

  • 60FPS：非常流畅（多数手机标准刷新率）

  • 90/120FPS：高端机型的高刷体验

帧率是数值越高越好 

fps测试方法 

1. 专业工具测试

Android平台：

使用 Android Profiler：打开 Android Studio 并打开项目，点击右下角的 “Android Profiler” 标签打开 Android Profiler。在 Android Profiler 中选择 “CPU” 选项卡，接着点击 “Frame Metrics” 选项卡，即可看到应用程序的帧率数据 

或者： 

# 使用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. 测试场景设计

1. 列表滑动测试：

   • 快速滑动长列表（200+项）

   • 记录惯性滚动阶段的FPS

2. 页面转场测试：

   • 反复切换Tab/页面

   • 监测过渡动画的帧率

3. 复杂布局测试：

   • 加载含多图片/动画的页面

   • 检查FPS波动情况

CPU占用率

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

利用 Android Studio 自带的 Android Profiler：

• 打开 Android Studio：启动 Android Studio 并打开需要监控的项目。
• 进入 Android Profiler 界面：点击下方的 “Profiler” 标签，在左侧选择设备，右侧会显示 CPU、内存、网络流量等信息

或者： 

监控命令：

adb shell top -n 1 | grep <package>

4.资源消耗指标

电量消耗

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

查看电量消耗的方式： 

1. 在 Android Studio 中，选择 “View”>“Tool Windows”>“Profiler” 或点击工具栏中的 “Profile” 图标打开 Android Profiler。
2. 如果出现 “Select Deployment Target” 对话框，选择要进行分析的设备和应用。
3. 点击 “Energy” 时间轴中的任意位置以打开能耗性能剖析器，它会立即开始显示应用的估算耗电量

流量消耗 

Android Profiler: 

在 Android Profiler 窗口中，点击 “Network” 选项卡，之后就能看到应用的网络流量消耗情况

三、兼容性测试

兼容性测试：

1.新旧版本的兼容：从旧版本升级到新版本 

2.系统兼容性： ios系统： 15.8  - 18. 4 ； android系统： 10 -15 

• iOS 18.3：29.58%
• iOS 18.1：25.81%
• iOS 18.2：8.3%
• iOS 17.6：7.91%
• iOS 16.7：3.57%
• iOS 15.8：3.04% 

• Android 14：占比 27.4%，是当前使用最广泛的安卓版本。
• Android 13：安装率为 16.8%，是较受欢迎的版本之一。
• Android 12：占比 12.8%，仍有相当一部分用户在使用。
• Android 11：市场份额为 15.9%，在安卓系统版本中也占有一定比例。
• Android 10：占比 10.2%，还有不少用户停留在这个版本。
• Android 9 Pie：占比 5.8%，仍有一定的市场份额。
• Android 15：虽于 2024 年 9 月发布，但由于提供升级的品牌数量有限，装机率仅 4.5%

3.屏幕兼容：  

安卓： 全面屏，非全面屏，曲面屏，折叠屏

ios： 刘海屏， 非刘海屏幕

4.分辨率兼容

5.尺寸兼容

6.网络兼容

wifi 和 4g 互相切换

有网和无网互相切换

四、弱网测试 

移动端： 

• QNET：腾讯推出的适用于安卓系统的 App 弱网测试工具。不借助 PC 或服务器，在智能手机上安装即可搭建弱网环境，覆盖国内所有省份及海外 47 个主流国家地区的运营商实时网络数据，提供地铁、电梯等 20 多种真实场景。支持 adb 命令驱动，可实现自动化弱网测试，还具备网络数据包抓包功能，便于分析网络数据问题。
• Network Link Conditioner： iOS 自带的弱网测试工具，也可在 MacBook 中使用。通过 Xcode 连接手机，激活开发者选项后可放开此功能来模拟弱网5。可方便地设置各种网络条件，如不同的带宽、延迟、丢包率等，以模拟弱网环境 

conditioner： 调节器

PC 端

• Fiddler：是一款 PC 端安装的抓包工具，作为代理服务器，可设置延迟参数来模拟不同的网络情况，但主要支持延迟模拟，不支持丢包、带宽等配置。
• Clumsy：专门针对弱网测试的 PC 端工具，作为代理服务器，支持延迟、丢包、带宽等弱网配置，使用较简单。可对拦截的网络数据包进行多种操作，如延迟发送、随机丢弃、节流、重发、乱序、篡改等。
• Network Emulator Toolkit：专门针对弱网测试的工具，支持延迟、丢包、带宽等弱网配置，可设置丢包率、数据包队列长度、乱序等参数，适用于 Windows 系统

五、国际化测试

语言测试： 

界面文本:  语言翻译要符合当地语言习惯；  不同的语言字符长度差异，防止文本在界面上显示不全

日期和时间的格式：验证 APP 在不同地区是否能正确显示日期和时间

数字和货币的格式： 确认数字的显示格式，包括小数点、千分位分隔符等符合目标地区的习惯。对于涉及货币的功能，确保货币符号和货币格式正确，并且能够根据不同地区的货币进行准确的换算和显示

地区和文化测试：   

避免app中出现和目标地区的文化习俗冲突的内容和符号

比如： “nigger” 是一个非常具有冒犯性、贬义且种族歧视色彩极重的词汇，用来指代黑人

输入和键盘测试 ： 

• 输入法支持：测试 APP 在不同语言环境下对各种输入法的兼容性，确保用户能够顺利输入文本，包括拼音输入法、手写输入法、语音输入法等。

• 特殊字符和符号：验证 APP 能够正确处理和显示不同语言中的特殊字符和符号，如日语的假名、韩语的谚文、俄语的西里尔字母等

本地化测试：  

和本地应用的集成：比如登录方式，支付应用，社交平台的分享  

本地法律法规：隐私政策，数据保护法规

六、 adb常用命令

设备连接与管理
adb devices  查看当前连接的设备:查看当前通过 USB 或网络连接到计算机的 Android 设备或模拟器

adb connect <device_ip_address>  :需要通过网络连接到android设备，可以使用此命令，确保涉笔和计算机在同一个网络中

adb disconnect <device_ip_address>  ： 断开和指定ip地址设备的连接

应用安装与卸载
adb install/uninstall <apk文件路径>  ： 将指定的apk安装/ 卸载 到设备上 

adb install -r <path_to_apk> :强制安装apk文件

文件操作

adb pull <device_path> <local_path>  :  从设备中拉取文件或者目录

adb pull <local_path> <device_path>:  将文件或者目录推送到设备

系统操作

adb reboot ：  重启android设备 

adb reboot recovery : 将设备重启并进入到recovery 模式，通常用于恢复系统(尝试恢复出厂设置)，安装更新等操作

日志查看

adb logcat 查看日志

logcat | grep "error" :  将logcat的输出当作grep的输入

adb bugreport   输出全部的日志到文件夹

屏幕截图和录制

adb shell screencap <device_path>   ： 截图设备屏幕，并将截图保存到设备的指定路径

adb shell screenrecord <device_path> ：录制设备屏幕

自动化测试

adb shell mokey     android自动化测试的一种手段，模拟用户的按键输入，触摸屏输入

adb shell monkey -p com.example.app 100  ： 这条命令表示对包名为 com.example.app 的应用发送 100 个伪随机用户事件 

adb服务器

adb start-server ：  启动adb服务器 

使用的场景：

连接到新设备的时候，adb服务器若未启动，就无法识别这些设备

设备断开连接(比如拔掉usb线)后又重新连接 ，就可以启动或者重启adb服务器来重新识别设备

adb kill-server ： 停止当前的adb服务器 

adb shell 可以进入设备或者模拟器的shell环境
adb shell pm list packages 查看手机端安装的所有app包名
adb shell ps/top  查看当前终端中的进程信息