lovewedy 日志收藏 - lovewedy的个人空间 - 51Testing软件测试网 51Testing软件测试网-软件测试人的精神家园

空间管理您的位置: 51Testing软件测试网 » lovewedy的个人空间 » 日志收藏

HTTP请求模型和头信息

smile665 发布于 2010-06-26 09:04:02

作为一个Web测试工程师，对HTTP协议还是需要一定的了解的，对其请求模型和头信息进行了学习，总结如下：
HTTP请求模型
一、连接至Web服务器
一个客户端应用（如Web浏览器）打开到Web服务器的HTTP端口的一个套接字（缺省为80）。
例如：http://www.myweb.com:8080/index.html
在Java中，这将等同于代码：

Socket socket=new Socket("www.myweb.com",8080);
InputStream in=socket.getInputStream();
OutputStream out=socket.getOutputStream();

二、发送HTTP请求
通过连接，客户端写一个ASCII文本请求行，后跟0或多个HTTP头标，一个空行和实现请求的任意数据。一个请求由四个部分组成：请求行、请求头标、空行和请求数据。
1、请求行：请求行由三个标记组成：请求方法、请求URI和HTTP版本，它们用空格分隔。
例如：GET /index.html HTTP/1.1
HTTP规范定义了8种可能的请求方法：

GET //检索URI中标识资源的一个简单请求
HEAD //与GET方法相同，服务器只返回状态行和头标，并不返回请求文档
POST //服务器接受被写入客户端输出流中的数据的请求
PUT //服务器保存请求数据作为指定URI新内容的请求
DELETE //服务器删除URI中命名的资源的请求
OPTIONS //关于服务器支持的请求方法信息的请求
TRACE //Web服务器反馈Http 请求和其头标的请求
CONNECT //已文档化但当前未实现的一个方法，预留做隧道处理

2、请求头标：由关键字/值对组成，每行一对，关键字和值用冒号（:）分隔。
请求头标通知服务器有关于客户端的功能和标识，典型的请求头标有：

User-Agent //客户端厂家和版本，eg：Mozilla /5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3
Accept //客户端可识别的内容类型列表，eg：text /html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language //接收语言，eg：zh- cn,zh;q=0.5
Accept-Encoding //接收压缩方式，eg：gzip,deflate
Accept-Charset //接收编码，eg：GB2312,utf-8
Keep-Alive //客户端到服务器端的连接持续有效
Connection //链接方式，eg：keep-alive
Cookie //
Cache-Control //控制HTTP缓存
Referer //请求的来源页面
Host //请求主机
Authorization //页面验证
//POST时
Content-Type //数据或文件的类型
Content-Length //附加到请求的数据字节数

3、空行：最后一个请求头标之后是一个空行，发送回车符和退行，通知服务器以下不再有头标。

4、请求数据：使用POST传送数据，最常使用的是Content-Type和Content-Length头标。

三、服务端接受请求并返回HTTP响应
Web服务器解析请求，定位指定资源。服务器将资源副本写至套接字，在此处由客户端读取。
一个响应由四个部分组成；状态行、响应头标、空行、响应数据

1、状态行：状态行由三个标记组成：HTTP版本、响应代码和响应描述。
HTTP版本：向客户端指明其可理解的最高版本。
响应代码：3位的数字代码，指出请求的成功或失败，如果失败则指出原因。
响应描述：为响应代码的可读性解释。
例如：HTTP/1.1 200 OK
HTTP响应码：

1xx：信息，请求收到，继续处理
2xx：成功，行为被成功地接受、理解和采纳
3xx：重定向，为了完成请求，必须进一步执行的动作
4xx：客户端错误，请求包含语法错误或者请求无法实现
5xx：服务器错误，服务器不能完成对一种正常请求的处理

2、响应头标：像请求头标一样，它们指出服务器的功能，标识出响应数据的细节。

Date //返回时间，eg：Thu, 15 Oct 2009 15:44:12 GMT
Server //web服务器类型 Apache /2.0.54 (Unix)
Last-Modified //最近更新时间 Thu, 15 Oct 2009 15:43:22 GMT
Accept-Ranges //接收范围，eg：bytes
X-Powered-By //使用的语言工具，eg：PHP /5.2.6
Cache-Control //缓存控制，eg：max-age=60
Expires //过期时间 Thu, 15 Oct 2009 15:45:12 GMT
Content-Encoding //页面压缩 eg：gzip
Content-Type //返回数据类型，eg： text/html; charset=UTF-8
Connection //请求连接，eg：close
Set-Cookie //The server sends the line Set-Cookie only if the server wishes the browser to store a cookie. Set-Cookie is a request for the browser to store the string name=value and send it back in all future requests to the server.

3、空行：最后一个响应头标之后是一个空行，发送回车符和退行，表明服务器以下不再有头标。

4、响应数据：HTML文档和图像等，也就是HTML本身。

四、服务器关闭连接，浏览器解析响应
1.浏览器首先解析状态行，查看表明请求是否成功的状态代码。
2.然后解析每一个响应头标，头标告知以下为若干字节的HTML。
3.读取响应数据HTML，根据HTML的语法和语义对其进行格式化，并在浏览器窗口中显示它。
4.一个HTML文档可能包含其它需要被载入的资源引用，浏览器识别这些引用，对其它的资源再进行额外的请求，此过程循环多次。

五、无状态连接
HTTP模型是无状态的，表明在处理一个请求时，Web服务器并不记住来自同一客户端的请求。HTTP是一种无状态的协议，无状态是指Web浏览器和Web服务器之间不需要建立持久的连接，这意味着当一个客户端向服务器端发出请求，然后Web服务器返回响应(response)，连接就被关闭了，在服务器端不保留连接的有关信息.
如果浏览器或者服务器在其头信息加入了这行代码：Connection:keep-alive，TCP连接在发送后将仍然保持打开状态，于是，浏览器可以继续通过相同的连接发送请求。保持连接节省了为每个请求建立新连接所需的时间，还节约了网络带宽。

六、实例
1.浏览器发出请求
GET /index.html HTTP/1.1

服务器返回响应:

HTTP /1.1 200 OK
Date: Apr 11 2006 15:32:08 GMT
Server: Apache/2.0.46(win32)
Content-Length: 119
Content-Type: text/html

<HTML>
<HEAD>
<LINK REL="stylesheet" HREF="index.css">
</HEAD>
<BODY>
<IMG SRC="image/logo.png">
</BODY>
</HTML>

附录知识：
1.HTTP规范：Internet工程制定组织（IETF）发布的RFC指定Internet标准，这些RFC被Internet研究发展机构广泛接受。因为它们是标准文档，故一般用正规语言编写，如立法文标一样。
2.RFC：RFC一旦被提出，就被编号且不会再改变，当一个标准被修改时，则给出一个新的RFC。作为标准，RFC在Internet上被广泛采用。
3.HTTP的几个重要RFC：
    RFC1945    HTTP 1.0 描述
    RFC2068    HTTP 1.1 初步描述
    RFC2616    HTTP 1.1 标准
4.资源标识符URI（Uniform Resource Identifter，URI）
5.在http 1.0的协议里定义了三种请求方式：GET，POST，HEAD。http 1.1又补充了一些，如PUT，DELETE，OPTIONS和TRACE。
6.查看HTTP请求和相应的头信息：http://web-sniffer.net/ 或者 firebug/httpwatch等工具。

参考资料：
http://www.java3z.com/cwbwebhome/article/article2/2406.html?id=1093
http://www.jgcao.com/index.php/2009/10/http-%E8%AF%B7%E6%B1%82%E7%AE%80%E4%BB%8B/

查看(2214) 评论(0) 收藏分享管理

白盒测试之静态检查－－检测循环判断体重复计算

xiaohanjiang 发布于 2010-04-17 22:25:06

在编写循环结构的程序很多程序会犯一个错误，就是在循环判断体中做重复计算。

例如：for(int i = 0;i <list.size; i ++) {

           …

}

应替换为：

for(int i = 0,int len = list.size();i < len; i ++) {

            …

}

在循环的语句结构中，每次跳转都需要比较，判断是否进行继续循环，但是最好不要在比较之前有

计算的语句，尽量避免。否则循环中重复计算，效率会非常低。

    今天开发的静态扫描检测器就是检查这个问题，

时刻提醒程序员注意该问题。

扫描器运行结果如图：

该检测器详细介绍：

1.1.1        PERFORMANCE_LOOP_CALCULATE

循环中重复计算

1.1.1.1       版本

Verson:1.2.0

1.1.1.2       作者

Author: River.liu

Date : 2010.4.17

Email :   liuhanhong@yahoo.com.cn

1.1.1.3       原理

在循环的语句结构中，每次跳转都需要比较，判断是否进行继续循环，但是最好不要在比较之前有

计算的语句，尽量避免。否则循环中重复计算，效率会非常低。

例如：for(int i = 0;i < list.size; i ++) {

            …

}

应替换为：

for(int i = 0,int len = list.size();i < len; i ++) {

            …

}

1.1.1.4       开发原理

当遇到循环指令，就查找之前保存的preDirectCount个指令，判断是否存在includeMethordsDirect指定的指令，同时判断是否调用了includeMethords指定的方法，如果存在就表示存在循环计算。

1.1.1.5       配置说明

配置文件pluginConfig.properties在插件的jar包里面，直接修改里面的配置项目，再放回jar包就可以了。

1.1.1.5.1      isOpen

是否启用该检测器。

PERFORMANCE_LOOP_CALCULATE.isOpen=true

1.1.1.5.2      includeMethords

在循环中进行计算的方法的名字，比如list.size()为szie

每个方法名以逗号分隔

PERFORMANCE_LOOP_CALCULATE.includeMethords=size

1.1.1.5.3      preDirectCount

循环指令保存的前preDirectCount个指令，

也就是循环指令的前preDirectCount指令中调用了指定的方法就算匹配了

PERFORMANCE_LOOP_CALCULATE.preDirectCount=3

1.1.1.5.4      includeMethordsDirect

循环指令的前preDirectCount个指令中调用的指令的列表

# all methord direct:INVOKEVIRTUAL = 182;INVOKESPECIAL = 183;INVOKESTATIC = 184;INVOKEINTERFACE = 185;

PERFORMANCE_LOOP_CALCULATE.includeMethordsDirect=182,185

1.1.1.6       误报说明

1、可能会把循环体里面的计算当作条件判断的计算

如果preDirectCount参数的值过大

可能会把aa.size();当作循环计算

for(int i = 0,int len = list.size();i < len; i ++) {

            aa.size();

}

－－－－－－－－－－－－－－－－－－－－－－river.liu 2010.4.17

查看(718) 评论(0) 收藏分享管理
测试用例设计－－因果图方法

wuxj 发布于 2009-02-23 12:08:29

一. 方法简介
　　1.定义：是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。

　　2.因果图法产生的背景：

　　等价类划分法和边界值分析方法都是着重考虑输入条件，但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了，但多个输入条件组合起来可能出错的情况却被忽视了。

　　如果在测试时必须考虑输入条件的各种组合，则可能的组合数目将是天文数字，因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计，这就需要利用因果图（逻辑模型）。

　　3.因果图介绍

　　1) 4种符号分别表示了规格说明中向4种因果关系。

　　2) 因果图中使用了简单的逻辑符号，以直线联接左右结点。左结点表示输入状态（或称原因），右结点表示输出状态（或称结果）。

　　3) Ci表示原因，通常置于图的左部；ei表示结果，通常在图的右部。Ci和ei均可取值0或1，0表示某状态不出现，1表示某状态出现。

　　4. 因果图概念

　　1) 关系

　　① 恒等：若ci是1，则ei也是1；否则ei为0。

　　② 非：若ci是1，则ei是0；否则ei是1。

　　③ 或：若c1或c2或c3是1，则ei是1；否则ei为0。“或”可有任意个输入。

　　④ 与：若c1和c2都是1，则ei为1；否则ei为0。“与”也可有任意个输入。

2) 约束

　　输入状态相互之间还可能存在某些依赖关系，称为约束。例如, 某些输入条件本身不可能同时出现。输出状态之间也往往存在约束。在因果图中,用特定的符号标明这些约束。

　　A.输入条件的约束有以下4类：

　　① E约束（异）：a和b中至多有一个可能为1，即a和b不能同时为1。

　　② I约束（或）：a、b和c中至少有一个必须是1，即 a、b 和c不能同时为0。

　　③ O约束（唯一）；a和b必须有一个，且仅有1个为1。

　　④ R约束（要求）：a是1时，b必须是1，即不可能a是1时b是0。

　　B.输出条件约束类型

　　输出条件的约束只有M约束（强制）：若结果a是1，则结果b强制为0。

　　5. 采用因果图法设计测试用例的步骤：

