APP测试基本流程

1、 测试周期
app测试周期通常为两周，根据项目状况以及版本质量可适当缩短或延长测试时间。正式测试前先向主管或产品经理确认项目排期。

2、测试资源
测试任务开始前，检查各项测试资源。

产品功能需求文档

产品原型图

产品效果图

行为统计分析定义文档

测试设备（ios3.1.3-ios5.0.1；Android1.6-Android4.0；Winphone7.1及以上；Symbian v3/v5/Nokia Belle等）

其余（例若有秒杀专题的项目，须要规划秒杀时间表；有优惠券使用的项目，须要申请添加优惠券数据；支付宝/银联支付功能的项目，须要提早申请支付宝/银联帐户等等）

2、测试要点
接收版本
本人以为，这个过程能够直接略过。非专业测试着，不喜勿拍。

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）只有在回归测试经过以后，才对产品进行提交。

3、测试日报及产品上线报告
测试人员天天需对所测项目发送测试日报。

测试日报所包含的内容为：

A）对当前测试版本质量进行分级。

B）对较严重的问题进行例举，提示开发人员优先修改。

C）对版本的总体状况进行评估。

产品上线前，测试人员发送产品上线报告