版本声明:转载请注明出处。未经允许,禁止商业用途。
用户不管什么软件需求规格,他想怎么用就怎么用。对用户来说,凡是没有被禁止的,都是允许的。所以千万不要在用户正常操作(但是不符合程序员的预期)之后,发现没有达到预期效果时,告诉他他的操作方式不对。因为他会骂人。
测试用例对应着软件中的主路径,探索测试用来敲击其它路径。
菜鸟的梦想是写出基于需求规格的完善的测试用例。测试老鸟知道,什么测试用例都是浮云。只要真的参加了一个大的软件工程实践,就会发现测试用例能暴露的缺陷(一般性缺陷)只占到所有缺陷的一小部分。大部分的缺陷需要通过探索测试来暴露。鲁迅说过,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、故意犯错:故意构造重发布路由环路。
这些点已经不少了,但是远没有列全,你可以在每一点后面增加新的具体的测试点,也可以继续扩展出更多的方法。非常要命的是,这些方法可以进一步组合使用,这使得可以测试的情况迅速膨胀。不要忘了,各项命令参数也很渴望参与组合喔。
也许有人会说,很多点没有什么意义,但是因为有意外耦合这个大魔王,就从没有人敢保证,这些情况绝对不会出错。是否有错,测了才知道。
还有很多点我没有写到,如果你想到,也测试了。那么恭喜你,你可能发现了我遗漏的缺陷。不过不要高兴的太早了,因为菜鸟也可以在老鸟已经充分测试过的软件中发现新的缺陷。关键是,谁找得更多。