生命有限,测试无限!

测试用例图形化

上一篇 / 下一篇  2008-04-30 11:10:59 / 个人分类:工作

现在很多的测试用例都是在规定的模板上堆着以后也不太会有人看的文字,一本接一本的,看得人云里雾里,还是没有搞清楚到底是要测的什么,也没有搞清楚要测的系统到底是要干什么。

个人比较喜欢图形,在上个东家里做的系统都是跟图形打交道,认为图形其实是个很直接的东西。因为我的抽象思维很差,形象思维很好,很多东西要画出来,我一般都能知道是什么(印象派除外),而且人又很懒,不喜欢看全是字的东西。做了这么多年的测试工作,说起写测试用例,其实最多也就是1-2K行吧,不多,就是因为我不喜欢写,而且在写的过程中我也不知道我会写到哪里去,只能是写一些对付了事的,但总是能安全的没有被发现过关,也许也归功能我的测试执行其他跟我的用例并不是一样的,我的执行一定是比我所写的测试用例要多得多的。

测试用例的图形化,在我认为其实也没有什么,就是在堆文字前,使用一些工具(现在在这方面开源的小工具很多)可以做出一些必要的图形,就像在做需求时,要做的需求分析一样,我们测试也可以没有必要一上来就抽出模板,不停的在上面写着自己也没有搞清楚的文字。

那为什么不能直接就用需求分析时做出来的图呢(一般在需求时会做出一些用例图等),这些图太简单,只是一个大致的轮廓,如果按这图去做测试用例的话,真的写不出真正在后期执行中有用的用例,其实就目前我所做的项目中文字化测试用例的问题有这些:

1、文字化测试用例是乏味的,因为全是文字,就象如果是看小说的话,一个人也一天也看不了两本书,更何况是没有情节的文字测试用例

2、文字化测试用例是孤立的,虽然有文字说明他的接口,但并不直观,难以表现过程

3、文字化测试用例是烦多的,一个小功能,就能写上成千上万行的用例,而且当需要修改时,那就更惨了,不是全推掉,就是让你找个半天然后改个一点

4、文字化测试用例无法让不同的人统一理解的,当一个人写完一个测试用例,一段时间后,由其他的人接手做时,理解原来的测试用例不但花一定的时间,而且会对同一功能产生不一样的理解

其实想想在做码case前,为什么我们不加入先把要写的测试用例图形化呢!现在很多人都在使用一种做脑图的工具(freemind),开源的,不错!可以把它应用到在测试用例前,先把整个系统在你脑子里的构造描绘出来,形成一个脑图(也可以叫做是一个系统的流图或是功能图等等),然后把这张图中的各个结点再去讨论,细化出更小的结点,再确认,最后在最小的结点中加入必要的描述注释,在关键的结点中做出标记,可以认为是重点测试,在描述注释中可写出相应的简化的测试用例,这样在测试团队中全体成图也就知道这个系统的功能以及关键是什么了!

接下来做一些文字化的测试用例,对于一些特别重要的的结点可以做文字化的测试用例,以保证在测试覆盖达到最大。

现在这种做图的工具很多,因为我用得多的是freemind,昨天刚看到一个叫keystone的,还没有用,不知道怎么样!但思想是一样的!

先想到这么多了!


TAG: 工作

老鼠不偷米的测试空间 引用 删除 m2b2x   /   2008-12-30 20:16:21
想法不错,不过很难实现,UML搞了这么多年了,开发也还是在code而不是建模或者你说的作图,当然未来是一定要实现的,只是时间问题
 

评分:0

我来说两句

Open Toolbar