　　1) 分析软件规格说明描述中, 那些是原因(即输入条件或输入条件的等价类),那些是结果(即输出条件), 并给每个原因和结果赋予一个标识符。

　　2) 分析软件规格说明描述中的语义，找出原因与结果之间, 原因与原因之间对应的关系，根据这些关系,画出因果图。

　　3) 由于语法或环境限制, 有些原因与原因之间,原因与结果之间的组合情况不可能出现，为表明这些特殊情况, 在因果图上用一些记号表明约束或限制条件。

　　4) 把因果图转换为判定表。

　　5) 把判定表的每一列拿出来作为依据,设计测试用例。

　　二. 实战演习

　　1. 某软件规格说明书包含这样的要求：第一列字符必须是A或B，第二列字符必须是一个数字，在此情况下进行文件的修改，但如果第一列字符不正确，则给出信息L；如果第二列字符不是数字，则给出信息。

　　解答：

　　1) 根据题意，原因和结果如下：

　　原因：

　　1——第一列字符是A；

　　2——第一列字符是B；

　　3——第二列字符是一数字。

　　结果：

　　21——修改文件；

　　22 ——给出信息L；

　　23——给出信息M。

　　2) 其对应的因果图如下：

　　11为中间节点；考虑到原因1和原因2不可能同时为1，因此在因果图上施加E约束。

　　3) 根据因果图建立判定表。

　　表中8种情况的左面两列情况中，原因①和原因②同时为1，这是不可能出现的，故应排除这两种情况。表的最下一栏给出了6种情况的测试用例，这是我们所需要的数据。

　　2. 有一个处理单价为5角钱的饮料的自动售货机软件测试用例的设计。其规格说明如下：若投入5角钱或1元钱的硬币，押下〖橙汁〗或〖啤酒〗的按钮，则相应的饮料就送出来。若售货机没有零钱找，则一个显示〖零钱找完〗的红灯亮，这时在投入1元硬币并押下按钮后，饮料不送出来而且1元硬币也退出来；若有零钱找，则显示〖零钱找完〗的红灯灭，在送出饮料的同时退还5角硬币。

　　1) 分析这一段说明，列出原因和结果

　　原因：

　　1.售货机有零钱找

　　2.投入1元硬币

　　3.投入5角硬币

　　4.押下橙汁按钮

　　5.押下啤酒按钮

　　结果：

　　21.售货机〖零钱找完〗灯亮

　　22.退还1元硬币

　　23.退还5角硬币

　　24.送出橙汁饮料

　　25.送出啤酒饮料

　　2) 画出因果图，如图所示。所有原因结点列在左边，所有结果结点列在右边。建立中间结点，表示处理的中间状态。中间结点：

　　11. 投入1元硬币且押下饮料按钮

　　12. 押下〖橙汁〗或〖啤酒〗的按钮

　　13. 应当找5角零钱并且售货机有零钱找

　　14. 钱已付清

　　3) 转换成判定表：

　　4) 在判定表中，阴影部分表示因违反约束条件的不可能出现的情况，删去。第16列与第32列因什么动作也没做，也删去。最后可根据剩下的16列作为确定测试用例的依据。

查看(799) 评论(1) 收藏分享管理
[转]OATS正交表测试策略

jiangnanxinxi 发布于 2009-01-09 09:47:25

1    OATS的概念：

次数（Runs）：简单的说，就是次数是多少，就有多少个用例。

因素数（Factors）：简单的说，就是有多少个变量。

水平数（Levels）：比如有三个变量，其中变量取值最多的是四个值，那么水平数就是四。

强度（Strength）：即变量间的相互关系，当强度为二时，只考虑变量两两之间的影响，如果强度为三，同考虑三个变量对结果的影响；当强度增加时，用例的个数会急剧增加。

正交表的表现形式： L runs（levels^factors  ）

介绍混合水平数正交表的知识，混合水平数的正交表中的因素数的水平数是不同的，比如，有5个变量，一个因素数的水平数为4，另外四个因素数的水平数为2，则用正交表表示如下：

L 8（41×24）

2    OATS的好处：

对有些组合测试，我们可选择的一种测试途径是测试所有变量的迪卡尔积（即统计学中的全面搭配法），无疑，这种方式得到的是所有变量、所有取值的完全组合，是最全面的测试。而在变量多的情况下，这无疑也是最不可能实现的方法，所以我们要选择一种方法，即可以测试大部分的BUG，又能极大的缩短我们的时间，正交表是我们的选择：

其特点为：

①    完成测试要求所需的测试用例少。

②    数据点的分布很均匀。

③    可用其他统计学的方法等对测试结果进行分析。

OATS用来设计测试用例的方法如下的好处：

1，可以组合所有的变量；

2，得到一个最小的测试集，这个集合，包括最少的测试用例，并且，包括了所有变量的组合,

3，得到的变量的组合是均匀的分布的（这一点可以参照上面的正交表的特点）；

4，可以测试用一些复杂的组合；

5，它生成的测试用例是有迹可循日，即有规律的，不像手工测试那样会遗漏一些用例的组合。
3    选择OATS的基本原则

一般都是先确定测试的因素、水平和交互作用，后选择适用的正交表。在确定因素的水平数时，主要因素应该多安排几个水平，次要因素可少安排几个水平。

（1）先看水平数。若各因素全是2水平，就选用L(2＊)表；若各因素全是3水平，就选L(3＊)表。若各因素的水平数不相同，就选择适用的混合水平正交表。

（2）每一个交互作用在正交表中应占一列或二列。要看所选的正交表是否足够大，能否容纳得下所考虑的因素和交互作用。为了对试验结果进行方差分析或回归分析，还必须至少留一个空白列，作为“误差”列，在极差分析中要作为“其他因素”列处理。

（3）要看测试精度的要求。若要求高，则宜取测试次数多的正交表。

（4）若测试费用很昂贵，或测试的经费很有限，或人力和时间都比较紧张，则不宜选实验次数太多的正交表。

（5）按原来考虑的因素、水平和交互作用去选择正交表，若无正好适用的正交表可选，简便且可行的办法是适当修改原定的水平数。

（6）对某因素或某交互作用的影响是否确实存在没有把握的情况下，选择L表时常为该选大表还是选小表而犹豫。若条件许可，应尽量选用大表，让影响存在的可能性较大的因素和交互作用各占适当的列。

4    OATS的步骤：

1，先要知道你有多少个变量，这个不用说了，很简单的就能确定了。它对应到正交表的概念中的因素数。

2，查看每个变量的测试取值个数（这里我用a代替，以方便后面调用），这个取值不是说这个变量的取值范围中包括多少个值，而是用等价类划分出来的。关于等价类的方法，这里就不说了。

3，选择正交表，我们选择正交表时，要满足两点：因素数（即变量个数）和水平数。在选择正交表的时候，要保存：

A、正交表的列不能小于变量的个数；

B、正交表的水平数不能小于a。

4，拿着自己的因素数和水平数，去找对应的正交表，按3中说的原则，现在正交表有一部分已经在网上公布了，在很大程度上已经够设计测试用例用了，如果你的情况太特殊，也可以考虑自己去推算。

5，如果你选择的正交表中某个因素数有剩余的水平数，就拿这个因素数的值从上到下循环代进去。以增加发现缺陷的机会。

6，按次数设计用例，每次数对应一个用例。设计完成后，如果觉得有些组合是可能会有问题的，而正交表中又没有包括，那就增加一些用例。
5    OATS的实例：
5.1 实例

下面介绍一个混合正交表的例子：

变量个数：4个　　分别为：A、B、C、D。

取值为：

A－＞3个值（A1、A2、A3）、

B－＞4个值（B1、B2、B3、B4）、

C－＞4个值（C1、C2、C3、C4）、

D－＞4个值（D1、D2、D3、D4）。

把上述数值对应到正交表的概念中去，如下：

因素数：4

水平数：其中3个变量的水平数为4，1个变量的水平数为3。

对应到正交表中写法如下：

L runs（3^1 ＋ 4^3）

1，  只考虑强度为：2的情况。

A、其对应的正交表如下：

Runs  A B C D

1  | 1 1 1 1

2  | 2 2 2 2

3  | 3 3 3 3

4  | - 4 4 4

5  | 1 2 3 4

6  | 2 1 4 3

7  | 3 4 1 2

8  | - 3 2 1

9  | 1 3 4 2

  10  | 2 4 3 1

  11  | 3 1 2 4

  12  | - 2 1 3

  13  | 1 4 2 3

  14  | 2 3 1 4

  15  | 3 2 4 1

  16  | - 1 3 2

即应用到次数为16的正交表，我们可以得到16个用例。

B、把各个变量的代入正交表得到如下正交表：

Runs  A 　B C D

1  | A1 B1 C1 D1

2  | A2 B2 C2 D2

3  | A3 B3 C3 D3

4  | - 　B4 C4 D4

5  | A1 B2 C3 D4

6  | A2 B1 C4 D3

7  | A3 B4 C1 D2

8  | - 　B3 C2 D1

9  | A1 B3 C4 D2

  10  | A2 B4 C3 D1

  11  | A3 B1 C2 D4

  12  | -    B2 C1 D3

  13  | A1 B4 C2 D3

  14  | A2 B3 C1 D4

  15  | A3 B2 C4 D1

  16  | -    B1 C3 D2

C、看上面的正交表可以知道变量A有剩余的水平数。下面我们用A的值循环代入：

Runs  A 　B C D

1  | A1 B1 C1 D1

2  | A2 B2 C2 D2

3  | A3 B3 C3 D3

4  | A1 　B4 C4 D4

5  | A1 B2 C3 D4

6  | A2 B1 C4 D3

7  | A3 B4 C1 D2

8  | A2 　B3 C2 D1

9  | A1 B3 C4 D2

  10  | A2 B4 C3 D1

  11  | A3 B1 C2 D4

  12  | A3 B2 C1 D3

  13  | A1 B4 C2 D3

  14  | A2 B3 C1 D4

  15  | A3 B2 C4 D1

  16  | A1 B1 C3 D2

上面我用A的值循环填充了A剩余的水平数（蓝色标记的部分）。

D、接着，我们就可以用上面的正交表来设计用例了。不再多言。

2，  考虑强度为3的情况：

得到对应的正交表如下：

Runs    A B  C D

1  | 1 1 1 1

2  | 1 1 2 2

3  | 1 1 3 3

4  | 1 1 4 4

5  | 1 2 1 2

6  | 1 2 2 1

7  | 1 2 3 4

8  | 1 2 4 3

9  | 1 3 1 3

  10  | 1 3 2 4

  11  | 1 3 3 1

  12  | 1 3 4 2

  13  | 1 4 1 4

  14  | 1 4 2 3

  15  | 1 4 3 2

  16  | 1 4 4 1

  17  | 2 1 1 2

  18  | 2 1 2 1

  19  | 2 1 3 4

  20  | 2 1 4 3

  21  | 2 2 1 1

  22  | 2 2 2 2

  23  | 2 2 3 3

  24  | 2 2 4 4

  25  | 2 3 1 4

  26  | 2 3 2 3

  27  | 2 3 3 2

  28  | 2 3 4 1

  29  | 2 4 1 3

  30  | 2 4 2 4

  31  | 2 4 3 1

  32  | 2 4 4 2

  33  | 3 1 1 3

  34  | 3 1 2 4

  35  | 3 1 3 1

  36  | 3 1 4 2

  37  | 3 2 1 4

  38  | 3 2 2 3

  39  | 3 2 3 2

  40  | 3 2 4 1

  41  | 3 3 1 1

  42  | 3 3 2 2

  43  | 3 3 3 3

  44  | 3 3 4 4

  45  | 3 4 1 2

  46  | 3 4 2 1

  47  | 3 4 3 4

  48  | 3 4 4 3

  49  | - 1 4 1

  50  | - 2 3 1

  51  | - 3 2 1

  52  | - 4 1 1

  53  | - 1 3 2

  54  | - 2 4 2

  55  | - 3 1 2

  56  | - 4 2 2

  57  | - 1 2 3

  58  | - 2 1 3

  59  | - 3 4 3

  60  | - 4 3 3

  61  | - 1 1 4

  62  | - 2 2 4

  63  | - 3 3 4

  64  | - 4 4 4

我们得到一个次数为64的正交表，按照1中的步骤B、C、D可以得到64测试用例。

在这个例子中，如果我们选择强度为4的表的话，也就相当于覆盖整个迪卡尔积了。所以在强度为4的时候，在这个例子中正交已经没有意义。

查看(573) 评论(0) 收藏分享管理
功能测试

Spark.lee 发布于 2006-12-08 11:44:50

