场景介绍 近,小明所参与的某项目正在紧锣密鼓的开发测试中,但是对于项目的排期,他与产品同学产生较大分歧。 产品同学:这次的1.1版本希望能够在3周后完成开发和测试,快速上线收集用户的反馈并迭代,以便在下月底能够快速抢占市场。 小明:但是这个版本增加了7-8个大的功能改动,参考以前的测试经验,测试时间至少需要2个月的时间。 产品同学:2个月的话太久了,能不能只测试基本功能保证不崩溃,两周之后上线呢? 小明:这次功能改动很大,除了设计用例,执行用例,还要写Gtest单元用例以及随机测试、冻结测试等,整个测试加起来至少也要1个半月时间。 产品同学:这个项目现在是初始阶段,正是快速抢占市场阶段,能否在测试的范围进行缩减,只保证功能正确使用,不会发生基本路径的崩溃问题。 小明:这个….. 经过1小时的讨论,双方对于时间排期仍然没有达成一致。
场景回顾 作为测试工程师的小明,心中只有质量二字,大熊也是这么教导和要求小明的。所以他不论大小项目,谨慎再谨慎,生怕上线后产品出现质量问题影响用户口碑。然而保证产品质量的目标是希望产品成功,在不同的产品目标情况下,应该选择与之对应的测试策略(如下图)。
回顾以上场景,小明是复制其他产品项目的测试策略,测试的类型涵盖功能性测试、关联性测试、健壮性测试、稳定性测试、性能测试等类型。而他目前正在做的这个项目用户量目前只有几千人,相比其他产品线上千万级别的用户量而言,是非常小的。所以,将千万级别用户的产品的测试策略,原封不动地在这个新项目来开展,其实是不合时宜的。
如何制定测试策略 1.明确产品目标和质量要求:与项目组产品、开发等其他成员,明确本次上线的目标和质量要求。 如果是产品创建初期,用户量不大快速发展扩张期,测试可以选择更为激进的测试策略。 如果是产品稳定上升期,用户量已经形成一个很大的规模,产品口碑是第一考虑的,那么可以选择保守的测试策略。 如果是介于以上两者之间,则根据产品发布目标在激进和保守策略中求得平衡。 2.列举测试的覆盖类型 功能性: 业务逻辑测试:功能正常可用。 关联性测试:与业务相关的其他功能的 。 健壮性:在功能使用过程中,对于网络异常、文件数据库IO异常、第三方数据(如json数据异常)异常等特殊情况进行考虑,保证程序不会出现崩溃。 稳定性:长时间使用被测软件各项功能,保证软件不会出现崩溃异常问题。 性能: 大数据量测试:程序在大数据、大量用户的使用情况下,功能或服务正常。 基准性能测试:关键性影响用户体验的性能指标的对比评测,例如:app的启动性能。 易用性:操作及交互方面用户体验测试,符合常见的交互规范。 兼容性:在不同设备、不同分辨率等要素下的兼容性测试。 …等等其他类型。 附:Android手机客户端的测试类型。
3.根据实际情况选择与之对应的测试覆盖类型。 根据产品目标选择。 例如:在前文举例的场景中,小明所测试的产品主要保证业务功能测试和稳定性测试两类,其他的测试并不涉及。 根据产品特点选择。 例如:被测的测试系统的业务是网上支付,那么在测试覆盖类型中应加入安全性测试,而与之无关的流量测试则不必加入其中。 4.评估可能的风险和补救措施。 例如:小明所做的这个项目,在兼容性方面并不做过多要求,当得到兼容性问题的反馈后,case by case地进行修改即可。 5.综合评估进行决策。 6.公示策略和风险。将沟通过的测试策略,公示给项目中的其他成员,以便大家理解对本次上线的目标、策略和风险隐患。