1.向开发负责人以邮件形式发个开发好的带版本号的安装包给测试，和产品要相应的产品文档
ios：可以用itools，把ipa包拖进去就会自动安装，如果不会是可以到百度上查（itools安装ipa包的方法）
Android：打好的包叫apk包 ，安装方式有很多（可以上百度搜apk安装包方法），以下是其中两种
1、windows系统可以使用手机助手双击apk文件安装
2、也可以通过QQ等工具发送到手机，然后下载安装
2.检查现在的测试环境和相应的产品文档：
检查要测试安装包与要测试文档：产品功能需求文档； 产品原型图（只是一个大概的样子demo）； 产品效果图（一般IOS和Android有产品提供的效果图）
ios环境检查：ios操作系统的版本，设备类型，网络的状态
Android环境检查：Android操作系统的版本，设备类型，网络的状态
web环境检查：所使用的浏览器的版本（如果是网站主流的浏览器都要测，如果是管理系统这要产品确定我们的系统将来使用哪个浏览器且版本是多少以上）
3.开始测试：（ios、Android，web，有些部分测试要求是一样的）
ios：先把按照业务需求上描述的基本功能及要求的测试完成后，有时间可以进行下面一些测试
1. app使用过程中，接听电话。可以测试不同的通话时间的长短，对于通话结束后，
原先打开的app的响应，比如是否停留在原先界面，继续操作时的响应速度等。
2. app使用过程中，如果有推送消息时，对app的其他功能的使用是否有影响，其次推送的是否点开查看消息
3.设备在充电时，app的响应以及操作流畅度怎么样
4.网络环境变化时，app的应对情况如何：是否有适当提示？从有网络环境到无网络环境时，app的反馈如何？从无网络
环境回到有网络环境时，是否能自动加载数据，多久才能开始加载数据
5.多点触摸的情况跟其他app之间互相切换时的响应
6.进程关闭再重新打开的，
7.IOS系统语言环境变化（也就是IOS苹果操作系统升级为另一个版本）时app的流畅使用情况
8.各实体按键的测试，比如音量键，锁屏键，home键。后两者还可以设计好多用例，比如App打开状态下，
按home键/锁屏键之后，隔1分钟，5分钟，10分钟，30分钟后，重新打开app/解锁，看是否还在原来打开的app子界面，
还是回到app的主界面。横屏和竖屏的显示和切换多次快速点击时，这个同样适用于Andriod
IOS不同版本（尤其是IOS 5和7之间，UI更新比较大）
9. app有更新时能否主动推送
10. 开始你拿到 ipa 文件的时候， 要看看文件大小。 50M 是个分界点。 因为 用手机网络的时候， 如果 大于 50M， 会有警告，
（也许是不能下载了， 只能用WiFi， 我记不清楚了， 你去查一下。）
12. 程序界面里有 UIWebView 的时候， 试试快速切换界面， 多做几次， 看看会不会奔溃。因为UIWebView里不止一个线程，
有可能会有奔溃的现象。3. 还有就是模拟itunes app更新的过程。 （怎么模拟， 我不敢乱说。 也许你可以作点研究。）比如
你购买了app里的某些东西， 然后更新了app， 看看购买的东西是不是还在， 等等 。。。4. 你提到的UI， 补充一下， 要看看
一般屏幕 和 双倍精度屏幕， 显示的是不是都好
Android：同上
web：主要的业务逻辑功能测完后，可以测试其它（非正常使用的一些测试操作看看这个软件产品够不够健壮）
总结：
1、功能模块测试：首先应分析功能模块的功能项，测试每个功能项是否能够实现对应的功能。一般根据测试用例（Test Case）或软件本身的流程就可以完成基本功能测试（相对简单，故障也较容易发现、解决）。
2、交叉事件测试：又叫事件或冲突测试，是指一个功能正在执行过程中，同时另外一个事件或操作对该过程进行干扰的测试。
3、压力测试：又叫边界值容错测试或极限负载测试。即测试过程中，已经达到某一软件功能的最大容量、边界值或最大的承载极限，仍然对其进行相关操作。
4、容量测试（ios和Android）：即存储空间已满时的测试，包括手机用户可用内存和SIM卡的所有空间被完全使用的测试。此时再对可编辑的模块进行和存储空间有关的任何操作测试。
5、兼容性测试（ios和Android）：也就是不同品牌、款型的手机，不同网络，不同品牌的测试。
web也有不同浏览器不同版本之间的兼容性测试
6、易用性/用户体验测试：易用性（Useability）/用户体验是指在指定条件下使用时，软件产品被理解、学习、使用和吸引用户的能力，是交互的适应性、功能性和有效性的集中体现。
4.记录bug（比如把bug记录到mantis系统里面）：
1. 缺陷摘要（Summary） 简单明了，便于理解
长度一般不超过30个单词
尽可能讲明：什么情况，导致了什么问题
便于他人定位Bug，杜绝不重复报相同的Bug
2. 缺陷描述（Descrīption）
a) 重现步骤（Actions） 详细描述重现该问题的关键步骤
省略无关的操作，力求做到：所有重现步骤是充分的和必要的
容易理解的常规步骤，可以一句话带过，比如以管理员身份登录，进入后台用户管理页面
和环境有关的问题，给出特定的条件，比如某某操作系统，某某浏览器
b) 实际结果（Actual Result）
描述实际出现的错误结果
可借助截屏来表达
不是总能重现的Bug，给出发生频率或规律
5.上线（也就是发布）后确认（测试和产品一起确认都对该功能进行确认），原因如下：
a、冗余代码、垃圾代码、不必要代码可以造成系统的功能性、效率（性能）、安全性风险
b、接口问题造成各个模块间运行的不正常，造成效率（性能）及功能性风险
c、在不同的平台上（即不通硬件、网络、支撑软件的情况下）存在的兼容性、可靠性风险
d、错误理解的错误造成功能设计的偏差，造成整个开发失败
