等价类划分
边界值分析
错误推测
因果图
正交分析
场景设计
...
等等以上的测试方法并不是这篇文章想重点介绍的点，因为这些知识可以随时从各种地方获取，所以本身偏理论但是实践性并不强。
本文主要表述两个论点：
关注核心场景的测试设计我在深入理解测试计划一文中提过关于互联网的测试计划关注的重要环节点。其中测试场景设计中要从如下几个点来考虑测试场景的设计分类：
先解释下为什么这样做：首先互联网公司中的测试场景多从业务需求出发做的产品设计，而且产品经理（PM/PD）在描述产品需求的时候，多从用户的角度来说需求的价值，所以其实我们比较容易从用例角度体现这种需求价值的描述，例如：
功能需求：下雨天用户可接受的提价范围是1.5~2.5倍，因此打车产品对接天气系统查询到附近的天气如果有雨天的变化，可以考虑提价在合理范围内。
以上需求可以简单分解为以下几个大类型去设计和考虑用例：
核心用户场景类用例
雨天接口结果和用户提价结果范围验证
雨天接口的获取逻辑
业务逻辑场景
数据场景
当然我为了表述观点，只做了以上简单分类，从测试设计上来看，可能还需要考虑技术架构、业务影响等各方面因素再补充一些用例。
测试场景设计也要逐步递进，不需要追求一步到位我记得在校招面试的时候，我经常会问一些学生关于“教室门怎么测试”的问题，大部分的应聘的同学都给我的是很标准的答案：
从功能、性能、安全性、稳定性、可靠性等分类，每个分类下面有xxxx条用例，分别是xxxx。
这样的回答很中规中矩，比较无懈可击。但是我其实从真正工程化的角度来看这个场景的用例设计，我更希望听到的是如下的设计想法：
生产过程：
运输过程：
使用过程：
维护过程：
稳定性
使用寿命、可靠性
可维护性（维修、保养、替换等）
如上层层递进式的设计，反而是互联网公司最可能遇到的测试用例设计方法，其实就类似一个项目，测试和开发一起进行过程中，每个阶段的不同测试关注点：
UT和接口测试阶段：
集成阶段：
系统阶段：
维护阶段：
通过以上这个例子，我主要要表达的观点：测试用例设计需要在每个阶段有侧重点，这个也是一旦项目过程敏捷后要考虑的核心问题。
本文只是我在最近考虑测试场景设计时候的一些简单观点，欢迎讨论！ 其实现在大部分测试都在讨论技术，而不是场景设计和业务测试本身，其实这里面值得思考的点还很多。
/1 
关于我们
发表于 2018-2-2 15:19:53
QQ好友和群
QQ空间
腾讯微博
腾讯朋友
微信
收藏
置顶服务
换色服务
发表于 2018-4-29 17:06:23
