用路径分析的方法编写测试用例

skinapi · 发表于 2004-6-8 13:08:48

说明：这段文字可以看成是Testing from use cases using path analysis technique, Naresh Ahlowalia Object System Group的读书笔记，目前还没有很好的系统的尝试过，以后尝试了再给大家谈谈具体的感受吧。或者哪位大虾用过类似的方法可以介绍介绍嘛。

熟悉测试理论的人都知道，路径覆盖是白盒测试中一种很重要的方法，广泛应用于单元测试。那么基于路径覆盖的分析方法是不是只能应用于单元测试呢，能不能将其推而广之呢。一般而言，在单元测试中，路径就是指函数代码的某个分支，而实际上如果我们将软件系统的某个流程也看成路径的话，我们将可以尝试着用路径分析的方法来设计测试用例。采用路径分析的方法设计测试用例有两点好处：一是降低了测试用例设计的难度，只要搞清了各种流程，就可以设计出高质量的测试用例来，而不用太多测试方面的经验；二是在测试时间较紧的情况下，可以有的放矢的选择测试用例，而不用完全根据经验来取舍。下面就具体的介绍一下如何用路径分析的方法编写测试用例。
首先是将系统运行过程中所涉及到的各种流程图表化，可以先从最基本的流程入手，将流程抽象成为不同功能的顺序执行。在最基本流程的基础上再去考虑次要或者异常的流程，这样将各种流程逐渐细化，这样既可以逐渐加深对流程的理解，还可以将各个看似孤立的流程关联起来。完成所有流程的图表化后就完成了所有路径的设定。
找出了所有的路径，下面的工作就是给每条路径设定优先级，这样在测试时就可以先测优先级高的，再测优先级低的，在时间紧迫的情况下甚至可以考虑忽略一些低优先级的路径。优先级根据两个原则来选取：一是路径使用的频率，使用越频繁的优先级越高；二是路径的重要程度，如果失败对系统影响越大的优先级越高。将根据两个原则所分别得到的优先级相加就得到了整个路径的优先级。根据优先级的排序就可以更有针对性的进行测试。
为每条路径设定好优先级后，接下来的工作就是为每条路径选取测试数据，构造测试用例。一条路径可以对应多个测试用例，在选取测试数据时，可以充分利用边界值选取等方法，通过表格将各种测试数据的输入输出对应起来，这样就完成了测试用例的设计。
对于测试人员而言，测试用例的设计是一件非常困难的工作，而同时测试用例的设计好坏又直接关系到整个系统的设计质量。本文介绍了一种更理论化的设计方法来尽量简化这种工作，将一般应用于单元测试的路径分析方法推广到集成测试、系统测试等后续测试过程中，希望能给大家一点启示。

trancy · 发表于 2009-10-1 16:51:41

觉得比较理论化呢，目前还没有通过这样子去实践，最后有个例子看看。

樱qq · 发表于 2009-9-21 15:23:45

有例子不？

zhouzxcv · 发表于 2007-9-24 23:37:28

刘洪鹏 · 发表于 2007-7-24 17:06:51

实际应用很广泛

孤独无心 · 发表于 2007-6-28 16:14:09

利用路径覆盖的思想来实现流程测试，这个想法不错

lymusicar · 发表于 2007-6-22 19:40:21

我是测试新手，谢谢帮助，现在急着充电 sdlkfj3

蓝花一朵 · 发表于 2007-4-19 16:16:22

不错,学习

lianglina_2003 · 发表于 2007-4-18 09:56:57

这个方法呢在测试中我是常用的,但对于不同的系统怎样凭测试经验去做呢?

winning1 · 发表于 2007-4-18 09:29:11

谢了！学习中。

hayerk · 发表于 2007-1-18 10:45:24

醍醐灌顶啊~
最近觉得自己设计测试用例遇到了瓶颈，在单个功能点或者测试数据选择方面都比较得心应手，但是对整个软件的业务流程把握不是很好，测完后对软件大的方面心里都还是没底。
尝试一下用这里介绍的路径分析去看看我的测试到底覆盖了多少路径

yxd2006 · 发表于 2006-12-3 17:34:42

stonemary · 发表于 2006-11-15 16:21:49

运用这样的方法编写测试用例方法不错噢，这样的编写是建立在对系统有很彻底的了解的基础之上的。如果你的系统真的是使用了UML的标准用例图的话，也许会很有效果。如果不是，还是得靠自己思考有哪些情况导致这样的分支会出现。

枫飞林 · 发表于 2006-11-8 10:12:58

经理以后要我转集成测试，单元测试，我的好好看看这个

lingzhen · 发表于 2006-10-24 01:20:49

设计测试用例的方法不少，但始终离不开逻辑这个概念。
不管你是哪个方法，其他都可以看做是不同抽象层次的事务逻辑和不同角度看待的事务逻辑。最后还是要通过覆盖全部或者部分的逻辑来达到目标的。
黑合路径、用例事件流、领域模型、业务逻辑、类关联。这些都可以看成是不同抽象层次的事务/事物逻辑关系的表示而已。至于测试能覆盖多深，一个取决于获取的项目信息的充分程度，一个取决于你对特定层次的相关知识掌握的广度和深度。所以这也涉及到论坛里老问的测试人员需要多少开发的技能这个问题，这其实是取决于你的组织需要你测试的完全程度的，需要测试的越完全，那么就需要测试更多的细节和逻辑组合，你需要用到的知识就越多，仅此而已。

个人感觉如此，或许有错，交流一下而已。

aifly · 发表于 2006-10-21 15:23:45

不错不错,学了不少,谢谢~~~~~~

yongjun4 · 发表于 2006-10-20 15:10:53

lz的思路很好，我们公司主要做流程类的项目，这种方法很适用，但就像前面的朋友们说的，如果流程剧复杂的话，这样设计用例还是比较费时间的

walker_lai · 发表于 2006-9-3 13:37:14

学习先

chyl313 · 发表于 2006-8-24 11:31:55

thank you !

zhaofengwwx · 发表于 2006-8-22 09:29:25

skinapi 朋友，麻烦你再抽点时间再结合一个实际的例子，再给我们大家讲讲吧，谢谢了！

		自动登录	找回密码
密码			(注-册)加入51Testing

[讨论] 用路径分析的方法编写测试用例

相关帖子

好思路

回复 #65 starseeker 的帖子

站长推荐 /1