51Testing软件测试论坛

标题: 用路径分析的方法编写测试用例 [打印本页]

作者: skinapi 时间: 2004-6-8 13:08
标题: 用路径分析的方法编写测试用例
说明：这段文字可以看成是Testing from use cases using path analysis technique, Naresh Ahlowalia Object System Group的读书笔记，目前还没有很好的系统的尝试过，以后尝试了再给大家谈谈具体的感受吧。或者哪位大虾用过类似的方法可以介绍介绍嘛。

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

作者: ting_yt2 时间: 2004-6-10 12:42
精彩！！谢谢了

作者: boathell 时间: 2004-6-22 10:31
标题: 原来流程是这样测试的（^_^恍然大悟^_^）
原来流程是这样测试的（^_^恍然大悟^_^）
谢谢了

作者: wgfxman 时间: 2004-7-7 15:49
标题: 俺们使用了这种方法
俺们使用了这种方法，确实在流程明确（就是有画出相应业务或者功能走向图）的时候极大的加快了用例编写的速度和质量，但是使用这个方法制定的用例模版在碰到没有明确流程图的时候，可能会花不少的时间去捉摸功能点的流程走向问题，这又让我的工作进度慢了下来，（流程不明确是因为需求没有明确表述和设计没有相应流程描述）
所以，俺想如果想使用这种方法来加快和改进测试用例的进度和质量，还要说服项目组尽可能的规范需求和设计的文档规范性，毕竟软件质量的控制不是我们一组人就能做到的。
个人意见，欢迎指点:d

作者: wind 时间: 2004-7-12 20:26
楼主的设想是很好的，对于简单的系统，相信也是可行的，但对于复杂的系统，通常有一个功能状态转换图存在，也就是说是一种网状结构，是很难简单的划分成一条条路径的。

作者: zccsict 时间: 2004-7-28 08:27
我对用例设计还是迷糊！
能不能用例设计的例子呢？最好是用程序语言编写的例子

作者: Daisy 时间: 2004-7-29 17:32
对于一个多任务的，很多分支，代码很长的程序，好像事先起来，麻烦。

在这里我想问一下，出现调用函数和返回时，你们是怎么处理的？

   是给他赋一个理想的值，把它当顺序语句执行下去，还是? 这个路径的输入数据怎样设计？

   做一个接口边界测试 write(int a, int b, int c，e,d,f,g,h)

我们的软件测试工程师，就写了这么多的传递函数，a b c d e f g h 都有边界，

我怎样写边界测试用例。

还有传递参数试结构体的怎样用例？

传递参数类型试指针的怎样做边界测试？

搂主这些都是软界测试常遇到的，有没有有效的办法，

在代码中一眼能看出的路径，或者只有=和！= 两种还需要设计用例吗？

报告中，还要体现吗？

作者: wangxiang 时间: 2004-7-31 15:50
标题: 初学者
对于我而言，我看得不是很懂，我只是个初学者，希望能给我设计一个简单的测试用例，这样我也会有一个感观我认识。

作者: Kapok 时间: 2004-8-25 15:32
这种方法的主要思想应该是将path analysis应用在functional testing也就是black-box testing中吧。也就是说，在white-box testing时，从语句中寻找testing path，而现在则是从requirement specification中寻找path；这时通常都是将各个组件放在一起的integration testing阶段了。

Boris Beizer，也是挺有名的软件测试学者，写了一本《Black-Box Testing -- Techniques for Functional Testing of Software and Systems》，介绍了许多可以应用到functional testing中的white-box的方法，譬如condition/domain/data flow testing之类。这些white-box的方法的effectiveness在structural testing中是经过严格数学证明的，虽然其在functional testing中的应用没有经过严格证明，但应该还是有效的。

作者: hxf 时间: 2004-8-26 09:43
写的很好，能不能给一个具体例子。

作者: annie 时间: 2004-8-27 15:42
写的很不错，希望能又一个例子就更好了！

作者: Fuli 时间: 2004-8-30 17:30
不错！

作者: 围晶 时间: 2004-9-1 14:15
标题: 新手意见
写case之前分析需求是必须的过程。

