为什么要测试？
测试目的是在有限的时间内发现最多的问题并解决，最大程度降低产品错误带来的负面影响
怎样测试？
技术测试
技术测试主要由程序员（或测试员）对编码进行逻辑覆盖测试，遍历程序遇到的所有情况，捕获异常进行处理，模拟访问做高并发的压力测试。该阶段可以发现产品需求中的疏漏或逻辑错误，排除程序员粗心编程而出现的算法、逻辑错误。该阶段可以排除大量Bug，特别是后台或逻辑性很强的工具性产品，把控的好，产品经理后期测试工作量会大大降低，Bug在技术内部进行修改，反复测试无Bug后，可打包提交，进入下一阶段测试。
内部测试
内部测试主要由产品经理主导在公司内部进行，设计师可以验收UI效果是否符合预期，产品经理模拟多套用户数据按照流程图对其进行操作测试，确认所有功能都与产品文档中的需求一一对应，测试方法可以参看文末的黑盒测试。另外可以邀请其他部门的同事来充当小白用户进行产品体验。此阶段开始要收集所有人的整改意见，进行归类和排序。对于基础性的Bug可以马上责令技术进行修改，有争议性的修改意见或非重要Bug可待下一阶段的用户测试完后集中修改。
用户测试
用户测试由产品经理（策划/运营共同配合）主导，用户测试分为两个阶段。
三、 如何测试？
第一阶段
寻找固定的用户群体进行测试（即每个版本邀请同一批用户来测试），以问卷或者一对一聊天的方式，获得他们对比新旧版本来直观感受产品好坏。如果无章可循，今天找个路人甲测试，明天找个路人乙测试，面向不同品味的用户，难免会出现下图尴尬情况。
第二阶段
灰度测试，向用户群中的1000人，10000人…依次递增推送测试版本，利用自建数据后台或友盟tlakingdata观察埋点数据的功能使用情况和程序crash崩溃报错信息，如发现数据异动及时下架处理。
以上三步循环进行，直至无Bug方可正式发行新版本。下面东东酱顺带介绍测试过程中常见的问题。
版本管理
产品版本用V3.0.3编号管理可以吗？那仅仅是面向用户的，在软件工程中对软件版本管理，分为Alpha、Beta、Rlease Candidate、Release版。
- Alpha是开发人员的内部测试版，一般不向外部发布，会有很多Bug，只有程序员和测试员使用。
- Beta：这是供公司内部测试的版本，这个阶段版本仍可适当加入新的功能。
- Rlease Candidate：RC是发行候选版本，几乎不会加入新的功能，主要着重于出错，可开放给部分用户体验。
- Release：这就是“真的打死不改(6).doc”版本了,交付给用户的最终版本，如果仍出现Bug，那就启动下一版本开发周期了，也就是常见的“v2.1.3”版本迭代了。
因此在管理安装包的时候，最好把不同阶段的名称设为包名前缀，避免出现错乱。
灰度测试
灰度值是不饱和的黑色，是白色向黑色过渡的一种表现。比如突然熄灯看手机，屏幕亮度逐渐变暗；歌曲由暂停开始播放，音量逐渐提高。这样做的好处不言而喻，灰度是一种思想，应用在项目管理中，为避免辛苦开发出来的产品与用户所期待的相差甚大，摒弃传统冗长的开发流程， 将项目按照功能优先级排序，对产品实行分阶段，分版本开发，第一个版本满足用户基础需求，后续版本在原基础上反复迭代，这样试错成本最低。对于某一版本内的测试，也可以实行灰度机制，测试版本先邀请100名用户进行测试，反馈问题修改Bug，如此类推放量1000人再测试。最终发行版的用户满意度会提高很多，项目成员也不会上线Bug频频出现而压力山大。
A/B测试其实是灰度测试的一种。如果产品方案发生了分歧，可以针对多个方案进行等量推送，查看数据从中择优。Tlakingdata的运营平台就能提供此类方法。
测试方法
白盒测试
白盒测试顾名思义内部是透明可见的，是通过检查软件内部的逻辑结构，对软件中的逻辑路径进行覆盖测试，在程序不同地方设立检查点，检查程序的状态，以确定实际运行状体与预期是否一致。
测试方法包含：逻辑覆盖测试（语句，判定，条件，判定条件，条件组合，路径），循环覆盖，基本路径测试。
黑盒测试
黑盒测试也称为功能测试，测试者在看不到程序内部代码情况下采用穷举输入测试，主要用于发现：功能不正确或遗漏；界面错误；输入和输出错误；数据库访问错误；性能错误；初始化和终止错误。
- 产品功能与需求文档保持一致。
- 对所有用户输入值的合法范围内，非法范围，边界值进行抽样取值测试，确保程序在合法和非法输入值情况下都能正常运行。
- 凭借测试经验，推测有可能出现错误的地方。
- 准备多种测试数据，判断输入和输出结果之间的因果关系是否一致。
总结
测试是产品输出的最关键也是最后一步，在实际项目中，因为项目进度紧等诸多原因，可以适当省去灰度发布过程，但是技术测试和内测工作不能省，不然功亏一篑。测试方法有多重，最终目的是在有限的时间内发现最多的问题并解决，最大程度降低产品错误带来的负面影响。