我们都知道全局探索性测试的漫游测试法，也知道局部探索性测试可以从用户输入、状态、代码路径、用户数据和执行环境测试着手点。
那么，如果我们能够获取开发代码，我们怎么从代码入手，进行具体的局部探索性测试呢？
简单回顾
在进行具体的案例讲解前，我们先简单回顾下局部探索性测试的用户输入、状态、代码路径、用户数据和执行环境测试方法。
一张图说明一切。
图1 局部探索性测试测试要点总结
具体案例讲解
本文从代码层入手，分享如何进行局部探索性测试。值得注意的是，接下来的叙述没有优先级和重要性排序，单纯是某些测试要点的启发。
比对代码改动，寻找测试要点！
随着功能的改进或者故障的修复，总会伴随代码的改动。因此，我们可以从代码改动点出发寻找测试要点。
在此，需要大家问自己几个问题：开发人员为什么要这样改？这样改有什么意义？
图2 elasticsearch开源代码提交记录：修改远程集群设置的authorization为credentials
由上图2所示，为elasticsearch开源代码某次提交记录（修改远程集群设置的authorization为credentials）。如果我们获取到这样一份代码，我们要怎么寻找测试要点呢？！
对于代码修改的原因和意义，开发人员在代码提交记录中已经声明：credentials名字更精确。而且从提交记录中，我们还可以看到有许多地方涉及的authorization被修改。因此，我们很容易就能想到一个测试要点：authorization名字修改是否覆盖完全？！
我们再来看一个样例。如下图所示，为elasticsearch的PreviewTransformAction.java某次代码变动。
从提交记录说明可以看到变动原因：目前我们按顺序序列化转换预览文档。
然而，当我们在另一端读取它们时，我们将其反序列化为散列映射，失去顺序。因此，排序时序列化毫无意义。但是在集成测试时，writeMapWithConsistentOrder的使用总使得集成测试失败，因此将其改为无功能影响的writeGenericMap。
由此我们一眼可以得出最重要的一个信息：功能不影响。
所以，对此次变更，我们应首要进行功能回归测试，确保已有功能正常。那还有没有其它测试要点呢？试试writeGenericMap是否真的是无顺序转换？
图3 elasticsearch开源代码提交记录：修改writeMapWithConsistentOrder方法调用为为writeGenericMap调用
注意覆盖代码中的分支！
开发代码中经常会有if…else、switch…case等分支，可是当我们从外部进行场景测试或功能测试时很少能覆盖完全代码中的分支，从而可能忽视某些故障。因此，可以从代码层面出发，寻找或构造能够触发代码某个分支的场景。
图4 elasticsearch的ElasticsearchException.java某部分代码1
如上图4所示，为ElasticsearchException.java某部分代码。该代码使用了if…else分支结构，面对这样的代码，我们是不是首先就会想：如何进入不同分支？进入不同分支后会有什么样的效果？
如上图所示，试试elasticsearchException不为null呢？再试试id != 127呢？更或者，试试传入的id为null呢？
图5 elasticsearch的ElasticsearchException.java某部分代码2
如图5所示，switch…case分支，想想：测试场景中覆盖完了所有case分支吗？如果没有，如何构造场景走到这些分支，尤其是default分支？
本文节选自第七十二期《51测试天地》
《从代码入手的局部探索性测试》一文
想继续阅读全文或查看更多精彩内容，请点击下载：
