作为一个经历了两个app发版的QA负责人，希望把自己的经验总结下来，分享给大家。
一、需求收集确认
首先就是收集需求，收集需求的过程，也是你对这个需求了解以及判断它的复杂度和工期的过程。首先对于app发版的需求，无非就是两种：新增的需求和优化的需求。那么此刻划重点：
（1）优化需求。对于优化需求，你要注意了。因为优化需求往往你会看到这句话：逻辑同之前逻辑，逻辑不做改动。那么你就要注意了， 因为，每版app的发版负责人都在变，业务也不是你之前的业务逻辑。那么鬼知道之前的逻辑是什么，万一因为新版需求改成问题了怎么办。所以，无论通过什么办法，了解之前的线上逻辑是及其必要的。为了方便你在测完这版的需求在回归之前的逻辑，防止出现问题。
（2）新增需求。新增的需求，相对于优化需求来说好点。因为起码对你来说没有测试的盲点，不存在同之前逻辑的鬼话。
二、排期和用例编写
（1）排期一定要注意，关注的因素：需求大小和集成时间。排期时间一定要合适（排期的时候一定要把所有可能考虑因素都考虑进去，所有要测的测试时间也排了） 。
（2）集成时间，是你最应该关注的时间点。因为app发版都是有期限时间限制的。所以，在集成测试时间前一到两天就要保证所有的后端全部上线。客户端80%的需求已经集成。这时，没有满足要求的需求，为了版本质量，可以考虑放到下个版本或者找寻更好的解决办法。
（3）如果你是主测的话，那么记得，所有的用例都由你来写，而且一定要写详细。因为你是负责版本到最后的人。而且用例中最好标明：需求是否进行了版本控制（这点很重要）。
三、测试阶段
需求到了提测阶段，开发会发提测邮件，根据地址，打包，安装，连代理，测试。除正常的测功能外，介绍一些工具方法。
（1）charles工具。测app我比较喜欢用charles。当然有人喜欢用fiddler。我只是喜欢charles目录样式的结构，请求看的更清晰。
（2）charles打断点。对于一些测试需求，需要特定满足需求的帖子，可是正常的app请求很难请求到你要的帖子。那么，你只要有你想要的帖子信息，可以打断点请求：
a、请求APP请求，请求成功后，请求右键，选择breakpoints，打断点。
b、再次请求这个请求，请求就会被打断，然后把请求改成你想要的数据。完了之后点击执行。请求成功，app页面就会显示你要的数据。（注意：修改请求注意时间，要快，要不可能这个断点就失效了）
（3） 修改请求返回数据。当然有时候你要需要看到一些样式什么的，也需要修改返回数据。有两种办法：像上面一样和Maplocal都可以实现。
a、
b、 将请求结果保存到本地，并改成你要的数据保存。 然后选择：Tools -》Map Local。。。
接下来你请求的这个接口，返回接口都是你本地保存的（注：有些接口做了缓存，并不是每次都会发起请求，那么你就要清除手机缓存）。
（3） app的功能测试，主要关注后端返回的值是否正确，前端展示的值是否正确。
（4）对于有版本控制的需求，一定要记得看完本版本的需求之后，还有下载线上的版本测试，保证对线上的版本是没有影响的。
（5）对于数据性的测试需求，一定要注意数据的准确性，看数据对应的类别是否一致。仔细看，不一致的，赶紧找开发，总有一个字段开发传错了，或者忘记处理了（这种需求页面上看不出来什么，所以很容易忽略，但是对用户体验，是致命的）。
（6）埋点产品自测，这个产品也能完成，就不要占用测试时间了。
四、集成测试
回归主流程
附：
app测试方法总结：
通常从如下几个角度开展测试工作：
功能模块测试
交叉事件测试
性能测试
安全测试
容量测试
兼容性测试
接口测试
易用性/用户体验测试
硬件环境测试
安装/卸载测试
升级/更新测试
应用的前后台切换
1、功能模块测试：
根据软件需求说明书或者用户需求验证app的各个功能是否实现，采用如下方法实现并评估功能测试过程：
采用时间、地点、对象、行为、和背景五元素或业务分析等方法、提炼app的用户使用场景，对比说明和需求，整理出内在，外在及非功能直接相关需求，构建测试点和用例，并明确测试标准，若用户需求中无明确标准遵循，则需要参考行业或相关国际标准或准则。
根据被测试功能点的特性列出相应类型的测试用例对其进行覆盖，如：涉及输入的地方需要考虑等价、边界、负面、异常或非法、场景回滚、关联测试等测试类型对其进行覆盖。
在测试实现的各个阶段跟踪测试实现与需求输入的覆盖情况，及时修正业务或需求理解错误地方。
2、交叉事件测试：又叫事件冲突测试
是指一个功能正在执行过程中，同时另外一个事件或操作对该过程进行干扰测试。如：App在前/后台运行状态时与来电、文件ixaz、音乐收听等关键运用的交互情况测试等。
多个App同时运行是否影响正常功能。
App运行时前/后台切换是否影响正常功能。
App运行时拨打/接听电话。
App运行时发送/接收信息。
App运行时发送/收取邮件。
App运行时切换网络（2G/3G/WIFI）.
App运行浏览网页。
App运行时使用蓝牙传送/接收数据。
App运行时使用相机、计算器手机自带设备。
App运行时插拔充电器。
执行干扰的冲突事件不能导致软件应用软件异常、手机死机或者花屏等严重问题，还需要注意各交叉事件的优先级别，检验系统是否能依据各事件的优先级别依次进行处理。不能因执行优先级别高的事件而导致优先级别较低的事件吊死。另外有中英文模式切换的手机要注意中英文模式切换后的功能实现存在的问题。
3、性能测试：评估App的时间和空间特性
极限测试：
在各种边界压力情况下，如电池、存储、网速等，验证App是否能正确响应。
--内存满时安装App
--运行App时手机断电
--运行App时断掉网络
响应能力测试：
测试App中的各类操作是否满足用户响应时间要求 。
--App安装、卸载的响应时间
--App各类功能性操作的影响时间
压力测试：
反复/长期操作下、系统资源是否占用异常。
--App反复进行安装卸载，查看系统资源是否正常
--其他功能反复进行操作，查看系统资源是否正常
性能评估：
评估典型用户应用场景下，系统资源的使用情况。
Benchmark测试（基线测试）：与竞争产品的Benchmarking, 产品演变对比测试等。
特定场景测试
1.通过模拟终端低电量（例如5%电量）的状态来测试功能在该状态下的正确性
2.通过模拟终端处于特殊地理位置（例如上海）来测试功能在该状态下的正确性
3.通过模拟终端处于特定网络状态下（例如3G）来测试功能在该状态下的正确性
深度性能测试
1.获取App在典型使用场景及状态下消耗的电量流量消耗
2.获取App在典型使用场景及待机状态下消耗的流量
3.获取App在典型使用场景及待机状态下的CPU占用率
4.获取App在典型使用场景及待机状态下内存量
5.获取App冷启动和热启动耗时内容
6.获取App特定页面的内容加载耗时
7.获取App退出的耗时
8.获取App在典型使用场景下帧率
4、安全测试：
软件权限
--扣费风险：包括发送短信、拨打电话、连接网络等
--隐私泄露风险：包括访问手机信息、访问联系人信息等
--对App的输入有效性校验、认证、授权、敏感数据存储、数据加密等方面进行检测
--限制/允许使用手机功能接人互联网
--限制/允许使用手机发送接受信息功能
--限制/允许应用程序来注册自动启动应用程序
--限制或使用本地连接
--限制/允许使用手机拍照或录音
--限制/允许使用手机读取用户数据
-- 限制/允许使用手机写人用户数据
--检测App的用户授权级别、数据泄漏、非法授权访问等
安装与卸载安全性
--应用程序应能正确安装到设备驱动程序上
--能够在安装设备驱动程序上找到应用程序的相应图标
--是否包含数字签名信息
--JAD文件和JAR包中包含的所有托管属性及其值必需是正确的
--JAD文件显示的资料内容与应用程序显示的资料内容应一致
--安装路径应能指定
--没有用户的允许, 应用程序不能预先设定自动启动
--卸载是否安全, 其安装进去的文件是否全部卸载
--卸载用户使用过程中产生的文件是否有提示
--其修改的配置信息是否复原
--卸载是否影响其他软件的功能
--卸载应该移除所有的文件
--验证App是否能正确安装、运行、卸载，以及操作过程和操作前后对系统资源的使用情况，主要包括：
--检测软件是否能正确安装、运行、卸载；大量真机多维度测试,兼容性测试无死角
--安装、卸载、更新错误报告；包含安装、卸载、高/低版本覆盖安装
--用于检测的安全软件包括：百度手机管家、LBE、QQ手机管家、网秦、安卓优化大师
数据安全性
--当将密码或其他的敏感数据输人到应用程序时, 其不会被储存在设备中, 同时密码也不会被解码
--输人的密码将不以明文形式进行显示
--密码, 信用卡明细, 或其他的敏感数据将不被储存在它们预输人的位置上
--不同的应用程序的个人身份证或密码长度必需至少在4一8 个数字长度之间
--当应用程序处理信用卡明细, 或其他的敏感数据时, 不以明文形式将数据写到其它单独的文件或者临时文件中。以
--防止应用程序异常终止而又没有侧除它的临时文件, 文件可能遭受人侵者的袭击, 然后读取这些数据信息。
--当将敏感数据输人到应用程序时, 其不会被储存在设备中
--备份应该加密, 恢复数据应考虑恢复过程的异常
5、兼容测试
包括手机型号（不同的安卓机型，不同屏幕大小的ios机型）、不同版本的手机系统。 对于安卓手机的机型兼容，可根据用户的使用习惯情况，覆盖使用率高的几款机型。
总结到此结束~