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

skinapi

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

ting_yt2

精彩！！ 谢谢了

boathell

原来流程是这样测试的（^_^恍然大悟^_^）
谢谢了

wgfxman

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

wind

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

zccsict

我对用例设计还是迷糊！
能不能用例设计的例子呢？最好是用程序语言编写的例子

Daisy

对于一个多任务的，很多分支，代码很长的程序，好像事先起来，麻烦。

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

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

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

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

我怎样写边界测试用例。  

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

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

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

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

报告中，还要体现吗？

wangxiang

对于我而言，我看得不是很懂，我只是个初学者，希望能给我设计一个简单的测试用例，这样我也会有一个感观我认识。

Kapok

这种方法的主要思想应该是将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

写的很好，能不能给一个具体例子。

annie

写的很不错，希望能又一个例子就更好了！

Fuli

不错！

围晶

写case之前分析需求是必须的过程。

simonllf

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

yy_q123

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

xiaojunbo_886

具体情况具体分析

chaoyang_70

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

ghost

高！就这么做！

nancy.liu

ＴＤ是什么,不明白?

cecliawangy

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