APP测试走过的那些坑

Posted 2020-08-27 不当咸鱼

     我现在的工作有一大部分也是app测试，虽然自己是app开发出身，但是在测试上还是跌入了很多大坑，毕竟二者还是有很大不同，所处的角度也是不一样的。而开发转测试中，我认为较难的也是一个角度的转换，以一个开发者的角度去测试，往往会忽略很多问题。

     在记录app测试走过的那些坑之前，先总结下app测试的工作主要有哪些。

     1.功能测试，无论是什么软件产品，必不可少的就是功能测试。我们需要测试这款app产品的功能是否完善，是否符合客户需求，是否符合用户正常体验。而功能测试最重要的一点也是测试案例的设计，这个抽个时间单独总结下。案例设计的是否全面，覆盖率是否高决定了这款产品功能强弱。作为一名开发，需要在开发过程中考虑逻辑实现中的种种情况，根据不同的情况做不同的处理，而这种考虑往往以正向考虑为主，即用户在正常使用情况下会进行哪些操作，从而产生什么样的问题。作为一名测试不能单单从正向流程考虑，用户在各种情况下的各种操作要绞尽脑汁想到并设计相应的测试案例，才能保证app功能的完善。因此在app测试流程中要做到：

         1）需求评审——知道要测试的是什么，测试的范围

         2）案例设计——根据需求文档及产品原型设计测试案例

         3）案例评审——换一名测试人员对测试案例进行评审，查看有没有漏掉的案例场景，评审案例是否正确。

         4）案例执行——对测试案例执行测试，覆盖测试案例。

     2.app客户端性能测试。这个性能测试主要关注的参数有：多高的cpu，内存，耗电量，流量，还有app的安装耗时和启动耗时。其实在实际工作中这个做的是没有那么全面的。我们正常测试过程中比较关注的是app的安装耗时和启动耗时（wifi下的启动，4G下的启动，3G下的启动）。还有一个需要关注的是运营商的测试，之前曾经遇到的问题是在移动下没有问题，但是在联通下就有问题，这个也是需要关注下的，当然这种问题有时候不是开发人员及测试人员能够把控的。但是像内存，流量什么的是需要特别关注的，在我们的工作中，我们在app中的zip包超过500k的在测试环境是特别弹出提示框提醒的，需要找开发确认这个地方为什么会需要放置这么大的文件。

     3.适配兼容性测试。记得之前在群里有人问怎么进行兼容性测试啊，然后都一致回答，买买买，买各种型号的手机，哈哈。在平时的测试工作中，我们公司因为测试团队是比较大的，因此我们也是会不断更新市面上主流的机型，但是不可能做到全面的。我们都是在主流机型上测试通过就可以发版上线的，如果遇到生产问题，我们是特别进行处理。借助真机或者去百度云测等测试平台，借助他们提供的服务复现问题，解决问题。但这种问题解决起来是比较棘手的，像是ios还好说，一般关注ios系统版本及尺寸就可以了，这些问题都可以进行相应的适配。但是安卓设备由于太过于广泛，往往处理一些问题还需要联系厂商，比较麻烦，因此我认为这类测试不需要专门的进行兼容性测试，这样做的意义不是很大。真要做的话可以找下相关的三方平台做下。

     4.弱网络测试。上面也提到过客户端性能测试的时候要关注安装耗时和启动耗时，其中就需要进行弱网络测试。但是在我们实际工作中并没有进行专门的弱网络测试，原因也是这种测试可控性较差，不稳定，得到的测试结果没有很大的借鉴意义。因此在我们实际工作，一般是有特殊需求才会进行测试下，但是得出的测试结果也并不理想。我之前进行app开发的时候，会有对不同网络状况下的不同处理。

    5.耗电量测试。包括app使用过程中的耗电测试以及后台运行挂起设置的耗电测试。手机设备在满电的时候，这个App能玩多久；App每小时的耗电是多少；App在某个场景挂机10分钟耗电量是多少等等。

    6.安全性测试。这个应该说是一个很重要的测试，自己还没有深入研究过安全测试，这个涉及到地方就比较多了，安全协议，信息加密等等。

    这些是自己实际工作中遇到的一些测试，我认为这个也是根据不同产品从而产生不同的测试，并没有一个标准规定一个app测试需要进行哪些方面的测试，这个要根据实际需求成本控制等等进行选择的。

    来谈下app测试中的那些坑。。。

   1.web，客户端，服务端三者的恩怨情仇。现在主流的app都不会是纯原生的客户端，而是和web相结合的，那样在进行测试的时候一定要考虑全面，web的修改，客户端的修改，服务端的修改，会对哪些地方产生影响一定要理清思路。

   2.测试环境的使用。测试环境没有问题不会代表生产环境就没有问题，产生问题的原因是多方面的，因此尽可能的在测试环境测试全面，不要让问题出现在生产环境。

   3.与开发，需求的沟通。这个是比较重要的，一些功能的实现可能在某些细节与需求设计有所不同，在这种情况下不要轻易将问题放过，容易背锅（血泪教训）。不能单方面的听取开发意见或者需求意见，要明确问题是否存在，是否形成缺陷。

   4.无影响测试。在实际工作中遇到过的一个问题，开发将一个接口修改了，测试人员只测试了一个逻辑中该接口的调用，而没有找下开发问下这个接口到底涉及哪些业务逻辑，这就会造成其它地方的缺陷的产生，这个一定要注意，测试到一个bug，不要盲目查看修改完成后这个业务能否正常使用，一定要了解到他到底修改了什么，根据修改的东西再去设计测试案例然后执行。

   以后还会遇到很多坑。。。。。到时候再补充吧