App测试是一项批判性的工作，目的就是找出软件中的缺陷。这里暂时不去深究为什么要进行App测试，以及App测试带来的好处。只介绍App测试中一些基本的测试方法。根据是否查看代码程序分为黑盒测试和白盒测试；根据是否运行软件又可分为静态测试和动态测试。
黑盒测试：又叫功能测试或行为测试，只需考虑各个功能，不需要考虑整个软件的内部结构及代码。
白盒测试：访问代码，通过检查代码的线索来协助测试。
静态测试：测试软件不运行的部分，只是检查和审核。
动态测试：使用和运行软件进行测试。
1、静态黑盒测试：检查产品说明书，并在软件编写之前找出问题
· 对产品说明书或软件需求报告进行高级审查：
(1)站在一个设计者的角度进行审查，找出根本性问题或遗漏之处
(2)站在客户（使用者）的角度来审查，因为软件质量的定义是满足客户的需求
(3)研究现有的标准和规范，可以是公司习惯用语和约定、行业要求、GUI、安全标准；检查所用标准是否正确、遗漏，是否与标准和规范相抵触
(4)审查和测试类似软件，检查它的规模、复杂性、测试性、质量和可靠性、安全性
· 对产品说明书或软件需求报告进行低层次测试：
一份优秀的产品说明书或者需求报告：必须是完整、准确、精确（不含糊、清晰）、一致、贴切、合理、代码无关、可测试性
2、动态黑盒测试：在不了解软件如何工作的前提下进行测试
两种基本方法：通过性测试和失效性测试
选择测试用例：等价类划分：把软件具有相似输入，相似输出，相似操作的分在一组。一个等价类或等价类划分是指测试相同目标或者暴露相同软件缺陷的一组测试用例。
等价类划分的目标：把可能的测试用例集缩减到可控制且仍然足以测试软件的小范围内。
(1)测试数据
通过性测试：
a) 边界条件：软件运行在计划操作界限的边界情况。测试边界包括测试临近边界的有效数据、测试最后一个可能有效的数据、测试刚超过边界的无效数据。
b)次边界条件：典型的次边界条件：2的幂、ASCII表
c)测试默认、空白、空值、零值和无这些数据
失效性测试：
d)测试非法、错误、不正确和垃圾数据
(2)测试状态
软件状态：软件当前所处的条件或者模式。
状态测试：测试程序的状态及其转换。
步骤：
1)建立状态转换图
2)减少要测试的状态及其转换的数量
a. 每一种状态至少访问一次
b. 测试状态之间最不常用的分支
c. 测试所有错误状态及其返回值
d. 测试随机状态转换
e. 测试看起来是最常见和普遍的状态转换
** 通过性状态测试**：审查软件，描绘状态，尝试各种合法可能性，确认状态及其转换正常。
失效性状态测试：竞争条件、重复（检查内存泄漏）、压迫（在不够理想条件下运行：内存小，磁盘空间少...尽量限制软件的必要条件）、重负（提供条件任其发挥）。
3、静态白盒测试：在不执行软件的条件下有条理地仔细审查软件设计、体系结构和代码，从而找出软件缺陷的过程
(1) 编码标准和规范：可靠性、可读性/可维护性、可移植性
(2)通用代码审查清单：
a. 数据引用错误 -> 缓存区溢出
b. 数据声明错误 <- 不正确地声明和使用变量和常量
c. 计算错误
d. 比较错误 <- 边界条件问题
e. 控制流程错误 <- 循环等控制结构未按预期方式工作，由计算或比较错误间接引起
f. 子程序参数错误 <- 子程序不正确地传递数据
g. 输入/输出错误
h. 其他检查 -> 编码、可移植、兼容
4、动态白盒测试：结构化测试，检查代码并观察运行状况，利用查找代码功能和实现方式得到的信息来确定哪些需要测试，哪些不需要，如何开展测试，包括如下内容：
(1) 直接测试底层函数过程，子程序和库（API）
(2) 以完整程序的方式从顶层测试软件，根据对软件运行的了解调整测试用例
(3)从软件获得读取变量和状态信息的访问权，确定测试与预期结果是否相符，强制软件以正常测试难以实现的方式运行
(4) 估算执行测试时命中的代码量和具体代码，调整测试，去掉多余的测试用例，补充遗漏的用例
动态白盒测试与调试的区别：都包括处理软件缺陷和查看代码的过程，但是它们的目标不同：测试的目标是寻找软件缺陷；调试的目标是修复缺陷
测试方法：分段测试（单元测试和集成测试）、数据覆盖、代码覆盖
数据覆盖：
数据流覆盖，在软件中完全跟踪一批数据。
次边界：与动态黑盒测试类似。
公式和等式：类似除法运算中，考虑除数为0的情况。
错误强制：迫使软件中的所有错误提示信息显示出来。
代码覆盖：测试程序的状态以及程序的流程，设法进入和退出每一个模块，执行每一行代码，进入软件每一条逻辑和决策分支
代码覆盖包括：程序语句和代码行覆盖、分支覆盖（比如判断语句中if分支和else分支）、条件覆盖（一个条件中可能包含几个子条件，要覆盖每一个子条件及它们的组合）。
App测试其实就是在用户之前使用和运行软件，尽早找出软件中存在缺陷。我们不可能对软件进行完全测试，只可能在测试有限的用例后使得软件仍然存在bug的概率尽可能小。以上所述仅仅只是一点皮毛，App测试覆盖的知识面很广，需要学习的还有很多！！
Android app启动时间测试
对于app测试中的性能测试，启动时间是个重要指标，启动时间分为两种情况，一种是冷启动时间（通常是系统重启，即在启动前没有该app进程的情况），另一种是热启动，即app从被切换到前台（点back退出后再点击图标启动）。
从Android4.4（API 19）开始，可以从logcat获取activity的启动信息，如下我用应用宝做实验，可以看到如下的输出，从这里我们可以看到应用的这个activity启动用了639ms。
这个log信息会在activity首次被绘制时输出，也就是如果activity栈里有这个activity，再启动不会输出该信息，典型的场景是通过recent task列表切换到其他activity再立即切换回来时。
log中的时间包括系统从开始处理启动activity的时间到完成运行layout和draw函数的时间，不包括点击icon到系统接收到消息的时间。显然，这个时间也不包括启动中异步UI绘制的时间。但是我们在测试中关注的其实是用户体验的启动时间，那么上面log中的时间就不能满足我们的需求了。
不过还好，既然是用户体验我们可以用更直观的方式，使用screenrecord进行屏幕录制然后分析视频。使用如下命令录制视频。
adb shell screenrecord --bugreport /sdcard/launch.mp4
--bugreport参数会使视频输出一些时间信息和帧信息便于我们分析启动时间。
activity启动后，使用ctrl+c结束视频录制，使用
adb shell pull /sdcard/launch.mp4 /Users/xxx/Downloads/launch.mp4
导出视频到电脑，使用可以按帧播放的视频软件打开（mac上quicktime就可以，win下可以用kmplayer），并按帧播放。
按帧播放视频，视频左上角会显示每一帧的时间（精确到ms）和帧数。在视频中会看到icon会变暗然后高亮，高亮时就是系统开始处理本次icon点击事件了。可以把这里作为点击时间，然后根据体验要求，看到app启动页完全绘制完作为终止时间，这个时间减去点击时间就是app的启动时间。
在进行app启动时间测试时，系统中运行的其他app会对启动时间有干扰，如果需要进行版本对比及竞品对比，最好要尽量保持环境一致，并反复执行多次取平均值。最后，不要忘了分别测试冷启动和热启动哦~
App测试经验分享
集成测试
按照模块上下集关系，进行从上到下或者从下到上的集成测试方法进行集成测试，单元测试与集成测试主要考虑功能性测试。同时也要对模个模块或者集成模块进行非功能性的抽样测试。
系统测试
对整合系统进行整合测试，这时的测试主要测试系统的整体功能和全部非功能性的需求。
测试的主要工作
测试人员的工作开展是在需求下发后，需求下发后，测试人员要先熟悉需求，根据需求设计文档设计相关的测试案例，测试案例需要覆盖所有业务场景，包括功能方面以及业务方面的。
测试案例设计
（1） 首先针对页面的功能设计功能测试案例，常见的方法有：等价类划分方法、边界值分析方法、错误推测方法、因果图方法、正交实验设计方法。
（2） 充分掌握业务知识，业务流程以及业务的数据流向。站在用户的角度思考，而不仅仅考虑在系统中如何操作业务流程；搞清楚每一项业务中的详细流程和各个环节涉及的角色，一项比较复杂的业务其详细流程往往比较多，只有了彻底掌握了这项业务，才能对当前业务环节进行全方位的测试，才能设计完整的测试案例。
（3） 从需求人员或者客户那里了解到各业务流程的重要程度和使用频率。（这点对把握测试重点很重要），设置好用例的优先级
（4） 了解业务流程在系统中对应的功能。（建立业务与系统的映射，为编写测试用例做好准备）
（5） 绘制业务流程图（对于较简单的流程，也可以用文字描述的形式，但流程图比较直观，也便于进行路径的分析）。
测试执行
测试过程中主要分成两种类型，一种是系统的功能性测试，一种是对需求实现的业务流程测试。
功能测试
（1） 页面链接检查，每一个链接是否有对应的界面
（2） 相关性检查，删除/增加一项会不会对其他项产生影响，如果产生影响，是否正确
（3） 检查按钮功能是否正确
（4） 字符串长度检查，输入超出需求所说明的字符串长度的内容，看系统是否检查，会不会出错。
（5） 字符类型检查
（6） 标点符号检查
（7） 中文字符处理，乱码或出错
（8） 检查带出信息的完整性，在查看信息和update信息时,查看所填写的信息是不是全部带出,带出信息和添加的是否一致。
（9） 信息重复，在一些需要命名，且名字唯一的信息输入重复的名字或ID，看系统有没有处理，重名包括是否区分大小写，以及在输入内容的前后输入空格，看系统是否处理。
（10） 检查删除功能，在一些可删除多个的地方，不选任何内容按删除按钮看系统如何处理
（11） 选择一个或多个时又如何处理
（12） 检查添加修改是否一致，检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型.
（13） 检查修改重名，修改时把不能重名的项改为已存在的内容，看会否处理，报错，同时看会否报和自己重名的错。
（14） 重复提交表单，一条已成功提交的记录，back后在提交，看系统是否进行处理。
（15） 检查多次处理back键的情况
（16） Search检查:在有search功能的地方输入系统存在和不存在的内容，看结果是否正确；
（17） 如果可以输入多个search条件，同时可以添加合理和不合理的条件，看系统是否处理正确。
（18） 输入信息的位置，输入信息时，光标的位置
（19） 上传和下载文件的检查，上传下载的功能是否实现，上传文件是否能打开，上传文件的格式规定，系统是否有解释信息。
（20） 必填项检查，必填项是否有提示信息
（21） 快捷键检查，是否支持常用快捷键检查
（22） 回车键检查，在输入结束后直接按回车键，看系统处理如何，会否报错。
业务流程测试
业务流程测试是测试人员把系统各个模块连贯起来运行、模拟真实用户实际的工作流程，满足用户需求定义的功能来进行测试的过程。
业务流程测试过程中可以通过以下几点：
(1)站在用户的角度：优秀的需求应该是站在用户的角度来思考问题，是用户能够利用系统完成什么，而不是系统自己完成。因此在需求理解时要多和App的最终用户进行交流，了解他们的诉求，以便有针对性的进行测试。
(2)重视业务的连贯性，整个业务流程：尽可能全面的收集需求要点、了解整体的业务流程、分析主体业务流程和重点业务流程等，将整个业务流程全量进行测试。
(3)相关联业务测试：工作上业务实现过程中，有可能会影响到相关联的业务，在进行当前需求的业务流程测试时，需要对相关联的业务进行测试。
缺陷管理
App测试的主要目的在于发现App存在的错误(Bug)，对于如何处理测试中发现的错误，将直接影响到测试的效果。只有正确、迅速、准确地处理这些错误，才能消除App错误，保证要发布的App符合需求设计的目标。在实际App测试过程中，对于每个Bug都要经过测试、确认、修复、验证等的管理过程，这是App测试的重要环节。
Bug管理的流程
（1） 测试人员提交新的Bug入库，错误状态为New。
（2） 高级测试人员验证错误，如果确认是错误，分配给相应的开发人员，设置状态为Open。如果不是错误，则拒绝，设置为Declined状态。
（3） 开发人员查询状态为Open的Bug，如果不是错误，则置状态为Declined；如果是Bug则修复并置状态为Fixed。不能解决的Bug，要留下文字说明及保持Bug为Open状态。
（4） 对于不能解决和延期解决的Bug，不能由开发人员自己决定，一般要通过某种会议（评审会）通过才能认可。
（5） 测试人员查询状态为Fixed的Bug，然后验证Bug是否已解决，如解决置Bug的状态为
（6） Closed，如没有解决置状态为Reopen
基于全球首创的对象识别技术，TestBird可以为客户提供深入到移动App&游戏内部所有功能的深度解析能力。通过自助App功能测试、远程真机调试、真机兼容性测试、真人体验测试、 真人压力测试和崩溃分析等产品，TestBird建立了云手机、云测试和云分析三大测试平台，为移动应用提供从研发到上线再到运营的一站式质量管理服务，帮助移动应用企业建立完善的质量管理体系和能力，全面提高移动应用的DAU、留存率以及付费情况。