功能测试

      黑盒测试（Black-box Testing，又称为功能测试或数据驱动测试）是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。

      采用黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略。

      黑盒测试注重于测试软件的功能性需求，也即黑盒测试使软件工程师派生出执行程序所有功能需求的输入条件。黑盒测试并不是白盒测试的替代品，而是用于辅助白盒测试发现其他类型的错误。

      黑盒测试试图发现以下类型的错误：

      1）功能错误或遗漏；
      2）界面错误；
      3）数据结构或外部数据库访问错误；
      4）性能错误；
      5）初始化和终止错误。

一、黑盒测试的测试用例设计方法

·等价类划分方法
·边界值分析方法
·错误推测方法
·因果图方法
·判定表驱动分析方法
·正交实验设计方法
·功能图分析方法

等价类划分:

      是把所有可能的输入数据,即程序的输入域划分成若干部分（子集）,然后从每一个子集中选取少数具有代表性的数据作为测试用例.该方法是一种重要的,常用的黑盒测试用例设计方法.

      1) 划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.

      有效等价类:是指对于程序的规格说明来说是合理的,有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能.

      无效等价类:与有效等价类的定义恰巧相反.

      设计测试用例时,要同时考虑这两种等价类.因为,软件不仅要能接收合理的数据,也要能经受意外的考验.这样的测试才能确保软件具有更高的可靠性.

2）划分等价类的方法:下面给出六条确定等价类的原则.

      ①在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类.

      ②在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可确立一个有效等价类和一个无效等价类.

      ③在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类.

      ④在规定了输入数据的一组值（假定n个）,并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类.

      ⑤在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）.

      ⑥在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类.

3）设计测试用例:在确立了等价类后,可建立等价类表,列出所有划分出的等价类:

      输入条件有效等价类无效等价类

      ... ... ...

      ... ... ...

      然后从划分出的等价类中按以下三个原则设计测试用例:

      ①为每一个等价类规定一个唯一的编号.

      ②设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步.直到所有的有效等价类都被覆盖为止.

      ③设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步.直到所有的无效等价类都被覆盖为止.

边界值分析法

      边界值分析方法是对等价类划分方法的补充.

（1）边界值分析方法的考虑:

      长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.

      使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.

（2）基于边界值分析方法选择测试用例的原则:

      1）如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个范围边界的值作为测试输入数据.

      2）如果输入条件规定了值的个数,则用最大个数,最小个数,比最小个数少一,比最大个数多一的数作为测试数据.

      3）根据规格说明的每个输出条件,使用前面的原则1）.

      4）根据规格说明的每个输出条件,应用前面的原则2）.

      5）如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例.

      6）如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值作为测试用例.

      7）分析规格说明,找出其它可能的边界条件.

错误推测法

      错误推测法: 基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.

      错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.

因果图方法

      前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）.

      因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.

      利用因果图生成测试用例的基本步骤:

      (1) 分析软件规格说明描述中, 那些是原因(即输入条件或输入条件的等价类),那些是结果(即输出条件), 并给每个原因和结果赋予一个标识符.

      (2) 分析软件规格说明描述中的语义.找出原因与结果之间, 原因与原因之间对应的关系. 根据这些关系,画出因果图.

      (3) 由于语法或环境限制, 有些原因与原因之间,原因与结果之间的组合情况不不可能出现. 为表明这些特殊情况, 在因果图上用一些记号表明约束或限制条件.

      (4) 把因果图转换为判定表.

      (5) 把判定表的每一列拿出来作为依据,设计测试用例.

      从因果图生成的测试用例（局部,组合关系下的）包括了所有输入数据的取TRUE与取FALSE的情况,构成的测试用例数目达到最少,且测试用例数目随输入数据数目的增加而线性地增加.

      前面因果图方法中已经用到了判定表.判定表（Decision Table）是分析和表达多逻辑条件下执行不同操作的情况下的工具.在程序设计发展的初期,判定表就已被当作编写程序的辅助工具了.由于它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确.

      判定表通常由四个部分组成.

      条件桩（Condition Stub）:列出了问题得所有条件.通常认为列出得条件的次序无关紧要.

      动作桩（Action Stub）:列出了问题规定可能采取的操作.这些操作的排列顺序没有约束.

      条件项（Condition Entry）:列出针对它左列条件的取值.在所有可能情况下的真假值.

      动作项（Action Entry）:列出在条件项的各种取值情况下应该采取的动作.

      规则:任何一个条件组合的特定取值及其相应要执行的操作.在判定表中贯穿条件项和动作项的一列就是一条规则.显然,判定表中列出多少组条件取值,也就有多少条规则,既条件项和动作项有多少列.

      判定表的建立步骤:（根据软件规格说明）

      ①确定规则的个数.假如有n个条件.每个条件有两个取值（0,1）,故有种规则.

      ②列出所有的条件桩和动作桩.

      ③填入条件项.

      ④填入动作项.等到初始判定表.

      ⑤简化.合并相似规则（相同动作）.

      B. Beizer 指出了适合使用判定表设计测试用例的条件:

      ①规格说明以判定表形式给出,或很容易转换成判定表.

      ②条件的排列顺序不会也不影响执行哪些操作.

      ③规则的排列顺序不会也不影响执行哪些操作.

      ④每当某一规则的条件已经满足,并确定要执行的操作后,不必检验别的规则.

      ⑤如果某一规则得到满足要执行多个操作,这些操作的执行顺序无关紧要.

黑盒测试的优点

      1. 基本上不用人管着，如果程序停止运行了一般就是被测试程序crash了
      2. 设计完测试例之后，下来的工作就是爽了，当然更苦闷的是确定crash原因

黑盒测试的缺点

      1. 结果取决于测试例的设计，测试例的设计部分来势来源于经验，OUSPG的东西很值得借鉴
      2. 没有状态转换的概念，目前一些成功的例子基本上都是针对PDU来做的，还做不到针对被测试程序的状态转换来作
      3. 就没有状态概念的测试来说，寻找和确定造成程序crash的测试例是个麻烦事情，必须把周围可能的测试例单独确认一遍。而就有状态的测试来说，就更麻烦了，尤其不是一个单独的testcase造成的问题。这些在堆的问题中表现的更为突出。

查看(2623) 评论(11) 收藏分享管理
从测试用例看测试的发展与变化

kuailederen 发布于 2008-02-19 14:11:44

关键字：测试用例，变化的现状，测试驱动，功能与业务
        对于一个测试人员来说测试用例的设计与编写是一项必须掌握的能力。但有效的设计和熟练的编写却是一个十分复杂的技术，它需要你对整个软件不管从业务还是功能上都有一个明晰的把握。如何系统、结构的对用例加以规范将直接影响到其后的测试效率和效果，同时测试用例也将用来控制软件的整体执行覆盖，对最后的测试结果给出一种量化的评估标准。
一、问题：
        许多测试类的书籍都有大幅篇章介绍用例的设计方法，如等价类划分，边界值，错误推断，因果图，判定表等。但实际应用中这些理论却不能给我们很明确的行为指导，尤其是业务复杂，关联模块紧密，输入标准和输出结果间路径众多时，完全的遵循这些方法只能让我们在心理上得到一种满足，而无法真正有效的提高测试效率，并且我们也没有足够的时间和资源编写完备的用例。通常我们只能依靠以前项目的用例编写经验（或习惯），希望能在这一个项目中更加规范，但多数情况下我们规范的只是“书写的规范”，在用例设计上以前存在的问题现在依旧。
        当好不容易用例基本完成，我们却发现面对随之而来的众多地区特性和新增需求，测试用例突然处于一种十分尴尬的境地：
 从此几乎很少被执行
 已经与程序的实现发生了冲突（界面变动，功能变动）
 执行用例发现的bug很少
 根本没有时间为新的功能需求增补用例
 有时间补充，但用例结构越来越乱
 特性的用例与通性用例之间联系不明确（以新增需求为主线列出所有涉及到的更改，但特性与通行之间的数据或业务联系在用例中逐渐淡化）
   知道怎样执行这个用例，但它要说明什么呢？（多数用例给我们的感觉是只见树木，不见森林，只说明某一功能的实现，无法串起）
        通过上面的一系列问题可以看到，似乎测试用例给我们带来的问题远多于益处，也正是因为在实际过程中遇到的问题积累，导致我们有很充分的理由忽视或拒绝用例的应用。
        但没有用例或简略用例的编写我们又会舒服很多么？不言自明，谁也不想倒退发展。
二、原因：
        事实上我们在测试用例编写和设计上遇到的一系列问题只是一种表面的呈现，究其原因我认为有如下几点：
1、没有适合的规范
        “适合的规范”或称“本地化的规范”。这是我们在测试过程中遇到的第一个问题，通常也是很容易习惯且淡忘的。我们拥有相当多的流程文档、指导步骤和书本上的定义，但它适合我们当前的项目么？
        每一个测试工程师在进入这个职业的初期都会了解一些测试上的概念和术语，进入公司或项目组后也会进一步学习相应的文档，例如怎样规范编写，怎样定义bug级别，软件实现的主要业务等。但当测试经理开始给我们分配某一模块的用例编写时，又有多少人知道该怎样去写，怎样写算是好？
        在测试论坛中常能看到介绍用例编写方法的帖子，而迷茫于怎样应用到实践的回复也不为少数。为何我们无法在公司和项目组内找到明确且适合的规范？于是我们只得选择从书本或之前的用例中复制，不管是结构还是方式都依赖于以往的经验，我并不是说这样就是错误的，但不能总结成文的经验无法给予测试更多帮助。我们有太多经验，但却没有形成适合的规范。
2、功能与业务的分离
        我们知道怎样列举一个输入框的用例，但却很少考虑说明这个输入框是用来做什么的，如果仔细分析不难发现，用例中这种功能与业务的分离越来越普遍也越来越明显。
        边界值、等价类划分、因果图，这些用例方法是一种高度提纯的方法，本身就很偏向于功能及代码，所以怎样编写业务的用例我们就从理论上失去了参考。
        复杂的业务会贯穿于整个软件，涉及众多功能点，里面组合的分支更不可胜数。测试用例务求简洁、明确，这一点也与业务“格格不入”。功能用例依赖程序界面，业务描述依赖需求文档。于是我们更偏向于根据已实现的界面编写功能用例，列举出众多的边界值、等价类。流程的操作只有凭借经验和理解，这时测试出的bug是最多的，但我们却无法使这个bug对应到一个用例中（点击一个按钮报出的错误有时原因并不在这个按钮或按钮所在的窗体），只能自己添加note向开发人员指出可能出错的源头。正因为我们没有很好的积累业务上的用例，才使得我们感到执行用例时发现的bug不多。
        用例结构的划分一定程度上也造成了功能和业务的分离，依照界面模块建立文件夹，并在其中新建不同用例，这使得用例从结构上就很难联通起来。
3、测试未能跟上变化
        变化！想象一下，当我们越来越多的听到开发人员在那里高呼“拥抱变化”“敏捷开发”的时候，测试又有什么举措呢？当地区特性，软件版本越来越多的时候，测试是否在积极响应呢？变化是我们面临的最大挑战，我认为测试未能跟上变化是造成测试过程中遇到种种问题和矛盾的主要原因。
        对需求和程序的变化测试人员的感受是非常深的，测试总是跟在需求和开发后面跑，使得所有风险都压在自己身上。不断压缩的时间和资源使我们只能放弃那些“不必要”的工作：尽快投入测试，尽快发现bug，而非从整体把握软件的质量情况，统筹策略。
        疲于应对的直接影响就是程序质量无法准确度量，进度无法控制，风险无法预估。用例与程序脱节，新增用例混乱和缺少。长此以往我们只得放弃修改、增补用例，甚至放弃之前积累的所有成果。用例变为程序变更的记录摘要，没有测试数据的保留，测试步骤和重点无法体现，新加功能与原来的程序逐渐“脱离”，可能还会出现相互违背的情况，但这我们却无法及时发现。
永远是变化决定我们的下一步工作，这也是混乱的开始。
三、可能的解决办法：
        上面的问题也许在成熟的公司和项目组内很少遇到，而遇到问题的也需根据不同的情况单独考虑。分析错误并不能给我们带来成功，而成功的特质也不会尽为相同。所以在这里我希望以探讨的方式提出一些可能的解决办法，不拘泥形式，以结果来确定，最适合的就是最好的。
