作为一个经历了两个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测试方法总结：

app测试总结