App测试面试问答（一）

1、Web 端测试和 App 端测试差异

2、App专项测试有哪些？

• 干扰测试：中断，来电，短信，关机，重启等
• 弱网络测试：（模拟2g、3g、4g，wifi网络状态以及丢包情况）；网络切换测试（网络断开后重连、3g切换到4g/wifi 等）
• 安装、更新、卸载安装： 需考虑安装时的中断、弱网、安装后删除安装文件等情况 卸载： 需考虑卸载后是否删除 App 相关的文件 更新： 分强制更新、非强制更新、增量包更新、断点续传、弱网状态下更新
• 界面操作： 关于手机端测试，需注意手势，横竖屏切换，多点触控，前后台切换
• 安全测试： 安装包是否可反编译代码、安装包是否签名、权限设置，例如访问通讯录等
• 边界测试： 可用存储空间少、没有SD卡/双SD卡、飞行模式、系统时间有误、第三方依赖（QQ、微信登录）等
• 权限测试： 设置某个 App 是否可以获取该权限，例如是否可访问通讯录、相册、照相机等

3、ADB命令

查看设备号  adb devices
安装  adb -s  设备号 install 包名
卸载软件  adb -s 设备名 uninstall 软件包名(以com开始的例如：com.qqmusic)
查看安装的软件包名 adb shell pm list package 查看所有的手机软件包名
查看第三方的手机软件包名 adb shell pm list -3 
查看手机当前使用的内存情况，各个线程的内存占用情况  adb shell dumpsys meminfo
查看手机的电池信息  adb shell dumpsys batteryinfo
查看系统资源状态  adb shell top

手机日志 
产看手机日志  adb logcat 
清除手机日志  adb logcat -c 
显示时间  adb logcat -v time 
将日志导入一个文件中  adb logcat > mobile.log
将手机的图片导入到PC端  adb pull 手机文件的路径  电脑路径
例如：Adb pull /storage/emulated/legacy/Pictures/Screenshots/Screenshot_2019-02-21-17-48-55.png F:\

adb 命令录屏  adb shell screenrecord  --time-limit 10 /sdcard/demo.mp4  （10表示录制10秒，默认是180s）
获取当前页面元素(activity名)   adb shell dumpsys activity top
获取任务列表  adb shell dumpsys activity activities
查看app入口(activity)  1)adb logcat |findstr -i displayed ;
					  2)adb shell dumpsys window w | findsrt mCurrent ; 
					  3)aapt dump badging 安装包名.apk | findstr launchable-activity
启动应用  adb shell am start -W -n com.hundsun.winner.pazq/.ui.home.activity.MainContainerActivity -S

设置时间的比率  --pct-touch(percent touch)
adb shell monkey -p app 安装包名 --throttle 25  --pct-touch 50 --ignore-crashes --ignore-timeouts --ignore-security-exceptions --ignore-native-crashes --monitor-native-crashes -v -v -v -s 种子数 执行事件次数 >保存在pc的路径\日志名.log(一般不设置，都选择默认的事件处理事项)

4、App测试流程？

• 当我拿到需求后就要进行需求分析，提炼测试点，设计测试用例，并进行评审。
• 然后如果没有搭建测试环境的话就要搭建测试环境。
• 开发人员把apk把发给我，我就先做一个冒烟测试。（冒烟测试（Smoke Test）是一种快速验证软件基本功能的测试方法，主要用于确认核心功能是否正常运行，避免后续测试浪费在严重缺陷上。）不通过就打回，通过了再进行执行测试用例。
• 先做功能测试，保证每一个功能都能过关。
• 然后再做一些专项测试。主要的专项测试有安装，卸载，升级，交互性，稳定性，弱网，兼容性，性能测试。

5、如何做冒烟测试？

App端的冒烟测试是在每次新构建(Build)或部署后，快速执行一组最核心、最基本的功能测试用例，目的是验证App的关键路径是否通畅、是否存在阻塞性缺陷，确保这个版本足够“稳固”可以进行更深入、更全面的测试（如功能测试、回归测试、兼容性测试等）。

核心目标： 用最短的时间（通常几分钟到十几分钟）确认App的“主干”是否还能跑通，避免测试团队在无法正常使用的基础版本上浪费时间。

App端冒烟测试的详细步骤和要点：

📌 1. 明确冒烟测试的范围 (最重要！)

