局部探索式测试，是根据软件的各种属性，输入、状态、代码路径、用户数据、执行环境等进行的测试。
输入：
一个数据、一个动作；
一个时间，一个状态；
一个文件，一个指纹；
一个眼神，一个微笑。
只要能触发程序工作的，我认为都是输入。
我们经常测试输入的方法就是等价类和边界值，而且很多人都用在测试输入框的时候；
其实这两个方法不仅仅可以用在测试输入，他们还可以用在数据准备、测试分析中，总之，他们是一种测试思考分析的方法。
在测试一段程序或者一个页面，首先要判断他的输入类型都有哪些？输入的值都有哪些可能？然后就可以使用等价类划分的思想进行分析。尽可能分析出所有可能的输入。
输入，一般又分为单个输入和组合输入。单个输入我们一般会根据等价类划分为有效输入和无效输入。组合输入一般是需要根据业务要求和逻辑进行组合。排列的不同、组合的不同都有可能影响输入结果。单个输入里最有可能出问题的就是下面这一组
[""," ",null,"null"]
他们分别代表 [空字符串、空格字符串，空对象，null字符串]，但是开发经常会很容易搞错 。
输出：
输出也有很多种类型，
有些输出用户可以看到，有些用户是看不到的。
有些对用户有用，有些是跟用户没有关系的。
有些输出是最终结果的输出，有些只是过程当中的一个记录。
输出可能是界面看到的提示，也可能是数据库数据的增删改查；
输出可能是接口的调用，也可能是日志的修改；
输出可能是文件的生成，也可能是对其他系统、中间件平台的调用。
总之，我们应该根据阅读开发的代码或与开发进行沟通，了解所有的输出，通过输出，我们还可以补充输入。
输出的类型：
- 页面提示
- 数据库的增删改查
- 文件的增删改查
- 接口调用
- 中间件（JMQ、PAF、PDQ）的调用
- 缓存的调用
- 硬件设备的调用
状态：
状态一般是指数据在整个生命过程当中不同的表现。也就是从产生这条数据，程序处理过程中，一直到处理结束；处理的逻辑不同，数据的状态也会不同。所以要想要想验证数据不同状态的表现，一般需要准备多条数据，准备多种输入情况。所以通过状态的梳理和测试，也能起到对输入和输出的补充。
逻辑：
虽然我们对输入、输出、状态都进行了全面的收集、测试。但是为了保证每一条分支我们都能测到，我们还需要分析一下代码的逻辑；因为相同的输入，对应不同的数据状态，就可能走不同的分支；相同的数据状态，但是由于输入不同或操作不同也可能走不同的分支；也许输入、状态都相同，但是由于其他条件不同，比如时间或数据的其他字段值不同，都有可能导致逻辑分支不同；总之，一切皆有可能。
数据：
数据，我们尽量要保证数据的多样性和真实性；如果可以，最好是使用真实的线上数据，或者导一批真实数据到测试数据库。如果这些办不到，我们也一定要尽量去模拟真实数据，多了解真实数据是什么样的，然后照着真实进行编辑修改。另外还要保证数据的多样、充足。数据的数量少、种类少，很有可能会遗漏问题。造数据我们可以通过系统去生成，也可以通过数据库直接插入或修改。通过系统生成是最好的，但是如果通过数据库插入，一定要小心，一定要搞清楚你需要的测试数据应该是什么样的。比如我想要造一条数据，跟京东没有合作的供应商数据，在数据库中可能有多种表达方式：
- 在表中就没有这条数据
- 在表中有数据，但是状态显示没有合作
- 在表中有数据，也有合作，但是已过期
- 在表中有数据，也有合作，但是被逻辑删除了
不同的数据表达方式就会有不同的含义，所以自己必须搞清楚，自己要的数据在数据库中应该是怎么表现的，最好是跟开发沟通，查看对应的代码。
场景探索式测试
内部探索：保证场景的完整性，通过上下游及本身，覆盖所有相关的场景。
- 收集实现某个场景所有方式
- 收集当前场景所有的状态
- 收集当前场景所有的下一步所有分支
- 收集当前场景所有的下一步操作
外部探索：通修改正常流程，进行额外的其他操作，验证是否会对当前场景造成影响。
- 插入场景之外的步骤
- 重复场景中的一些步骤
- 删除场景中的可选步骤
- 替换场景中可被替换的步骤
- 替换场景中的数据
- 替换场景中所处的环境
<作者：张强（JD零售） 2016/11/04 如需转载，请注明作者及来源 >
