探索测试实战

版本声明：转载请注明出处。未经允许，禁止商业用途。

用户不管什么软件需求规格，他想怎么用就怎么用。对用户来说，凡是没有被禁止的，都是允许的。所以千万不要在用户正常操作（但是不符合程序员的预期）之后，发现没有达到预期效果时，告诉他他的操作方式不对。因为他会骂人。
测试用例对应着软件中的主路径，探索测试用来敲击其它路径。
菜鸟的梦想是写出基于需求规格的完善的测试用例。测试老鸟知道，什么测试用例都是浮云。只要真的参加了一个大的软件工程实践，就会发现测试用例能暴露的缺陷（一般性缺陷）只占到所有缺陷的一小部分。大部分的缺陷需要通过探索测试来暴露。鲁迅说过，bug就像海绵里的水，只要你挤，总是有的，喔，对不起，他说的是时间。不管多少人，测试多久，测试多么充分，一个大型的软件系统在交付用户之后，仍然存在大量的未知缺陷。比如缺陷遗漏率是10%（其中也许有一半是白盒测试可以明确暴露的，但是却丢给黑盒测试碰运气，可是黑盒测试的运气也用完了），如果整个项目中存在缺陷10000个，那么就会有1000个流入用户环境。看起来很恐怕吧，实际上却大致就是这样。知道了这些，如果版本发布前夕发现了一般特性在特定情况下的缺陷，就不用感到担忧了吗？这需要问产品经理。也许修改了这些bug，再发布，更容易向领导交差。修改之后再交测的版本，如果又暴露新的缺陷，尤其是暴露陈年缺陷，这个时候测试部门可能就要背上影响了版本发布的锅了。虽然陈年缺陷原本就像海绵里的水慢慢的被挤出来，或许它出现在了错误的时间。不过实际发布前夕，通常是这样的，每个版本只来得及覆盖基本功能，检查结果时只够简单扫一眼，发现埋藏多年的缺陷的可能性很低。基于测试用例就能发现的一般性缺陷，如果遗漏了，那就是严重的工作失误。基于探索测试才能发现的特定条件下的缺陷，虽然总存在遗漏，但是测试人员对每个遗漏的缺陷都负有责任，需要吸取经验，持续改进工作。幸福总是千篇一律，不幸却各种各样。软件预期正确的情况很明确，但是鬼才知道什么情况下会出错。
OSPF重发布IS-IS测试：
首先测试案例会写什么，搭建一个环境，使OSPF能够重发布IS-IS，然后测试命令中各个参数都工作正常。
你以为测试就此结束了吗？不，测试才刚刚开始：
1、构造冲突法：如果OSPF和IS-IS有到同一目的地的路由。
2、重叠法：如果OSPF中的某条路由被包含于IS-IS的某条路由中，或者IS-IS中的某条路由被包含于OSPF中。
3、共用资源法：OSPF和IS-IS中通告了同一条本地直连路由。
4、数量变化法：OSPF重发布多个IS-IS进程，IS-IS中没有路由，有很多路由。这里，上面三条中的测试点，都可以把"一"改成"多"。在一个节点上重发布不过瘾，多个节点上同时重发布才够精彩！听说配合过滤和策略修改，口感更好。
5、引入变化法：OSPF已经重发布了IS-IS路由。IS-IS回收具体路由、回收汇总路由。IS-IS修改路由的metric值。删除IS-IS进程。down IS-IS接口。修改一下OSPF或者IS-IS的distance值，可以吗？当然可以。总之，你想干什么，就去干吧。你的地盘，你做主！测试中最怕的是不知道自己该干些什么。
6、互相引用法：OSPF和IS-IS互相重发布。同时引用数量变化法，可以让多个OSPF和IS-IS互相重发布。想一想就挺热闹的，如果再加上一些冲突，回收和通告的事件。我已经闻到了bug的味道。其实上面的方法都可以叠加上来。