• 聚焦核心功能： 选择那些如果失败，整个App或核心业务流程就无法继续的功能。这些通常是用户最常用、业务最核心的路径。
• 例子：
• 安装/更新： 能否成功从应用商店/测试分发平台下载并安装/更新App？
• 启动： App能否正常启动，不崩溃？
• 用户旅程主干：
• 电商类： 浏览商品列表 -> 查看商品详情 -> 加入购物车 -> 登录/注册 -> 结算 -> 支付流程(模拟) -> 生成订单。
• 社交类： 登录 -> 查看主信息流/消息列表 -> 发布一条内容(文字/图片) -> 查看他人内容 -> 发送一条消息。
• 工具类： 登录(如果需要) -> 执行核心操作（如：导航App输入目的地开始导航、笔记App创建一条笔记）。
• 关键入口点： 主屏幕/首页是否能正常加载显示？
• 基本导航： 能否在几个最重要的标签页/模块间切换？
• 退出/后台切换： App能否正常切换到后台？从后台切换回来是否正常？能否正常退出？
• 避免： 深层次的边界测试、UI细节、性能测试、兼容性测试等。这些留给后续测试阶段。

🧪 2. 准备测试环境与数据

• 测试设备： 选择1-2台主流的测试设备（覆盖目标用户的主要平台：iOS/Android，最好包含不同屏幕尺寸/分辨率）。无需覆盖所有设备，速度优先。
• 测试账号： 准备1-2个稳定的、权限正确的测试账号（避免因账号问题导致测试失败）。
• 测试数据： 确保有可用的核心测试数据（如：有商品可浏览、有联系人可发消息）。数据可以是预置的或通过测试脚本生成的。
• 网络环境： 通常选择稳定的Wi-Fi或4G/5G网络。如果需要测试弱网，放在后续阶段。
• 构建版本： 获取最新的待测试App安装包（.ipa/.apk 或 TestFlight/TestFairy/Firebase App Distribution等分发平台的链接）。

📋 3. 设计冒烟测试用例

• 数量精简： 通常控制在5-15个用例以内，目标是几分钟内能跑完。
• 正向为主： 主要验证正确的操作是否能得到预期的、成功的结果。例如：
• “使用有效账号密码登录，应成功进入首页。”
• “在首页点击商品A，应成功跳转到商品详情页。”
• “在商品详情页点击‘加入购物车’，购物车图标数字应增加1。”
• 清晰明确： 每个用例步骤清晰，预期结果明确、可验证（避免模糊描述）。
• 原子性： 每个用例尽量独立，避免严重依赖前一个用例的状态（虽然在实际操作中它们可能是串起来的流程）。这样某个用例失败不会导致后续所有用例无法执行。
• 覆盖核心路径： 确保设计的用例串联起来覆盖了第1步定义的核心用户旅程。
• 示例用例集 (电商App)：
• 成功安装/更新最新版本App。
• 启动App，主页面在X秒内加载完成且无崩溃。在
• 主页面浏览商品列表，列表能正常加载显示。
• 点击列表中任一商品，成功进入该商品详情页。
• 在商品详情页点击“加入购物车”，提示加入成功（或购物车数量增加）。
• 点击进入购物车页面，能看到刚加入的商品。
• 点击“结算”（如未登录应跳转登录）。
• 使用有效测试账号登录，登录成功。
• 成功进入订单确认页（地址、支付方式等已选或可正常选择）。
• 点击“提交订单”，成功生成订单（跳转订单详情页或提示成功）。

🚀 4. 执行冒烟测试

• 时机： 在开发提交一个新的、可测试的构建(Build) 后立即执行。建议每日或每次重要代码合并后进行。
• 步骤：
• 安装/更新： 在目标设备上安装或更新待测试的App版本。清除旧版本数据（或首次安装）以避免脏数据干扰。按序执行： 按照设计好的冒烟测试用例顺序逐一执行。
• 严格检查： 仔细核对每一步的实际结果是否与预期结果一致。
• 记录结果： 清晰记录每个用例的执行结果（通过/失败）。如果失败，详细记录：
• 失败的操作步骤
• 实际结果（截图/录屏非常有用！）
• 设备信息（型号、OS版本）
• App版本号
• 错误日志（如果方便获取）
• 快速决策：
• 全部通过： 标记该版本“冒烟测试通过”，通知测试团队可以开始进行更全面的测试。
• 关键用例失败： 如果任何一个核心用例失败（如安装失败、启动崩溃、主流程阻塞），立即中止本次冒烟测试，标记该版本“冒烟测试失败”。将详细的失败信息反馈给开发团队，要求修复并重新构建。不应对一个冒烟失败的版本进行深入测试！