1、测试驱动开发，用例指导结果，数据记录变化
        “测试驱动开发”（TDD）是一个比较新的概念，在网上可以看到很多介绍文章，它主要讨论如何让开发的代码更奏效（Work）更洁净（Clean），“测试驱动开发的基本思想就是在开发功能代码之前，先编写测试代码”。可以看到，TDD是建立在“代码”级别的驱动，但目前我们需要探讨的问题是怎样在黑盒测试中做到“测试驱动开发”。
        首先我们需要纠正一个态度，很多人认为黑盒测试的技术含量不高，可思考可拓展的内容不多，主要的工作就是用鼠标在那里瞎点，于是很多“高级”的技术方法都试图与黑盒测试划清界限。但测试人员发现的bug有80％以上都是黑盒测试发现的，手工操作软件仍是目前检验软件质量最有效的一种方法。
        如何在黑盒测试中做到测试驱动开发？我认为可以从用例级别做起，以业务用例指导实现的结果。
        开发人员通常比较关注技术，对于业务上的理解容易忽视并出现偏差，而需求文档又不会很全面的指出应该实现怎样的结果，这就使得从业务到功能出现一个“阅读上的障碍”，如果最后发现程序错了还需返工，这样耗费的人力物力就非常大了。测试人员和最终用户不用过分关心软件实现的细节，所以以业务用例驱动开发，就是一个比较好的方法。给出一个明确的预期结果，指导开发人员如何界定是否达成目标，同样这也需要运用测试中的各种方法，列举出业务流程里数据的等价类和边界值。
        业务用例的构造要先于程序实现，与需求和开发人员沟通一致，并以此作为一个基准，保证程序实现不会出错，还能对整个软件的进度和质量有一个很好的估计和度量。业务用例可以不关注程序的界面，但一定要有数据的支持。这就是测试主导变化的另一点“数据记录变化”。
        我们不仅要应对变化，还要记录变化，使测试用例成为对程序持续性的监控，数据可以作为最基本、最简单的支持。当一个业务很复杂时可以拆分成段（业务段与程序中以窗体或页面的划分是不一样的），使用典型的用例方法列出实际输入和预期结果。我们希望数据能做到通用和共享，最理想的情况就是建立一个“数据库”，每个业务用例都从“数据库”中取得输入数据和预期结果，这个数据只是针对业务入口和出口的，当程序内部设计变更时，保留的数据不会因此而作废。举一个例子，例如我的程序要从某种文件中读取数据并计算结果，一段时间后程序内部字段增加了，如果是以保存的文件附件方式提供数据，则现在程序很可能就打不开这个文件了。使用“数据库”指导测试人员可以在变化的程序里直接针对业务输入，而不关心程序内部结构。
        再进一步的话“数据库”就开始涉及到程序内部的接口，属于单元和集成测试，这需要开发人员的配合。
2、为用例标明时间（版本）和优先级
        为测试用例标明时间或版本可以起到一种基准的作用，标明项目进度过程中的每一个阶段，使用例直接和需求基线、软件版本对应。同样这需要规范流程，也是对变更的一种确认和控制。或者可以为用例增加一个状态，指明这个用例目前是否与程序冲突，当程序变更时改变用例的状态，并更新用例版本。
        为测试用例标明优先级可以指出软件的测试重点、用例编写的重点，减少用例回归的时间，增加重点用例执行的次数，帮助项目组新人尽快了解需求，在自动化测试的初期也可以参考这个优先级录制脚本。
3、功能用例与业务用例分开组织
        为业务用例单独开辟出一种分类，将功能用例与业务用例分开组织，按照不同关注点列举执行路径。业务用例应在开发前或同期编写，帮助测试人员和开发人员明确业务，了解正确流程和错误流程。功能用例更依赖于程序界面的描述，但功能用例并不等于使用说明。对某些模块的等价类、边界值测试会发现很多严重的bug，也许与业务无关，但用户往往很容易这样操作（例如登录名，你是否考虑到很长的名字，或者用户的键盘有问题，总是敲入n多空格在里面，这与业务无关，但程序将会怎样处理？）。
4、审核用例，结对编写
        测试组长或经理对用例进行审核可以做到用例的补充和校对，但一般情况下是很难做到的，我们可以采用另一种方法，就是结对编写测试用例（前提是你有两个以上的测试人员），内部审核。
        测试用例不是自己编写自己执行，它需要其他测试人员都能读懂且明白目标所指。结对编写可以尽量减少个人的“偏好习惯”，同时也能拓展思维，加强测试重点的确认，小组内部达到统一。一定程度上结对编写也可以减少组长或经理对用例的管理负担，提高组员的参与积极性。
四、发展
        上面的这些解决方法只是一种建议，具体如何实施到项目中还需根据情况而定。同时即使我们正在积极的寻求改变，我们还是会碰到无数的新问题和新苦恼，也许会比以前更为众多，这是我们必须付出的。
        可以看到测试的发展方向很多很广，即使传统的黑盒测试并不是毫无新意，高级的测人员必须同时在测试技巧和专业领域方面都有很高的“修为”。测试工作怎样更适合我们而发展，将给予我们更多的思考。

查看(416) 评论(0) 收藏分享管理
功能测试用例设计积累（六）：在敏捷测试中如何设计用例

okokokk 发布于 2009-01-08 19:54:53

敏捷宣言：
个体和交互比过程和工具更有价值；
能工作的软件比全面的文档更有价值；
顾客的协作比合同谈判更有价值；
及时响应变更比遵循计划更有价值。

　　并非每个企业都能严格按敏捷的相关开发方法进行项目管理，例如测试驱动、XP、SCRUM等。也并非都需要按这些方式管理才能实现敏捷。只要我们理解了敏捷的原则和精髓，我认为很多方法、很多地方都可以应用敏捷的思想，实现敏捷的管理。测试用例的设计是其中一项。

1。测试用例的粒度
　　测试用例可以写得很简单，也可以写得很复杂。最简单的测试用例是测试的纲要，仅仅指出要测试的内容，如探索性测试（Exploratory Testing）中的测试设计，仅会指出需要测试产品的哪些要素、需要达到的质量目标、需要使用的测试方法等。而最复杂的测试用例就像飞机维修人员使用的工作指令卡一样，会指定输入的每项数据，期待的结果及检验的方法，具体到界面元素的操作步骤，指定测试的方法和工具等等。
　　测试用例写得过于复杂或过于详细，会带来两个问题：一个是效率问题，一个是维护成本问题。另外，测试用例设计得过于详细，留给测试执行人员的思考空间就比较少，容易限制测试人员的思维。
　　测试用例写得过于简单，则可能失去了测试用例的意义。过于简单的测试用例设计其实并没有进行“设计”，只是把需要测试的功能模块记录下来而已，它的作用仅仅是在测试过程中作为一个简单的测试计划，提醒测试人员测试的主要功能包括哪些而已。测试用例的设计的本质应该是在设计的过程中理解需求，检验需求，并把对软件系统的测试方法的思路记录下来，以便指导将来的测试。
　　大多数测试团队编写的测试用例的粒度介于两者之间。而如何把握好粒度是测试用例设计的关键，也将影响测试用例设计的效率和效果。我们应该根据项目的实际情况、测试资源情况来决定设计出怎样粒度的测试用例。
　　软件是开发人员需要去努力实现敏捷化的对象，而测试用例则是测试人员需要去努力实现敏捷化的对象。要想在测试用例的设计方面应用“能工作的软件比全面的文档更有价值”这一敏捷原则，则关键是考虑怎样使设计出来的测试用例是能有效工作的。

2。基于需求的测试用例设计
　　基于需求的用例场景来设计测试用例是最直接有效的方法，因为它直接覆盖了需求，而需求是软件的根本，验证对需求的覆盖是软件测试的根本目的。
　　要把测试用例当成“活”的文档（Effective Software Testing : 50 Specific Ways to Improve Your Testing – Elfriede Dustin），因为需求是“活”的、善变的。因此在设计测试用例方面应该把敏捷的“及时响应变更比遵循计划更有价值”这一原则。
　　不要认为测试用例的设计是一个阶段，测试用例的设计也需要迭代，在软件开发的不同的阶段都要回来重新审视和完善测试用例。

3。测试用例的评审
　　测试用例设计出来了，质量如何，如何提高测试用例设计的质量？就像软件产品需要通过各种手段来保证质量一样，测试用例的质量保证也需要综合使用各种手段和方法。
　　测试用例的检查可以有多种方式，但是最敏捷的应当属临时的同行评审。我认为同行评审，尤其是临时的同行评审，应该演变成类似结对编程一样的方式。从而体现敏捷的“个体和交互比过程和工具更有价值”，要强调测试用例设计者之间的思想碰撞，通过讨论、协作来完成测试用例的设计，原因很简单，测试用例的目的是尽可能全面地覆盖需求，而测试人员总会存在某方面的思维缺陷，一个人的思维总是存在局限性。因此需要一起设计测试用例。
　　除了同行评审，还应该尽量引入用户参与到测试用例的设计中来，让他们参与评审，从而体现敏捷的“顾客的协作比合同谈判更有价值”这一原则。这里顾客的含义比较广泛，关键在于你怎样定义测试，如果测试是对产品的批判，则顾客应该指最终用户或顾客代表（在内部可以是市场人员或领域专家）；如果测试是指对开发提供帮助和支持，那么顾客显然就是程序员了。
　　因此，参与到测试用例设计和评审中来的人除了测试人员自己和管理层外，还应该包括最终用户或顾客代表，还有开发人员。

4。测试用例数据生成的自动化
　　在测试用例设计方面最有希望实现自动化的，要当属测试用例数据生成的自动化了。因为设计方面的自动化在可想象的将来估计都很难实现，但是数据则不同，数据的组合、数据的过滤筛选、大批量数据的生成等都是计算机擅长的工作。
　　很多时候，测试用例的输入参数有不同的类型、有不同的取值范围，我们需要得到测试用例的输入参数的不同组合，以便全面地覆盖各种可能的取值情况。但是全覆盖的值域可能会不可思议地广泛，我们又需要科学地筛选出一些有代表性的数据，以便减轻测试的工作量。在这方面可利用正交表设计数据或成对组合法设计数据。
　　可利用一些工具，例如TConfig、PICT等来产生这些数据。
　　在性能测试、容量测试方面，除了设计好测试用例考虑如何测试外，还要准备好大量的数据。大量数据的准备可以使用多种方式：编程生成、SQL语句生成（基于数据库的数据）、利用工具生成。
　　工具未必能生成所有满足要求的数据，但是却是最快速的，编程能生成所有需要的数据，但是可能是最复杂、最慢的方式。所以应该尽量考虑使用一些简单实用的工具，例如DataFactory等。

查看(982) 评论(0) 收藏分享管理
功能测试用例设计积累（五）：等价类划分法分析与实践

okokokk 发布于 2009-01-08 19:53:58

1。方法定义：
从软件测试的角度来说，等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭示程序中的错误都是等效的。等价类划分包含两个部分：有效等价类和无效等价类。
1) 有效等价类
是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。主要为了检验程序是否实现了规格说明中所规定的功能和性能。
2) 无效等价类
与有效等价类相反，主要为了程序的健壮性与可靠性。

2。方法运用到用例设计中的思路：
1) 根据需求说明书，把需要输入的数据划分成若干个子集合。在这里要确保两点：
A。每个子集中的数据在测试过程中对于发现程序缺陷是有效的。
B。每个子集中的数据在测试过程中对于发现程序缺陷是等效的。
C。子集之间数据互不相交。
2) 然后从每个集合中选择部分代表性数据形成测试用例中的输入数据。
3) 覆盖所有有效的和无效的等价类

3。确定等价类的原则
1) 在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类。
例如：成年人每分钟的心跳60-100之间为正常。
有效等价类：60-100 无效等价类：<60 和 >100
2) 在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可确立一个有效等价类和一个无效等价类。
例如：用户连续输入错误密码的次数最多为3次。
有效等价类：<=3次无效等价类：>3次
3) 在输入条件是一个布尔量的情况下，可确定一个有效等价类。
例如：单选的选中与不选中。
4) 在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。
例如：输入数据为省份的选择。
5) 在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。
例如：规定必须输入非0的正整数。
这种例子应充分考虑规则是否可以拆分为具有单一的子规则，然后得到从不同角度违反规则的无效等价类。
该例子起码可拆分为非0、数字、正数、整数4个子规则，至少每个规则对应一个无效等价类，即0、字符串、负数、小数，甚至可挖掘出输入为空的隐含等价类。
6) 在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步的划分为更小的等价类。
例如：核对日期的有效性，初步有效等价类是1<=Month<=12，1<=Day<=31
可是考虑到2月以及闰年、闰月、长月、短月等，需要进一步细分，当然其中还涉及到了年月日组合的问题。

4。测试用例举例
竞猜系统中：投注的金额要求是大于10的正整数。
根据分析等到以下等价类表。

输入条件有效等价类无效等价类

>10的正整数大于10的正整数空
小数
<10的数
负数
字符串

5。优缺点
优点：避免了盲目或随机选取输入数据的布完整性和覆盖的不稳定性
缺点：没有对组合情况进行充分的考虑，需要结合其他测试用例设计的方法进行补充

查看(1118) 评论(0) 收藏分享管理
功能测试用例设计积累（四）：在没有需求文档的情况下如何设计测试用例

