测试资源
App 测试任务开始前，检查各项测试资源。
以下各项都必须包含 非本期开发的 产品功能部分
产品功能需求文档、概要设计文档
产品原型图
产品效果图
-
测试用例（一定要确认和以上资料吻合，以上不准确验收，测试驱动可以说是个笑话）
行为统计分析定义文档
测试设备（ ios7-ios9 ； Android2.3-Android x , 也可兼容到 5.0 ）
其他
例如有限时抢购类的项目，需要规划时间表；有优惠券使用的项目，需要申请添加优惠券数据；支付宝 /银联支付功能的项目，需要提前申请支付宝 /银联账户等等
测试要点
接收版本
目前iOS团队是每天固定自动化发布一次版本，临近提交点频繁修改bug时会提高提交频率
在测试之前，需要向开发主管、产品经理确认当前测试版本的版本号与版本名
-
要区别对待本期开发的功能与已发布的功能
UI 测试
确保手头的原型图与效果图为当前最新版本。
确保产品 UI 符合产品经理制定的原型图与效果图。
一切界面问题以效果图为准，若有用户体验方面的建议，必须先以邮件或口头的形式询问产品经理。
由于测试环境中的数据为模拟数据，测试时必须预先想到正式环境中可能出现的数据类型。
App 功能测试
确保手头的功能需求文档为当前最新版本。
确保所有的软件功能都已实现且逻辑正常。
一切功能问题以需求文档为准，若有用户体验方面的建议，必须先以邮件或口头的形式询问产品经理。个人建议，用户体验方面的建议，优先级放在修复 bug 之后。
若有些功能在技术上难以实现或者由于排期的原因无法在短时间内实现，必须得到产品经理的确认，而不是单单只听开发人员的技术解释。此处确认最好以邮件形式存在。
所有的“外部原因”问题，都需要尽早地督促开发人员与客户服务端人员联系协调解决。并在之后的测试报告中予以体现。
所有的“设计如此”、“延期处理”问题，都需要和产品经理确认后再进行验证。并在之后的测试报告中予以体现。
测试下单时，注册的测试账号必须符合公司规范；收货地址必须包含“测试”关键字，最好每次下单的名称中含有日期，以便查询；在正式环境中下单后必须取消该订单等。
兼容测试 /性能测试
确保软件在所有兼容机型上都能正常使用（ ios 一般需要兼容到 6, ios5 可以不用，用户使用率已经低于 5%以下）
性能测试方面必须满足硬件压力条件下的测试需要（例如多线程，用户常用的 app 都要后台运行的环境中测试。）
网络响应用户体验方面的性能测试，需要保证在 wifi 、 3g 、 2g 网络下的切换效果。比如 wifi 切换到 2g ，网络响应的速度以及切换界面。
后台订单统计测试
核对“客户端相关启动查询”项，此项数据就是经常说的“激活量”，非常重要。测试时必须保证该项中的各数据均正确，且每次启动软件都会有相应的统计记录。
核对“订单查询”项，测试时必须保证各数据均正确，且每次成功下单后都会有相应的统计记录。
需要注意的是，在成功下单之后，后台会做判断将该订单划到测试订单范围，测试人员必须到“订单查询（测试）”模块中核对订单统计记录信息。
用户行为统计测试（这个暂时略过不提）
确保手头的行为统计分析定义文档为最新版本，且与开发人员手中的文档一致。
确保产品经理在文档中所定义的页面在该产品中都是存在的。
尽可能真实地模拟用户行为。
核对统计日志，确保各项操作所对应的页面 ID 以及操作 ID 都是正确的。
回归测试
软件最终上线前，需对产品进行回归测试，测试内容包含之前所有的测试项目
在回归测试通过之后，对产品进行提交
- 回归测试不再对细节进行测试，而是类似于对产品进行验收，从客户正常使用的角度对产品进行再一轮的整体测试。
参考网络资源，经本人收集，整理和编辑，如有侵权请联系本人删除。