6、Android App测试点

（1）界面测试 ，测试界面跟需求文档中界面原图是否一致，使用不同的手机界面分辨率，以及界面大小等方面进行测试。

（2）功能测试 ，功能测试和web测试差不多，主要测试app对其他相关功能模块的影响。

（3）兼容性测试，兼容性测试主要测试app在不同机型，不同手机系统版本上能不能正常启动，运行。不同屏幕分辨率和屏幕大小能不能正常显示，会不会出现拉伸，显示不全的情况。测试兼容性主要是通过真机和云测相结合的方法做测试的。

（4）网络测试，在不同的网络中进行测试，比如：2G，3G，4G，移动，电信，联通，还有网络之间切换，用fiddler进行弱网测试。

（5）交互性测试，

（6）易用性测试，

（7）异常测试，异常测试手机关机、重启以及断网的一些异常情况

（8）安全测试，安全测试的话，我们会使用xss脚本和sql注入来进行代码攻击，一般使用扫描工具Appscan来进行攻击，然后还会用fiddler进行抓包，查看关键信息有没有进行加密，查看日志中有没有加密，数据库有没有加密，以及界面上的展示和输入是否加密了，会在fiddler抓包的时候设置断点，篡改数据，看能不能篡改成功。

（9）权限测试，

（10）稳定性测试，还会使用monkey测试App的稳定性，一般运行100W次，大概八个小时，查看日志文件，如果出现crash，anr，exception这些单词，则是出现bug，我们会将bug提交给开发，开发修复之后，我们会用种子数来进行回归复测。

（11）性能测试，是为了提高用户的体验感，我们一般是用emaggee来测试监控App的cpu、内存、fps等性能指标，监控完之后编写性能测试报告，然后再对比性能指标，看是否达标。

7、App闪退的可能原因？

• 缓存的垃圾太多，长时间没有清理垃圾
• 运行的程序太多，内存不足导致的闪退
• 版本兼容的问题
• 网络的原因：弱网、2G或3G环境下
• app的sdk和系统不兼容
• 系统升级之后，新版本和老版本不兼容导致的

8、App性能你是怎么测的？

• APP测试主要有了解性能需求，指定测试计划，编写测试用例，和准备测试数据。执行测试用例，提交bug，编写测试报告，这几个流程。

• 手机性能性能测试主要测的是cpu占用率，内存占用率，耗电量，流量以及流畅度。除此之外也要重点关注app的安装，启动，卸载时间，加载页面的响应时间，以及是否有内存泄漏的情况。
• 测试之前，一般是会给我们提供指标。如果没有给的话，我会通过分析竞品，比如要测试京东，我会拿淘宝作为竞品，所测的京东性能要强于淘宝的才行。如果app之前有版本的话，可以拿上一个版本的数据作为对比对象，所测的性能要优于上一个版本的。
• 通常来说，cpu平均占用率不超过10%，内存占用率不超过100M，平均安装时间50S，平均启动时间4S等，这都是一些比较普遍的app的性能，也可以作为一种参考。
• 服务器性能是用jmeter进行测试。主要看并发数，响应时间，事务通过率，以及资源占用情况。
• 首先分析业务，这可以通过组内评审得出，然后准备数据，了解并发数。并发数可以通过需求了解，没有的话可以跟客户交谈总结，或者分析竞品得出。
• 得到了并发数后，按各个场景的使用比例进行分配并发数。先测试单一场景，并发数在原来的基础上增加百分之十到二十，用linux监控资源，找出系统中隐藏的问题，比如通过查看内存前后对比看看有没有内存泄漏，通过查看日志内存溢出（OutOfMemoryError，StackOverflowError），死锁。
• 必要时要考虑二八原则，测试一个场景一般15-30分钟。在测试混合场景，就是各个不同场景，一起压测，找出未满足的需求。测试时间一般为30-60分钟。
• 然后再进行一个负载测试，找出系统所能承受的最大的并发数。然后把所有的报告汇总，进行分析，最后写一个性能测试报告。

9、原生开发、H5开发、混合开发的区别

如何辨别原生和H5？

看加载的方式：如果在打开新页面导航栏下面有一条加载的线的话，这个页面就是H5页面，如果没有就是原生的

断网的情况：把手机的网络断掉。然后点开页面。可以正常显示页面内容就是原生写的。 显示404或者错误页面的是html页面。原生部分页面是可以正常打开的，打不开的原生和H5的报错也是有区别的