测试场景设计的自我看法
原创作者： 九宸@到家 DeepTesting
测试过程中很重要也很考验测试人员能力的事情就是测试场景设计了，当然很多测试书上有跟多前人整理出来的好的方法，这些都建议可以去看看相关的测试用例设计的书籍。一般书上也都会介绍如下的一些测试方法：
[*]等价类划分
[*]边界值分析
[*]错误推测
[*]因果图
[*]正交分析
[*]场景设计
[*]...
等等以上的测试方法并不是这篇文章想重点介绍的点，因为这些知识可以随时从各种地方获取，所以本身偏理论但是实践性并不强。本文主要表述两个论点：
[*]测试设计要关注核心场景，核心场景要从用户、业务、数据三块分析入手
[*]场景设计要逐步递进，每个阶段关心要有不同的设计要求
关注核心场景的测试设计我在深入理解测试计划一文中提过关于互联网的测试计划关注的重要环节点。其中测试场景设计中要从如下几个点来考虑测试场景的设计分类：
[*]核心用户场景
[*]受益用户的典型使用场景
[*]业务主流程场景
[*]业务逻辑场景
[*]正向业务逻辑
[*]反向业务逻辑
[*]数据场景设计
先解释下为什么这样做：首先互联网公司中的测试场景多从业务需求出发做的产品设计，而且产品经理（PM/PD）在描述产品需求的时候，多从用户的角度来说需求的价值，所以其实我们比较容易从用例角度体现这种需求价值的描述，例如：功能需求：下雨天用户可接受的提价范围是1.5~2.5倍，因此打车产品对接天气系统查询到附近的天气如果有雨天的变化，可以考虑提价在合理范围内。以上需求可以简单分解为以下几个大类型去设计和考虑用例：
[*]核心用户场景类用例
[*]雨天接口结果和用户提价结果范围验证
[*]雨天接口的获取逻辑
[*]业务逻辑场景
[*]下雨天提价
[*]晴天价格恢复
[*]数据场景
[*]测试策略相关性（雨天提价策略和其他策略冲突时）
当然我为了表述观点，只做了以上简单分类，从测试设计上来看，可能还需要考虑技术架构、业务影响等各方面因素再补充一些用例。测试场景设计也要逐步递进，不需要追求一步到位我记得在校招面试的时候，我经常会问一些学生关于“教室门怎么测试”的问题，大部分的应聘的同学都给我的是很标准的答案：从功能、性能、安全性、稳定性、可靠性等分类，每个分类下面有xxxx条用例，分别是xxxx。这样的回答很中规中矩，比较无懈可击。但是我其实从真正工程化的角度来看这个场景的用例设计，我更希望听到的是如下的设计想法：生产过程：
[*]门的生产都是基于标准零部件的规格进行验证，先保证规格正确
运输过程：
[*]核心组件的损坏可能性
使用过程：
[*]功能
[*]安全性
维护过程：
[*]稳定性
[*]使用寿命、可靠性
[*]可维护性（维修、保养、替换等）
如上层层递进式的设计，反而是互联网公司最可能遇到的测试用例设计方法，其实就类似一个项目，测试和开发一起进行过程中，每个阶段的不同测试关注点：UT和接口测试阶段：
[*]规格验证，保证函数/类/模块都满足规格，这个时候多关注的是开发的结果是否满足规格要求
集成阶段：
[*]接口组合调用回归
系统阶段：
[*]功能、安全性、性能等
维护阶段：
[*]考虑系统在各种环境中的设计的易用和可维护性（一般互联网测试会较少介入这块）
通过以上这个例子，我主要要表达的观点：测试用例设计需要在每个阶段有侧重点，这个也是一旦项目过程敏捷后要考虑的核心问题。本文只是我在最近考虑测试场景设计时候的一些简单观点，欢迎讨论！ 其实现在大部分测试都在讨论技术，而不是场景设计和业务测试本身，其实这里面值得思考的点还很多。
666 长篇大论啊 :victory: :handshake 有点复杂了吧:L 可以前往 微信的测试群 提出问题哦
:lol 学习 :victory: 支持一下 :victory:
页:
[1]