okokokk 发布于 2009-01-08 19:49:04

“测试用例应该依照需求文档来开发，但是我们的项目根本就没有需求文档？那测试用例该如何开发呢？”

1.根据客户的功能点整理测试需求追朔表：

一般的客户都要把要开发软件的功能点写成一个表格交给市场部，让市场部门转交研发部。所以客户的功能点是编写测试用例一个最最重要的依据。

2.根据开发人员的Software Specification List整理我们的功能测试点：

一般来说，开发人员实现一个功能都要把该功能分成几个子模块来实现，所以Software Specification List也是我们参考的另一个比较重要的依据。

3.开展项目跨部门讨论会：

可以抽出时间，叫市场部的项目负责人、产品经理、项目经理、软件开发经理和软件开发人员，分别讲讲他们对整个产品的认识和设计模式，对每个功能点的理解和认识，理顺思路，达成共识，测试人员负责记录，测试Leader负责整理汇总，形成测试的部分参考文档。

4.测试人员整理用例需求疑问递交项目组和客户代表回复：

测试人员根据项目讨论会后的理解，测试过程中可能碰到的问题（如：边界值、输入数据类型等等）和需求不明确的问题，整理用例需求疑问，让相关的模块负责人在“用例需求疑问”表格中回复，并给出详细解释和说明。

5.项目内部用例评审：

测试人员根据对项目的理解，编写测试用例要点，测试组内部评审修改后，可以召集项目组的成员，帮助Review一下，然后进行修改。经过多次修改和评审以后，测试用例要点可能会更加全面一些。

6.邮件和客户代表确认部分争议问题：

测试人员与开发人员、项目组成员，在需求问题上讨论有时候观点不一致，各说各有理，这种情况下最好把争议问题写成邮件，发给客户让客户来拍板，确定那种需求合理，到底如何做？抄送项目组的全体成员，方便大家都了解客户的意见。最后编写测试用例的时候，以客户的邮件内容为准。

7.项目Demo和部分已开发系统：

大部分的系统，由于没有需求，为了避免项目风险，开发方一般都要做成Demo，不断让客户确认后签字，不断展现新开发的功能，以达到吸引客户的目的。如果项目中有Demo，Demo也是参考标准。如果什么都没有，那已经开发的部分功能模块，要去随时让用户了解了解，并提出部分修改意见，也可以为我们熟悉系统提供部分依据。

8.参考同行业和竞争对手的类似产品：

假如说是做一个网上书店类似的网站，我们编写测试用例的时候，可以看看“当当网”，“China—pub”等等类似成熟相关的网站。很容易发现本公司产品的问题，无意识给产品添加了竞争力。对于竞争对手的了解一定不能够少。

9.交叉模块的测试，最容易被人忽略：

一般的产品，功能部分的交叉，即是说在A模块中设置了参数，在B模块和C模块中体现该参数的实际运用。比较难的如我们现在测试的“银行系统”中的交叉模块，还可能牵涉到不同的用户，3个以上的模块之间的调用。即是有了需求也很少写，同时也是需求编写的一个薄弱环节。这样的测试用例编写问题，一般初级测试工程师很难考虑全。对于有这种交叉功能的模块，必须要求项目组中的精兵强将，画出相关的调用关系图，表明调用关系，方便后面编写测试用例。

10.可以使用电话、MSN、Skype等网络聊天工具咨询部分需求：

我们做的产品，大多数的客户都在国外，测试经理也可以用这些网络聊天工具和客户确认部分需求疑问。不过要要事先越好时间，并注意异地的“时差”。

查看(868) 评论(0) 收藏分享管理
功能测试用例设计积累（三）：正交表分析与实践

okokokk 发布于 2009-01-08 19:44:56

这个blog上传附件确实不容易，我就直接留个链接了 ^o^

http://www.7dtest.com/bbs/viewthread.php?tid=440&extra=page%3D1

查看(505) 评论(0) 收藏分享管理
功能测试用例设计积累（二）：错误推测法分析与实践

okokokk 发布于 2009-01-08 19:42:59

一。错误推测法

1。方法定义：
基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法。

2。思路：
分析程序中最易出错的场景和情况，在此基础上有针对性的设计测试用例。需要完成的前提条件如下：
A。深度熟悉被测系统的业务、需求。
B。对被测系统或类似系统之前的缺陷分布情况进行过系统的分析。包括功能缺陷，数据缺陷，接口缺陷和界面缺陷等等。

3。测试用例举例
（一）：聊天窗口功能
A。输入特殊字符（全角，半角）后，窗口是否能够正常显示
B。输入空格，是否能够过滤，是否会算入长度计算
C。输入html字符
D。输入脚本语言函数
E。在需要密码验证，或者需要二次输入确认的地方，通过复制粘贴第一次的输入内容是否能够通过

（二）：查询功能
A。无条件查询
B。是否支持模糊查询
C。查询的关键字之间是否可用连接符
D。输入正确的查询条件以前加上空格，看是否能正确地查出相应的数据

（三）：登录功能
A。输入的数据前存在空格，是否能够正常登录
B。输入的密码是否能够加密显示
C。用户在注销之后是否能够再登录成功

4。优缺点
优点：充分发挥个人的经验和潜能，命中率高
缺点：覆盖率难以保证；过多的依赖于个人的经验

查看(844) 评论(0) 收藏分享管理
功能测试用例设计积累（一）：软件界面

okokokk 发布于 2009-01-08 19:41:55

界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。目前界面的设计引起软件设计人员的重视的程度还远远不够，直到最近网页制作的兴起，才受到专家的青睐。而且设计良好的界面由于需要具有艺术美的天赋而遭拒绝。
目前流行的界面风格有三种方式：多窗体、单窗体以及资源管理器风格，无论那种风格，以下规则是应该被重视的。

      1：易用性
按钮名称应该易懂，用词准确，屏弃没楞两可的字眼，要与同一界面上的其他按钮易于区分，能望文知意最好。理想的情况是用户不用查阅帮助就能知道该界面的功能并进行相关的正确操作。

易用性细则：
1):完成相同或相近功能的按钮用Frame框起来，常用按钮要支持快捷方式。
2):完成同一功能或任务的元素放在集中位置，减少鼠标移动的距离。
3):按功能将界面划分局域块，用Frame框括起来,并要有功能说明或标题。
4):界面要支持键盘自动浏览按钮功能，即按Tab键的自动切换功能。
5):界面上首先应输入的和重要信息的控件在Tab顺序中应当靠前,位置也应放在窗口上较醒目的位置。
6):同一界面上的控件数最好不要超过10个，多于10个时可以考虑使用分页界面显示。
7):分页界面要支持在页面间的快捷切换，常用组合快捷键Ctrl+Tab
8):默认按钮要支持Enter及选操作，即按Enter后自动执行默认按钮对应操作。
9):可写控件检测到非法输入后应给出说明并能自动获得焦点。
10):Tab键的顺序与控件排列顺序要一直，目前流行总体从上到下，同时行间从左到右的方式。
11):复选框和选项框按选择几率的高底而先后排列。
12):复选框和选项框要有默认选项，并支持Tab选择。
13):选项数相同时多用选项框而不用下拉列表框。
14):界面空间较小时使用下拉框而不用选项框。
15):选项数叫少时使用选项框，相反使用下拉列表框。
16):专业性强的软件要使用相关的专业术语，通用性界面则提倡使用通用性词眼。

      2：规范性
通常界面设计都按Windows界面的规范来设计，即包含“菜单条、工具栏、工具厢、状态栏、滚动条、右键快捷菜单”的标准格式，可以说：界面遵循规范化的程度越高，则易用性相应的就越好。小型软件一般不提供工具厢。

规范性细则：
1):常用菜单要有命令快捷方式。
2):完成相同或相近功能的菜单用横线隔开放在同一位置。
3):菜单前的图标能直观的代表要完成的操作。
4):菜单深度一般要求最多控制在三层以内。
5):工具栏要求可以根据用户的要求自己选择定制。
6):相同或相近功能的工具栏放在一起。
7):工具栏中的每一个按钮要有及时提示信息。
8):一条工具栏的长度最长不能超出屏幕宽度。
9): 工具栏的图标能直观的代表要完成的操作。
10):系统常用的工具栏设置默认放置位置。
11):工具栏太多时可以考虑使用工具厢。
12):工具厢要具有可增减性，由用户自己根据需求定制。
13):工具厢的默认总宽度不要超过屏幕宽度的1/5。
14): 状态条要能显示用户切实需要的信息，常用的有：
目前的操作、系统状态、用户位置、用户信息、提示信息、错误信息等，如果某一操作需要的时间较长，还应该显示进度条和进程提示。
15):滚动条的长度要根据显示信息的长度或宽度能及时变换，以利于用户了解显示信息的位置和百分比。
16):状态条的高度以放置五好字为宜，滚动条的宽度比状态条的略窄。
17):菜单和工具条要有清楚的界限;菜单要求凸出显示，这样在移走工具条时仍有立体感。
18):菜单和状态条中通常使用5号字体。工具条一般比菜单要宽，但不要宽的太多，否则看起来很不协调。
19):右键快捷菜单采用与菜单相同的准则。

      3：帮助设施
系统应该提供详尽而可靠的帮助文档，在用户使用产生迷惑时可以自己寻求解决方法。

帮助设施细则：
1):帮助文档中的性能介绍与说明要与系统性能配套一致。(我们的系统帮助文档都是系统的祖先时期的说明，让人困惑)。
2):打包新系统时，对作了修改的地方在帮助文档中要做相应的修改。
3):操作时要提供及时调用系统帮助的功能。常用F1。
4):在界面上调用帮助时应该能够及时定位到与该操作相对的帮助位置。也就是说帮助要有即时针对性。
5):最好提供目前流行的联机帮助格式或HTML帮助格式。
6):用户可以用关键词在帮助索引中搜索所要的帮助，当然也应该提供帮助主题词。
7):如果没有提供书面的帮助文档的话，最好有打印帮助的功能。
8 ):在帮助中应该提供我们的技术支持方式，一旦用户难以自己解决可以方便的寻求新的帮助方式。
      4：合理性
屏幕对角线相交的位置是用户直视的地方，正上方四分之一处为易吸引用户注意力的位置，在放置窗体时要注意利用这两个位置。

合理性细则：
1):父窗体或主窗体的中心位置应该在对角线焦点附近。
2):子窗体位置应该在主窗体的左上角或正中。
3):多个子窗体弹出时应该依次向右下方偏移，以显示窗体出标题为宜。
4):重要的命令按钮与使用较频繁的按钮要放在界面上注目的位置。
5):错误使用容易引起界面退出或关闭的按钮不应该放在易点位置。横排开头或最后与竖排最后为易点位置。
6):与正在进行的操作无关的按钮应该加以屏蔽(Windows中用灰色显示，没法使用该按钮)。
7):对可能造成数据无法恢复的操作必须提供确认信息,给用户放弃选择的机会。
8):非法的输入或操作应有足够的提示说明。
9): 对运行过程中出现问题而引起错误的地方要有提示，让用户明白错误出处，避免形成无限期的等待。
10):提示、警告、或错误说明应该清楚、明了、恰当。

      5：美观与协调性
界面应该大小适合美学观点，感觉协调舒适，能在有效的范围内吸引用户的注意力。

美观与协调性细则：
1): 长宽接近黄金点比例，切忌长宽比例失调、或宽度超过长度。
2): 布局要合理,不宜过于密集，也不能过于空旷，合理的利用空间。
3): 按钮大小基本相近，忌用太长的名称，免得占用过多的界面位置。
4): 按钮的大小要与界面的大小和空间要协调。
5): 避免空旷的界面上放置很大的按钮。
6):放置完控件后界面不应有很大的空缺位置。
7): 字体的大小要与界面的大小比例协调, 通常使用的字体中宋体9-12较为美观，很少使用超过12号的字体。
8): 前景与背景色搭配合理协调，反差不宜太大，最好少用深色，如大红、大绿等。常用色考虑使用Windows界面色调。
9): 如果使用其他颜色，主色要柔和，具有亲和力与磁力，坚决杜绝刺目的颜色。
10): 大型系统常用的主色有"#E1E1E1"、"#EFEFEF"、"#C0C0C0"等。
11): 界面风格要保持一致，字的大小、颜色、字体要相同，除非是需要艺术处理或有特殊要求的地方。
12): 如果窗体支持最小化和最大化或放大时，窗体上的控件也要随着窗体而缩放；切忌只放大窗体而忽略控件的缩放。
13):对于含有按钮的界面一般不应该支持缩放，即右上角只有关闭功能。
14): 通常父窗体支持缩放时，子窗体没有必要缩放。
15):如果能给用户提供自定义界面风格则更好，由用户自己选择颜色、字体等。

      6：菜单位置
