App项目生命周期
App 项目生命周期分为三个阶段，开发阶段，测试阶段，发布阶段。测试人员是需要全程参与的。
测试的基本思路
测试范围－测试内容－测试计划－测试方案－测试用例－测试执行
一般看来，测试并不是拿到手就可以直接做的这样一种工作，我们需要先熟悉整个项目的流程，心中有个大体的框架才能入手。测试的执行是在整个项目的中间以及发布前所进行的。然而实际上测试是需要贯穿整个项目的，在一个项目测试任务被告知前，作为测试的我们需要通过邮件，会议之类了解新项目的框架范围，要知道接下来整个团队的任务，我们应该如何去完善这份项目计划。了解了测试的范围，我们需要通过产品经理给出的原型图以及需求文档去了解详细的测试内容。在此基础上，我们对自己的测试任务已经有个基本的概念了，但依然会存在一些细节方面的问题，接下来我们要做的就是和开发沟通。测试和开发是相辅相成的，开发少不了测试帮助优化，测试需要开发的支持才能顺利地完成任务，双方沟通越细，后续能够避免的问题就越多。开发沟通完毕，需要对照已有的项目相关的需求文档开始立项，准备测试计划方案，列出每个功能模块，大致的功能点和执行方法。个人认为，此处测试用例可以列出雏形，后续测试过程中可以加以完善。其实，这里我考虑的还有一点就是测试用例是永远不可能补全的，每一个测试工程师的想法，操作手法以及思维角度是不一致的，随时都可能产生新的操作手法，所以我们只需要列举出基本的功能点，后续的一些特殊操作可以作为测试用例附加，但不属于基础用例的范畴。这一点，对于测试人员来说，更方便管理测试用例，但对于公司来说，app模块更新变动较大，测试用例过于详细的话维护成本过高，实际上也是节省了公司项目的执行时间。
APP测试用例的那些事
初入测试的工作者来说，一份很好的测试用例能引导新人跟上测试所需要的思路，因为这些都是有经验的老人无数次查漏补缺迭代更新的产出，可以细节到每一个常人想不到的步骤，考虑到全方位的各种情况。
在我从事的这几年工作以来，接触过DELL的test case，虽然不用自己动手去写case用例，但是需要我们对test case非常熟悉。当然，我见过一些很牛的测试工程师，他们可以做到细节到每一个步骤，以至于test case拿到手就可以想到接下来这个case有哪些操作步骤，通常会发生哪些issue。这些是需要时间经验积累的。
测试用例也是有规律的，一般来说是由浅入深，由表至里。基本上可以分为几个模块，大标题小标题，测试模块，详细测试步骤，附带测试结果供后续测试工作者参考。
APP测试用例设计思路：
测试项目：App应用软件
需求测试：查看App的需求文档，原型图
界面测试：查看App的界面外观是否符合标准
功能测试：查看App的功能是否可以使用
可靠性测试：使用App过程中是否退出等情况
兼容性测试：安装App到平台（Android2.2/4.2），不同的分辨率是否成功
疲劳测试：安装App程序一直置于后台是否退出或闪退等情况，idle测试
易用性测试：App程序是否容易操作、人性化，用户角度体验，也就是简约便捷的趋势
压力测试：重复安装、卸载App程序或不断点击某一个按钮是否退出等情况
并发测试：安装、卸载App程序过程中或操作App程序功能时受到第三方的干扰
回归测试：对App过程中Bug进行回归测试，在回归测试的同时要注意在bug是否修复的基础上有没有产生其他新的bug
数据连接测试：数据、WIFI、热点等情况下测试，包括网络切换等各种情况
用户手册测试：查看使用手册是否对App程序用法、限制、条件等有详细描述
测试常用的方法
等价类划分、边界值、场景法、错误推测法
1.等价类划分：等价类划分法原则是一种典型的、重要的黑盒测试方法，它将程序所有可能的输入数据（有效的和无效的）划分成若干个等价类。然后从每个部分中选取具有代表性的数据当做测试用例进行合理的分类，测试用例由有效等价类和无效等价类的代表组成，从而保证测试用例具有完整性和代表性。利用这一方法设计测试用例可以不考虑程序的内部结构，以需求规格说明书为依据，选择适当的典型子集，认真分析和推敲说明书的各项需求，特别是功能需求，尽可能多地发现错误。等价类划分法是一种系统性的确定要输入的测试条件的方法。
2.边界值：长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况。应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。
3.场景法：通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果的一种方法。用例场景来测试需求是指模拟特定场景边界发生的事情，通过事件来触发某个动作的发生，观察事件的最终结果，从而用来发现需求中存在的问题。我们通常以正常的用例场景分析开始，然后再着手其他的场景分析。场景法一般包含基本流和备用流，从一个流程开始，通过描述经过的路径来确定的过程，经过遍历所有的基本流和备用流来完成整个场景。场景主要包括4种主要的类型：正常的用例场景，备选的用例场景，异常的用例场景，假定推测的场景。
4.错误推测法：列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结。总之，就是进行错误的操作。
测试用例的误区
1）测试用例应该详细记录所有的操作信息，使一个没有接触过系统的人员也能进行测试。
作为一个测试人员，我一直被灌输的思想正是这些。所谓的好的测试用例，就是可以让一个从头到尾都没有接触过你要测试的产品的人，能通过你的测试用例产品拿到手就会用。这句话不是不对的，我也并没有否认这句话的意思，的确是这样。之所以放在误区，是需要提醒大家考虑一点，这句话是需要一个前提的。对于测试用例，我有过犹豫，写的太简单，担心使用者看不懂，每一点都要过来亲自问我，这样反而会耗费更多的时间。写的太详细，个人时间耗费太多不说，在一个互联网时代，版本更新迭代太快的时代，这样的用例是很快就会被更新淘汰的。其实，我们忽略了一点，我们之所以为了让测试用例尽可能详细，是为了测试目的，为了完善产品。
测试的目的是尽可能发现程序中存在的bug，测试活动本身也可以被看作是一个项目，也需要在给定的资源条件下尽可能达成目标，因此我们必须在测试计划阶段明确测试的目标，一切围绕测试的目标进行。
测试用例的详细程度也需要确定。如果测试用例的执行者、测试用例设计者、测试活动相关人对系统了解都很深刻，那测试用例就没有必要太详细了，文档的作用本来就在于沟通，只要能达到沟通的目的就可以。在测试计划阶段，一般建议测试设计30% - 40%左右的时间，测试设计工程师能够根据项目的需要自行确定用例的详细程度，在测试用例的评审阶段由参与评审的相关人对其把关。
2）测试用例是一劳永逸的事情
这个例子可能有些极端，但测试用例与需求和设计不同步的情况在实际开发过程中却是屡见不鲜的，测试用例文档是“活的”文档，这一点应该被测试人员牢记。
3）能发现到目前为止没有发现的bug的用例是好的用例。
作为测试实施依据的测试用例，必须要能完整覆盖测试需求，而不应该针对单个的测试用例去评判好坏。
测试需要保证以下两点：
程序做了它应该做的事情
程序没有做它不该做的事情（来源于简书：莫可可小姐and琦 ）
