标签：兼容性 依次 本质 数字 清除 后台 经验 准则 手机拍照
作为一个经历了两个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测试方法总结：
标签：兼容性 依次 本质 数字 清除 后台 经验 准则 手机拍照
原文地址：http://www.cnblogs.com/wpx-yk/p/6846235.html
