客户端应用也叫app，手机上的app分为基于HTML5的app（类似于pc上的b/S应用）和本地app（类似于C/S结构）。
所以测试上我们也可以充分吸收web的b/s和c/s测试经验。但是不同于pc上的应用测试，手机上的测试有其独特性
测试前的思考：我们这个产品主要是做什么的？为什么我要做这个产品?市场上有哪些同类型的产品？
对自动化的一些看法：
目前我们可以接触到手机方面的自动化工具：robotium，monkey，monkeyrunner，androidjunit。但是由于ui变化快，自动化测试往往不方便维护。前三个不需要源码支持，但是功能有限，androidjunit很强大，对代码能力要求高，同时需要源码支持。app的开发周期一般都很短，ui变化大，用自动化要考虑投入成本，大多数的公司估计都不适用。不过测接口之类的通过自动化是个不错的选择。
转载：
1.移动互联网开发节奏很快，版本快速迭代，如何让测试敏捷起来？
Monkey：我建议放弃完全的Test Case。全部用featurelist或者测试思维导图或者功能点划分表来进行引导的测试。主要目的不会漏掉功能点以及防止regression的bug。其次要敏捷必须要有自动化的支持。关于这点就是根据不同得app进行定义了。首先UT无论如何就要做起来。其次是api和regression test的自动化要做起来。当然CI也一定要搭建的。
2.移动应用测试，如何更全面的保证产品质量？如何让用户参与到测试中来？
Monkey：更全面得保证产品质量。如果要说到全面，那么必须就是功能，压力，性能，安全，用户体验面面具到了。其实还是和我第一个问题说得一样。将app结合os的特性分层进行逐个的测试或者自动化测试。关于让用户参与到测试中来的话。我建议可以将不同的用户集合起来，qq或者微信保持联系。然后android可以定期发布内测版本，ios可以发布testflight版本。
3.用户反馈问题建议非常多，如何做好有效管理、分析和反馈？
Monkey：这个我相信无论哪家公司都会碰见。用户的反馈不一定都是有效的。管理的话，我建议还是需要安排一个专门的人进行记录。将反馈全部作为bug的一种，随后填入bug系统方便跟踪。其次关于crash或者无法重现的问题。就需要自己在软件中增加自动反馈crash log的机制。包括用第三方的友盟等也可以。随后再定期的进行log的分析。这些其实都不难，主要就是需要坚持，一直去做。
4.竞争产品很多，测试如何做竞品分析？
Monkey：这个其实我并不是很在行。不过我觉得分析的话。主要有几点。其一，核心功能的体验。也就是说核心功能路径长短。比如A用了3步完成B用了4步完成的功能，那么A明显有优势。其二，核心功能的交互，包括用户的学习成本。其三，场景分析，比如我们可以设计N个场景，在这N个场景中我们自己的产品和竞争对手的产品，用户会做什么选择。其实往往我们一设计之后就发现，有些功能用户根本无法理解，或者根本不用去做。自然也就没有意义。当然分析还有很多，包括下载量，点击数，评论等等。都可以观察。
app的测试方式不是拿到手就开测，而是更多的了解相关文档、产品逻辑、功能实现结构等相关信息
a。产品功能feature list需要熟悉
b。需要产品所在的系统的架构
c。需要熟悉产品本身的结构，本身的逻辑，包括cs结构，生命周期，api等
d。根据abc来设计测试点，测试点可以是思维导图或者别的。但是并不需要去编写很详细的测试用例。
所以测试上我们也可以充分吸收web的b/s和c/s测试经验。但是不同于pc上的应用测试，手机上的测试有其独特性
测试前的思考：我们这个产品主要是做什么的？为什么我要做这个产品?市场上有哪些同类型的产品？
测试前的准备：1.使用同类型的产品，不仅仅是使用，应该是测试同类型的产品。
2. 熟悉我们产品的spec文档、原型和pm交流。
3. 写测试用例，没有时间至少要有一个checklist。
1.功能1.1.基本功能
主要指app是否完成了设计的所有功能。分清模块，写一份checklist，避免漏测。考虑横竖屏切换，不过很多app现在只支持竖屏。
1.2.系统交互
电话短信干扰，低电量提醒，push提醒，usb数据线插拔提醒，充电提醒等。
2.性能
2.1.稳定性。
2.2.兼用型（android碎片化是个难题，bug也多，ios相对bug少）。
2.3.app运行的内存消耗和cpu消耗。
2.4.app后台长时间运行的耗流量、耗电量。
推荐testin这个第三方平台，对android兼用性测试比较有帮助。3.易用性
3.1.界面是否吸引人、容易理解。
3.2..界面整洁、简单。无错别字。
3.3.点击范围确定等。
这部分测试中，如果测试认为有不合理的地方通常会提交需求bug。
4.网络环境测试
4.1.网络切换时，app识别网络情况。
4.2.网络信号强、弱下的app运行情况。
4.3.断网情况下，app是否有提示；是否可以自动识别网络进行建立连接。
对自动化的一些看法：
目前我们可以接触到手机方面的自动化工具：robotium，monkey，monkeyrunner，androidjunit。但是由于ui变化快，自动化测试往往不方便维护。前三个不需要源码支持，但是功能有限，androidjunit很强大，对代码能力要求高，同时需要源码支持。app的开发周期一般都很短，ui变化大，用自动化要考虑投入成本，大多数的公司估计都不适用。不过测接口之类的通过自动化是个不错的选择。
转载：
1.移动互联网开发节奏很快，版本快速迭代，如何让测试敏捷起来？
Monkey：我建议放弃完全的Test Case。全部用featurelist或者测试思维导图或者功能点划分表来进行引导的测试。主要目的不会漏掉功能点以及防止regression的bug。其次要敏捷必须要有自动化的支持。关于这点就是根据不同得app进行定义了。首先UT无论如何就要做起来。其次是api和regression test的自动化要做起来。当然CI也一定要搭建的。
2.移动应用测试，如何更全面的保证产品质量？如何让用户参与到测试中来？
Monkey：更全面得保证产品质量。如果要说到全面，那么必须就是功能，压力，性能，安全，用户体验面面具到了。其实还是和我第一个问题说得一样。将app结合os的特性分层进行逐个的测试或者自动化测试。关于让用户参与到测试中来的话。我建议可以将不同的用户集合起来，qq或者微信保持联系。然后android可以定期发布内测版本，ios可以发布testflight版本。
3.用户反馈问题建议非常多，如何做好有效管理、分析和反馈？
Monkey：这个我相信无论哪家公司都会碰见。用户的反馈不一定都是有效的。管理的话，我建议还是需要安排一个专门的人进行记录。将反馈全部作为bug的一种，随后填入bug系统方便跟踪。其次关于crash或者无法重现的问题。就需要自己在软件中增加自动反馈crash log的机制。包括用第三方的友盟等也可以。随后再定期的进行log的分析。这些其实都不难，主要就是需要坚持，一直去做。
4.竞争产品很多，测试如何做竞品分析？
Monkey：这个其实我并不是很在行。不过我觉得分析的话。主要有几点。其一，核心功能的体验。也就是说核心功能路径长短。比如A用了3步完成B用了4步完成的功能，那么A明显有优势。其二，核心功能的交互，包括用户的学习成本。其三，场景分析，比如我们可以设计N个场景，在这N个场景中我们自己的产品和竞争对手的产品，用户会做什么选择。其实往往我们一设计之后就发现，有些功能用户根本无法理解，或者根本不用去做。自然也就没有意义。当然分析还有很多，包括下载量，点击数，评论等等。都可以观察。
app的测试方式不是拿到手就开测，而是更多的了解相关文档、产品逻辑、功能实现结构等相关信息
a。产品功能feature list需要熟悉
b。需要产品所在的系统的架构
c。需要熟悉产品本身的结构，本身的逻辑，包括cs结构，生命周期，api等
d。根据abc来设计测试点，测试点可以是思维导图或者别的。但是并不需要去编写很详细的测试用例。