菜单是界面上最重要的元素，菜单位置按照按功能来组织。

菜单设测试细则：
1):菜单通常采用“常用--主要--次要--工具--帮助”的位置排列，符合流行的Windows风格。
2):常用的有“文件”、“编辑”，“查看”等，几乎每个系统都有这些选项，当然要根据不同的系统有所取舍。
3):下拉菜单要根据菜单选项的含义进行分组，并切按照一定的规则进行排列，用横线隔开。
4): 一组菜单的使用有先后要求或有向导作用时，应该按先后次序排列。
5): 没有顺序要求的菜单项按使用频率和重要性排列，常用的放在开头，不常用的靠后放置；重要的放在开头，次要的放在后边。
6): 如果菜单选项较多，应该采用加长菜单的长度而减少深度的原则排列。
7): 菜单深度一般要求最多控制在三层以内。
8): 对常用的菜单要有快捷命令方式，组合原则见8。
9):对与进行的操作无关的菜单要用屏蔽的方式加以处理，如果采用动态加载方式——即只有需要的菜单才显示——最好。
10):菜单前的图标不宜太大，与字高保持一直最好。
11):主菜单的宽度要接近，字数不应多于四个，每个菜单的字数能相同最好。
12)：主菜单数目不应太多，最好为单排布置。

   7：独特性
如果一味的遵循业界的界面标准，则会丧失自己的个性.在框架符合以上规范的情况下，设计具有自己独特风格的界面尤为重要。尤其在商业软件流通中有着很好的迁移默化的广告效用。

独特性细则：
1):安装界面上应有单位介绍或产品介绍，并有自己的图标。
2):主界面，最好是大多数界面上要有公司图标。
3):登录界面上要有本产品的标志，同时包含公司图标。
4):帮助菜单的“关于”中应有版权和产品信息。
5):公司的系列产品要保持一直的界面风格，如背景色、字体、菜单排列方式、图标、安装过程、按钮用语等应该大体一致。

      8：快捷方式的组合
在菜单及按钮中使用快捷键可以让喜欢使用键盘的用户操作得更快一些在西文Windows及其应用软件中快捷键的使用大多是一致的。

细则：
1):面向事务的组合有:
Ctrl-D 删除；Ctrl-F 寻找；Ctrl –H替换；Ctrl-I 插入；Ctrl-N 新记录；Ctrl-S 保存 Ctrl-O 打开。
2):列表:
Ctrl-R ，Ctrl-G定位；Ctrl-Tab下一分页窗口或反序浏览同一页面控件；。
3):编辑:
Ctrl-A全选；Ctrl-C 拷贝；Ctrl-V 粘贴；Ctrl-X 剪切；Ctrl-Z撤消操作；Ctrl-Y恢复操作。
4):文件操作:
Ctrl-P 打印；Ctrl-W 关闭。
5):系统菜单
Alt-A文件；Alt-E编辑；Alt-T工具；Alt－W窗口；Alt－H帮助。
6):MS Windows保留键:
Ctrl-Esc 任务列表；Ctrl-F4 关闭窗口； Alt-F4 结束应用；Alt-Tab 下一应用；Enter 缺省按钮/确认操作；Esc 取消按钮/取消操作；Shift-F1 上下文相关帮助。
按钮中：
可以根据系统需要而调节，以下只是常用的组合。
Alt-Y确定(是)；Alt-C取消；Alt-N 否；Alt-D删除；Alt-Q退出；Alt-A添加；Alt-E编辑；Alt-B浏览；Alt-R读；Alt-W写。
这些快捷键也可以作为开发中文应用软件的标准,但亦可使用汉语拼音的开头字母。

      9：安全性考虑
在界面上通过下列方式来控制出错几率，会大大减少系统因用户人为的错误引起的破坏。开发者应当尽量周全地考虑到各种可能发生的问题,使出错的可能降至最小。如应用出现保护性错误而退出系统,这种错误最容易使用户对软件失去信心。因为这意味着用户要中断思路,并费时费力地重新登录,而且已进行的操作也会因没有存盘而全部丢失。

安全性细则：
1):最重要的是排除可能会使应用非正常中止的错误。
2):应当注意尽可能避免用户无意录入无效的数据。
3):采用相关控件限制用户输入值的种类。
4):当用户作出选择的可能性只有两个时,可以采用单选框。
5):当选择的可能再多一些时,可以采用复选框,每一种选择都是有效的,用户不可能输入任何一种无效的选择。
6):当选项特别多时，可以采用列表框，下拉式列表框。
7):在一个应用系统中,开发者应当避免用户作出未经授权或没有意义的操作。
8):对可能引起致命错误或系统出错的输入字符或动作要加限制或屏蔽。
9):对可能发生严重后果的操作要有补救措施。通过补救措施用户可以回到原来的正确状态。
10):对一些特殊符号的输入、与系统使用的符号相冲突的字符等进行判断并阻止用户输入该字符。
11):对错误操作最好支持可逆性处理，如取消系列操作。
12):在输入有效性字符之前应该阻止用户进行只有输入之后才可进行的操作。
13):对可能造成等待时间较长的操作应该提供取消功能。
14):特殊字符常有；;’”><,｀‘：“［”｛、\|｝］+=)-(_*&&^%$#@!~,.。?/还有空格。
15):与系统采用的保留字符冲突的要加以限制。
16):在读入用户所输入的信息时，根据需要选择是否去掉前后空格。
17):有些读入数据库的字段不支持中间有空格，但用户切实需要输入中间空格，这时要在程序中加以处理。

      10：多窗口的应用与系统资源
设计良好的软件不仅要有完备的功能，而且要尽可能的占用最底限度的资源。

细则：
1):在多窗口系统中，有些界面要求必须保持在最顶层，避免用户在打开多个窗口时，不停的切换甚至最小化其他窗口来显示该窗口。
2):在主界面载入完毕后自动卸出内存，让出所占用的WINDOWS系统资源。
3):关闭所有窗体，系统退出后要释放所占的所有系统资源，除非是需要后台运行的系统。
4):尽量防止对系统的独占使用。

查看(406) 评论(0) 收藏分享管理
[用例设计]测试用例设计的误区

卧龙公子发布于 2008-11-19 20:05:17

测试用例设计的误区

1、能发现到目前为止没有发现的缺陷的用例是好的用例：
首先要申明，其实这句话是十分有道理的，但我发现很多人都曲解了这句话的原意，一心要设计出发现“难于发现的缺陷”而陷入盲目的片面中去，忘记了测试的目的所在，这是十分可怕的。我倾向于将测试用例当作一个集合来认识，对它的评价也只能对测试用例的集合来进行，测试本身是一种“V&V”的活动，测试需要保证以下两点：

    * 程序做了它应该做的事情
    * 程序没有做它不该做的事情

因此，作为测试实施依据的测试用例，必须要能完整覆盖测试需求，而不应该针对单个的测试用例去评判好坏。

2、测试用例应该详细记录所有的操作信息，使一个没有接触过系统的人员也能进行测试；
      不知道国内有没有公司真正做到这点，或者说，不知道有国内没有公司能够将每个测试用例都写得如此详细。在我的测试经历中，对测试用例描述的详细和复杂程度也曾有过很多的彷徨。写得太简单吧，除了自己没人能够执行，写得太详细吧，消耗在测试用例维护（别忘了，测试用例是动态的，一旦测试环境、需求、设计、实现发生了变化，测试用例都需要相应发生变化）上的时间实在是太惊人，在目前国内大部分软件公司的测试资源都不足的情况下，恐怕很难实现。但我偏偏就能遇到一些这样的老总或者是项目负责人，甚至是测试工程师本身，全然不顾实际的资源情况，一定要写出“没有接触过系统的人员也能进行测试”的用例。
      在讨论这个问题之前，我们可以先考虑一下测试的目的。测试的目的是尽可能发现程序中存在的缺陷，测试活动本身也可以被看作是一个Project，也需要在给定的资源条件下尽可能达成目标，根据我个人的经验，大部分的国内软件公司在测试方面配备的资源都是不足够的，因此我们必须在测试计划阶段明确测试的目标，一切围绕测试的目标进行。
      除了资源上的约束外，测试用例的详细程度也需要根据需要确定。如果测试用例的执行者、测试用例设计者、测试活动相关人对系统了解都很深刻，那测试用例就没有必要太详细了，文档的作用本来就在于沟通，只要能达到沟通的目的就OK。
      在我担任测试经理的项目中，在测试计划阶段，一般给予测试设计30% - 40%左右的时间，测试设计工程师能够根据项目的需要自行确定用例的详细程度，在测试用例的评审阶段由参与评审的相关人对其把关。

3、测试用例设计是一劳永逸的事情；
      这句话摆在这里，我想没有一个人会认可，但在实际情况中，却经常能发现这种想法的影子。我曾经参与过一个项目，软件需求和设计已经变更了多次，但测试用例却没有任何修改。导致的直接结果是新加入的测试工程师在执行测试用例时不知所措，间接的后果是测试用例成了废纸一堆，开发人员在多次被无效的缺陷报告打扰后，对测试人员不屑一顾。
      这个例子可能有些极端，但测试用例与需求和设计不同步的情况在实际开发过程中确是屡见不鲜的，测试用例文档是“活的”文档，这一点应该被测试工程师牢记。

4、测试用例不应该包含实际的数据；
      测试用例是“一组输入、执行条件、预期结果”、毫无疑问地应该包括清晰的输入数据和预期输出，没有测试数据的用例最多只具有指导性的意义，不具有可执行性。当然，测试用例中包含输入数据会带来维护、与测试环境同步之类的问题，关于这一点，《Effective Software Test》一书中提供了详细的测试用例、测试数据的维护方法，可以参考。

5、测试用例中不需要明显的验证手段；
      我见过很多测试工程师编写的测试用例中，“预期输出”仅描述为程序的可见行为，其实，“预期结果”的含义并不只是程序的可见行为。例如，对一个订货系统，输入订货数据，点击“确定”按钮后，系统提示“订货成功”，这样是不是一个完整的用例呢？是不是系统输出的“订货成功”就应该作为我们唯一的验证手段呢？显然不是。订货是否成功还需要查看相应的数据记录是否更新，因此，在这样的一个用例中，还应该包含对测试结果的显式的验证手段：在数据库中执行查询语句进行查询，看查询结果是否与预期的一致。

查看(647) 评论(1) 收藏分享管理
[用例设计]如何设计编制软件测试用例

卧龙公子发布于 2008-11-24 16:38:44

　　一、测试用例是软件测试的核心
　　二、什么叫测试用例
　　三、编制测试用例
　　四、测试用例在软件测试中的作用
　　五、相关问题
　　随着中国软件业的日益壮大和逐步走向成熟，软件测试也在不断发展。从最初的由软件编程人员兼职测试到软件公司组建独立专职测试部门。测试工作也从简单测试演变为包括：编制测试计划、编写测试用例、准备测试数据、编写测试脚本、实施测试、测试评估等多项内容的正规测试。测试方式则由单纯手工测试发展为手工、自动兼之，并有向第三方专业测试公司发展的趋势。

　　一、测试用例是软件测试的核心　　
　　软件测试的重要性是毋庸置疑的。但如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件公司探索和追求的目标。每个软件产品或软件开发项目都需要有一套优秀的测试方案和测试方法。　
　　影响软件测试的因素很多，例如软件本身的复杂程度、开发人员(包括分析、设计、编程和测试的人员)的素质、测试方法和技术的运用等等。因为有些因素是客观存在的，无法避免。有些因素则是波动的、不稳定的，例如开发队伍是流动的，有经验的走了，新人不断补充进来；一个具体的人工作也受情绪等影响，等等。如何保障软件测试质量的稳定？有了测试用例，无论是谁来测试，参照测试用例实施，都能保障测试的质量。可以把人为因素的影响减少到最小。即便最初的测试用例考虑不周全，随着测试的进行和软件版本更新，也将日趋完善。　
　　因此测试用例的设计和编制是软件测试活动中最重要的。测试用例是测试工作的指导，是软件测试的必须遵守的准则。更是软件测试质量稳定的根本保障。

　二、什么叫测试用例
　　测试用例(Test Case)目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。

[Kiki] 目前有以下一些解释：
"A set of test inputs, execution conditions, and expected results developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement." － IEEE Standard 610 (1990)

"Test cases are ways of stating how we will verify what the system actually does, and therefore they should be tracked and maintained as requirements. We introduce the notion of requirements type to separate these different expressions of requirements." - RUP
　
　　不同类别的软件，测试用例是不同的。不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不统一，变化更大、更快。笔者主要从事企业管理软件的测试。因此我们的做法是把测试数据和测试脚本从测试用例中划分出来。测试用例更趋于是针对软件产品的功能、业务规则和业务处理所设计的测试方案。对软件的每个特定功能或运行操作路径的测试构成了一个个测试用例。