作者: simonllf 时间: 2004-10-20 10:43
这个原理是不是和TD中的REQUIREMENT的编写有关系？现在我有点不明白的是TD中的REQUIREMENT的编写用的迭代方式是怎样操作的，我看了这篇文章。我感觉是不是原理上有联系。。我是新手。。所以请有经验的兄弟说说行吗？

作者: yy_q123 时间: 2004-10-20 21:42
楼主所指的是理论让的路径测试，可是在白盒中的的路径测试相对应的是语句的路径覆盖。而在流程中，这个工作量是太大了。在整个流程中使用我本人认为到现在还没有发现一个好的路径覆盖方法。我认为楼主提出的这个观点。可能是把这一理论化了。

作者: xiaojunbo_886 时间: 2004-11-1 17:02
具体情况具体分析

作者: chaoyang_70 时间: 2004-11-11 09:43
用例描述的是通过一系列的行为完成对用户来说具有价值的功能。在用例详述的过程中有的会绘出其活动图，在活动图中会涉及到用户的主要路径。当然还会有很多其它的可备选路径、异常路径以及扩展路径等。
在对一个用例的所有可能的路径全部覆盖的话，工作量也是挺大的。假若在测试时间比较紧的情况下，可以先对其主要路径进行测试，然后再测试其它优先级相对高一点的备选路径。

作者: ghost 时间: 2004-11-11 09:54
高！就这么做！

作者: nancy.liu 时间: 2004-11-11 15:17
ＴＤ是什么,不明白?

作者: cecliawangy 时间: 2004-11-12 16:57
恩，我一直都很希望能够实现这样的方法来整理测试用例，但是由于系统的复杂性也一直不能够很好的完成。道理大家都能够体会到，但实际应用上又有什么技巧和原则呢？

作者: pktest 时间: 2004-11-13 23:00
现在很多单位还为了所谓的保密而不让测试人员接触代码!!!

作者: shtesting 时间: 2004-11-18 14:36
大家接触的自动化测试软件还是太少了，质量分析和保障软件McCabe就是这样来提出指导设计测试用例指导的

作者: newzxf 时间: 2004-11-23 09:30
我们公司在测试ERP项目时，专门针对业务流程设计了测试用例，感兴趣的话可以交流一下哈。

作者: wanglpz 时间: 2004-11-30 22:28
写的好。希望能继续给大家发一些这样的帖子。

作者: xinwuhan2006 时间: 2004-12-12 14:49
Very good!

作者: Hanker 时间: 2004-12-12 17:49
楼主的想法非常好，但首先我们要分析系统的系统构架，熟悉UML关系图。如果我们把软件的系统、模块间的关系搞清楚。这将需要很大的精力去学习。。。不过为了软件的质量和多学点东东。我支持！！！

作者: atce 时间: 2004-12-22 17:17

Originally posted by pktest at 2004-11-13 11:00 PM:
现在很多单位还为了所谓的保密而不让测试人员接触代码!!!

其实如果可以在GUI发现各功能键之间的路径覆盖，测试人员是不需要了解具体代码的。

作者: txjoyo 时间: 2004-12-31 16:20
标题: 测试理论太重要了！

作者: njalic 时间: 2005-1-11 19:29

Originally posted by newzxf at 2004-11-23 09:30 AM:
我们公司在测试ERP项目时，专门针对业务流程设计了测试用例，感兴趣的话可以交流一下哈。

我从事物流方面的测试工作,正苦于测试用例的设计问题,希望能和你交流交流.

MSN :njsundy@hotmail.com

作者: rien2128 时间: 2005-1-31 15:28
很有帮助，谢谢！！

作者: xjtuzxq 时间: 2005-2-6 15:57
不错不错

作者: windbee 时间: 2005-2-7 09:07
thanks

作者: fatbullkid 时间: 2005-2-21 22:29
up

作者: 疯子 时间: 2005-2-24 14:42
标题: 感谢
没一篇贴子都仔细研读

读懂的要读，读不懂的更要反复读。

感谢楼主，支持才有动力。

作者: 女人汤 时间: 2005-3-3 23:33
软件测试工具McCabe可以进行独立路径的分析，
借助这个工具可以提高测试用例设计的效率。

作者: testerPaul 时间: 2005-3-15 10:53

Originally posted by Daisy at 2004-7-29 05:32 PM:
对于一个多任务的，很多分支，代码很长的程序，好像事先起来，麻烦。

