对于手机端测试，按照平台来分，分为Android和IOS两大主流系统，对于ios和Android区别，Android开源导致碎片化比较严重，bug比较多，而IOS通常bug会少一些。
还有分辨率测试，Android手机分辨率有20多种，IOS较少一些。
再就是手机操作系统，Android系统太多了，IOS较少，但是升级之后不能够降级。
一、功能测试
对于手机app来说，和我们测试web项目差不太多，也是各种测试方式需要考虑进来，比如说逻辑功能测试功能是否合理。
二、安装与卸载测试
1.软件安装后是否可以正常运行，安装过程中是否可以取消。
2.安装空间不足时，是否有相应提示。
3.是否可以卸载应用（可通过桌面卸载，也可以通过软件卸载。）
4.卸载是否支持取消功能，单击取消后软件卸载功能是否正常,卸载后文件是否全部删除所有的安装文件夹。
5.从不同的应用市场下载进行安装测试，比如测试小米市场，华为市场，应用宝，安卓市场，安智市场的安装测试。
三、软件升级测试
1.当客户端有新版本时，是否有更新提示。
2.当版本为非强制升级版时，用户可以取消更新，老版本是否能正常使用，且在用户在下次启动app时，仍能出现更新提示。
3.当版本为强制升级版时，当给出强制更新信息后用户没有做更新时，退出客户端，下次启动app时，仍出现强制升级提示，当然现在强更已经很少出现了。检查更新后各个功能是否能正常使用。
4.在线跨版本升级后能否正常使用，当然现在主流的安装更新方式开始向热更新热部署方式转变，就是在用户不需要手动更新的情况下，完成版本的静默更新，这个技术是有难度的，需要看公司中程序员的技术能力还有就是是否有这样的产品需求。
四、登录测试
1.基本上每一款app都有登录注册功能，所以在测试App的时候，登录测试是必不可少的一项。
2.我们做登录测试的时候，往往包含这么些项，登录用户名和密码错误时，界面有是否有提示信息，如果登录成功，用户主动退出登陆后，下次进入app时，是否直接进入登陆界面
3.密码更改后，登录时是否做到了有效数据的校验，对于未登录状态时，一些页面的操作，是否做了控制
4.切换账号登录，检验登录的信息是否做到及时更新，对于多个端（web、iso、android等）进行操作时，确保数据库操作无误，且每个端可以及时看到数据的更新,一个账号只允许一台机器登陆的软件，需要账号登录多个手机时，是否将原用户踢下线，且能够给出提示信息,用户登录状态太久，session会过期，会出现“虽然是登录状态，系统会提示用户没有登陆”。
五、安全性测试——权限测试
对于手机权限，如果我们是刚开发不知名的app，权限这块尽量少一些，这些权限在安装的时候都必须用户同意。在Android 6.0之后，权限需要动态的申请，我们测试的时候,需要测试在使用到这些权限的时候，程序员是否做逻辑判断，用户同意权限应该怎么操作，不同意权限又应该怎么操作。
六、消息推送测试
1、未锁屏时，应用后台运行，消息推送是否可正常接收，未锁屏时，APP客户端使用过程中，是否可以收到消息提醒，且点击可查看。
2、锁屏时，手机消息栏是否可以接收到消息提醒。且点击可查看。点击后消息栏中消失。
3.当推送消息是针对登录用户的时候，需要检查收到的push与用户身份是否相符，没有错误的将其他人的消息推送过来
4.push推送消息是是否能有针对性的推送，如相应内容推送给相应用户（精准推送）
5.退出登录后，是否接受push推送（根据需求来）
七、前后台切换测试
1、APP切换到后台，再回到APP，检查是否停留在上一次操作界面；检查功能及应用状态是否正常；程序是否崩溃，功能状态是否正常，尤其是对于从后台切换回前台数据有自动更新的时候
2、手机锁屏解屏后进入app注意是否会崩溃，功能状态是否正常
3、当APP使用过程中有电话进来中断后再切换到APP，功能状态是否正常
当关闭APP进程后，在开启APP，APP能否正常启动
对于有数据交换的页面，尤其是有视频图片之类的页面，每个页面都必须要进行前后台切换、锁屏的测试，这种页面最容易出现崩溃。
八、UI测试
确保产品UI符合产品经理制定的原型图与效果图
一般涉及界面（如菜单、对话框、窗口和其他可视控件）布局、风格、文字是否正确，页面是否美观，操作是否友好。
九、兼容性测试
1、兼容性测试主要考虑手机的版本，型号，分辨率，现在手机碎片化比较严重，各个版本，比如Android，从Android4.0到Android8.0的版本它是不一样的，然后现在各大手机厂商像华为，三星，小米，锤子，魅族，vivo这些厂商都修改android源代码。
2、还有手机分辨率，现在主流的可能是1920*1080，但是还有好多其他分辨率，比如720*1280，还有一些更大分辨率的手机，都要考虑这些分辨率的兼容，不然用户视觉体验就不好。
3、兼容测试，公司中会买好多测试机来太让我们进行测试，一般是不同厂商的手机，当然还有第三方云测平台，比如testin还有腾讯wetest，就可以做兼容性测试。可以一次性测试100台测试机，同时会有相应的兼容报告，bug报告。
十、网络环境测试
1、测试2G、3G、4G、wifi、有网、无网、弱网情况下应用的运行
2、网络不好时，提交数据是否一直处理提交中，是否会有延迟，数据交换失败是否会有提醒
3、有网到无网再到有网环境时，数据是否可以自动恢复，正常加载
4、无网络时，各种提示信息是否友好，数据本地化是否正确（比如提示当前已断开网络，请检查网络设置；
5、还有从wifi环境切换到4G环境提示是否启用4G网络，会产生扣费。
十一、性能测试
对于性能测试，（eclipse和Android studio中本身有检测cpu和内存的工具，也有检测手机内存泄漏的工具）靠工具来测试手机cpu占用，内存占用，电池温度等，以及测试我们的app在后台持续运行的流量消耗和电量消耗问题。
十二、mokey测试
1、除了常规的功能测试，我们还会做压力测试，比如对于Android手机，我会使用adb指令进行一些相应的操作，比如通过adb查看设置，进入设备，抓取log，我们测试的时候，会使用adb logcat所抓出来的log日志存到电脑，发给开发，方便他们快速解决bug。
2、另外，我还会使用monkey对app进行测试，可以使用monkey对app做压力测试，主要就是测试操作app的时候，程序是否会崩溃。
我们使用adb shell monkey 指定对应的app，执行要测试的次数，指定要触摸的比率，超时时间和忽略崩溃信息，就可以执行测试，将测试log存到某个位置，然后把测试出的bug 日志发送给开发。
adb shell mokey -p 指定要测试的包名
--ignore-crashs 忽略崩溃
--ignore-timeout 忽略超时
--throttle 指定延迟时间毫秒
-s 指定测试种子 指定测试次数，然后将文件 >输出到磁盘中。
十三、Monkey测试的优点和缺点？
优点：
1、使用简单，节省了重复性操作的时间，随机输入可能会发现一些平常意想不到的缺陷。
2、Monkey虽然可以根据一个指定的命令脚本发送按键消息，但其不支持条件判断，也不支持读取待测界面的信息来执行验证操作。
3、可对Monkey Test的对象，事件数量，类型，频率等进行设置。
缺点：
测试的对象仅为应用程序包，有一定的局限性。
十四、APP测试与web测试的区别
相同点：
同样的测试用例设计方法；
2、同样的测试方法；都会依据原型图或效果图检查UI；
3、测试页面载入和翻页的速度、登录时长、内存是否溢出等；
4、测试应用系统的稳定性
不同点：
app的中断测试：来电中断、短信中断、蓝牙、闹钟、拔插数据线、手机锁定、手机断电、手机问题（系统死机重启）
2、app的安装卸载：全新安装、升级安装、第三方工具安装、第三方工具卸载、直接卸载删除、消息推送测试、手机授权测试、前后台切换、网络环境（wifi/2G/3G/4G/无网络）
3、兼容性测试：web项目考虑不同浏览器的兼容；app需要考虑手机不同操作系统、不同机型、不同屏幕等
4、web自动化测试工具较常用：selenium，而手机自动化monkey、monkeyrunner
app测试平台：百度云测、testin云测--------
十五、接口测试，测试的时候这几个方面:
1、改变请求参数，看响应结果是否和接口文档一致
2、查看参数是否有敏感信息（比如个人账户信息，资金信息）
3、查看是否对关键参数进行加密处理(密码信息)
4、所有列表页接口必须考虑排序值
5、接口返回的图片地址能否打开，图片尺寸是否符合需求；
6、接口有翻页时，页码与页数的异常值测试；
7、当输出参数有联动性时，需要校验返回两参数的实际结果是否都符合需求
8、每个接口入参的默认值、异常类型、非空校验
9、入参支持多个值时，要考虑传的值的个数多的情况下，接口会不会报错
实际落地:
十六、get请求和post请求区别:
1、get请求通常从服务器获取数据，请求参数在地址栏之后，数据量有限制，不够安全
2、Post请求通常往服务器提交数据，请求参数在请求实体中，数据量无限制，较为安全。在postman中post请求可以设置form-data类型，上传文件，也可以设置raw类型，可以上传xml类型的报文。
十七、https包怎么抓?
1、https和http协议区别在于https多了一个ssl协议，更加安全，默认端口是443，而http协议默认端口是80
2、抓取https，需要申请证书，在fiddler或者charles中，可以模拟下载证书，下载之后，在手机上访问代理服务器的ip和端口，下载证书，就可以抓取到https的请求了。
十八、当你参加需求评审时，你的评审准则是什么？
完整性：每一项需求都必须将所有要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。
正确性：每一项需求都必须准确的陈述其要开发的功能。
一致性：指与其它软件需求或高层需求不相矛盾
可行性：每一项需求都必须是已系统和环境的权能和限制范围可以实施的。
5、无二义性：对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求简明的用户性的语言表达出来。 6、健壮性：需求的说明中是否对可能出现的异常进行了分析，并且对这些异常进行了容错处理。
7、必要性：可理解为每项需求都是用来授权你编写文档的“根源”，要使每项需求都能回溯至某项客户的输入。
8、可测试性：每项需求都能通过设计测试用例或其它的验证方法来进行测试。
9、可修改性：每项需求只应在SRS中出现一次。这样更改时容易保持一致性。另外，使用目录列表、索引和相互参照列表方法使软件需求规格说明书更容易修改。
10、可跟踪性：应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好(f i n e - g r a i n e d )的方式编写并单独标明，而不是大段大段的叙述。
11、分配优先级：应当对所有的需求分配优先级。如果把所有的需求都看作同样的重要，那么项目管理者在开发或节省预算或调度中就丧失控制自由度
以上特点也是需求评审的要点，评审前可以根据实际情况指定需求评审检查表来帮助评审。 可以根据以上特点对需求进行评审
需求评审
1 产品经理或者SR把需求书发下来给开发和测试
2 测试先看一遍，进行需求分析。测试组长编写测试计划，并且分配测试任务给测试人员（2天时间）（此时开发也在进行需求分析）
3 过了2天，产品经理再把测试和开发召集在一起，进行需求讲解（或者说需求评审），有问题可以直接问，如果发现需求有问题，也可以提出来，SR回去会修改。（需求讲解时间0.5天）
4 讲完需求后，测试同事要进行测试场景的梳理和案例的编写了（xmind和Excel就要用上了），一共5个工作日。（此时开发在编写代码）
5 之后就要进行案例评审了，评审时候有SR、测试同事、开发同事，评审时候一般SR、测试组长、对应模块的开发同事会提出一点意见，评审完之后，回去修改、补充一下案例。（案例评审0.5天）
6 修改完以后，有两种处理情况：
6.1 对大项目有时候要进行案例的第二次评审。
6.2 对小项目，在时间紧的时候，一般不会二审，但是要以邮件的形式把修改或者新增后的案例发出来，给领导看，并抄送给其他同事。（案例评审0.5天，修改案例0.5天，案例二审0.5天）
7 案例评审完就要开始测试了，一般测试环境开发搭建好（要说自己也会搭建，搭建流程背老师总结的）：
7.1 中型版本的测试一般分2轮：第一轮：5天；第二轮：3天；回归测试2天；（共10个工作日）。
8 回归测试完后，达到了上线标准，就会如期上线，一般当天晚上12点上线
二十、功能测试你们一般做几轮？
1 中型版本（大修改，一个月上线一次）：测试一般分2轮：第一轮：5天；第二轮：3天；回归测试2天；（共10个工作日）。（一个月工作日22天，需求分析评审，编写测试用例等等一般占用整个版本时间的一半，或者少个几天）
2 小型版本（小修改，两个星期一次）：一轮测试3天，回归测试2天。
3、你们每次开会讨论的时候十几个开发都去开会了吗？
1 案例评审会：一般开发和测试、产品经理都会到场。（开发分组经理可能也会去）
需求评审会：项目经理、开发分组经理、产品经理、测试、开发一般都会到。
2如果是我们测试小组开会，一般都要到，各位测试同事报告自己的心得体会，汇报自己的进度和问题。
二十一、等价类划分
1.划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.等价类划分可有两种不同的情况:有效等价类和无效等价类.
2．边界值分析法
边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.
3．错误推测法
基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.
错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.
4．因果图方法
前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）. 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.、
判定表
正交表
二十二、你们有几台服务器，怎么部署的
参照:可以回答三台服务器
分别部署开发环境、测试环境、生产环境
也可以回答不清楚，项目架构比较大，到底多少台服务器不太清楚。
二十三、开发环境、测试环境、生产环境（线上） 到底是什么？
1：开发环境：项目尚且在编码阶段，我们的代码一般在开发环境中 不会在生产环境中，生产环境组成：操作系统 ，web服务器 ，语言环境。 php 。 数据库 。
2：测试环境：项目完成测试，修改bug阶段
3：生产环境：项目数据前端后台已经跑通，部署在阿里云上之后，有客户使用，访问，就是网站正式运行了
二十四、您以往的工作中，一条软件缺陷（或者叫Bug）记录都包含了哪些内容？
1.和bug产生对应的软件版本
2.开发的接口人员
3.bug的优先级
4.bug的严重程度
5.bug可能属于的模块，如果不能确认，可以用开发人员来判断
6.bug标题，需要清晰的描述现象
7.bug描述，需要尽量给出重新bug的步骤
8.bug附件中能给出相关的日志和截图。
二十五、常见的一些错误、异常
NullPointerException 空指针异常
ClassNotFoundException 指定的类不存在
NumberFormatException 字符串转换成数字异常
IndexOutOfBoundsException 角标越界
ArithmeticException 运算异常
FileNotFoundException 文件找不到
ArrayStoreException 数组存储异常
二十六、在项目中找到的经典BUG是什么
1 兼容性问题，在ie浏览器，提交订单按钮可以点击，到了谷歌，火狐就不能了。
2 查询订单页面，根据条件筛选的结果不是想要的结果，还有某些字段的值没有显示出来，或者显示错误。（因为开发从库表取值有误）
3 付款成功后，订单状态一直不翻转为交易成功。（因为代码没有正确获取库表中付款成功记录的状态码）
4 修改支付密码，新密码和原密码一致，也通过了，系统没有做新旧密码的校验。
5 付款时候的手机验证码，可以一直使用，没有成功做有效期控制。
6 手机app断开网络后，再去点击，没有友好的错误页面提示网络已断开，只有undefined返回
二十七、弱网测试
回答手机弱网测试,需要回答手机端测试话术里面弱网测试部分,再结合下面的内容
2G的网速：150Kbps，折合下载速度15-20K/s。 B=8b
3G的网速：1-6Mbps，折合下载速度120K/s-600K/s。
4G的网速：10-100Mbps，折合下载速度1.5M/s-10M/s。
测试方法：
1、使用真实的SIM卡、运营商网络来进行测试（移动无线测试中存在一些特别的BUG必须在特定的真实的运营商网络下才会发现）
2、通过代理的方式模拟弱网环境进行测试（charles 硬延迟）
在fiddler和charles中可以设置网络，fiddler可以在rule中调，charles可以在proxy中延迟设置中设置网络速度。
3、连接模拟弱网的热点进行测试 比如360wifi助手可以设置
二十八、手机性能测试
Cpu 可以通过adb 指令来查看
adb shell
dumpsys cpuinfo | grep packagename
内存可以通过adb指令来查看
adb shell
dumpsys meminfo [pakagename | pid]
查看占cpu最高的10个进程
adb shell top -m 10 -s cpu #查看占用cpu最高的前10个程序
二十九、APP的环境搭建
1.java环境配置好
* JAVA_HOME
* %JAVA_HOME%\bin;%JAVA_HOME%\jre\bin;
android SDK=software develop kit ,android软件开发工具包，sdk文件夹就是android的开发工具包
* 配置sdk的环境变量
新建ANDROID_HOME C:\AndroidStudioSdk
在path里面添加三个变量
*%ANDROID_HOME%;%ANDROID_HOME%\platform-tools;%ANDROID_HOME%\tools;
三十、测试过程中遇到app出现crash(崩溃)或者ANR(卡死)，你会怎么处理？
参考答案：可以先把日志过滤出来：adb logcat | findstr xxxxx(过滤日志信息) ，然后再搜索其中的关键字，比如：exception、crash，看看是那些方法或者异常导致了问题的发送，初步定位问题原因后，可以交给开发人员去具体查找深层原因并修复。
三十一、APP常见崩溃的原因：
设备碎片化：由于设备极具多样性，App在不同的设备上可能有表现不同。
带宽限制：带宽不佳的网络对App所需的快速响应时间可能不够。
网络的变化：不同网络间的切换可能会影响App的稳定性。
内存管理：可用内存过低，或非授权的内存位置的使用可能会导致App失败。
用户过多：连接数量过多可能会导致App崩溃。
代码错误：没有经过测试的新功能，可能会导致App在生产环境中失败。
第三方服务：广告或弹出屏幕可能会导致App崩溃。
三十二、请详细阐述接口测试和UI测试在测试活动中是如何协同测试的？
接口测试和UI测试这两块其实是有一部分是重叠的，UI测试是通过前端写的界面，来调用接口，而接口测试是直接调接口。所以排除前端的处理的逻辑和调用的正确性，在理论上接口测试是可以覆盖所有的UI测试。但实际过程中，如果只是在接口层覆盖所有的业务流，在UI上只测试前端的逻辑，最终的结果可能会是忽视很多原有的功能点，导致了UI测试的不充分。所以存在多人分工且时间充分的时候可以尝试接口去做业务流的全覆盖，否则不要轻易尝试。
三十三、人员简称
RD – Research & Develop 研发工程师
FE – Front End 前端工程师
BE – Back End 后端工程师
QA – Quality Assurance测试工程师
DBA – Database Administrator 数据库
PM – Product & Marketing 产品经理
TS – Technology Support 技术支持
OP – Operation 运维工程师
UE(UX) – User Experience 用户体验设计师
UI – User Interface 用户界面设计师
UER – User Experience Research 用户研究
SYS – System
SCM – Software Configuration Management
FM – Facility Managemen
三十四、埋点测试
三十五、adb连接安卓机和苹果机
三十六、Tonen值如何设定
三十七、tonen值如何多次设定
三十八、如何定义测试已经完善，已经覆盖。
一、测试用例的切面设计
1、功能点切面
2、特定切面
3、隐含切面
（1）、后台功能
（2）、完整业务流程的测试
（3）、某种特定情况下的系统运行
（4）、其它相关系统
（5）、除功能测试外的其它测试类型
二、详细用例的设计
1、功能切面表面用例设计
（1）、具体功能测试
（2）、组合操作的测试
（3）、GUI界面的测试
（4）、数据初始化情况测试
（5）、业务需求实现是否正确
2、功能切面隐含测试项用例设计：
（1）、数据完整性的测试
（2）、后台的特殊处理
（3）、功能业务之间的关联与转换
（4）、从设计实现发掘测试点
（5）、并发操作时的测试
3、特定切面用例设计
4、隐含切面用例设计
（1）、无界面的后台功能
（2）、与业务流相关的测试
（3）、其它测试类型
三十九、如何定义是前端和后端的问题
1）抓包接口定位分析
1.web项目的话，一般工作中使用方式比较多的是使用浏览器自带的F12抓包看接口请求。如果是app客户端之类的，一般采用fiddler等工具进行抓包接口。不管哪种方式，目的都是通过查看接口，去定位分析属于前端问题还是后端问题。
2.如果抓不到这个接口，就是前端没有发出请求，显然是前端问题。
3.如果有请求并且响应了，就查看这个接口响应信息，如果返回报错了，则需要具体分析报错内容。
4.这个时候既有可能是前端入参传的不对，导致后端报错。也有可能是前端传对了，后端处理错误，需要具体分析是前端问题还是后端问题。
5.如果后端成功响应了且返回信息跟接口文档定义的一致，那么大概率是前端展示的问题，这个时候需要找前端同事。
6.查看linux日志
四十、安卓和mac系统测试区别