　三、编制测试用例
　　着重介绍一些编制测试用例的具体做法。
　
　　1、测试用例文档　
　　编写测试用例文档应有文档模板，须符合内部的规范要求。测试用例文档将受制于测试用例管理软件的约束。　
　　软件产品或软件开发项目的测试用例一般以该产品的软件模块或子系统为单位，形成一个测试用例文档，但并不是绝对的。　
　　测试用例文档由简介和测试用例两部分组成。简介部分编制了测试目的、测试范围、定义术语、参考文档、概述等。测试用例部分逐一列示各测试用例。每个具体测试用例都将包括下列详细信息：用例编号、用例名称、测试等级、入口准则、验证步骤、期望结果(含判断标准)、出口准则、注释等。以上内容涵盖了测试用例的基本元素：测试索引，测试环境，测试输入，测试操作，预期结果，评价标准。

[Kiki] 对测试用例划分等级有很多感触：许多时候当开发部门应客户需要或发现严重bug而快速发布一个新版本时，要求在限定的时间内快速测试以确保系统基本功能正常时，有些测试人员不知如何从现有的测试用例中挑选测试用例，更有甚者还是按顺序测试。所以一定需要划分级别，方便BVT或上述的测试。具体参加：《快速划分测试用例的优先级》

　2、测试用例的设置
　　我们早期的测试用例是按功能设置用例。后来引进了路径分析法，按路径设置用例。目前演变为按功能、路径混合模式设置用例。　
　　按功能测试是最简捷的，按用例规约遍历测试每一功能。　
　　对于复杂操作的程序模块，其各功能的实施是相互影响、紧密相关、环环相扣的，可以演变出数量繁多的变化。没有严密的逻辑分析，产生遗漏是在所难免。路径分析是一个很好的方法，其最大的优点是在于可以避免漏测试。
　　但路径分析法也有局限性。在一个非常简单字典维护模块就存在十余条路径。一个复杂的模块会有几十到上百条路径是不足为奇的。笔者以为这是路径分析比较合适的使用规模。若一个子系统有十余个或更多的模块，这些模块相互有关联。再采用路径分析法，其路径数量成几何级增长，达5位数或更多，就无法使用了。那么子系统模块间的测试路径或测试用例还是要靠传统方法来解决。这是按功能、路径混合模式设置用例的由来。

3、设计测试用例
　　测试用例可以分为基本事件、备选事件和异常事件。设计基本事件的用例，应该参照用例规约(或设计规格说明书)，根据关联的功能、操作按路径分析法设计测试用例。而对孤立的功能则直接按功能设计测试用例。基本事件的测试用例应包含所有需要实现的需求功能，覆盖率达100%。　
　　设计备选事件和异常事件的用例，则要复杂和困难得多。例如，字典的代码是唯一的，不允许重复。测试需要验证：字典新增程序中已存在有关字典代码的约束，若出现代码重复必须报错，并且报错文字正确。往往在设计编码阶段形成的文档对备选事件和异常事件分析描述不够详尽。而测试本身则要求验证全部非基本事件，并同时尽量发现其中的软件缺陷。　
　　可以采用软件测试常用的基本方法：等价类划分法、边界值分析法、错误推测法、因果图法、逻辑覆盖法等设计测试用例。视软件的不同性质采用不同的方法。如何灵活运用各种基本方法来设计完整的测试用例，并最终实现暴露隐藏的缺陷，全凭测试设计人员的丰富经验和精心设计。

　四、测试用例在软件测试中的作用

　1、指导测试的实施
　　测试用例主要适用于集成测试、系统测试和回归测试。在实施测试时测试用例作为测试的标准，测试人员一定要按照测试用例严格按用例项目和测试步骤逐一实施测试。并对测试情况记录在测试用例管理软件中，以便自动生成测试结果文档。　
　　根据测试用例的测试等级，集成测试应测试那些用例，系统测试和回归测试又该测试那些用例，在设计测试用例时都已作明确规定，实施测试时测试人员不能随意作变动。

　2、规划测试数据的准备
　　在我们的实践中测试数据是与测试用例分离的。按照测试用例配套准备一组或若干组测试原始数据，以及标准测试结果。尤其象测试报表之类数据集的正确性，按照测试用例规划准备测试数据是十分必须的。
　　除正常数据之外，还必须根据测试用例设计大量边缘数据和错误数据。

　3、编写测试脚本的"设计规格说明书"
　　为提高测试效率，软件测试已大力发展自动测试。自动测试的中心任务是编写测试脚本。如果说软件工程中软件编程必须有设计规格说明书，那么测试脚本的设计规格说明书就是测试用例。

　4、评估测试结果的度量基准
　　完成测试实施后需要对测试结果进行评估，并且编制测试报告。判断软件测试是否完成、衡量测试质量需要一些量化的结果。例：测试覆盖率是多少、测试合格率是多少、重要测试合格率是多少，等等。以前统计基准是软件模块或功能点，显得过于粗糙。采用测试用例作度量基准更加准确、有效。

　5、分析缺陷的标准
　　通过收集缺陷，对比测试用例和缺陷数据库，分析确证是漏测还是缺陷复现。漏测反映了测试用例的不完善，应立即补充相应测试用例，最终达到逐步完善软件质量。而已有相应测试用例，则反映实施测试或变更处理存在问题。

　五、相关问题

　1、测试用例的评审
　　测试用例是软件测试的准则，但它并不是一经编制完成就成为准则。测试用例在设计编制过程中要组织同级互查。完成编制后应组织专家评审，需获得通过才可以使用。评审委员会可由项目负责人、测试、编程、分析设计等有关人员组成，也可邀请客户代表参加。

　2、测试用例的修改更新
　　测试用例在形成文档后也还需要不断完善。主要来自三方面的缘故：第一、在测试过程中发现设计测试用例时考虑不周，需要完善；第二、在软件交付使用后反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成；第三、软件自身的新增功能以及软件版本的更新，测试用例也必须配套修改更新。
　　一般小的修改完善可在原测试用例文档上修改，但文档要有更改记录。软件的版本升级更新，测试用例一般也应随之编制升级更新版本。

　3、测试用例的管理软件
　　运用测试用例还需配备测试用例管理软件。它的主要功能有三个：第一、能将测试用例文档的关键内容，如编号、名称等等自动导入管理数据库，形成与测试用例文档完全对应的记录；第二、可供测试实施时及时输入测试情况；第三、最终实现自动生成测试结果文档，包含各测试度量值，测试覆盖表和测试通过或不通过的测试用例清单列表。
　　有了管理软件，测试人员无论是编写每日的测试工作日志、还是出软件测试报告，都会变得轻而易举。

开发一个软件产品，会发布多个版本，伴随着测试用例（Test case）的不断维护, 使测试用例不断完善并与产品功能、特性(features)的变化保持一致，所以测试用例是和产品版本相关联的。特别是对提供软件服务的软件产品，多个版本常常共存，为客户提供服务，这时多个版本的测试用例也是并存的，所以在新建、修改、删除测试用例时要十分小心，并有相应的规则。

根据产品特性和test case一致性，分下面几种情况分别处理：

1. 产品特性没变，只是根据Late Discovery Bug 或 Remedy Ticket 来完善 test case，只有这时候可以修改Test case, 也就意味着当前修改的test case，对目前和以前的版本都有效。

2. 原有产品特性发生了变化，不是new feature, 而是enhanced features（功能增强）, 这时候原有的 test case 只对先前版本（如version 1.0、2.0) 有效，而对新的版本（如 version 3.0)无效，这时绝不能修改 test case ，只能增加新的 test case，这一点很重要。原有的 test case 依然对原有版本有效（如version 1.0、2.0)。

3. 原有功能取消了，这时只要在新版本上使之对应的test case置为inactive（无效）。

4. 完全新增加的特性，大家比较清楚，增加对应的、新的测试用例。

这样，新旧版本的相同测试用例得到一致的维护，测试用例数也不会成几、十几倍的增加，可以真正保证 test case 的完整性、有效性！

查看(782) 评论(0) 收藏分享管理
测试计划的全面性和有效性

静澜发布于 2008-11-05 17:05:48
- 测试计划的要点
测试规划与软件开发活动同步时行，在需求分析时，就开始测试策划，确定测试需求、目标、资源等。测试计划可以按不同的测试阶段（集成测试、系统测试等）来组织，也可以为每个测试任务或目标（安全性、性能、可靠性等测试）进行考虑。
测试计划主要集中在测试目标、质量标准、测试策略、测试范围、测试用例设计方法、所需资源和日程安排等，其关键是制订有效的测试策略，清楚地界定测试范围，识别测试中所存在的各种风险并找出风险回避、监控和管理的方法，针对不同的测试目标或阶段确定测试方法，对测试工作量及所需的资源、时间进行合理的估算。所有这些都是为了两个根本目的：测试的质量和效率。
- 制订测试策略
制定测试策略主要分析测试的目标和质量指标、确定测试的对象和依据，测试的重点和所采用的方法，包括在规定的时间内哪些测试内容要完成，软件产品的特性或质量在哪些方面要得到确认。测试策略可以分为如下方面。
为了更好地制定好测试策略，要做到如下几点。
- 确定测试范围
测试主要根据产品设计规格说明书、代码所发生的变化及其影响的区域，来确定哪些功能和特性要测试、哪些功能和特性不需要测试。在确定测试范围时，要考虑的因素如下：
- 所需资源和日程安排
为了合理、准确地安排日程，对测试工作量要时行正确的估计。除了对工作量的估计之外，还要正确评估参与该项目人员的培训时间、适应过程和工作能力等。由于涉及不同的项目、不同的测试人员、不同的前期介入方式，要对每人每天能够完成的平均测试用例数目做出一个准确的估计确实困难，但是可以根据以前一些项目测试以经验或历史积累下来的数据进行判断推理，并适当地增加10%－20％的余量，估算结果就比较准确了。
在估算的基础上进行有效的、合理的资源安排。在不同的测试阶段人力资源的需求是不一样的，所以人力资源的计划要有一定的灵活性和动态性，要形成有机的动态平衡，保证测试的进度和资源的使用和效率。
- 编制测试计划的技巧
要做好测试计划，测试设计人员要仔细阅读有关资料，包括用户需求规格说明书、设计文档等，全面熟悉系统，并建议注意以下方面。
- 测试项目计划的评审
测试项目的计划不可能一气呵成，而是要经过计划初期、起草、讨论、审查等不同阶段，才能将测试计划制订好。测试计划的评审是完成测试计谋关键的一个环节，包括测试组织内部的自我评审、讨论和修改，然后交到评审会进行正式的评审，直至测试计划得到审批。
测试计划的正式评审，项目中的每个人（产品经理、项目经理、开发工程师等）都应当参与。计划的审查是必不可少的，每一个参与者都可能根据其经验及专长提出问题或建议，弥补在测试范围、工作量、风险等各方面的不足，从而进一步完善测试计划。
查看(939) 评论(0) 收藏分享管理

软件测试用例的设计

静澜发布于 2008-11-10 10:39:59

是否每个测试用例（或每组相关的测试用例）都确定了初始的测试目标状态和测试数据状态？

测试用例是否包含了所有单一的边界？

测试用例是否包含了所有的业务数据流？

是否所有的测试用例名称，ID都与测试工件命名约定一致？

测试用例评审时需要参加的人员：项目经理，系统分析员，测试设计员，测试员

3.2 用例库的更新维护

随着软件项目的开发，用例库的数据随着项目的进展动态变化也是需要维护的，主要包括：不合适用例的修改、冗余用例的删除、测试用例的增加，并对进行的操作在备注中署名修改者以及修改时间和改动原因。

4 测试用例实例

该测试案例是以一个B/S结构的登录功能点位被测对象, 该测试用例为黑盒测试用例。假设用户使用的浏览器为IE6.0 SP4。

功能描述如下：

1. 用户在地址栏输入相应地址，要求显示登录界面；

2. 输入用户名和密码，登录，系统自动校验，并给出相应提示信息；

3. 如果用户名或者密码任一信息未输入，登录后系统给出相应提示信息；

4. 连续3次未通过验证时，自动关闭IE。

表4-1 登录界面测试用例

用例ID		XXXX-XX-XX	用例名称		系统登录
用例描述		系统登录用户名存在、密码正确的情况下，进入系统页面信息包含：页面背景显示用户名和密码录入接口，输入数据后的登入系统接口
用例入口		打开IE，在地址栏输入相应地址进入该系统登录页面