在这里我想问一下，出现调用函数和返回时，你们是怎么处理的？

是给他赋一个理想的值，把它当顺序语句执行下去，还是? 这个路径 ...

针对这类测试,我的想法是写个自动化测试脚本,让程序自己去测试,会更高效

作者: xy831228 时间: 2005-3-28 10:24
有点感觉,特别是时间紧的情况下,很实用!

作者: zyh2008108 时间: 2005-4-12 14:57
能举个手机反面的设计用例吗?谢谢,我是新手刚开始做这一反面的工作,摆脱拉!!!@_@

作者: goal0813 时间: 2005-4-15 11:21
斑竹的想法是很不错，利用路径覆盖的思想来实现流程测试，我想将来测试用例设计的趋势也是应该朝这边发展的。
不过在实际的测试过程中可能会遇到些问题，比如用户需求变化太快，测试用例对应起来也就比较麻烦，等等。。。
欢迎讨论！

作者: songfun 时间: 2005-4-19 20:34
这也是我近来体会越来越深刻的一点，真是英雄所见略同呵呵。
的确，路径覆盖完全可以放到系统测试来做！
而且很有必要！

作者: zibeikehappy 时间: 2005-6-8 15:00
学习学习再学习！

作者: elevenchen 时间: 2005-6-8 16:15
不错啊,谢谢

作者: elevenchen 时间: 2005-6-8 16:16
不错啊,谢谢

作者: michelle_happy 时间: 2005-7-1 13:57
我基本上一直就是用这种方法的，不然测试可能象无头苍蝇一样，如果能覆盖所有的路径，起码自己心里也有底了。
我觉得这种方法难就难在对流程的深刻剖析上，要滴水不漏的抓住所有引起分叉路径的要点，有些是很容易看出来的，有些则是隐藏较深的，如果对系统不是深刻理解，估计一时半会找不出来。还有输入的数据也很重要，因为各条路径均是由不同的数据驱动的，设计出好的数据可以提高效率。
对于复杂的系统测试流程的自动化，前期的录制，修改，调试的工作也是大的惊人啊，唉，由于团队小，以及对自动化软件不精通，一直不敢用啊。感觉弄不好效率会更低。

以上是本人的一点愚见。

[ Last edited by michelle_happy on 2005-7-1 at 13:58 ]

作者: lxd1229 时间: 2005-7-1 17:16
想覆盖所有路径挺困难的
这得需要对软件相当的了解了，否则很难做到的。

作者: coffeemilk 时间: 2005-7-13 10:40
标题: 这个方法是不错。
还有个也是类的，假设一个流程的由功能A,B,C，串起来。你也可以这样入手，A的来源数据有那些，全部列出来，出口数据有那些，全部列出，（其余类似），这样的话也可以理清楚。

但是这样有个不好的地方就是都是正常流程。我们测试过程中不金仅仅要考虑正常流程，也要考虑异常的流程，备选的流程。

作者: panpan221 时间: 2005-7-19 11:40
标题: 不错,可惜
不错,要是能有个具体的例子就更好了!

作者: dolphin90 时间: 2005-8-4 15:57
个人感觉楼主的提议是个好方法
但是不一定适用所有的软件
对强化流程的软件可以采用
但又不能是关系非常复杂的
像蜘蛛网结构的软件

作者: bangzhu 时间: 2005-8-18 17:07
偶是新人，很有收获
顶

作者: gxl529 时间: 2005-9-8 15:56
关于如何很好的将基本路径法用到黒盒测试中,我曾经研究过很长一段时间,个人感觉,基本路径法可以很好的用在一些流程的测试中,尤其是办公自动化类的测试!

作者: SayeWang 时间: 2005-9-9 09:18
似的方法选对了就会少走很多弯路

作者: vily1314 时间: 2005-11-1 11:05
我也在试着用这种方法写测试用例，基本上可以通过需求分析中的业务流程去设计我们的测试用例，但是也会碰到一些麻烦，比如说需求描述的不够清楚，我想去规范是有必要的，但是实际上往往会有许多事情是做不到的，那么我想及时跟写需求的人员进行沟通去解决这个问题也是一种办法，可能好的时间会多。但是毕竟漏掉的，或者说没有详尽描述应该是居于少数的，大部分的公司不是太有可能做到那么规范，能处处到位！这是我们应该要想办法去克服的问题！

