场景介绍
　　近，小明所参与的某项目正在紧锣密鼓的开发测试中，但是对于项目的排期，他与产品同学产生较大分歧。
　　产品同学：这次的1.1版本希望能够在3周后完成开发和测试，快速上线收集用户的反馈并迭代，以便在下月底能够快速抢占市场。
　　小明：但是这个版本增加了7-8个大的功能改动，参考以前的测试经验，测试时间至少需要2个月的时间。
　　产品同学：2个月的话太久了，能不能只测试基本功能保证不崩溃，两周之后上线呢？
　　小明：这次功能改动很大，除了设计用例，执行用例，还要写Gtest单元用例以及随机测试、冻结测试等，整个测试加起来至少也要1个半月时间。
　　产品同学：这个项目现在是初始阶段，正是快速抢占市场阶段，能否在测试的范围进行缩减，只保证功能正确使用，不会发生基本路径的崩溃问题。
　　小明：这个…..
　　经过1小时的讨论，双方对于时间排期仍然没有达成一致。

　　场景回顾
　　作为测试工程师的小明，心中只有质量二字，大熊也是这么教导和要求小明的。所以他不论大小项目，谨慎再谨慎，生怕上线后产品出现质量问题影响用户口碑。然而保证产品质量的目标是希望产品成功，在不同的产品目标情况下，应该选择与之对应的测试策略(如下图)。

　　回顾以上场景，小明是复制其他产品项目的测试策略，测试的类型涵盖功能性测试、关联性测试、健壮性测试、稳定性测试、性能测试等类型。而他目前正在做的这个项目用户量目前只有几千人，相比其他产品线上千万级别的用户量而言，是非常小的。所以，将千万级别用户的产品的测试策略，原封不动地在这个新项目来开展，其实是不合时宜的。

　　如何制定测试策略
　　1.明确产品目标和质量要求：与项目组产品、开发等其他成员，明确本次上线的目标和质量要求。
　　如果是产品创建初期，用户量不大快速发展扩张期，测试可以选择更为激进的测试策略。
　　如果是产品稳定上升期，用户量已经形成一个很大的规模，产品口碑是第一考虑的，那么可以选择保守的测试策略。
　　如果是介于以上两者之间，则根据产品发布目标在激进和保守策略中求得平衡。
　　2.列举测试的覆盖类型
　　功能性：
　　业务逻辑测试：功能正常可用。
　　关联性测试：与业务相关的其他功能的 。
　　健壮性：在功能使用过程中，对于网络异常、文件数据库IO异常、第三方数据(如json数据异常)异常等特殊情况进行考虑，保证程序不会出现崩溃。
　　稳定性：长时间使用被测软件各项功能，保证软件不会出现崩溃异常问题。
　　性能：
　　大数据量测试：程序在大数据、大量用户的使用情况下，功能或服务正常。
　　基准性能测试：关键性影响用户体验的性能指标的对比评测，例如：app的启动性能。
　　易用性：操作及交互方面用户体验测试，符合常见的交互规范。
　　兼容性：在不同设备、不同分辨率等要素下的兼容性测试。
　　…等等其他类型。

　　附：Android手机客户端的测试类型。


　　3.根据实际情况选择与之对应的测试覆盖类型。
　　根据产品目标选择。
　　例如：在前文举例的场景中，小明所测试的产品主要保证业务功能测试和稳定性测试两类，其他的测试并不涉及。
　　根据产品特点选择。
　　例如：被测的测试系统的业务是网上支付，那么在测试覆盖类型中应加入安全性测试，而与之无关的流量测试则不必加入其中。
　　4.评估可能的风险和补救措施。
　　例如：小明所做的这个项目，在兼容性方面并不做过多要求，当得到兼容性问题的反馈后，case by case地进行修改即可。
　　5.综合评估进行决策。
　　6.公示策略和风险。将沟通过的测试策略，公示给项目中的其他成员，以便大家理解对本次上线的目标、策略和风险隐患。