测试用例ID	场景			测试步骤		预期结果	备注
TC1	初始页面显示			从用例入口处进入		页面元素完整，显示与详细设计一致
TC2	用户名录入－验证			输入已存在的用户：test		输入成功
TC3	用户名－容错性验证			输入：aaaaabbbbbcccccdddddeeeee		输入到蓝色显示的字符时，系统拒绝输入	输入数据超过规定长度范围
TC4	密码－密码录入			输入与用户名相关联的数据：test		输入成功
TC5	系统登录－成功			TC2，TC4，单击登录按钮		登录系统成功
TC6	系统登录－用户名、密码校验			没有输入用户名、密码，单击登录按钮		系统登录失败，并提示：请检查用户名和密码的输入是否正确
TC7	系统登录－密码校验			输入用户名，没有输入密码，单击登录按钮		系统登录失败，并提示：需要输入密码
TC8	系统登录－密码有效性校验			输入用户名，输入密码与用户名不一致，单击登录按钮		系统登录失败，并提示：错误的密码
TC9	系统登录－输入有效性校验			输入不存在的用户名、密码，单击登录按钮		系统登录失败，并提示：用户名不存在
TC10	系统登录—安全校验			连续3次未成功		系统提示：您没有使用该系统的权限，请与管理员联系！
…	…					…	…

查看(906) 评论(0) 收藏分享管理

测试用例设计白皮书－－测试用例基本概念（转）

yanfang84 发布于 2008-11-27 14:05:38

　　目录

　　1. 概述

　　2. 测试用例基本概念

　　2.1. 测试用例的定义

　　2.2. 测试用例的特征

　　2.3. 测试用例组成元素

　　2.4. 测试用例设计原则

　　3. 测试用例设计方法

　　3.1. 等价类划分方法

　　3.2. 边界值分析方法

　　3.3. 错误推测方法

　　3.4. 因果图方法

　　3.5. 判定表驱动分析方法

　　3.6. 正交实验设计方法

　　3.7. 功能图分析方法

　　3.8. 场景设计方发

　　4. 测试用例设计综合策略

　　1.概述

　　Grenford J. Myers在《The Art of Software Testing》一书中提出：一个好的测试用例是指很可能找到迄今为止尚未发现的错误的测试，由此可见测试用例设计工作在整个测试过程中的地位，我们不能只凭借一些主观或直观的想法来设计测试用例，应该要以一些比较成熟的测试用例设计方法为指导，再加上设计人员个人的经验积累来设计测试用例，二者相结合应该是非常完美的组合。本文所介绍的测试用例设计方法对于测试设计人员将是一个很好的方法指导，当然看完本文也未必能设计出好的测试用例，有了好的方法作为指导后需要更多的实践经验加以巩固和提炼。只有将测试设计思想与丰富的实践经验相融合才能设计出高质量的测试用例，相信你行！

　　本文描述的范围：测试用例基本概念、测试用例设计方法、测试用例设计综合策略。

　　关键词：测试用例、等价类划分、边界值分析、错误推测、因果图、判定表驱动分析、正交实验、功能图分析、场景设计

　　读者对象：测试设计人员、测试人员

　　参考文献：

　　1. 《计算机软件测试技术》郑人杰

　　2. 《The Art of Software Testing》 Grenford J. Myers

　　2.测试用例基本概念

　　2.1.测试用例的定义

　　测试用例是为特定的目的而设计的一组测试输入、执行条件和预期的结果。测试用例是执行的最小实体。简单地说，测试用例就是设计一个场景，使软件程序在这种场景下，必须能够正常运行并且达到程序所设计的执行结果。

　　2.2.测试用例的特征

　　1.最有可能抓住错误的；

　　2.不是重复的、多余的；

　　3.一组相似测试用例中最有效的；

　　4.既不是太简单，也不是太复杂。

　　2.3.测试用例组成元素

　　1.用例ID；

　　2.用例名称；

　　3.测试目的；

　　4.测试级别；

　　5.参考信息；

　　6.测试环境；

　　7.前提条件；

　　8.测试步骤；

　　9.预期结果；

　　10.设计人员。

　　2.4.测试用例设计原则

　　1.测试用例的代表性：能够代表并覆盖各种合理的和不合理的、合法的和非法的、边界的和越界的以及极限的输入数据、操作和环境设置等。

　　2.测试结果的可判定性：即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果。

　　3.测试结果的可再现性：即对同样的测试用例，系统的执行结果应当是相同的。

查看(455) 评论(0) 收藏分享管理

测试用例设计白皮书－－判定表驱动分析方法（转）

静澜发布于 2008-11-27 10:34:41

一.方法简介

1.定义：判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。

2.判定表的优点
能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。因此，利用判定表能够设计出完整的测试用例集合。
在一些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合，即：针对不同逻辑条件的组合值，分别执行不同的操作。判定表很适合于处理这类问题。

3.“阅读指南”判定表

		1	2	3	4	5	6	7	8
问题	觉得疲倦？	Y	Y	Y	Y	N	N	N	N
	感兴趣吗？	Y	Y	N	N	Y	Y	N	N
	糊涂吗？	Y	N	Y	N	Y	N	Y	N
建议	重读					√
	继续						√
	跳下一章							√	√
	休息	√	√	√	√

4.判定表通常由四个部分组成如下图所示。

        1)条件桩（Condition Stub）：列出了问题得所有条件。通常认为列出的条件的次序无关紧要。
        2)动作桩（Action Stub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。
        3)条件项（Condition Entry）：列出针对它左列条件的取值。在所有可能情况下的真假值。
        4)动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。

5.规则及规则合并
1)规则：任何一个条件组合的特定取值及其相应要执行的操作称为规则。在判定表中贯穿条件项和动作项的一列就是一条规则。显然,判定表中列出多少组条件取值,也就有多少条规则,既条件项和动作项有多少列。
2)化简：就是规则合并有两条或多条规则具有相同的动作，并且其条件项之间存在着极为相似的关系。

查看(527) 评论(0) 收藏分享管理

测试用例设计白皮书－－正交实验设计方法（转）

静澜发布于 2008-11-27 10:33:22

　一、方法简介
　　利用因果图来设计测试用例时，作为输入条件的原因与输出结果之间的因果关系，有时很难从软件需求规格说明中得到。往往因果关系非常庞大，以至于据此因果图而得到的测试用例数目多的惊人，给软件测试带来沉重的负担，为了有效地，合理地减少测试的工时与费用，可利用正交实验设计方法进行测试用例的设计。

　　正交实验设计方法:依据Galois理论，从大量的（实验）数据（测试例）中挑选适量的，有代表性的点（例），从而合理地安排实验（测试）的一种科学实验设计方法。类似的方法有:聚类分析方法，因子方法方法等。

　　利用正交实验设计测试用例的步骤：

　　1.提取功能说明，构造因子--状态表

　　把影响实验指标的条件称为因子。而影响实验因子的条件叫因子的状态。利用正交实验设计方法来设计测试用例时，首先要根据被测试软件的规格说明书找出影响其功能实现的操作对象和外部因素，把他们当作因子，而把各个因子的取值当作状态。对软件需求规格说明中的功能要求进行划分，把整体的概要性的功能要求进行层层分解与展开，分解成具体的有相对独立性的基本的功能要求。这样就可以把被测试软件中所有的因子都确定下来，并为确定个因子的权值提供参考的依据。确定因子与状态是设计测试用例的关键。因此要求尽可能全面的正确的确定取值，以确保测试用例的设计作到完整与有效。

　　2.加权筛选，生成因素分析表

　　对因子与状态的选择可按其重要程度分别加权。可根据各个因子及状态的作用大小，出现频率的大小以及测试的需要，确定权值的大小。

　　3.利用正交表构造测试数据集

　　正交表的推导依据Galois理论（这里省略，需要时可查数理统计方面的教材）。

　　利用正交实验设计方法设计测试用例，比使用等价类划分，边界值分析，因果图等方法有以下优点:节省测试工作工时；可控制生成的测试用例数量；测试用例具有一定的覆盖率。

　　二、实战演习

　　暂无

查看(518) 评论(0) 收藏分享管理
测试用例设计白皮书－－功能图分析方法（转）

静澜发布于 2008-11-27 10:32:20

一、方法简介
　　一个程序的功能说明通常由动态说明和静态说明组成。动态说明描述了输入数据的次序或转移的次序。静态说明描述了输入条件与输出条件之间的对应关系。对于较复杂的程序，由于存在大量的组合情况，因此，仅用静态说明组成的规格说明对于测试来说往往是不够的。必须用动态说明来补充功能说明。功能图方法是用功能图FD 形式化地表示程序的功能说明，并机械地生成功能图的测试用例。功能图模型由状态迁移图和逻辑功能模型构成。状态迁移图用于表示输入数据序列以及相应的输出数据。在状态迁移图中，由输入数据和当前状态决定输出数据和后续状态。逻辑功能模型用于表示在状态中输入条件和输出条件之间的对应关系。逻辑功能模型只适合于描述静态说明，输出数据仅由输入数据决定。测试用例则是由测试中经过的一系列状态和在每个状态中必须依靠输入/输出数据满足的一对条件组成。功能图方法其实是是一种黑盒白盒混合用例设计方法。

　　（功能图方法中，要用到逻辑覆盖和路径测试的概念和方法，其属白盒测试方法中的内容。逻辑覆盖是以程序内部的逻辑结构为基础的测试用例设计方法。该方法要求测试人员对程序的逻辑结构有清楚的了解。由于覆盖测试的目标不同，逻辑覆盖可分为:语句覆盖，判定覆盖，判定-条件覆盖，条件组合覆盖及路径覆盖。下面我们指的逻辑覆盖和路径是功能或系统水平上的，以区别与白盒测试中的程序内部的。）

　　1、功能图

　　功能图由状态迁移图和布尔函数组成。状态迁移图用状态和迁移来描述。一个状态指出数据输入的位置（或时间），而迁移则指明状态的改变。同时要依靠判定表或因果图表示的逻辑功能。例，一个简化的自动出纳机ATM的功能图。

　　2、测试用例生成方法

　　从功能图生成测试用例，得到的测试用例数是可接受的。问题的关键的是如何从状态迁移图中选取测试用例。若用节点代替状态，用弧线代替迁移，则状态迁移图就可转化成一个程序的控制流程图形式。问题就转化为程序的路径测试问题（如白盒测试）问题了。

　　3、测试用例生成规则

　　为了把状态迁移（测试路径）的测试用例与逻辑模型（局部测试用例）的测试用例组合起来，从功能图生成实用的测试用例，须定义下面的规则。在一个结构化的状态迁移（SST）中，定义三种形式的循环:顺序，选择和重复。但分辨一个状态迁移中的所有循环是有困难的。（其表示图形省略）。

　　4、从功能图生成测试用例的过程

　　1)生成局部测试用例:在每个状态中，从因果图生成局部测试用例。局部测试用例由原因值（输入数据）组合与对应的结果值（输出数据或状态）构成。

　　2)测试路径生成:利用上面的规则（三种）生成从初始状态到最后状态的测试路径。

　　3)测试用例合成:合成测试路径与功能图中每个状态中的局部测试用例。结果是初始状态到最后状态的一个状态序列，以及每个状态中输入数据与对应输出数据的组合。

　　5、测试用例的合成算法:采用条件构造树。

　　二、实战演习

　　暂无

查看(381) 评论(0) 收藏分享管理

401/212 >

HTTP请求模型和头信息

白盒测试之静态检查－－检测循环判断体重复计算

1.1.1 PERFORMANCE_LOOP_CALCULATE

1.1.1.1 版本

1.1.1.2 作者

1.1.1.3 原理

1.1.1.4 开发原理

1.1.1.5 配置说明

1.1.1.5.1 isOpen

1.1.1.5.2 includeMethords

1.1.1.5.3 preDirectCount

1.1.1.5.4 includeMethordsDirect

1.1.1.6 误报说明

测试用例设计－－因果图方法

[转]OATS正交表测试策略

功能测试

从测试用例看测试的发展与变化

功能测试用例设计积累（六）：在敏捷测试中如何设计用例

功能测试用例设计积累（五）：等价类划分法分析与实践

功能测试用例设计积累（四）：在没有需求文档的情况下如何设计测试用例

功能测试用例设计积累（三）：正交表分析与实践

功能测试用例设计积累（二）：错误推测法分析与实践

功能测试用例设计积累（一）：软件界面

[用例设计]测试用例设计的误区

[用例设计]如何设计编制软件测试用例

测试计划的全面性和有效性

软件测试用例的设计

测试用例设计白皮书－－测试用例基本概念（转）

测试用例设计白皮书－－判定表驱动分析方法（转）

测试用例设计白皮书－－正交实验设计方法（转）

测试用例设计白皮书－－功能图分析方法（转）

用户菜单

我的栏目

标题搜索

我的存档

数据统计

RSS订阅

输入条件	有效等价类	无效等价类
>10的正整数	大于10的正整数	空小数 <10的数负数字符串