作者: 983221wy 时间: 2005-12-6 10:12
谢谢了~！~！！！

作者: weiwen 时间: 2005-12-7 17:23
想法的确不错，很有感触，如果能用一个例子说明将会更好

作者: adam1000 时间: 2005-12-14 23:33
根据流程确定优先级不错的想法，

作者: gxl529 时间: 2006-4-14 09:46
楼主COPY我的文章，为什么不连同例子一起COPY过来让大家一起讨论讨论！

如想了解更多，就参看原文：http://community.hf-mstc.org/cs/forums/1228/ShowPost.aspx

作者: CONNIE06 时间: 2006-5-18 12:04
谢谢!

作者: BLEACH 时间: 2006-5-25 16:36
谢谢sdlkfj2

作者: jiyan81 时间: 2006-5-31 10:51
这种测试方法我明白，也常用，但是如果设计用例采用那个用例模版好呢，很多不适合
测试方法我通常都会，但是一提到设计用例就没有思路了
谢谢指教

作者: jihuli5 时间: 2006-6-1 19:53
这就是系统测试用例设计方法中的流程分析法，这种方法的关键是从对应的需求规格项中抽象出业务的流程图，流程图只要包括3个部分，一是用户的操作(输入数据，确认等)，然后就是系统的对用户输入的反应了，再有就是一些条件的判断，只要搞清楚了这三部分内容就基本上可以画出业务流程图了，画好了流程图后就可以把所有的路径都确定出来，对于每一条路径使用等价类边界值等方法来确定测试数据，从而形成测试用例。

作者: jinlan 时间: 2006-7-18 15:00
hao !

作者: huangfei 时间: 2006-7-18 15:46
真精彩！

作者: baobaoliang 时间: 2006-7-19 11:48
标题: 不错！
真需要了解这方面的知识呢！谢谢！！！

作者: longlove2003 时间: 2006-7-19 13:27
利用自动化测试软件就如虎添翼了,希望和大家多多交流

作者: starseeker 时间: 2006-7-20 15:49
不错，受到点启发。

作者: llmm0409 时间: 2006-7-20 16:06
哈哈，我在设计测试用例用的就是这种方法，本人认为这种方式在测试用户需求实现的覆盖率上是不错的选择，但是在发现 ad hoc类的bug 上不是很好使。拙见！

作者: qmier 时间: 2006-7-22 10:30
其实这种思考方式与场景法设计测试用例有什么不一样吗？

作者: zhaofengwwx 时间: 2006-8-22 09:29
skinapi 朋友，麻烦你再抽点时间再结合一个实际的例子，再给我们大家讲讲吧，谢谢了！

作者: chyl313 时间: 2006-8-24 11:31
thank you !

作者: walker_lai 时间: 2006-9-3 13:37
标题: 回复 #65 starseeker 的帖子
学习先

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

作者: aifly 时间: 2006-10-21 15:23
不错不错,学了不少,谢谢~~~~~~

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

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

作者: 枫飞林 时间: 2006-11-8 10:12
经理以后要我转集成测试，单元测试，我的好好看看这个

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

作者: yxd2006 时间: 2006-12-3 17:34
3Q

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

作者: winning1 时间: 2007-4-18 09:29
谢了！学习中。

作者: lianglina_2003 时间: 2007-4-18 09:56
这个方法呢在测试中我是常用的,但对于不同的系统怎样凭测试经验去做呢?

作者: 蓝花一朵 时间: 2007-4-19 16:16
不错,学习

作者: lymusicar 时间: 2007-6-22 19:40
我是测试新手，谢谢帮助，现在急着充电 sdlkfj3

作者: 孤独无心 时间: 2007-6-28 16:14
利用路径覆盖的思想来实现流程测试，这个想法不错

作者: 刘洪鹏 时间: 2007-7-24 17:06
实际应用很广泛

作者: zhouzxcv 时间: 2007-9-24 23:37
3Q

作者: 樱qq 时间: 2009-9-21 15:23
有例子不？

作者: trancy 时间: 2009-10-1 16:51
觉得比较理论化呢，目前还没有通过这样子去实践，最后有个例子看看。

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)