APP项目测试体系从0到1的建设主要考虑如下：
①自动化测试、②性能测试、③稳定性测试
一、自动化测试
自动化测试主要包括几个部分，UI功能的自动化测试、接口的自动化测试、其他专项的自动化测试。
1.1UI功能自动化测试
UI功能的自动化测试，也就是大家常说的自动化测试，主要是基于UI界面进行的自动化测试，通过脚本实现UI功能的点击，替代人工进行自动化测试。
这个测试的优势在于对高度重复的界面特性功能测试的测试人力进行有效的释放，利用脚本的执行，实现功能的快速高效回归。
但这种测试的不足之处也是显而易见的，主要包括维护成本高，易发生误判，兼容性不足等。因为是基于界面操作，界面的稳定程度便成了维护脚本最大的制约因素。频繁变化的界面交互，就意味着需要不断的更新测试用例脚本，占用大量的测试资源。易发生误判主要是因为基于UI控件进行的识别，容易因为网络条件、设备配置、测试环境等原因导致加载缓慢或异常，从而导致测试用例执行过程中部分判断不准确，进而影响测试的准确性。兼容性不足主要是指测试脚本在不同设备、不同操作系统、不同硬件环境等情况下执行会带来不可预料的情况，导致测试用例执行结果的不准确。
基于以上优劣对比，我们在UI功能自动化测试中，主要实现的是APP核心路径的测试，对需要大量重复执行、重复验证、UI界面变化频率较低的功能模块进行UI功能自动化测试的实现。需要大量重复执行、重复验证，则意味着实现自动化后的利用率高，UI界面变化频率较低，则意味着后续维护成本不高，这三类用例对于我们来说是投入产出比较高的部分，我们会最高优先级去做UI功能自动化测试的实践。
在做UI功能自动化测试的过程中，可以对相关控件、测试用例、测试集进行有效的梳理和管理，对可重复的工作进行及时归并，减少资源的浪费。当UI功能出现变更的时候，也可以以较小的成本进行维护，降低维护成本。
1.2接口自动化测试
在UI功能自动化测试的部分，我们提到了做自动化的制约因素：稳定性。正因为UI界面的不稳定，所以做UI功能自动化的成本是相对较高的，那么我们很自然就想到相对于UI功能更稳定的、更有利于做自动化的部分，那就是接口。
一个APP，界面可能会因为产品经理在不同阶段的不同诉求而变来变去，但其背后的接口通常是较为稳定的，这就为我们开展自动化测试做好了有利的保证。
我们需要准备APP所调用的接口，依据功能模块对其进行梳理归纳，排出开展自动化的优先级，了解每个接口代表的含义，不同参数的取值范围，对不同的输入产生各种输出的情况进行盘点，对错误或异常的返回进行汇总，如此以确保接口测试的有效性和完整性。
在接口自动化测试启动后，需要与开发工程师共同维护一个接口文档，后续无论是接口有增加或者减少，或者现有接口有相关变更，测试工程师都可以第一时间知晓，并对接口自动化测试的用例做相应的调整。
1.3其他专项的自动化测试
除了以上两大类自动化之外，我们还可以利用自动化做一些专项的测试，以辅助提高我们的测试质量和测试效率。这里，需要我们在日常的测试工作中勤于思考，思考哪些工作可以通过自动化来实现，哪些测试用自动化可以提高测试效率，哪些功能点可以通过自动化实现长期的测试监控等。
二、性能测试
性能测试主要包括三个维度的性能测试，即时间维度的性能测试、资源维度的性能测试以及流畅度测试。
2.1时间维度
时间维度的性能测试，主要是指功能特性在点击操作后的时间响应情况。我们比较熟悉的有首屏加载时间，点击后响应跳转打开时间等。
进行时间维度的性能测试有很多种方法，可以利用录屏截图计算时间，也可以利用在程序中打时间戳计算时间，还可以利用第三方脚本实现时间的计算，亦可以通过图像识别技术来进行时间的计算等。
在测试过程中，我们要结合项目本身进行工具的预研，是一次性的测试，还是后续需要持续的测试，是否需要转化成工具供后续长期使用，是在单台设备上用，还是需要考虑兼容性在不同的设备环境上用，工具是否开源或提供数据接口以便后续与团队的测试平台相结合，如此等等。
2.2资源维度
资源维度的性能测试，主要是指APP使用过程中各种系统资源的消耗情况，包括CPU、内存、电量、流量等。
测试工具的选择，根据测试终端的不同去自行选择，测试需要监控的维度，也根据项目自行确定，这里不对具体的测试方法做展开。
这里需要说的是，资源维度的性能测试，可以做两部分工作，一部分是测试过程中的性能测试，另一部分是线上性能数据的收集。
测试过程中的性能测试，可根据业务测试需要进行评估，需要测试哪些场景，是当前版本一次的测试，还是后续每个版本都要进行对比的测试，是只需要测试本机的性能数据，还是需要在多台设备上都进行性能数据的收集，只是需要本APP测试，还是需要和竞品做对比测试等。
在此基础上，评估是否需要通过自动化脚本实现测试用例，以便后续的重复使用。如果后续需要进行纵向的和历史版本的对比测试，需要确保测试环境、测试设备尽可能的一致，从而使测试结果更加真实可靠。
另外补充一个小点，测试数据的处理计算，可以通过自动化脚本实现，将人力计算的资源成本节约出来。如果有必要，还可以做一个简单的平台，将测试数据都存储到平台上，以便后续分析查阅用。
线上性能数据的收集，则需要开发工程师在功能实现过程中对相关数据进行上报，功能发布后，对线上数据进行捞取、处理和计算，发现其中可能存在的问题。在开发工程师日志拿到出现错误用户的日志配合下，实现相关性能问题的定位、分析和解决。
2.3流畅度测试
流畅度测试作为用户体验最直观的感受，也是很多做性能测试的必选。关于做流畅度测试的方法这里就不必赘述，但有几点上需要注意的：
一是我们如何规划流畅度测试的用例，二是流畅度测试后我们如何利用测试结果数据去做分析和改进，三是APP发布后我们需要如何从线上数据去做流畅度的监控。
关于流畅度测试用例的设计，需要结合APP的核心功能、用户常用路径去设计，这部分最好可以有线上数据做支撑，而不是拍脑袋去想。数据支撑下获取到的大多数用户在APP中的跳转路径，才是我们需要去重点关注的。另外，线上数据中监控到的易出现卡顿的路径，也需要我们中测试过程中去留意。
对流畅度测试后的数据的分析与使用，以及线上流畅度数据的监控，这就需要测试工程师与开发工程师去共同规划、共同排查。
三、稳定性测试
这部分，可以从APP的发布前的测试阶段和发布后的线上运营阶段两个阶段入手，分别开展工作。
测试阶段，我们可以围绕Monkey测试、代码走查两方面开展稳定性测试，有条件的团队亦可以在此阶段使用静态代码扫描工具。Monkey测试过程中，要注重测试执行的设备、环境、频率，对过程中发现的问题也要做一定的分析，对容易出现问题的部分做重点关照。代码走查，可以结合功能测试过程中容易发生崩溃的模块进行重点的走查，推动开发进行结对编程，检查这些模块可能存在的问题。至于静态代码扫描，就需要开发同学针对扫描出的问题进行解决，养成良好的代码习惯，以避免相关问题的漏出。
运营阶段，我们可以围绕外网崩溃数据的上报分析来开展稳定性测试。这部分更多的依赖开发工程师来解决，不过在此过程中，测试工程师可以分析上报的数据，定位崩溃的一些基本数据，比如常见的系统、机型等，以此来改进和优化日常的稳定性测试。
