软件测试用例的一些观点

上一篇 / 下一篇  2012-04-01 09:18:10 / 个人分类:测试用例

这里就测试用例功能测试上的设计方向,大略的谈谈我自己的一些浅见。

"r`+B9b f bA8UK"O0  测试用例是测试执行的关键,它直接指导如何测试。测试用例的产生源于测试需求,所以在此之前需要把测试需求做好。根据测试需求的分类,在系统功能方面,我把它分成三个集合:界面功能,通用功能,业务功能。任何一个页面的元素都可以分解成这三个集合中的子集或元素。根据这三个集合的特点选择不同的测试用例设计方式。具体的设计可以参考不同的用例模板,对于界面功能,选择简单的模版,甚至列表都可以,因为它们的元素一般都比较独立。通用功能指在很多系统中都会出现的一些常规功能,比如:“上一页”,“返回”,“返回主界面”等,它们有页面的动态变化。在数据库里的反映,就是最多只涉及单个表格的改动,并不引起表与表之间的连锁反应。它所使用的用例模式可采用现在常用的描述法表示。不过对具体系统中的某些功能点还需要具体再考虑。51Testing软件测试网#bu$] |?0mv

51Testing软件测试网#yY"?a*dY/u

  测试用例设计的重点就是业务功能。对于一个熟练的测试人员来说,界面和通用功能的检查,用例已在他们的心中,并不需要文档指导。业务功能是一个系统的核心,它往往也代表了一个管理软件的价值。业务功能的测试用例模版,我现在比较支持场景法。对主业务流的设计采取全路径的检测,因为他们的节点不是特别多,其它的不再累述。除了对系统正确业务流执行的设计外,还有其它一些设计方法,根据测试人员的不同特点,他们的设计也会有所不同。业务功能的设计在我看来是最能反映出测试设计人员的专业水平。因为它不但需要好的测试技术还需要好的系统相关行业知识。

bl3y.v ~ C{Y)j(f+SE0

*[8v'?o I,ErF&\0  这种用例分类的想法,是为公共用例库的建立策化。为了方便测试文档管理,培养新人,特别是将熟练的测试人员从重复繁重的文档工作中脱离出来,重点放在如何检查系统上。这种分离是有必要的。此外还有一个特别操作集,源于某些测试人员的非常规操作,范围超出三个集合,但错误对系统的影响很大。这个集合比较小,可以单独管理,用于对系统稳定性的考察。

f)Z1u [{H1x0

TAG:

 

评分:0

我来说两句

Open Toolbar