7、特殊情况法：默认路由，32位路由请特殊照顾一下

8、特定时间节点：路由还没有引入完成，就取消重发布了，就修改metric值了，就修改metric-type了。路由还没有删除完，就又重新配置重发布了。从IS-IS 1中还有完成所有路由的引入，就开始从IS-IS 2中得到完全相同，或者冲突的路由。

9、调整顺序法：代码的顺序处理典型的事件顺序。其它顺序，通过特定的方式进行事件响应，比如通知、定期检查等等。先灌路由再重发布vs先重发布再灌路由。OSPF先重发布IS-IS vs IS-IS先重发布OSPF。先构造相同的路由再重发布 vs 先重发布再构造相同的路由。

10、疑似等价类法：这个方法的必要性有两个原因。第一个原因。等价类是根据需求规则说明提取的。如果需求规则说明中提出不出这个等价类，但是有怀疑程序可能要做区分处理。那我们暂且认为它是疑似等价类。第二个原因：虽然逻辑上按道理互不影响，但是往往是事情搅在一起后，可能会出现意外的耦合性缺陷。要知道如果逻辑总是正确的，那程序根本就没有bug。举例：OSPF路由器的角色，区域内路由，ABR，骨干路由。IS-IS路由器角色，level1、level2、level1-2。IS-IS 路由类型，level-1 level2。不要担心自己不够懂协议原理，不够懂代码实现，对于黑盒测试，不懂或许是一种优势。太懂的测试工程师会过于精明，他明确了按道理逻辑上不会有影响的地方，就不愿花时间去尝试了。这让他错失了暴露一些耦合性bug的机会。

11、事件流法：软件的行为不仅和当前的操作和事件有关，还和软件目前的状态有关。软件在启动后，它的状态被各种事件修改着。软件状态被事件修改，总让我想起大话西游里，至尊宝说感觉紫霞仙子在他心里留下了一样东西，但他不知道是什么。因为黑盒测试者很多时候无法充分观察到软件的内部状态。内部状态出错了，可能需要后续的操作引发的故障来暴露。该雁过无痕的，真的没有留下不合适的痕迹吗？举例，按下面的序列执行：OSPF 1重发布IS-IS 1，OSPF 1重发布IS-IS 2，向IS-IS 1中通告路由，向IS-IS 2中通告到相同网络的更优路由，修改IS-IS 2中的部分路由，使之比IS-IS 1的要差，现在再把IS-IS 1中那些更好的路由删除掉一部分，IS-IS2中通告一些汇总路由，但是metric值更小，删除IS-IS 2，再恢复。这里虽然有一定的意图倾向，但是并没有强逻辑性，需要你要找到一些好的感觉。如果有人能够通过纯粹的逻辑就知道缺陷在哪里？就不需要测试工程师了。软件不死，状态不息，事件流只有起点，但是没有终点。

11、最不可能的情况：以你觉得最糟糕、最奇怪的方式进行操作。越难想到越好，测试工程师想不到的，开发工程师很可能也没有想到。

12、压力法：压力大了，小问题可能会被放大。让我们多灌些路由。进程数多一些吧。把引入的路由通告给我最亲近的1000个邻居。

13、故意犯错：故意构造重发布路由环路。

这些点已经不少了，但是远没有列全，你可以在每一点后面增加新的具体的测试点，也可以继续扩展出更多的方法。非常要命的是，这些方法可以进一步组合使用，这使得可以测试的情况迅速膨胀。不要忘了，各项命令参数也很渴望参与组合喔。

也许有人会说，很多点没有什么意义，但是因为有意外耦合这个大魔王，就从没有人敢保证，这些情况绝对不会出错。是否有错，测了才知道。
还有很多点我没有写到，如果你想到，也测试了。那么恭喜你，你可能发现了我遗漏的缺陷。不过不要高兴的太早了，因为菜鸟也可以在老鸟已经充分测试过的软件中发现新的缺陷。关键是，谁找得更多。