主要针对的是android和ios两大主流操作系统，总体上来说android碎片化是个难题，bug也多；ios相对bug少。主要考虑的就是功能性、兼容性、稳定性、易用性（也就是人机交互）、性能。
1 功能方面目前市场上还没达到自动化的水平，主要用手工来测。出现问题最多的也就是特殊符号、边界值、按钮之类的。
2 兼容性方面考虑手机的版本、型号、分辨率。不同的版本是存在差异的，一般低版本容易出现问题。
3 稳定性方面就是闪退、系统崩溃、没响应之类的。
4 易用性无非就是界面是否吸引人、容易理解、界面整洁、简单、无错别字。
5 性能主要是靠工具来实现的CPU占用、内存占用、电池温度等。
6 还有安装、卸载和便利测试。
一般测试时，开发会先在本地机上打好测试包，自己安装，轮完一轮，开发修改好后，再打一个包
1、登录
● 登录用户名和密码错误时，界面有提示信息
● 用户主动退出登录后，下次启动APP时，应该进入登录界面
● 对于支持自动登录的APP，数据交换时 ，是否能自动登录成功且数据库操作无误
● 密码更改后，登录时是否做到了有效数据的校验
● 对于未登录时一些页面的操作，是否做了控制
● 切换账号登录，检验登录的信息是否做到及时更新
● 对于多个端都进行操作时，确保数据库操作无误，且每个端可以及时看到数据的更新
● 对于一些软件，支持一个账号只允许登录一台机器，这时，需要检查账号登录多个手机时，是否将原用户剔除，且能够给出提示信息
● APP切换到后台时，再次切换到前台的测试，如登录时，有电话打进来
2、离线
● 离线是应用程序在本地的客户端会缓存一部分数据以功程序下次调用
● 对于一些程序，需要在登录进来后，这时没有网络的情况下可以浏览本地数据
● 对于无网络时，刷新获取新数据时，不能获取数据且能给出友好提示
● 切换到后台，再次切换到前台时，可以正常查看
● 离线后又连上网，这时对数据有更新时，需要从服务器端获取新数据来更新客户端数据，且要更新本地缓存信息
● 对于一些界面的数据不提供离线查看，需要给出相应提示且界面更新后无任何数据
3、Sqlite数据库
Android和iOS客户端都采用了sqlite数据库，当APP需要在客户端保存数据时，它们会创建相应的数据库表，最常见的就是对账号的保存，这时的测试点主要有：
● 跟一般数据库一样，需要检查数据的增，删，改，查
● 客户端即用即建，当表不存在时，是否会自动创建
● 数据表被删除后，新建的表中的数据能否自动从服务器端中获取回来并保存
● 当对数据进行了修改，删除，客户端和服务器端能否有相应的更新
● 获取数据，客户端是从直接从客户端获取还是和服务器端的数据进行比较
●对于客户端从服务器端更新的数据，客户端是否有保存于本地。
个人提的bug注意点：
● 因为iOS系统有不断的更新，所以会出现这样那样兼容性的问题
例如：假设送人彩票环节，赠送成功后会弹出一个温馨提示（问用户：是否要提醒用户领取），用户一旦点了【好的】，会跳到一个短信提醒框，此时就会出错，在苹果5上都没事，一旦在4s上运行就有可能出现闪退。
● 如果是同一个用户，那么她在android,ios上登录后，记录应该都是一样的。
● 一款手机软件在android系统上测试要特别注意，android手机款式多，内存，分辨率不一，所以测试难过也比较大。我们的软件有一个问题一直走不去，就是在小手机上，如果应用开多，占内存大了，就会出现闪退。
● 有新的版本要上线前，一定要测旧的版本，不能因为新版本上线了，老版本就不能用了，用老版本的用户还是大有人在。有一次，我用新版本注册的用户去玩老版本，结果就有有错过，当然这样玩的人很少。
● 如果一页面里有很多条记录里，要注意上下多滑动，我在测试过程中，好几次在上下滑动中又由于数据出现错误，导致闪退，尤其是android.
● 到了某个页面，突然断网了，然后你在不知情的情况下，点击某个按钮想继续往下走，此时，不能出现闪退的情况，而要给出断网提示。
● 文本框校验时采用等价类划分法，边界值法，错误推测法与场景法，至少这些方法的概念，自己网上去搜。
● 很多手机app在打开后，一般用户都不需要先注册登录，到了合适的地方，弹出合适的提示，很好友的让用户去登录。当然有些页面，而且有时没有判断，未登录去点一些按钮，有可能会闪退。未登录与登录显示的页面是完全不一样的，要仔细测。
● 用户登录状态太久，sessionId会过期，会出现“虽然是登录状态，系统会提示用户没有登录。”
● 外部软件需要更新导致自家软件闪退。我公司是一款博彩类软件，用户需要通过支付宝或财付通支付，有一次在用支付快捷支付时，提示我支付快捷支付需要更新，我就点了更新，更新完成后，我们的软件就异常退出了。
● 输入数据，点某颗按钮，会出现错误提示，有时不管这个提示，继续猛点这个按钮，会出现出人意外的结果哦。
● 上线前一定要测一下软件更新，我好几次这里没测，结果挨了批。这真是叫做“晚节不保”。所有功能都测了n遍了，大胆放心的上了，可是没有在测试环境测软件的更新。结果上线后，用户更新了就出大问题了，大大影响用户量
测试周期
测试周期一般为两周，根据项目情况以及版本质量可适当缩短或延长测试时间。正式测试前先向主管或产品经理确认项目排期。
测试资源
测试任务开始前，检查各项测试资源。
1.产品功能需求文档
2.产品原型图
3.产品效果图
4.行为统计分析定义文档
5.测试设备（iOS3.1.3-iOS5.0.1；Android4.1.2-Android6.0；WinPhone7.1及以上；Symbian v3/v5/Nokia Belle等）
注意：这里不是最新的版本按照自己项目的最低兼容版本和最高适配版本来定
6.其他（例如有秒杀专题的项目，需要规划秒杀时间表；有优惠券使用的项目，需要申请添加优惠券数据；支付宝/银联支付功能的项目，需要提前申请支付宝/银联账户等等）
测试要点
接收版本
本人觉得，这个过程可以直接略过。非专业测试着，不喜勿拍。
UI测试
A) 确保手头的原型图与效果图为当前最新版本。
B) 确保产品UI符合产品经理制定的原型图与效果图。
C) 一切界面问题以效果图为准，若有用户体验方面的建议，必须先以邮件或口头的形式询问产品经理。
D) 由于测试环境中的数据为模拟数据，测试时必须预先考虑到正式环境中可能出现的数据类型。
功能测试
A) 确保手头的功能需求文档为当前最新版本。
B) 确保所有的软件功能都已实现且逻辑正常。
C) 一切功能问题以需求文档为准，若有用户体验方面的建议，必须先以邮件或口头的形式询问产品经理。个人建议，用户体验方面的建议，优先级放在修复bug之后。
D) 若有些功能在技术上难以实现或者由于排期的原因无法在短时间内实现，必须得到产品经理的确认，而不是单单只听开发人员的技术解释。此处确认最好以邮件形式存在。
E) 所有的“外部原因”问题，都需要尽早地督促开发人员与客户服务端人员联系协调解决。并在之后的测试报告中予以体现。
F) 所有的“设计如此”、“延期处理”问题，都需要和产品经理确认后再进行验证。并在之后的测试报告中予以体现。
G) 测试下单时，注册的测试账号必须符合公司规范；收货地址必须包含“测试”关键字，最好每次下单的名称中含有日期，以便查询；在正式环境中下单后必须取消该订单等。
兼容测试/性能测试
A) 确保软件在所有兼容机型上都能正常使用（iOS一般需要兼容7或者6, iOS5可以不用考虑，用户使用率已经低于5%以下）
B) 对于低端性能兼容机上独有的问题（例如iOS5以下、Android1.6以下），若在技术上难以修改或者由于排期的原因无法在短时间内改进，必须在测试日报中注明，并得到技术平台主管、产品经理以及运营人员的确认，最好以邮件的形式得到确认）
C) 性能测试方面必须满足硬件压力条件下的测试需要（例如多线程，用户常用的app都要后台运行的环境中测试。）
D) 网络响应用户体验方面的性能测试，需要保证在wifi、3g、2g网络下的切换效果。比如：WiFi切换到2G，网络响应的速度以及切换界面。
后台订单统计测试
A) 核对“客户端相关启动查询”项，此项数据就是经常说的“激活量”，非常重要。测试时必须保证该项中的各数据均正确，且每次启动软件都会有相应的统计记录
B) 核对“订单查询”项，测试时必须保证各数据均正确，且每次成功下单后都会有相应的统计记录。
C) 需要注意的是，在成功下单之后，后台会做判断将该订单划到测试订单范围，测试人员必须到“订单查询（测试）”模块中核对订单统计记录信息。
用户行为统计测试
A) 确保手头的行为统计分析定义文档为最新版本，且与开发人员手中的文档一致。
B) 确保产品经理在文档中所定义的页面在该产品中都是存在的。
C) 尽可能真实地模拟用户行为。
D) 核对统计日志，确保各项操作所对应的页面ID以及操作ID都是正确的。
回归测试
A) 软件最终上线前，需对产品进行回归测试，测试内容包含之前所有的测试项目
B) 回归测试不再对细节进行测试，而是类似于对产品进行验收，从客户正常使用的角度对产品进行再一轮的整体测试。
C) 只有在回归测试通过之后，才对产品进行提交。
测试日报及产品上线报告
测试人员每天需对所测项目发送测试日报。
测试日报所包含的内容为：
A) 对当前测试版本质量进行分级。
B) 对较严重的问题进行例举，提示开发人员优先修改。
C) 对版本的整体情况进行评估。
产品上线前，测试人员发送产品上线报告
转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 nathanwriting@126.com
