目录
熟悉APP项目
模型介绍
更新速度取决于开发模型
上面所说的京东，就是做一次发布一次，传统行业用的是瀑布模型，互联网行业用的是敏捷模型，
瀑布模型就像是瀑布一般，从上到下，上一个环节没有完成下一个环节是没有办法开始的，需求分析没做完，开发是不能开始的，开发没有完成测试无法介入；这种情况下的时间比较漫长，测试介入的时间也比较晚，导致项目的发布周期比较长；
敏捷模型就是分期，每一期做一部分功能，这样就是处于一个衔接的状态；这样版本发布的就是相对来说较为频繁一些；
此时需求怎么去拆分呢？开会进行需求评审，确认哪些功能是需要先进行的，哪些是可以靠后排的；
敏捷模型：先把核心功能实现，然后逐步优化，分步实现，每次都可以在上次的结果进行优化修改，使得最后的产品质量更高；
面试问题：你们多久发布一次版本？询问的就是你们的迭代周期：
例如：迭代周期为2周，一周开发，一周测试，测试的时候，产品在规划下一个需求；测试完成之后，研发继续开发新的需求，测试继续写用例，研发完成之后测试继续写用例，环环相扣；
迭代周期一定会在敏捷模型中出现；
敏捷模型的开发流程
迭代周期就是多久发一次版；
前期的时候，会产生一个功能列表，开会去确定哪些功能是重要的，确定分期，在哪些期完成什么样的功能；（产品规划好去召开会议）
PM（产品负责人）--保证每一期都按时按点去完成，推动整个过程；
测试也是属于开发团队的，一般情况下，一个团队5-9人
上一个版本的交互时间决定下一个版本的开始时间，每一个的项目版本新阶段开始都会有需求评审（产品，测试，开发）
版本的发布
版本发布：先试用再全部发布！！！
一般一个项目有多台服务器，不会全部发布部署，有问题出现也可以快速地回滚--项目上线采取灰度发布：
灰度发布就是先发版一部分让一部分先试用，只部署一两台，体验新功能，如果没有问题就给全部人员去使用
app如何发布：（app--需要安装软件包，测试一般是手机端的app测试）
安卓的软件包和苹果的不一样：后缀是不一样的，apk和ipa后缀
两个app客户端是属于两个不同的项目，一般情况下不会是同一个研发；两者使用的是不同的语言；
京东：有安卓的团队和iOS的团队；
下载app--浏览器，应用商店，这是公共的平台，同样测试开发也是有一个公共的平台！
不同的平台有不同的渠道；
每一个平台都有自己的渠道表示--渠道id，id写在版本包中用来区分；
软件包的发布：
给测试（公共的平台--蒲公英 或者是标注版本号，放在大家都能访问的地址传递资料）
给用户（放在第三方平台--应用宝 360手机助手，应用平台）
熟悉app项目
不管是web端还是app端，访问的是同一个服务器；（不同的路口，不同的研发）
两者有不同点：BS架构和CS架构 前后端交互方式的不同
如何去熟悉APP项目：
app功能测试
app测试流程
app测试内容：功能测试 性能测试 专项测试
注册测试点扩充（针对注册这个测试点）
（1） 注册成功的账号在web端能成功登录（2）注册成功的账号在app端能成功登录
---验证的是能不能保证数据同步！！！
在web端下单在app端能不能看到，在web端加入购物车在app端能不能看到
（3）登陆成功 界面显示（跳转到首页）
（4）注册成功，数据在数据库的存储是否正常（要验证账号的完整性和正确性）
存储时是否安全（敏感信息是需要加密的）
web端测试兼容性（选取不同的浏览器--主流 公共的在线统计平台--百度流量研究院）（用户要求去找到用户兼容的浏览器）（也可以根据线上反馈，了解浏览器的缺陷，出问题的是哪一个版本，是哪一个浏览器）
（5）如果刚开始不知道是用什么，在浏览器上选取比较主流的
（6）验证码：图片验证码和手机验证码，手机验证码的有效期（验证码过期的时候要有提示且无法登录成功）如果发了两次验证码，应该使用最新的
图片验证码要验证图片是不是可以刷新，验证码的输入和图片不一致，会有什么提示。（一般情况下的验证码是不区分大小写的--输入的时候测试一下大小写，大小写对一部分人不是很友好）
（7）若是验证码注册失败--重点关注的是失败之后的逻辑处理，页面提示是否存在，页面提示是否友好--位置是不是醒目的，所描述的语言是否容易理解；
一共六点一定要罗列清楚
注册过程要关注一下使用的请求方法是什么
登录测试点扩充
（1）兼容性
（2）登录成功：账号--多点登录（同时可以在多个端登录）还是单点登录（重复登录账号会下线--只有当前设备可登录，其他登录设备会被挤掉，挤掉的设备是要有提示的，要确认是不是你本人操作，被挤掉的设备是否有二次确认，你的设备已在某某地某某设备上登录，清确认是否是本人操作，点是--新的设备登录成功且自己掉线，点否--新的设备登录失败且自己保持登录状态）的问题
web端和手机端同时登录这种情况是比较常见的
如果是多点登录--可以在多个设备同时登录设备（数据同步是否正常） 是要有登录状态提示的
（3）多点登录--如果两个设备是同时操作一个东西，这样就不知道执行哪一个了（频繁高速的执行命令会导致系统硬件的一个破坏）
（4）弱网情况下会出现消息指令的一个延迟，若是在同一个时间收到多个指令，这个时候会不会出现异常，造成硬件的一个破坏这样后果很严重，所以在app端要求是只能单点登录；
（5）请求方法是否是post请求
（6）是否增加了防篡改策略
（7）登录相关数据记录在数据库中是否正确
购物车测试点扩充
购物车的显示 增加商品 删除商品 编辑商品数量
（1）购物车多端登录的情况下，数据同步的问题
（2）页面响应时间
计算公式是最重要的 数据库存储是否正常
APP专项测试
APP兼容性
网络切换的过程中是否会出现异常
测试兼容性：
不同的手机品牌商的不同的机型
操作系统的版本：
安卓（根据在线统计平台数据获取） ios
对于分辨率，参考在线统计平台
屏幕：尺寸 5.1 4.7 5.5 类型 刘海屏水滴屏曲面屏 折叠屏
网络的兼容性：移动数据（2G 3G 4G 5G）和WiFi
应用兼容性：（1）手机硬件：手机上的物理按键（音量键 home键 电源键）
（2）外部硬件：蓝牙设备 有线设备
（3）操作系统设置：wlan 时间 定位
（4）其他APP：具有后台播放功能的APP例如音乐
安装测试
中断安装--是否可以继续安装
存储空间：当内存不足的时候安装会不会有提示 安装一半前面的下载信息是否会存在
安装的过程中手动取消（首先会是安装失败 再次安装或者恢复安装时会有什么异常）
此时软件已经在运行过程中，覆盖安装能不能覆盖，
运行的时候要考虑，是在前台运行还是在后台运行：前台和后台是什么意思？
在当前页面运行就叫做在前台运行，当退出程序的时候就叫做在后台运行；
当进入一个app页面的时候，就叫做前台运行；
当退出app的时候有一个重新加载的机会，如果没有退出且正在使用的时候，是不能进行的；
也就是说，安装的时候不能打断自己的使用；新的安装包有更新的时候是有一个红点提示的；
覆盖安装会杀死进程；安装的时候不能够阻断当前操作；
低版本一般不允许覆盖掉高版本（因为高版本是基于低版本进行修复的，如果配置版本可以降低的话是可以低版本覆盖高版本的，如果降不了是直接崩溃的，安装的时候是要进行提示的：此时已经有高版本了）
卸载是否会清除数据：
当卸载应用程序的时候如果没有卸载里面的内容，是否会影响安装操作；
***
正常安装：（1）从不同的渠道安装（2）不同的操作系统进行安装--测试兼容性的时候就顺带测试了；（兼容性要测试不同的操作系统）
（3）不同的安装路径：手机/SD卡
异常安装:（1）中断安装：关机 断网--此时要考虑中断安装能否恢复安装；（2）当存储空间不同时，安装会怎样；
（3）安装时手动取消安装或者是暂停安装，再次点击继续是否会恢复安装；（4）如果正在运行的时候是否会覆盖安装；--前台运行的时候是否会打断用户操作（5）低版本是否会覆盖高版本；
卸载测试
卸载包括两种：手动卸载和第三方卸载；软件管家等等卸载软件
运行涉及前台运行和后台运行：我们所提到的软件是否在运行就是后台运行；
取消卸载：第三方软件的卸载可以取消卸载，如果是有二次弹窗的话，提示取消还是继续卸载，点击取消，是否会继续当前的卸载
卸载的时候是会有进度的，当正在卸载的时候取消卸载；
对于异常中断的卸载，此时去关机，是否会有异常现象的出现；是否卸载成功；（此时我们可能是不希望卸载成功的）
进度如果没有到达100%，我们都称之为卸载失败；
还要考虑卸载之后的数据残留问题：一种是要有用户的提示弹窗确认，用户要是要保留数据的话，是要保留数据的；如果说用户拒绝残留的情况，是不能要有残留的；
如果没有给用户弹窗确认，是要全部清除不能有残留的--默认；
升级测试时在APP测试中非常重要的一项：（1）如果是从临近的版本升级到现在，指的是上一次发布的版本；
（2） 如果是跨版本升级，前几个版本一定是发布过的版本，一定是在用户使用过的基础上进行的；跨版本升级一定要明确的是跨几个版本
经常说的n+1，n+2，如果说当前版本是n的话，n+1就是指的是下一个版本，n-1就是指的是上一个版本
我们说跨两个版本就是n-2升级成n； n-1升级成n； n升级n+1 跨几个版本就是往前推几个版本
从不同的渠道升级
升级成功的提醒--（可以提醒也可以不提醒 一般是红点提示 消息提示）
升级前是否提醒--消息推送提示（点击升级 某某软件出现新版本升级）--日常升级，不属于强制的升级
升级--强制升级不提醒 （1）王者荣耀--不升级就不能使用--在打开软件的时候强制升级
（2）选择时间升级 夜间升级 强制升级--
强制升级出现在存在严重的bug必须修复的时候--如果不去升级是会出现损害的 人力精力会出现损耗
游戏是一定会强制升级的--技能上有更新，不同步的话会出现问题
强制升级是否要做一定是要考虑到产品对用户带来的体验感--例如淘宝不一定会强制升级 但游戏是用户想让升级的；
升级：（1）日常升级（2）强制升级
当遇到严重bug的时候必须要强制升级，否则当没有强制升级的入口的时候只能是强制卸载；
升级包--有的公司有自研升级系统
升级--要考虑验证当前版本是否有升级的能力（n升级n+1的时候） --找研发进行验证 升级规则
交叉测试
也可以将其称为是干扰测试：就是在使用app的时候被打扰到了
例如在使用app的时候突然来电了，势必会打扰到当前所使用到的软件 测试软件是否会出现异常
交叉测试也是在app测试中必须要测试的点
在使用app的时候去接打电话 去接收短信 当点击别的消息然后再回到app是否能继续之前的操作
app在运行的时候去接入蓝牙设备
有时候是会出现弹窗的：当前设备接入蓝牙设备，是否要进行连接 连接的弹窗就会干扰到我们的使用，会不会中断使用我们的app 是否会卡顿呢 我们系统的声音是否会出现异常
例如在火车上的隔空投送 这种弹窗提醒是会直接覆盖在你的当前界面的 如果确认接收是会怎样 取消接收是会怎样
手机是可以旋转屏幕的 如果旋转屏幕是否会对app造成影响 还有是WiFi的切换是不是会影响app的使用
app在使用的时候使用计算机相机等等 打开手电筒时候 使用手机自带的功能的时候是否会影响
还有低电量提醒也会弹窗 app正在播放的视频当有弹窗的时候是不是可以暂停，点完弹窗的时候是不是会继续刚刚的操作
还有插拔充电器的时候手机是会有一个声音或者是动画
这些都是可能会干扰你使用app的一个场景--这种测试就是交叉事件测试
查看应用推送 一种是当前软件的推送 一种是其他软件的推送
移动数据和WiFi的切换
push消息测试
接收消息推送：热点出现 接收消息--运营角度--消息传送
对于pull方式，对手机的资源消耗更大
这里是一定会有推送的服务器存在的 当服务器有更新消息 点击推送 会主动发送给客户端
这里是存在第三方的搭建平台的，也可以是自己搭建服务器
安卓和苹果使用的是不同的服务器如上图 自己搭建维护成本高但是性能好
整个推送服务器 从服务器直接推送到个人的手机端的app app和服务器相互关联起来 当有所更新时就会app端收到信息
测试的推送服务器和手机端
服务器推的内容时间和多久推送和推送给谁 测试！！
推送的指定对象是不是指定的人员才能收到其他人是收不到的
手机端：接收消息要设置在哪里接收
推送规则 指定用户--新版本搞内侧 只有一部分人是可以收到的 消息一般是可以打开的 是否打开正常（在前台后台等等是都可以打开正常的 还有离线的时候等）
消息推送的时候的页面是否是正常的 是不是上方的通知列表，可以接收提醒但是不显示消息内容
声音提醒还是震动提醒
接收到时打开打开到什么样的程度
要关注的推送平台是什么 是要推送给谁
用户体验测试
app测试最重要的就是用户体验 是不可以忽略的一点
对于国家公祭日页面效果是要有灰色效果的 通过要绿色 失败要是红色---是否符合常识
横竖屏测试 内容是否缺失
易用性测试 是否是有提示的 菜单层次要简单的去实现用户需求
下单功能的时候要判断是否登录 按钮的点击要符合用户的用户体验--按钮不能太小
对于手机是设置盲人使用的 会触发阅读模式 软件是否是会跟着手机所变化
