逢上线必加班？如何做好上线前的产品测试？

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