关于对象与引用之间的一些基本概念。

       初学Java时，在很长一段时间里，总觉得基本概念很模糊。后来才知道，在许多Java书中，把对象和对象的引用混为一谈。可是，如果我分不清对象与对象引用，

       那实在没法很好地理解下面的面向对象技术。把自己的一点认识写下来，或许能让初学Java的朋友们少走一点弯路。

       为便于说明，我们先定义一个简单的类：

       class Vehicle {

       int passengers;      

       int fuelcap;

       int mpg;

                   }

有了这个模板，就可以用它来创建对象：

       Vehicle veh1 = new Vehicle();

通常把这条语句的动作称之为创建一个对象，其实，它包含了四个动作。

1）右边的“new Vehicle”，是以Vehicle类为模板，在堆空间里创建一个Vehicle类对象（也简称为Vehicle对象）。

2）末尾的()意味着，在对象创建后，立即调用Vehicle类的构造函数，对刚生成的对象进行初始化。构造函数是肯定有的。如果你没写，Java会给你补上一个默认的构造函数。

3）左边的“Vehicle veh 1”创建了一个Vehicle类引用变量。所谓Vehicle类引用，就是以后可以用来指向Vehicle对象的对象引用。

4）“=”操作符使对象引用指向刚创建的那个Vehicle对象。

我们可以把这条语句拆成两部分：

Vehicle veh1;

veh1 = new Vehicle();

效果是一样的。这样写，就比较清楚了，有两个实体：一是对象引用变量，一是对象本身。

       在堆空间里创建的实体，与在数据段以及栈空间里创建的实体不同。尽管它们也是确确实实存在的实体，但是，我们看不见，也摸不着。不仅如此，

       我们仔细研究一下第二句，找找刚创建的对象叫什么名字？有人说，它叫“Vehicle”。不对，“Vehicle”是类（对象的创建模板）的名字。

       一个Vehicle类可以据此创建出无数个对象，这些对象不可能全叫“Vehicle”。

       对象连名都没有，没法直接访问它。我们只能通过对象引用来间接访问对象。

       为了形象地说明对象、引用及它们之间的关系，可以做一个或许不很妥当的比喻。对象好比是一只很大的气球，大到我们抓不住它。引用变量是一根绳， 可以用来系汽球。

       如果只执行了第一条语句，还没执行第二条，此时创建的引用变量veh1还没指向任何一个对象，它的值是null。引用变量可以指向某个对象，或者为null。

       它是一根绳，一根还没有系上任何一个汽球的绳。执行了第二句后，一只新汽球做出来了，并被系在veh1这根绳上。我们抓住这根绳，就等于抓住了那只汽球。

       再来一句：

       Vehicle veh2;

就又做了一根绳，还没系上汽球。如果再加一句：

       veh2 = veh1;

系上了。这里，发生了复制行为。但是，要说明的是，对象本身并没有被复制，被复制的只是对象引用。结果是，veh2也指向了veh1所指向的对象。两根绳系的是同一只汽球。

       如果用下句再创建一个对象：

veh2 = new Vehicle();

则引用变量veh2改指向第二个对象。

       从以上叙述再推演下去，我们可以获得以下结论：

（1）一个对象引用可以指向0个或1个对象（一根绳子可以不系汽球，也可以系一个汽球）；

（2）一个对象可以有N个引用指向它（可以有N条绳子系住一个汽球）。

       如果再来下面语句：

       veh1 = veh2;

按上面的推断，veh1也指向了第二个对象。这个没问题。问题是第一个对象呢？没有一条绳子系住它，它飞了。多数书里说，它被Java的垃圾回收机制回收了。

这不确切。正确地说，它已成为垃圾回收机制的处理对象。至于什么时候真正被回收，那要看垃圾回收机制的心情了。

       由此看来，下面的语句应该不合法吧？至少是没用的吧？

new Vehicle();

不对。它是合法的，而且可用的。譬如，如果我们仅仅为了打印而生成一个对象，就不需要用引用变量来系住它。最常见的就是打印字符串：

    System.out.println(“I am Java!”);

字符串对象“I am Java!”在打印后即被丢弃。有人把这种对象称之为临时对象。

       对象与引用的关系将持续到对象回收。

Java对象及引用

Java对象及引用是容易混淆却又必须掌握的基础知识，本章阐述Java对象和引用的概念，以及与其密切相关的参数传递。

先看下面的程序：

StringBuffer s;

s = new StringBuffer("Hello World!");

第一个语句仅为引用(reference)分配了空间，而第二个语句则通过调用类(StringBuffer)的构造函数StringBuffer(String str)为类生成了一个实例（或称为对象）。这两个操作被完成后，对象的内容则可通过s进行访问——在Java里都是通过引用来操纵对象的。

Java对象和引用的关系可以说是互相关联，却又彼此独立。彼此独立主要表现在：引用是可以改变的，它可以指向别的对象，譬如上面的s，你可以给它另外的对象，如：

s = new StringBuffer("Java");

这样一来，s就和它指向的第一个对象脱离关系。

从存储空间上来说，对象和引用也是独立的，它们存储在不同的地方，对象一般存储在堆中，而引用存储在速度更快的堆栈中。

引用可以指向不同的对象，对象也可以被多个引用操纵，如：

StringBuffer s1 = s;

这条语句使得s1和s指向同一个对象。既然两个引用指向同一个对象，那么不管使用哪个引用操纵对象，对象的内容都发生改变，并且只有一份，通过s1和s得到的内容自然也一样，(String除外，因为String始终不变，String s1=”AAAA”; String s=s1,操作s,s1由于始终不变，所以为s另外开辟了空间来存储s,)如下面的程序：

StringBuffer s;

s = new StringBuffer("Java");

StringBuffer s1 = s;

s1.append(" World");

System.out.println("s1=" + s1.toString());//打印结果为：s1=Java World

System.out.println("s=" + s.toString());//打印结果为：s=Java World

上面的程序表明，s1和s打印出来的内容是一样的，这样的结果看起来让人非常疑惑，但是仔细想想，s1和s只是两个引用，它们只是操纵杆而已，它们指向同一个对象，操纵的也是同一个对象，通过它们得到的是同一个对象的内容。这就像汽车的刹车和油门，它们操纵的都是车速，假如汽车开始的速度是80，然后你踩了一次油门，汽车加速了，假如车速升到了120，然后你踩一下刹车，此时车速是从120开始下降的，假如下降到60，再踩一次油门，车速则从60开始上升，而不是从第一次踩油门后的120开始。也就是说车速同时受油门和刹车影响，它们的影响是累积起来的，而不是各自独立（除非刹车和油门不在一辆车上）。所以，在上面的程序中，不管使用s1还是s操纵对象，它们对对象的影响也是累积起来的（更多的引用同理）。

只有理解了对象和引用的关系，才能理解参数传递。

一般面试题中都会考Java传参的问题，并且它的标准答案是Java只有一种参数传递方式：那就是按值传递，即Java中传递任何东西都是传值。如果传入方法的是基本类型的东西，你就得到此基本类型的一份拷贝。如果是传递引用，就得到引用的拷贝。

一般来说，对于基本类型的传递，我们很容易理解，而对于对象，总让人感觉是按引用传递，看下面的程序：

public class ObjectRef {

    //基本类型的参数传递

    public static void testBasicType(int m) {

        System.out.println("m=" + m);//m=50

        m = 100;

        System.out.println("m=" + m);//m=100

    }

    //参数为对象，不改变引用的值 ？？？？？？

    public static void add(StringBuffer s) {

        s.append("_add");

    }

    //参数为对象，改变引用的值 ？？？？？

    public static void changeRef(StringBuffer s) {

        s = new StringBuffer("Java");

    }

    public static void main(String[] args) {

        int i = 50;

        testBasicType(i);

        System.out.println(i);//i=50

        StringBuffer sMain = new StringBuffer("init");

        System.out.println("sMain=" + sMain.toString());//sMain=init

        add(sMain);

        System.out.println("sMain=" + sMain.toString());//sMain=init_add

        changeRef(sMain);

        System.out.println("sMain=" + sMain.toString());//sMain=init_add

    }

}

以上程序的允许结果显示出，testBasicType方法的参数是基本类型，尽管参数m的值发生改变，但并不影响i。

      add方法的参数是一个对象，当把sMain传给参数s时，s得到的是sMain的拷贝，所以s和sMain指向同一个对象，因此，使用s操作影响的其实就是sMain指向的对象，故调用add方法后，sMain指向的对象的内容发生了改变。

      在changeRef方法中，参数也是对象，当把sMain传给参数s时，s得到的是sMain的拷贝，但与add方法不同的是，在方法体内改变了s指向的对象（也就是s指向了别的对象,牵着气球的绳子换气球了），给s重新赋值后，s与sMain已经毫无关联，它和sMain指向了不同的对象，所以不管对s做什么操作，都不会影响sMain指向的对象，故调用changeRef方法前后sMain指向的对象内容并未发生改变。

对于add方法的调用结果，可能很多人会有这种感觉：这不明明是按引用传递吗？对于这种问题，还是套用Bruce Eckel的话：这依赖于你如何看待引用，最终你会明白，这个争论并没那么重要。真正重要的是，你要理解，传引用使得（调用者的）对象的修改变得不可预期。

 public   class   Test
{   public int   i,j;  
    public   void   test_m(Test   a)
    {     Test   b   =  new   Test();
          b.i   =   1;
          b.j   =   2;
          a   =   b;
    }
    public   void   test_m1(Test   a   )
    {     a.i   =   1;
        a.j   =   2;
    }
    public   static   void   main(String   argv[])
    {     Test   t=   new   Test();
          t.i   =   5;
          t.j   =   6;
          System.out.println( "t.i   =   "+   t.i   +   "   t.j=   "   +   t.j); //5,6
          t.test_m(t);
          System.out.println( "t.i   =   "+   t.i   +   "   t.j=   "   +   t.j); //5,6,a和t都指向了一个对象，而在test_m中s又指向了另一个对象，所以对象t不变！！！

          t.test_m1(t);

          System.out.println( "t.i   =   "+   t.i   +   "   t.j=   "   +   t.j); //1,2

    }

}

答案只有一个：Java里都是按值传递参数。而实际上，我们要明白，当参数是对象时，传引用会发生什么状况（就像上面的add方法）？

=========================================================================

楼主，这样来记这个问题
如下表达式：
A a1 = new A();
它代表A是类，a1是引用，a1不是对象，new A()才是对象，a1引用指向new A()这个对象。

在JAVA里，“=”不能被看成是一个赋值语句，它不是在把一个对象赋给另外一个对象，它的执行过程实质上是将右边对象的地址传给了左边的引用，使得左边的引用指向了右边的对象。JAVA表面上看起来没有指针，但它的引用其实质就是一个指针，引用里面存放的并不是对象，而是该对象的地址，使得该引用指向了对象。在JAVA里，“=”语句不应该被翻译成赋值语句，因为它所执行的确实不是一个赋值的过程，而是一个传地址的过程，被译成赋值语句会造成很多误解，译得不准确。

再如：
A a2;
它代表A是类，a2是引用，a2不是对象，a2所指向的对象为空null;

再如：
a2 = a1;
它代表，a2是引用，a1也是引用，a1所指向的对象的地址传给了a2(传址），使得a2和a1指向了同一对象。

综上所述，可以简单的记为，在初始化时，“=”语句左边的是引用，右边new出来的是对象。
在后面的左右都是引用的“=”语句时，左右的引用同时指向了右边引用所指向的对象。

再所谓实例，其实就是对象的同义词。

如果需要赋值，就需要类实现Cloneable接口，实现clone()方法。

1 2 3 4 5 6 7 8 9 10 11 

class D implements Cloneable{//实现Cloneable接口 	String sex; 	D(String sex){ 		this.sex=sex; 	} 	@Override 	protected Object clone() throws CloneNotSupportedException { 		// 实现clone方法 		return super.clone(); 	} }

赋值的时候：

1 2 

D d=new D("男"); D d2=(D) d.clone();//把d赋值给d2

如果类中的变量不是主类型，而是对象，也需要调用该对象的clone()方法
下面是一个完整的例子：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 

public class Test2 { 	public static void main(String[] args) throws CloneNotSupportedException { 		// TODO Auto-generated method stub 		D d=new D("男"); 		C c=new C("张三","20",d); 		C new_c=(C) c.clone();//调用clone方法来赋值 		new_c.name="李四"; 		d.sex="女";//d 		System.out.println(c.d.sex); 		System.out.println(c.name);   	}   }   class C implements Cloneable{ 	String name; 	String age; 	D d; 	C(String name,String age,D d) throws CloneNotSupportedException{ 		this.name=name; 		this.age=age; 		this.d=(D) d.clone();//调用clone方法来赋值，这样即便外部的d发生变化，c里的也不会变 	} 	@Override 	protected Object clone() throws CloneNotSupportedException { 		// TODO Auto-generated method stub 		return super.clone(); 	} } class D implements Cloneable{//实现Cloneable接口 	String sex; 	D(String sex){ 		this.sex=sex; 	} 	@Override 	protected Object clone() throws CloneNotSupportedException { 		// 实现clone方法 		return super.clone(); 	} }

会话（Session）跟踪是Web程序中常用的技术，用来跟踪用户的整个会话。常用的会话跟踪技术是Cookie与Session。Cookie通过在客户端记录信息确定用户身份，Session通过在服务器端记录信息确定用户身份。

本章将系统地讲述Cookie与Session机制，并比较说明什么时候不能用Cookie，什么时候不能用Session。

1.1  Cookie机制

在程序中，会话跟踪是很重要的事情。理论上，一个用户的所有请求操作都应该属于同一个会话，而另一个用户的所有请求操作则应该属于另一个会话，二者不能混淆。例如，用户A在超市购买的任何商品都应该放在A的购物车内，不论是用户A什么时间购买的，这都是属于同一个会话的，不能放入用户B或用户C的购物车内，这不属于同一个会话。

而Web应用程序是使用HTTP协议传输数据的。HTTP协议是无状态的协议。一旦数据交换完毕，客户端与服务器端的连接就会关闭，再次交换数据需要建立新的连接。这就意味着服务器无法从连接上跟踪会话。即用户A购买了一件商品放入购物车内，当再次购买商品时服务器已经无法判断该购买行为是属于用户A的会话还是用户B的会话了。要跟踪该会话，必须引入一种机制。

Cookie就是这样的一种机制。它可以弥补HTTP协议无状态的不足。在Session出现之前，基本上所有的网站都采用Cookie来跟踪会话。

1.1.1  什么是Cookie

Cookie意为“甜饼”，是由W3C组织提出，最早由Netscape社区发展的一种机制。目前Cookie已经成为标准，所有的主流浏览器如IE、Netscape、Firefox、Opera等都支持Cookie。

由于HTTP是一种无状态的协议，服务器单从网络连接上无从知道客户身份。怎么办呢？就给客户端们颁发一个通行证吧，每人一个，无论谁访问都必须携带自己通行证。这样服务器就能从通行证上确认客户身份了。这就是Cookie的工作原理。

Cookie实际上是一小段的文本信息。客户端请求服务器，如果服务器需要记录该用户状态，就使用response向客 户端浏览器颁发一个Cookie。客户端浏览器会把Cookie保存起来。当浏览器再请求该网站时，浏览器把请求的网址连同该Cookie一同提交给服务 器。服务器检查该Cookie，以此来辨认用户状态。服务器还可以根据需要修改Cookie的内容。

查看某个网站颁发的Cookie很简单。在浏览器地址栏输入javascript:alert (document. cookie)就可以了（需要有网才能查看）。JavaScript脚本会弹出一个对话框显示本网站颁发的所有Cookie的内容，如图1.1所示。

图1.1  Baidu网站颁发的Cookie

图1.1中弹出的对话框中显示的为Baidu网站的Cookie。其中第一行BAIDUID记录的就是笔者的身份helloweenvsfei，只是Baidu使用特殊的方法将Cookie信息加密了。

注意：Cookie功能需要浏览器的支持。

如果浏览器不支持Cookie（如大部分手机中的浏览器）或者把Cookie禁用了，Cookie功能就会失效。

不同的浏览器采用不同的方式保存Cookie。

IE浏览器会在“C:\Documents and Settings\你的用户名\Cookies”文件夹下以文本文件形式保存，一个文本文件保存一个Cookie。

1.1.2  记录用户访问次数

Java中把Cookie封装成了javax.servlet.http.Cookie类。每个Cookie都是该Cookie类的对象。服务器通过操作Cookie类对象对客户端Cookie进行操作。通过request.getCookie()获取客户端提交的所有Cookie（以Cookie[]数组形式返回），通过response.addCookie(Cookiecookie)向客户端设置Cookie。

Cookie对象使用key-value属性对的形式保存用户状态，一个Cookie对象保存一个属性对，一个request或者response同时使用多个Cookie。因为Cookie类位于包javax.servlet.http._*下面，所以JSP中不需要import该类。

1.1.3  Cookie的不可跨域名性

很多网站都会使用Cookie。例如，Google会向客户端颁发Cookie，Baidu也会向客户端颁发Cookie。那浏览器访问Google会不会也携带上Baidu颁发的Cookie呢？或者Google能不能修改Baidu颁发的Cookie呢？

答案是否定的。Cookie具有不可跨域名性。根据Cookie规范，浏览器访问Google只会携带Google的Cookie，而不会携带Baidu的Cookie。Google也只能操作Google的Cookie，而不能操作Baidu的Cookie。

Cookie在客户端是由浏览器来管理的。浏览器能够保证Google只会操作Google的Cookie而不会操作 Baidu的Cookie，从而保证用户的隐私安全。浏览器判断一个网站是否能操作另一个网站Cookie的依据是域名。Google与Baidu的域名 不一样，因此Google不能操作Baidu的Cookie。

需要注意的是，虽然网站images.google.com与网站www.google.com同属于Google，但是域名不一样，二者同样不能互相操作彼此的Cookie。

注意：用户登录网站www.google.com之后会发现访问images.google.com时登录信息仍然有效，而普通的Cookie是做不到的。这是因为Google做了特殊处理。本章后面也会对Cookie做类似的处理。

1.1.4  Unicode编码：保存中文

中文与英文字符不同，中文属于Unicode字符，在内存中占4个字符，而英文属于ASCII字符，内存中只占2个字节。Cookie中使用Unicode字符时需要对Unicode字符进行编码，否则会乱码。

提示：Cookie中保存中文只能编码。一般使用UTF-8编码即可。不推荐使用GBK等中文编码，因为浏览器不一定支持，而且JavaScript也不支持GBK编码。

1.1.5  BASE64编码：保存二进制图片

Cookie不仅可以使用ASCII字符与Unicode字符，还可以使用二进制数据。例如在Cookie中使用数字证书，提供安全度。使用二进制数据时也需要进行编码。

%注意：本程序仅用于展示Cookie中可以存储二进制内容，并不实用。由于浏览器每次请求服务器都会携带Cookie，因此Cookie内容不宜过多，否则影响速度。Cookie的内容应该少而精。

1.1.6  设置Cookie的所有属性

除了name与value之外，Cookie还具有其他几个常用的属性。每个属性对应一个getter方法与一个setter方法。Cookie类的所有属性如表1.1所示。

表1.1  Cookie常用属性

1.1.7  Cookie的有效期

Cookie的maxAge决定着Cookie的有效期，单位为秒（Second）。Cookie中通过getMaxAge()方法与setMaxAge(int maxAge)方法来读写maxAge属性。

如果maxAge属性为正数，则表示该Cookie会在maxAge秒之后自动失效。浏览器会将maxAge为正数的 Cookie持久化，即写到对应的Cookie文件中。无论客户关闭了浏览器还是电脑，只要还在maxAge秒之前，登录网站时该Cookie仍然有效。 下面代码中的Cookie信息将永远有效。

Cookie cookie = new Cookie("username","helloweenvsfei");   // 新建Cookie

cookie.setMaxAge(Integer.MAX_VALUE);           // 设置生命周期为MAX_VALUE

response.addCookie(cookie);                    // 输出到客户端

如果maxAge为负数，则表示该Cookie仅在本浏览器窗口以及本窗口打开的子窗口内有效，关闭窗口后该 Cookie即失效。maxAge为负数的Cookie，为临时性Cookie，不会被持久化，不会被写到Cookie文件中。Cookie信息保存在浏 览器内存中，因此关闭浏览器该Cookie就消失了。Cookie默认的maxAge值为–1。

如果maxAge为0，则表示删除该Cookie。Cookie机制没有提供删除Cookie的方法，因此通过设置该Cookie即时失效实现删除Cookie的效果。失效的Cookie会被浏览器从Cookie文件或者内存中删除，

例如：

Cookie cookie = new Cookie("username","helloweenvsfei");   // 新建Cookie

cookie.setMaxAge(0);                          // 设置生命周期为0，不能为负数

response.addCookie(cookie);                    // 必须执行这一句

response对象提供的Cookie操作方法只有一个添加操作add(Cookie cookie)。

要想修改Cookie只能使用一个同名的Cookie来覆盖原来的Cookie，达到修改的目的。删除时只需要把maxAge修改为0即可。

注意：从客户端读取Cookie时，包括maxAge在内的其他属性都是不可读的，也不会被提交。浏览器提交Cookie时只会提交name与value属性。maxAge属性只被浏览器用来判断Cookie是否过期。

1.1.8  Cookie的修改、删除

Cookie并不提供修改、删除操作。如果要修改某个Cookie，只需要新建一个同名的Cookie，添加到response中覆盖原来的Cookie。

如果要删除某个Cookie，只需要新建一个同名的Cookie，并将maxAge设置为0，并添加到response中覆盖原来的Cookie。注意是0而不是负数。负数代表其他的意义。读者可以通过上例的程序进行验证，设置不同的属性。

注意：修改、删除Cookie时，新建的Cookie除value、maxAge之外的所有属性，例如name、path、domain等，都要与原Cookie完全一样。否则，浏览器将视为两个不同的Cookie不予覆盖，导致修改、删除失败。

1.1.9  Cookie的域名

Cookie是不可跨域名的。域名www.google.com颁发的Cookie不会被提交到域名www.baidu.com去。这是由Cookie的隐私安全机制决定的。隐私安全机制能够禁止网站非法获取其他网站的Cookie。

正常情况下，同一个一级域名下的两个二级域名如www.helloweenvsfei.com和 images.helloweenvsfei.com也不能交互使用Cookie，因为二者的域名并不严格相同。如果想所有 helloweenvsfei.com名下的二级域名都可以使用该Cookie，需要设置Cookie的domain参数，例如：

Cookie cookie = new Cookie("time","20080808"); // 新建Cookie

cookie.setDomain(".helloweenvsfei.com");           // 设置域名

cookie.setPath("/");                              // 设置路径

cookie.setMaxAge(Integer.MAX_VALUE);               // 设置有效期

response.addCookie(cookie);                       // 输出到客户端

读者可以修改本机C:\WINDOWS\system32\drivers\etc下的hosts文件来配置多个临时域名，然后使用setCookie.jsp程序来设置跨域名Cookie验证domain属性。

注意：domain参数必须以点(".")开始。另外，name相同但domain不同的两个Cookie是两个不同的Cookie。如果想要两个域名完全不同的网站共有Cookie，可以生成两个Cookie，domain属性分别为两个域名，输出到客户端。

1.1.10  Cookie的路径

domain属性决定运行访问Cookie的域名，而path属性决定允许访问Cookie的路径（ContextPath）。例如，如果只允许/sessionWeb/下的程序使用Cookie，可以这么写：

Cookie cookie = new Cookie("time","20080808");     // 新建Cookie

cookie.setPath("/session/");                          // 设置路径

response.addCookie(cookie);                           // 输出到客户端

设置为“/”时允许所有路径使用Cookie。path属性需要使用符号“/”结尾。name相同但domain相同的两个Cookie也是两个不同的Cookie。

注意：页面只能获取它属于的Path的Cookie。例如/session/test/a.jsp不能获取到路径为/session/abc/的Cookie。使用时一定要注意。

1.1.11  Cookie的安全属性

HTTP协议不仅是无状态的，而且是不安全的。使用HTTP协议的数据不经过任何加密就直接在网络上传播，有被截获的可 能。使用HTTP协议传输很机密的内容是一种隐患。如果不希望Cookie在HTTP等非安全协议中传输，可以设置Cookie的secure属性为 true。浏览器只会在HTTPS和SSL等安全协议中传输此类Cookie。下面的代码设置secure属性为true：

Cookie cookie = new Cookie("time", "20080808"); // 新建Cookie

cookie.setSecure(true);                           // 设置安全属性

response.addCookie(cookie);                        // 输出到客户端

提示：secure属性并不能对Cookie内容加密，因而不能保证绝对的安全性。如果需要高安全性，需要在程序中对Cookie内容加密、解密，以防泄密。

1.1.12  JavaScript操作Cookie

Cookie是保存在浏览器端的，因此浏览器具有操作Cookie的先决条件。浏览器可以使用脚本程序如 JavaScript或者VBScript等操作Cookie。这里以JavaScript为例介绍常用的Cookie操作。例如下面的代码会输出本页面 所有的Cookie。

<script>document.write(document.cookie);</script>

由于JavaScript能够任意地读写Cookie，有些好事者便想使用JavaScript程序去窥探用户在其他网 站的Cookie。不过这是徒劳的，W3C组织早就意识到JavaScript对Cookie的读写所带来的安全隐患并加以防备了，W3C标准的浏览器会 阻止JavaScript读写任何不属于自己网站的Cookie。换句话说，A网站的JavaScript程序读写B网站的Cookie不会有任何结果。

1.1.13  案例：永久登录

如果用户是在自己家的电脑上上网，登录时就可以记住他的登录信息，下次访问时不需要再次登录，直接访问即可。实现方法是把登录信息如账号、密码等保存在Cookie中，并控制Cookie的有效期，下次访问时再验证Cookie中的登录信息即可。

保存登录信息有多种方案。最直接的是把用户名与密码都保持到Cookie中，下次访问时检查Cookie中的用户名与密码，与数据库比较。这是一种比较危险的选择，一般不把密码等重要信息保存到Cookie中。

还有一种方案是把密码加密后保存到Cookie中，下次访问时解密并与数据库比较。这种方案略微安全一些。如果不希望保存密码，还可以把登录的时间戳保存到Cookie与数据库中，到时只验证用户名与登录时间戳就可以了。

这几种方案验证账号时都要查询数据库。

本例将采用另一种方案，只在登录时查询一次数据库，以后访问验证登录信息时不再查询数据库。实现方式是把账号按照一定的规则加密后，连同账号一块保存到Cookie中。下次访问时只需要判断账号的加密规则是否正确即可。本例把账号保存到名为account的Cookie中，把账号连同密钥用MD1算法加密后保存到名为ssid的Cookie中。验证时验证Cookie中的账号与密钥加密后是否与Cookie中的ssid相等。相关代码如下：

代码1.8 loginCookie.jsp

<%@ page language="java"pageEncoding="UTF-8" isErrorPage="false" %>

<%!                                                  // JSP方法

    private static final String KEY =":cookie@helloweenvsfei.com";
                                                     // 密钥 

    public final static String calcMD1(Stringss) { // MD1 加密算法

       String s = ss==null ?"" : ss;                  // 若为null返回空

       char hexDigits[] = { '0','1', '2', '3', '4', '1', '6', '7', '8', '9',
       'a', 'b', 'c', 'd', 'e', 'f' };                        // 字典

       try {

        byte[] strTemp =s.getBytes();                          // 获取字节

        MessageDigestmdTemp = MessageDigest.getInstance("MD1"); // 获取MD1

       mdTemp.update(strTemp);                                // 更新数据

        byte[] md =mdTemp.digest();                        // 加密

        int j =md.length;                                 // 加密后的长度

        char str[] = newchar[j _* 2];                       // 新字符串数组

        int k =0;                                         // 计数器k

        for (int i = 0; i< j; i++) {                       // 循环输出

         byte byte0 =md[i];

         str[k++] =hexDigits[byte0 >>> 4 & 0xf];

         str[k++] =hexDigits[byte0 & 0xf];

        }

        return newString(str);                             // 加密后字符串

       } catch (Exception e){return null; }

    }

%>

<%

   request.setCharacterEncoding("UTF-8");             // 设置request编码

    response.setCharacterEncoding("UTF-8");        // 设置response编码

    String action =request.getParameter("action"); // 获取action参数

    if("login".equals(action)){                       // 如果为login动作

        String account =request.getParameter("account");
                                                     // 获取account参数

        String password =request.getParameter("password");
                                                     // 获取password参数

        int timeout = newInteger(request.getParameter("timeout"));
                                                     // 获取timeout参数

        String ssid =calcMD1(account + KEY); // 把账号、密钥使用MD1加密后保存

        CookieaccountCookie = new Cookie("account", account);
                                                     // 新建Cookie

       accountCookie.setMaxAge(timeout);              // 设置有效期

        Cookie ssidCookie =new Cookie("ssid", ssid);   // 新建Cookie

       ssidCookie.setMaxAge(timeout);                 // 设置有效期

       response.addCookie(accountCookie);             // 输出到客户端

       response.addCookie(ssidCookie);            // 输出到客户端

        // 重新请求本页面，参数中带有时间戳，禁止浏览器缓存页面内容

       response.sendRedirect(request.getRequestURI() + "?" + System.
        currentTimeMillis());

        return;

    }

    elseif("logout".equals(action)){                  // 如果为logout动作

        CookieaccountCookie = new Cookie("account", "");
                                                 // 新建Cookie，内容为空

       accountCookie.setMaxAge(0);                // 设置有效期为0，删除

        Cookie ssidCookie =new Cookie("ssid", ""); // 新建Cookie，内容为空

       ssidCookie.setMaxAge(0);                   // 设置有效期为0，删除

       response.addCookie(accountCookie);         // 输出到客户端

       response.addCookie(ssidCookie);         // 输出到客户端

        //重新请求本页面，参数中带有时间戳，禁止浏览器缓存页面内容

       response.sendRedirect(request.getRequestURI() + "?" + System.
        currentTimeMillis());

        return;

    }

    boolean login = false;                        // 是否登录

    String account = null;                        // 账号

    String ssid = null;                           // SSID标识

    if(request.getCookies() !=null){               // 如果Cookie不为空

        for(Cookie cookie :request.getCookies()){  // 遍历Cookie

           if(cookie.getName().equals("account"))  // 如果Cookie名为
                                                    account

               account = cookie.getValue();       // 保存account内容

           if(cookie.getName().equals("ssid")) // 如果为SSID

               ssid = cookie.getValue();          // 保存SSID内容

        }

    }

    if(account != null && ssid !=null){    // 如果account、SSID都不为空

        login =ssid.equals(calcMD1(account + KEY));
                                      // 如果加密规则正确, 则视为已经登录

    }

%>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01Transitional//EN">

       <legend><%= login ? "欢迎您回来" : "请先登录"%></legend>

        <% if(login){%>

            欢迎您, ${ cookie.account.value }. &nbsp;&nbsp;

           <a href="${ pageContext.request.requestURI }?action=logout">
            注销</a>

        <% } else {%>

        <formaction="${ pageContext.request.requestURI }?action=login"
        method="post">

           <table>

               <tr><td>账号： </td>

                   <td><input type="text"name="account" style="width:
                   200px; "></td>

               </tr>

               <tr><td>密码： </td>

                   <td><inputtype="password" name="password"></td>

               </tr>

               <tr>

                   <td>有效期： </td>

                   <td><inputtype="radio" name="timeout" value="-1"
                   checked> 关闭浏览器即失效 <br/> <input type="radio"
                   name="timeout" value="<%= 30 _*24 _* 60 _* 60 %>"> 30天
                   内有效 <br/><input type="radio" name="timeout" value=
                   "<%= Integer.MAX_VALUE %>"> 永久有效 <br/> </td> </tr>

               <tr><td></td>

                   <td><input type="submit"value=" 登  录 " class=
                   "button"></td>

               </tr>

           </table>

        </form>

        <% } %>

登录时可以选择登录信息的有效期：关闭浏览器即失效、30天内有效与永久有效。通过设置Cookie的age属性来实现，注意观察代码。运行效果如图1.7所示。

图1.7  永久登录

提示：该加密机制中最重要的部分为算法与密钥。由于MD1算法的不可逆性，即使用户知道了账号与加密后的字符串，也不可能解密得到密钥。因此，只要保管好密钥与算法，该机制就是安全的。

1.2  Session机制

除了使用Cookie，Web应用程序中还经常使用Session来记录客户端状态。Session是服务器端使用的一种记录客户端状态的机制，使用上比Cookie简单一些，相应的也增加了服务器的存储压力。

1.2.1  什么是Session

Session是另一种记录客户状态的机制，不同的是Cookie保存在客户端浏览器中，而Session保存在服务器上。客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上。这就是Session。客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了。

如果说Cookie机制是通过检查客户身上的“通行证”来确定客户身份的话，那么Session机制就是通过检查服务器上的“客户明细表”来确认客户身份。Session相当于程序在服务器上建立的一份客户档案，客户来访的时候只需要查询客户档案表就可以了。

1.2.2  实现用户登录

Session对应的类为javax.servlet.http.HttpSession类。每个来访者对应一个Session对象，所有该客户的状态信息都保存在这个Session对象里。Session对象是在客户端第一次请求服务器的时候创建的。 Session也是一种key-value的属性对，通过getAttribute(Stringkey)和setAttribute(String key，Objectvalue)方法读写客户状态信息。Servlet里通过request.getSession()方法获取该客户的 Session，

例如：

HttpSession session = request.getSession();       // 获取Session对象

session.setAttribute("loginTime", new Date());     // 设置Session中的属性

out.println("登录时间为：" +(Date)session.getAttribute("loginTime"));      // 获取Session属性

request还可以使用getSession(boolean create)来获取Session。区别是如果该客户的Session不存在，request.getSession()方法会返回null，而 getSession(true)会先创建Session再将Session返回。

Servlet中必须使用request来编程式获取HttpSession对象，而JSP中内置了Session隐藏 对象，可以直接使用。如果使用声明了<%@page session="false" %>，则Session隐藏对象不可用。下面的例子使用Session记录客户账号信息。

源代码如下：

代码1.9  session.jsp

<%@ page language="java" pageEncoding="UTF-8"%>

<jsp:directive.page import="com.helloweenvsfei.sessionWeb.bean.Person"/>

<jsp:directive.page import="java.text.SimpleDateFormat"/>

<jsp:directive.page import="java.text.DateFormat"/>

<jsp:directive.page import="java.util.Date"/>

<%!

    DateFormat dateFormat = newSimpleDateFormat("yyyy-MM-dd");         // 日期格式化器

%>

<%

    response.setCharacterEncoding("UTF-8");        // 设置request编码

    Person[] persons =

    {          

       // 基础数据，保存三个人的信息

        new Person("Liu Jinghua","password1", 34, dateFormat.parse
        ("1982-01-01")),

        new Person("Hello Kitty","hellokitty", 23, dateFormat.parse
        ("1984-02-21")),

        new Person("Garfield", "garfield_pass",23, dateFormat.parse
        ("1994-09-12")),

     };

    String message = "";                      // 要显示的消息

    if(request.getMethod().equals("POST"))

    {

        // 如果是POST登录       

        for(Person person :persons)

        {          

            // 遍历基础数据，验证账号、密码

            // 如果用户名正确且密码正确

           if(person.getName().equalsIgnoreCase(request.getParameter("username"))&&person.getPassword().equals(request.getParameter("password")))

           {              

               // 登录成功，设置将用户的信息以及登录时间保存到Session

               session.setAttribute("person", person);                   // 保存登录的Person

               session.setAttribute("loginTime", new Date());          // 保存登录的时间              

               response.sendRedirect(request.getContextPath() + "/welcome.jsp");

               return;

            }

        }      

        message = "用户名密码不匹配，登录失败。";       // 登录失败

    }

%>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01Transitional//EN">

<html>

    // ... HTML代码为一个FORM表单，代码略，请看随书光盘

</html>

登录界面验证用户登录信息，如果登录正确，就把用户信息以及登录时间保存进Session，然后转到欢迎页面welcome.jsp。welcome.jsp中从Session中获取信息，并将用户资料显示出来。

welcome.jsp代码如下：

代码1.10  welcome.jsp

<%@ page language="java" pageEncoding="UTF-8"%>

<jsp:directive.pageimport="com.helloweenvsfei.sessionWeb.bean.Person"/>

<jsp:directive.page import="java.text.SimpleDateFormat"/>

<jsp:directive.page import="java.text.DateFormat"/>

<jsp:directive.page import="java.util.Date"/>

<%!

    DateFormat dateFormat = newSimpleDateFormat("yyyy-MM-dd");         // 日期格式化器

%>

<%

    Person person =(Person)session.getAttribute("person");                       // 获取登录的person

    Date loginTime =(Date)session.getAttribute("loginTime");                     // 获取登录时间

%>

    // ... 部分HTML代码略

            <table>

               <tr><td>您的姓名：</td>

                   <td><%= person.getName()%></td>

               </tr>

               <tr><td>登录时间：</td>

                   <td><%= loginTime%></td>

               </tr>

               <tr><td>您的年龄：</td>

                   <td><%= person.getAge()%></td>

               </tr>

               <tr><td>您的生日：</td>

                   <td><%=dateFormat.format(person.getBirthday()) %></td>

               </tr>

            </table>

程序运行效果如图1.8所示。

图1.8  使用Session记录用户信息

注意程序中Session中直接保存了Person类对象与Date类对象，使用起来要比Cookie方便。

当多个客户端执行程序时，服务器会保存多个客户端的Session。获取Session的时候也不需要声明获取谁的Session。Session机制决定了当前客户只会获取到自己的Session，而不会获取到别人的Session。各客户的Session也彼此独立，互不可见。

提示：Session的使用比Cookie方便，但是过多的Session存储在服务器内存中，会对服务器造成压力。

1.2.3  Session的生命周期

Session保存在服务器端。为了获得更高的存取速度，服务器一般把Session放在内存里。每个用户都会有一个独立的Session。如果Session内容过于复杂，当大量客户访问服务器时可能会导致内存溢出。因此，Session里的信息应该尽量精简。

Session在用户第一次访问服务器的时候自动创建。需要注意只有访问JSP、Servlet等程序时才会创建Session，只访问HTML、IMAGE等静态资源并不会创建Session。如果尚未生成Session，也可以使用request.getSession(true)强制生成Session。

Session生成后，只要用户继续访问，服务器就会更新Session的最后访问时间，并维护该Session。用户每访问服务器一次，无论是否读写Session，服务器都认为该用户的Session“活跃（active）”了一次。

1.2.4  Session的有效期

由于会有越来越多的用户访问服务器，因此Session也会越来越多。为防止内存溢出，服务器会把长时间内没有活跃的Session从内存删除。这个时间就是Session的超时时间。如果超过了超时时间没访问过服务器，Session就自动失效了。

Session的超时时间为maxInactiveInterval属性，可以通过对应的getMaxInactiveInterval()获取，通过setMaxInactiveInterval(longinterval)修改。

Session的超时时间也可以在web.xml中修改。另外，通过调用Session的invalidate()方法可以使Session失效。

1.2.5  Session的常用方法

Session中包括各种方法，使用起来要比Cookie方便得多。Session的常用方法如表1.2所示。

表1.2  HttpSession的常用方法

Tomcat中Session的默认超时时间为20分钟。通过setMaxInactiveInterval(int seconds)修改超时时间。可以修改web.xml改变Session的默认超时时间。例如修改为60分钟：

<session-config>

   <session-timeout>60</session-timeout>      <!-- 单位：分钟 -->

</session-config>

注意：<session-timeout>参数的单位为分钟，而setMaxInactiveInterval(int s)单位为秒。

1.2.6  Session对浏览器的要求

虽然Session保存在服务器，对客户端是透明的，它的正常运行仍然需要客户端浏览器的支持。这是因为Session 需要使用Cookie作为识别标志。HTTP协议是无状态的，Session不能依据HTTP连接来判断是否为同一客户，因此服务器向客户端浏览器发送一 个名为JSESSIONID的Cookie，它的值为该Session的id（也就是HttpSession.getId()的返回值）。Session 依据该Cookie来识别是否为同一用户。

该Cookie为服务器自动生成的，它的maxAge属性一般为–1，表示仅当前浏览器内有效，并且各浏览器窗口间不共享，关闭浏览器就会失效。

因此同一机器的两个浏览器窗口访问服务器时，会生成两个不同的Session。但是由浏览器窗口内的链接、脚本等打开的新窗口（也就是说不是双击桌面浏览器图标等打开的窗口）除外。这类子窗口会共享父窗口的Cookie，因此会共享一个Session。

注意：新开的浏览器窗口会生成新的Session，但子窗口除外。子窗口会共用父窗口的Session。例如，在链接上右击，在弹出的快捷菜单中选择“在新窗口中打开”时，子窗口便可以访问父窗口的Session。

如果客户端浏览器将Cookie功能禁用，或者不支持Cookie怎么办？例如，绝大多数的手机浏览器都不支持Cookie。Java Web提供了另一种解决方案：URL地址重写。

1.2.7  URL地址重写

URL地址重写是对客户端不支持Cookie的解决方案。URL地址重写的原理是将该用户Session的id信息重写 到URL地址中。服务器能够解析重写后的URL获取Session的id。这样即使客户端不支持Cookie，也可以使用Session来记录用户状态。 HttpServletResponse类提供了encodeURL(Stringurl)实现URL地址重写，例如：

<td>

    <a href="<%=response.encodeURL("index.jsp?c=1&wd=Java") %>">
    Homepage</a>

</td>

该方法会自动判断客户端是否支持Cookie。如果客户端支持Cookie，会将URL原封不动地输出来。如果客户端不支持Cookie，则会将用户Session的id重写到URL中。重写后的输出可能是这样的：

<td>

    <ahref="index.jsp;jsessionid=0CCD096E7F8D97B0BE608AFDC3E1931E?c=
    1&wd=Java">Homepage</a>

</td>

即在文件名的后面，在URL参数的前面添加了字符串“;jsessionid=XXX”。其中XXX为Session的 id。分析一下可以知道，增添的jsessionid字符串既不会影响请求的文件名，也不会影响提交的地址栏参数。用户单击这个链接的时候会把 Session的id通过URL提交到服务器上，服务器通过解析URL地址获得Session的id。

如果是页面重定向（Redirection），URL地址重写可以这样写：

<%

    if(“administrator”.equals(userName))

    {

       response.sendRedirect(response.encodeRedirectURL(“administrator.jsp”));

        return;

    }

%>

效果跟response.encodeURL(String url)是一样的：如果客户端支持Cookie，生成原URL地址，如果不支持Cookie，传回重写后的带有jsessionid字符串的地址。

对于WAP程序，由于大部分的手机浏览器都不支持Cookie，WAP程序都会采用URL地址重写来跟踪用户会话。比如用友集团的移动商街等。

注意：TOMCAT判断客户端浏览器是否支持Cookie的依据是请求中是否含有Cookie。尽管客户端可能会支持Cookie，但是由于第一次请求时不会携带任何Cookie（因为并无任何Cookie可以携带），URL地址重写后的地址中仍然会带有jsessionid。当第二次访问时服务器已经在浏览器中写入Cookie了，因此URL地址重写后的地址中就不会带有jsessionid了。

1.2.8  Session中禁止使用Cookie

既然WAP上大部分的客户浏览器都不支持Cookie，索性禁止Session使用Cookie，统一使用URL地址重写会更好一些。Java Web规范支持通过配置的方式禁用Cookie。下面举例说一下怎样通过配置禁止使用Cookie。

打开项目sessionWeb的WebRoot目录下的META-INF文件夹（跟WEB-INF文件夹同级，如果没有则创建），打开context.xml（如果没有则创建），编辑内容如下：

代码1.11 /META-INF/context.xml

<?xml version='1.0' encoding='UTF-8'?>

<Context path="/sessionWeb"cookies="false">

</Context>

或者修改Tomcat全局的conf/context.xml，修改内容如下：

代码1.12  context.xml

<!-- The contents of this file will be loaded for eachweb application -->

<Context cookies="false">

    <!-- ... 中间代码略 -->

</Context>

部署后TOMCAT便不会自动生成名JSESSIONID的Cookie，Session也不会以Cookie为识别标志，而仅仅以重写后的URL地址为识别标志了。

注意：该配置只是禁止Session使用Cookie作为识别标志，并不能阻止其他的Cookie读写。也就是说服务器不会自动维护名为JSESSIONID的Cookie了，但是程序中仍然可以读写其他的Cookie。

1          从这里开始

第一部分我们将快速浏览什么是user stories以及如何使用，然后将阐述如何编写User Stories；如何通过系统用户模型来定义Stories；当客户自己本身无法前来的时候，如何同那些能够充当客户角色的人一起工作；如何来编写测试用例，来证明你的Stories已经被成功编写的细节，最后将阐述几条编写好的Story的指导建议。

当你学完这部分之后，你就可以定义、编写、测试你的Stories，同时你应该准备去看如何通过User Stories去进行评估和计划，也就是第二部分的内容。

1.1 概述

软件需求是一个沟通的问题，想得到（或者使用，或者出售）新软件的人，必须和软件的生产者进行沟通。项目的成功与否，依赖于从不同的人那里得到的信息：一方面是客户、用户、分析人员、领域专家以及其他从业务或者组织角度来看待软件的人；另一方面则是技术团队。

如果任何一方控制了沟通，那么项目注定会失败。如果业务一方控制，则会要求功能和日期，而不太担心开发人员是否能全部完成或者开发人员是否明白他们的真正要求；如果开发人员控制了沟通，技术术语会代替业务语言，开发人员也失去了通过倾听来了解客户真正需求的机会。

我们需要一种方法让大家一起合作，以至于沟通不会被单方控制，并且资源分配中的感情因素和原则问题就变成了双方共同的问题。.当资源分配完全倾向一方的时候，项目就会失败。如果开发人员全权负责（无论怎样都必须在7月 份之前全部做完），他们可能会因为一些附加的功能而牺牲质量，或者只实现部分功能，或者独自制定本该客户或用户参与制定的大量的决定。当客户和用户方全权 负责，项目前期就会出现一个漫长的讨论过程，在这个过程中越来越多的功能被从项目中删除，当软件被交付的时候，甚至实现的功能比删掉的功能少。

我们已经知道了我们不能够完美的预言一个软件开发项目。当用户看到软件的初版时，他们会产生一些新的想法，改变一些他们原有的想法，由于软件的不可把握性，开发人员进行时间估算变得非常困难。由于种种原因，我们无法罗列一个完整的PERT图表来显示我们在项目里所必须完成的全部工作。

那么，怎么办？

我们经常通过手头已经掌握的资料来做决定，会好过在项目初期就做出所有的决定。我们把做决定分散到整个项目过程中。为了做到这一点，我们要确认已经有一个尽早尽多获得相关的资料的程序。User Stories 由此而生。

1.1.1 User Story 是什么？

User story是对软件的用户或买主有价值的功能点的描述。User stories 由以下三点组成：

l        用来制定计划和作为提醒的一段书面描述

l        用来充实story的细节的谈话

l        测试用例，用来表达和记录细节并且能够在story实现的时候对进行验证

因为User Story的描述是通过传统的手写记录在卡片上，所以Ron Jeffies给这三个方面起了很好的名字，Card（卡片），Conversation（会话），和Confirmation（确认）。卡片是story最可见的表现形式，但是他不是最重要的。Rachel Davies 已经说过，卡片“重现客户需求场景好于记录它们”。思考User Stories的完美方法是：card 包含story的正文，通过会话得出细节，并记录在测试用例中。

User story 的例子，请参见Story Card 1.1

Story Card 1.1 是一个写在卡片上的初期的User Story

（用户可以在网站上发布简历）

为了保持一致，贯穿剩下的这本书的例子大多都是为BigMoneyJobs 网站而设计的。其他的例子故事可能包括：

·         A user can search for jobs（用户可以查找职位）

·         A company can post new job openings（公司可以发布新的职位）

·         A user can limit who can see her resume（用户可以限制那些人可以查看他的简历）

 因为user stories 描述了对客户来说有价值的功能点，所以对这个系统来说下边的例子就不是好的user stories。

·         The software will be written in C++.（软件应该用C++来编写）

·         The program will connect to the database through a connection pool（软件应该通过连接池来连接到数据库）.

第一个例子对BigMoneyJobs来说不是个好的user story是因为用户根本就不关心使用哪种编程语言。但是，如果这是一个应用程序接口，用户（他本身就是个程序员）写下“The software will be written in C++（软件应该用C++来编写）”就会很好。

第二个story在这种情况下也不是个好的user story ，因为系统的使用者并不关心应用程序如何连接到数据库的技术细节。

也许，你已经读了这些stories 并且很惊讶地说，“等等，使用一个连接池是我这个系统的一个需求” 如果这样的话，请一定要清楚，编写stories的关键点在于让客户认可他们的价值，我们将在第二部分“编写story”里看到一些关于编写Story方面的例子。

1.1.2 细节在哪呢？

说 “A user can search for jobs（用户可以查找职位）”是一件事情，而能否只靠这个作为指导就开始编码和测试却是另外一件事情。因为，细节在哪里呢？类似于下边的这些问题怎么办呢？

l        What values can users search on? State? City? Job title? Keywords?（用户查询的条件是什么？州？城市？职位？关键字？）

l        Does the user have to be a member of the site?（用户必须是网站的注册用户吗？）

l        Can search parameters be saved?（可以保存查询条件么？）

l        What information is displayed for matching jobs?（查询页面上应该显示哪些信息呢？）

许多类似的细节可以当作另外的stories来描述。实际上，多做几个stories 比做一个很大的stories要好。例如整个的BigMoneyJobs 网站可以用这两个stories来描述：

l        A user can search for a job（用户可以找工作）

l        A company can post job openings（公司可以发布职位空缺（好机会））

很明显，这两个stories太大了，大到没有太大用处.，在第二章“编写故事”中，完整的阐述了故事大小的问题。从一、两个开发人员花费半天或者两个星期来编写和测试一个story开始，是一个不错的起点。 公平一些来讲（Liberally interpreted），上边的两个stories简单的概括了BigMoneyJobs网站的大部分功能，，每一个大概要花费程序员多于一周的时间。

当一个故事太大的时候，他通常会被作为一个Epic（译者注：此词本意为史诗级的，我没有找到合适的汉语词汇表达，就是大的故事集的意思）提出.Epics可以被分割成两个或更多个小故事。例如，这个Epic“A user can search for a job（用户可以找工作）”就可以被分割成这些Stories。

l        A user can search for jobs by attributes like location, salary range, job title, company name, and the date the job was posted.（用户可以通过地区, 薪水, 职位, 单位名称, 和职位发布日期 来搜索）

l        A user can view information about each job that is matched by a search.（用户可以查看搜索出来的每个职位的详细信息）

l        A user can view detailed information about a company that has posted a job.（用户可以查看发布职位空缺信息公司的详细信息）

但是，当我们的story能够涵盖所有的细节时，我们就不再去分割story了。例如，故事“A user can view information about each job that is matched by a search”是非常适度和实用的。我们不需要再去把它进一步的像这样去拆分：

l        A user can view a job descrīption.（用户可以查看职位描述）

l        A user can view a job's salary range.（用户可以查看职位薪水）

l        A user can view the location of a job.（用户可以查看工作地点）

总的来说，user story 不需要用专业的需求文档格式夸张的描述成下面这个样子。

比坐在这里把这些细节写成stories更好的方法就是开发团队和客户来一起讨论这些细节。就是说，当这些细节比较重要的时候，就把他拿出来讨论。讨论后，在卡片上添加一些注释是没有错的，就像Story Card 1.2.一样。可是，重点是会话，而不是story card上的笔迹。不管是开发人员还是客户都能够在3个月后还指着卡片说“看，我那时候是这么说的”。Stories并不承担法律责任。我们将看到，协议通过可以证明某个story被正确实现的测试用例来记录。

Story Card 1.2. A story card with a note.

1.1.3 故事应该有多长呢？

当我上中学文化课时候，每当我们被指定去写一篇论文，我总是问“论文必须写多长呢？”老师是不喜欢这个问题的，但是我仍然认为这个问题是必要的，因为它告诉我老师期望的是什么。这个问题同样也是了解项目用户需求很重要的一点。这些要求最好以可测试的形势被捕获。

如果你使用的是纸质的笔记卡片，你可以把卡片翻过来，把需求写到背面。这些记录下来的要求提醒怎样测试这个story，就像Story Card 1.3所显示的那样。如果你使用的是电子系统，它应该有一个地方可以让你加进一些可测试性的提醒。

Story Card 1.3. The back of a story card holds reminders about how to test the story.

测试描述是简短和不完备的，测试用例可以随时添加或者删除。目的是涵盖Story的附加信息，以便开发人员知道Story什么时候就算完成了。就像老师的要求对我来说很有用，我可以知道什么时候我写的关于Moby Dick的东西算完成了。它对于开发人员来了解什么时候完成了客户需求一样有用。

1.1.4 客户团队

在我现在的游戏项目中，基本上每天都要代码，各种游戏资源需要更新。而且每次从SVN服务器上更新代码后都要编译好久。另外资源的更新也是一件很麻 烦的事情，因为我们的所有游戏资源都是统一放在一个FTP上面，每个版本发布之后都会把最新的游戏资源放在里面。每次从FTP上把好几G的数据更新下来很 是费时间。于是我在想能不能写个小程序让这些都自动执行，即能够设定一个时间。例如每天的凌晨从FTP上把资源更新下来，然后再从SVN上把最新的代码更 新下来，最后让程序自动编译。每一步都有详细的log记录，第二天上班后就可以取到最新的版本了。

实际我的上述方法就是Daily Build的雏形。Daily Build又称“nightly build”，是将一个软件项目的所有最新代码取出，从头开始编译、链接，用安装软件包将链接好的软件安装好，运行安装后的软件，运行测试软件包对主要功 能进行测试（smoke test），发现错误并报告错误的完整过程。我的上述想法只是没有自动安装和测试的步骤。

其实实现起来也不是很难，最简单的方法就是写个批处理，然后把批处理程序挂到控制面板的“Scheduled Tasks”中。这种土办法自己要玩玩还行，真要用到项目中去还必须使用专业的软件工具。我在网上搜了一下，发现一款名叫Visual Build的软件还不错，以后有机会要好好介绍一下。

下面还是稍微介绍下每日构建吧：

在微软软件开发中，每日构建是最重要的过程之一，被称为微软产品开发的“心跳”。简单来看，每天构建系统将整个产品解决方案完整构建一遍，生成的目 标文件和安装文件被放置在一个共享位置。接着，安装文件被自动部署到release server上，随后可以自动运行BVT（build verification test），并将所有结果寄送每个team member的信箱。

微软有一套完善的内部系统来完成整个自动化流程，以及流程管理、reporting等工作，而如果我们没有这套系统，也想实现完整的daily build流程，该怎么做呢？

在VS.NET2003时代，IDE可以控制整个方案的构建，但是所有的构建逻辑被IDE控制，对于开发人员来说，整个构建流程就像一个黑箱，很难 修改和管理。当然可以使用PreBuildEvent和PostBuildEvent来控制，但是这些event都写在csproj/vbproj文件 中，不便于修改，不适于扩展。而且使用IDE来做每日构建的话，要求构建系统本身装有VS.NET，这会带来额外的成本。另一种办法是使用NAnt，通过 XML配置文件，来管理构建流程，这会使得整个流程易于修改，可扩展，并且不要求构建系统安装IDE，只需要有framework即可。问题是使用 NAnt必须额外写一堆复杂的XML配置文件，足以让很多developer看了头疼。

VS.NET2005中引入了一套全新的构建系统：MSBuild。简单来讲，MSBuild可以直接读取csproj文件，控制csc/vbc等 编译器，生成整个方案。实际上，VS2005的IDE自身就是调用MSBuild来完成编译的，这与VS2003有很大的不同。并且由于VS2005的 csproj文件服从MSBuild的配置schema，因此我们可以直接使用csproj，稍稍修改一下，就能组织起完整的构建流程了。

虽然这是一个非常简单的过程，但却有非常重要的意义：

1、能最小化集成风险

项目组可能遇到的一个很大的风险是，项目组成员根据不同的系统功能各自开发不同的代码，但是当这些代码集成为一个系统的时候，也许系统完成不了预期 的功能。这种风险的发生取决于项目中的这种不兼容性多久才被发现，由于程序界面已经发生了变化，或者系统的主要部分已经被重新设计和重新实现了，相应的排 错工作将非常困难和耗时。极端情况下，集成的错误可能回导致项目被取消掉。每日构造和冒烟测试可以使这种集成错误变得非常小，而且便于解决，防止了很多集 成问题的产生。

2、能减小产品低质量的风险

       这种风险是和集成不成功、集成出错相关联的。每天对集成的代码做一些少量的冒烟测试，即可杜绝项目中那些基本的质量问题。通过这种方式，使系统达到一种周知的良好状态，维护这样的系统可以防止系统逐步恶化到耗费大量时间排查质量问题的地步。

3、能简单化错误诊断

当系统每天都进行build和测试时，系统任何一天发生的错误都能够变得十分精细，便于排查。比如在17日系统还运行正常，18日就出错了，那么只需要检查这两次build之间的代码变化就可以了。

4、能极大鼓舞项目组的士气

看到产品的不断成长，能够极大的鼓舞项目组的士气，有时甚至不管这个产品到底用来做什么。开发人员可能会为系统显示了一个矩形而感到激动。通过每日构造，产品每天进步一点点，保证项目士气的持续高涨。

进行每日构造和冒烟测试

虽然说这是一个简单枯燥的活，每天进行build，每天进行测试，但也有着一些值得注意的细节：

1、每天坚持

每日构造，最重要的就是“每日”。如Jim McCarthy所说，把每日构造看作是项目的“心跳”，没有“心跳”的话，项目也就死了(Dynamics of Software Development, Microsoft Press, 1995)。Michael Cusumano and Richard W. Selby描述了另外一种隐含的比喻，把每日构造比作项目的“同步脉冲”(Microsoft Secrets, The Free Press, 1995)。 不同开发人员写的代码在他们的“脉冲”之间肯定都会存在“同步”的差异，但是必须有这样一个“同步脉冲”，使得这些代码能够组合为一个整体。当项目组坚持 每天把这些不同的“脉冲”组合到一起的时候，开发人员脱离整体的情况就会得到极大程度的杜绝。

有些项目组把这一过程简化为“每周build一次”。这样带来的问题是，某一次build失败后，可能要回溯好几周才能找到原因。如果这种情况发生的话，已经得不到经常build带来的好处了。

2、严格检查每一次build

要保证每一次build的成功，就必须保证build后的结果（也可称为build）是可以正常运行的，如果build不可运行，那么本次build被认为是不成功的，同时应该将修复此次build的工作提高到项目组最高级别来处理。

对于如何衡量一个build，每一个项目组都会定义一些自己的标准，这些标准需要设定一个严格的质量级别来处理那些特别严重的缺陷，同时也需要具有一定的伸缩性来忽略掉那些微不足道的缺陷，一些不适当的关心也许会使整个过程举步为艰。

一个好的build起码应该具备以下条件：

●能够成功编译所有的文件、库，以及其它相关组件；

●能够成功链接所有的文件、库，以及其它相关组件；

●不能存在任何使得系统无法运行或者运行出错的高级别故障；

●当然，必须通过冒烟测试

3、每天进行冒烟测试

冒烟测试应该是对整个系统流程从输入到输出的完整测试。测试不必是面面俱到的，但是应该能够发现系统中较大的问题。冒烟测试应该是足够充分的，通过了冒烟测试的build就可以认为是经过充分测试、足够稳定的。

不进行冒烟测试的build是没有太大价值的。冒烟测试就像一个哨兵，在阻止着产品质量恶化和集成问题的产生，不进行冒烟测试，每日构造可能会变成浪费时间的练习。

冒烟测试必须随着系统的扩充而扩充。最初，冒烟测试可能是非常简单的，比如验证系统是否会打印“Hello World”，随着系统功能的扩充，冒烟测试需要越来越充分。最初的冒烟测试也许只需要几秒钟来执行，逐渐地，测试可能会花费30分钟，1小时，甚至更长。

4、建立一个专门的build小组

    在很多项目组，维护每日构造，并更新冒烟测试用例，会耗费一个人工作的大部分时间。因此在一些大的项目中，这项工作独立成不止一个人来完成的全职工作。比 如在 Windows NT 3.0的研发中，就有一个由四个全职人员组成的专门的build小组(Pascal Zachary, Showstopper!, The Free Press, 1994)。

5、为build增加修订，如果这样做有意义的话

    一般开发人员不会每天都经常向系统中快速的增加实际的代码，通常是每隔几天，他们在开发好完成某个功能的一套代码以后，然后集成到整个系统中。

6、规定一些导致build失败的惩罚措施

很多执行每日构造的项目组都会规定一些惩罚措施，来惩罚那些导致build失败的行为。从最开始，项目组成员就清楚的知道，build的正常执行是 项目组的头等大事。一个失败的build是项目组的意外，无法成为项目组工作的准则。必须坚持：导致build失败的同事，必须停下手中的工作，首先来解 决build失败的问题。如果一个项目组的build经常失败的话，久而久之的，再来谈build的正确性就没有意义了。

有种轻松的惩罚措施，能够突出解决问题的优先性。Some groups give out lollipops to each "sucker" who breaks the build. This developer then has to tape the sucker to his office door until he fixes the problem. 有些项目组会惩罚犯错的同事戴上山羊角，或者向一个项目基金捐献5块钱。

有些项目组对此的惩罚就有点残酷了。微软的开发人员，在一些知名度很高、很重要的产品如Windows NT，Windows 95，Excel等产品后期研发中，被要求随时带着寻呼机，如果你的代码导致build失败的话，即使是凌晨3点钟，也会要求你立即来处理这个问题。

7、即使在压力下也需坚持每日构造和冒烟测试

当项目进度的压力越来越大时，维护每日构造的工作看起来有些浪费时间，但是恰恰相反。在压力之下，开发人员丢掉一些平时的规定，会采用一些设计和实 现的捷径，这在平时压力较小的环境下一般时不会用的。代码的review和单元测试也可能会比平时粗心一些，这些代码的状态变化也会比平时快很多。

为防止这种情况的出现，每日构造会坚持相关的规定，让压力下的项目保持在正轨上。代码仍然每天在不断变化，但是构造过程使得这种变化每天都可控。

谁能够从每日构造这种过程中得到好处呢？一些开发人员会抗议说，由于他们的项目太大，每天进行build是没有实际意义的。但是为什么现在最复杂的 软件项目组却能够成功的执行每日构造的制度呢？本文首发时，Windows NT包括了560万行代码、分布在4万个源程序文件中，项目组仍然可以坚持每日构造。

–         在数字框中是否能输入文本？

–         是否允许通配符？

–         是否可以为空？

–         输入长度限制是否合理?

>         例如：身份证框限制为15字符，不合理

–         复选框和单选按钮的默认值是否正确?

–         是否只有一个单选框能被选中?

–         复选框是否出发了预期的事件

页面 Check List

–         当页面出现较长列表时，是否有滚动条？

–         调整控件或框架的大小，是否对页面造成非预期的影响？

–         当用户选中了页面中的一个复选框，之后回退一个页面，再前进一个页面，复选框是否还处于选中状态？

–         如果浏览器调整大小，页面是否还能完全显示？

–         刷新后界面是否正常显示？

–         控件在特定情况下是否被设置成disable状态？

导航 Check List

–         导航是否直观

–         Web系统的主要部分是否可通过主页存取

–         Web系统是否有站点地图、搜索引擎或其它的导航帮助

对于屏幕显示来说包括：
检查显示的布局；
检查域和按钮的顺序；
检查域的尺寸；
检查字体的大小和风格；
检查文本的含义；
检查拼写错误；
检查屏蔽域；
检查只读域；
检查图片；
检查按钮的状态；
检查按钮的尺寸；
检查按钮的图标和名字；
检查是否有重复的图标；
检查指针是否在第一个可输入域；
检查TAB键的次序；

对于域来说包括：
检查可编辑性；
检查域间的移动；
检查分界条件；
检查有效分界符；
检查无效分界符；
检查连续多个有效分界符；
检查仅一个分界符输入；
检查多余空格的截取；
检查只读域和屏蔽域在TAB时的状态；

对于数字域来说包括：
检查正数值；
检查负数值；
检查零值；
检查小数点；
检查特殊字符加数字；
检查字母加数字；
检查ASCII值；
检查重复值；
检查空值；


对于字符域来说包括：
检查仅有字母；
检查仅有数字；
检查字母数字；
检查允许的特殊字符；
检查禁止的特殊字符；
检查包含特殊字符的字母数字；
检查ASCII值；

对于字母域来说包括：
检查字母；
检查数字值；
检查字母数字值；
检查特殊字符；
检查ASCII值；

对于时间域来说包括：
检查字符?和/；
检查其它特殊字符；
检查字母数字值；
检查正确的格式；
检查错误的格式；
检查错误的日期数字；
检查正确的日期数字；
检查日历表；

对于错误信息和警告信息来说：
检查错误信息和警告信息的含义；
检查错误信息和警告信息的一致性；
检查确定位置的错误信息；
检查错误信息后的光标位置；
检查所有异常对应的错误信息；
检查错误信息的格式；

对于普通的检查来说：
检查文本域和字符域输入是否左对齐；
检查数字域输入是否右对齐；
检查标签的切换；
检查重复的名字；
检查可删除的表格；
检查表格的多选；
检查过滤器的逻辑性；
检查多个过滤器的逻辑性；
检查重复的序列号；
检查显示切换；
检查快捷键；
检查工具栏提示；
检查日期域是否居中；
检查选择项的高显；
检查选择符；
检查显示窗口的风格统一性；


对于按键的功能包括：
New button：
检查包含next和cancel按键的子窗口的显示；
检查子窗口显示的内容；
Add button：
检查包含save和cancel按键的子窗口的显示；
Edit button：
检查在未选择项目情况下点击后的警告信息；
检查包update和cancel按键的子窗口的显示；
检查选择的项目是否显示在制定的位置；
Copy button：
检查在未选择项目情况下点击后的警告信息；
检查点击后的确认信息；
检查插入后的复制数据；
Delete button：
检查在未选择项目情况下点击后的警告信息；
检查点击后的确认信息；
检查删除后的数据；
Run button：
检测运行时的参数窗口；
检查执行结果；
检查未选择项目情况下点击后的警告信息；
Back button：
检查是否回到上一屏幕；
Next button：
检查是否显示下一屏幕；
Finish button：
检查数据是否进入数据库；
检查完成屏幕的显示；
Cancel button：
检查确认信息；
检查是否有其它键执行同样功能；
检测是否能能够正确处理；

总之，这个问题就这样一直留下来了。中间也有人想改过，你要注意看 Excel 的 Options 设臵，就会发现有这样一个设臵——使用1904年开始的日期计算系统 （use 1904 date system）（如图7-1所示），但是一般的用户谁没事在这里打一个勾？

（点击查看大图）图7-1

　　1、登陆　　2、添加　　3、查询　　4、删除

　　1、登陆

　　①        用户名和密码都符合要求（格式上的要求）

　　②        用户名和密码都不符合要求（格式上的要求）

　　③        用户名符合要求，密码不符合要求（格式上的要求）

　　④        密码符合要求，用户名不符合要求（格式上的要求）

　　⑤        用户名或密码为空

　　⑥        数据库中不存在的用户名，不存在的密码

　　⑦        数据库中存在的用户名，错误的密码

　　⑧        数据库中不存在的用户名，存在的密码

　　⑨        输入的数据前存在空格

　　⑩        输入正确的用户名密码以后按[enter]是否能登陆

　　2、添加

　　①        要添加的数据项均合理，检查数据库中是否添加了相应的数据

　　②        留出一个必填数据为空

　　③        按照边界值等价类设计测试用例的原则设计其他输入项的测试用例

　　④        不符合要求的地方要有错误提示

　　⑤        是否支持table键

　　⑥        按enter是否能保存

　　⑦        若提示不能保存，也要察看数据库里是否多了一条数据

　　3、删除

　　①        删除一个数据库中存在的数据，然后查看数据库中是否删除

　　②        删除一个数据库中并不存在的数据，看书否有错误提示，并且数据库中没有数据被删除

　　③        输入一个格式错误的数据，看是否有错误提示，并且数据库中没有数据被删除。

　　④        输入的正确数据前加空格，看是否能正确删除数据

　　⑤        什么也不输入

　　⑥        是否指出table键

　　⑦        是否支持enter键

　　4、查询

　　精确查询：

　　①        输入的查询条件为数据库中存在的数据，看是否能正确地查出相应得数据

　　②        输入正确的查询条件以前加上空格，看是否能正确地查出相应的数据

　　③        输入格式或范围不符合要求的数据，看是否有错误提示

　　④        输入数据库中不存在的数据

　　⑤        不输入任何数据

　　⑥        是否支持table键

　　⑦        是否支持enter键

　　模糊查询：

　　在精确查询的基础上加上以下一点：

　　①        输入一些字符，看是否能查出数据库中所有的相关信息
用户注册和密码修改测试点

　　一．用户注册

　　只从用户名和密码角度写了几个要考虑的测试点，如果需求中明确规定了安全问题，Email，出生日期，地址，性别等等一系列的格式和字符要求，那就都要写用例测了~

　　以等价类划分和边界值法来分析

　　1、填写符合要求的数据注册： 用户名字和密码都为最大长度 （边界值分析，取上点）

　　2、填写符合要求的数据注册 ：用户名字和密码都为最小长度 （边界值分析，取上点）

　　3、填写符合要求的数据注册：用户名字和密码都是非最大和最小长度的数据（边界值分析，取内点）

　　4、必填项分别为空注册

　　5、用户名长度大于要求注册1位（边界值分析，取离点）

　　6、用户名长度小于要求注册1位（边界值分析，取离点）

　　7、密码长度大于要求注册1位（边界值分析，取离点）

　　8、密码长度小于要求注册1位（边界值分析，取离点）

　　9、用户名是不符合要求的字符注册（这个可以划分几个无效的等价类，一般写一两个就行了，如含有空格，#等，看需求是否允许吧~）

　　10、密码是不符合要求的字符注册（这个可以划分几个无效的等价类，一般写一两个就行了）

　　11、两次输入密码不一致（如果注册时候要输入两次密码，那么这个是必须的）

　　12、重新注册存在的用户

　　13、改变存在的用户的用户名和密码的大小写，来注册。（有的需求是区分大小写，有的不区分）

　　14、看是否支持tap和enter键等；密码是否可以复制粘贴；密码是否以* 之类的加秘符号显示

　　二．修改密码

　　当然具体情况具体分析哈~不能一概而论~

　　实际测试中可能只用到其中几条而已，比如银行卡密码的修改，就不用考虑英文和非法字符，更不用考虑那些ＴＡＰ之类的快捷键．

　　而有的需要根据需求具体分析了，比如连续出错多少次出现的提示，和一些软件修改密码要求一定时间内有一定的修改次数限制等等。

　　1、不输入旧密码，直接改密码

　　2、输入错误旧密码

　　3、不输入确认新密码

　　4、不输入新密码

　　5、新密码和确认新密码不一致

　　6、新密码中有空格

　　7、新密码为空

　　8、新密码为符合要求的最多字符

　　9、新密码为符合要求的最少字符

　　10、新密码为符合要求的非最多和最少字符

　　11、新密码为最多字符-1

　　12、新密码为最少字符+1

　　13、新密码为最多字符+1

　　14、新密码为最少字符-1

　　15、新密码为非允许字符（如有的密码要求必须是英文和数字组成，那么要试汉字和符号等）

　　16、看是否支持tap和enter键等；密码是否可以复制粘贴；密码是否以* 之类的加秘符号

　　17、看密码是否区分大小写，新密码中英文小写，确认密码中英文大写．

　　18、新密码与旧密码一样能否修改成功．

　　有个朋友问我，注册的时候测试了密码长度，修改的时候为什么还要测试。

　　我在这里举个我亲身经历的例子，以前我玩一个游戏，叫恋爱盒子，在游戏里我把密码改成了xuewufengtian，后来怎么也上不去了。因为资料填写不全无法找回密码。后来我在一次注册过程中发现，注册的时候密码长度最长是10位，这时我灵机一动，用了原来的用户名和xuewufengt的密码就进去了。 这表明，修改密码时候的最大长度和注册及登陆的时候密码最大长度有可能是不一致的。

　　Report Bug时，描述有效的Description的关键点：

　　Condense－精简，清晰而简短；

　　Accurate－准确，确定是Bug；

　　Neutralize－用中性的语言描述事实，不带偏见，不用幽默或者情绪化的语言；

　　Precise－精确；

　　Isolate－定位，尽量缩小这个问题的范围；

　　Generalize－还有没有其他的某些地方存在这样的问题；

　　Re-Create－如何引发和重现这个Bug？（环境，步骤，前提条件）

　　Impact－影响，这个缺陷对客户的影响以及对测试的影响；

　　DeBug－怎么做才可以让开发更容易来修改这个Bug？（跟踪，截图，日志，直接访问等等）

　　Evidence－证据。

　　Condense－精简，清晰而简短

　　首先，去掉不必要的词；

　　其次，不要添加无关的信息。

　　包含相应的信息是最重要的，但是确保这些信息都是有用的。对于那些没有描述清楚如何重现或者难以理解的问题，都应该提供更多的信息。但也要避免写过多的不必要的信息。

　　Accurate－准确，确定是Bug

　　确信是一个Bug，避免因为其他原因，导致错误的Report Bug，需要考虑：

• 是否会因为安装的某个原因导致这个问题？例如，是否安装了正确的版本而且各种先决条件也已经满足？是否登陆，安全设定，命令或者操作的顺序有错误？
• 是否存在清除不干净，或者结果不完整，或者因为上次测试的某些更改导致？
• 是否是网络或者环境的问题？
• 是否理解了期望的结果？
• 中性的语言
• 客观的描述Bug，不要使用幽默的或者其他带有感情色彩的语句。在提交Bug之前，仔细阅读Bug的描述，删除或者修改可能让人产生歧义的句子。

　　Precise－精确

　　当Bug的描述很长时，例如：“我按了回车键，然后现象A出现，接着按了后退键，现象B出现，接着输入命令‘XYZ’，现象C出现”，看到这样的说明，很难明白到底想说明什么问题，三个现象中哪一个是错误的。清晰准确并且客观的描述Bug，而不是简单说明发生了什么。

　　Isolate－定位，尽量缩小这个问题的范围

　　定位发现的问题。在试图隔离一个问题的时候，需要考虑下面的几点：

• 尝试找到最短，最简单的步骤来重现这个问题。
• 查看是否是外部的什么特殊的原因引起的这个问题？例如，系统挂起或延时，会不会是因为网络的问题？
• 对于一个存在多种输入条件的项目，尝试不断的改变输入值，并查看结果，直到确定哪个值导致的错误。
• 在问题描述中，在尽可能的范围内，精确描述所使用的测试输入值。例如，如果在测试中发现打印一份脚本的时候会出错，首先判断是不是打印所有的这种类型的脚本都会出错。

　归纳

　　Report Bug时，采用合理的步骤来确定这个问题是通常会发生还是偶然一次出现或者是在特殊条件才出现。

　　重现

　　如果测试时，可以重现Bug，那么，应该准确的解释重现Bug所必需的条件。列出所有的步骤，包括精确的组合，文件名以及碰到或者重现这个问题的操作顺序。如果确认这个问题在任何文件，任何的操作顺序等条件下都会发生，那也最好能够给出一个明确的示例用来帮助开发来重现。

　　如果测试时，不能重现Bug，那就提供尽可能多的有效的信息。在开发没有重现或者开发没有解决之前，不要清除相应的测试数据，或者至少要备份这些数据。

　　影响

　　发布产品时，需要判断未解决的影响问题。例如，在某一个窗口发现一个排版错误或者拼写错误，这类Bug对测试人员来说可能是微不足道的，但对于客户来说，这是接触产品的第一件事，所以必须在给客户实施前修改好。

　　调试

　　如果需要，在Report时，提供跟踪、截图、日志等对捕获这个Bug有帮助的信息。

　　证据

　　提供Report的是一个Bug的证据信息，这些信息可能包括操作指导，文档，必备条件等等，还有可能是客户以前反馈过来的零碎的信息，或者是竞争对手的软件中的一些标准，又或者来源于以往版本中的结果。

　　2.Bug的标题

　　Bug的标题在很多情况下是一个有力的和项目组成员之间的沟通工具，在很多情形下，PM，Team Leader等只是查看Bug的标题。

• 简单，明确的说明问题（不能只是说出现问题）
• 建议（如果长度允许的话）：
• 使用有意义的单词；
• 描述环境和影响；
• 回答5W1H的问题（why，when，who，where，what，how）；
• 使用简写，例如挂起，异常中止，拼写错误等
• 相对于描述清楚而言，语法不是很重要
• 例如：下面的标题就没有提供足够多的信息。

　　例一：Summary：在保存和恢复数据成员时出错。

　　例二：Summary：一个比较好的标题可能是这样：在WINNT环境下，XYZ的保存和恢复数据失败，数据丢失。

　　3. 其它注意事项

　　使用Bugzilla，报Bug时，需要注意以下事项：

　　第一，应先确认Bugzilla上已经建立了相应当前的版本；

　　第二，在报Bug时，需要选择，Show Advanced Fields，这样才会罗列出详细的信息，如要CC的人，QA Contact等等；

　　第三，Attachment，保存和发送的图片格式一般为JPG格式，OS操作系统也要选择好。

　　Bugzilla上，有7个严重程度等级。

　　具体定义如下，This field describes the impact of a Bug.

1. blocker    Blocks development and/or Testing work
2. critical    crashes， loss of data， severe memory leak
3. major    major loss of function
4. normal    regular issue， some loss of functionality under specific circumstances
5. minor    minor loss of function， or other problem where easy workaround is present
6. trivial    cosmetic problem like misspelled words or misaligned text
7. enhancement    Request for enhancement

　　第四，在报告Bug时，除了在描述中说明Bug的复现步骤外，还要在Description中，添加该Bug的测试发生率。测试发生率为按照特定步骤执行多次的Bug重现率。测试发生率=ug重现次数/按照特定步骤执行的总次数。其中：对于概率性问题，执行的总次数应根据Bug的复杂程度执行（20-50次）。这样对于再现Bug，定位问题等都有帮助。

　　例如，当测试前已经获知在线人数为10000，可以设定性能测试的目的是检测软件典型交易的平均响应时间是否符合小于5秒的指标值。

　　例如，当测试前不知道在线人数是多少，但是已经获知该软件在一定的时间周期内（t）必须处理N笔交易，可以设定性能测试的目的是检测软件典型交易的吞吐量是否符合大于25笔交易/秒的指标值。

　　但是，在第二种情况出现时，还应该考虑若软件的吞吐量符合指定的指标值时，软件典型交易的平均响应时间是否符合小于5秒的指标值。

　　为什么呢？

　　我们可以利用“门”的概念来理解这里面的偏差！

　　首先，我们假设如下的情况：

　　共有5个人；

　　有1扇门；

　　一个人通过这扇门需要花费1秒的时间；

　　此时，这扇门的吞吐量为1人/秒。5个人通过这扇门的平均响应时间为（1+2+3+4+5）/5=3秒。

　　如何才能提高人的通过效率呢？即，如何才能提高门的吞吐量呢？

　　有两种方法：

　　（1）减小通过门的时间；

　　（2）增加门的数量

　　例如，

　　（1）将一个人通过门的时间减小为0.5秒，门的吞吐量变成了2人/秒；

　　（2）增加一个门，门的吞吐量也变成了2人/秒

　　结果是：

　　（1）5个人通过改善通过时间的门的平均响应时间为（0.5+1+1.5+2+2.5）/5＝1.5秒；

　　（2）5个人通过两扇门的平均响应时间为（1+1+2+2+3）/5＝1.8秒

　　此时，你可以发现，软件开发员改进软件处理并发交易请求的方法有两个，第一种是提高单个请求的处理速率，第二种是增加处理请求的线程的数量；或 者是两种方法的组合。但是，不同方法的使用并不代表吞吐量得到了提高，而同时软件典型交易的平均响应时间也获得了相同值的改善。

　　因此，在性能测试以吞吐量为检测指标的时候，不光要评估吞吐量是否符合了性能指标的要求，同时也必须考虑响应时间是否符合性能指标的要求。

　　假设，在测试前，规定了吞吐量为大于25笔交易/秒，平均响应时间为小于5秒，在测试后，若实际吞吐量等于27笔交易/秒，不能仅凭这个27笔交易/秒就确定该软件的性能符合要求了，还要看平均响应时间是否符合要求。这时的平均响应时间可能大于5秒。

有一个农夫决定买一匹骡子，他认为这个骡子至少得能扛动3袋大米，他才会决定买这匹骡子（这相当于用户提出的性能需求）。结果他来到农贸集市上，试了好几头骡子，都不合适，最后终于有一头骡子能够比较轻松的扛动这3袋大米，而且还潇洒的走了几步（这相当于于性能测试通过）。然后农夫高高兴兴地牵着这头骡子回家，而且给它扛了4袋大米（相当于让系统超负荷运行），因为他跑了太远才买到了这匹不可多得的骡子，他想看看它到底能有多强，所以农夫决定，让这匹骡子就扛着这四袋大米走回家试试看，这匹骡子真的很厉害，刚开始的时候还一颠一跑的，可是后来实在路太远了，骡子越驮越费劲（在超负荷情况下检验系统能正常运行多久，这相当于压力测试）， 快到家的时候，已经是走两步歇一步了。终于到家了，农夫非常自豪地叫出自己的老婆，说：“老婆子，快来看看，看我买到了一头多么厉害的骡子啊！”，老婆出 来后，农夫把他和骡子在一路上的经历都告诉了老太婆，谁知这个老太婆却说：“你真蠢，这么大老远的路，也不让骡子驮着你，竟然和这头傻骡子一样走回 来！”，农夫听了，觉得非常后悔，说：“那好吧，既然在路上它没有驮我，那就让它现在补上，也算是对我的补偿。”，骡子还没有反应过来，就看那老农夫一个 箭步，跳到了骡子背上（这相当于容量测试的极限点），可怜的骡子，无论如何也不会想到，这狠心的农夫竟然在它走了这么久之后，不但没有帮它卸掉身上的重担，更没有给它喝口水，竟然变本加厉的跳到了它那本已弯曲的背上。可怜的骡子啊，就这么一命呜乎了！就看见那个骡子、农夫和4袋麦子一起轰然倒地。（相当于已经到了系统的最大拐点，造成了系统瘫痪，无法使用，容量测试结束）。

　　1) 在任何情况下都必须使用边界值分析方法，经验表明用这种方法设计出测试用例发现程序错误的能力最强。

　　2) 必要时用等价类划分方法补充一些测试用例。

　　3) 用错误推测法再追加一些测试用例。

　　4) 对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，如果没有达到要求的覆盖标准，应当再补充足够的测试用例。

　　5) 如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法。

　　2.测试用例的设计步骤

　　1) 构造根据设计规格得出的基本功能测试用例；

　　2) 边界值测试用例；

　　3) 状态转换测试用例；

　　4) 错误猜测测试用例；

　　5) 异常测试用例；

　　6) 性能测试用例；

　　7) 压力测试用例。

　　3.优化测试用例的方法

　　1) 利用设计测试用例的8种方法不断的对测试用例进行分解与合并；

　　2) 采用遗传算法理论进化测试用例；

　　3) 在测试时利用发散思维构造测试用例

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

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

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

　　2.测试用例基本概念

　　2.1.测试用例的定义

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

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

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

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

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

　　1.用例ID；

　　2.用例名称；

　　3.测试目的；

　　4.测试级别；

　　5.参考信息；

　　6.测试环境；

　　7.前提条件；

　　8.测试步骤；

　　9.预期结果；

　　10.设计人员。

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

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

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

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

　　1、功能图

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

　　2、测试用例生成方法

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

　　3、测试用例生成规则

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

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

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

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

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

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

　　二、实战演习

　　暂无

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

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

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

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

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

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

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

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

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

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

　　二、 实战演习

　　暂无

　　1) 边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。

　　2) 边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试情况。

　　3. 边界值分析方法的考虑：

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

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

　　4. 常见的边界值

　　1) 对16-bit 的整数而言 32767 和 -32768 是边界

　　2) 屏幕上光标在最左上、最右下位置

　　3) 报表的第一行和最后一行

　　4) 数组元素的第一个和最后一个

　　5) 循环的第 0 次、第 1 次和倒数第 2 次、最后一次

　　5. 边界值分析

　　1) 边界值分析使用与等价类划分法相同的划分，只是边界值分析假定错误更多地存在于划分的边界上，因此在等价类的边界上以及两侧的情况设计测试用例。

　　例：测试计算平方根的函数

　　--输入：实数

　　--输出：实数

　　--规格说明：当输入一个0或比0大的数的时候，返回其正平方根；当输入一个小于0的数时，显示错误信息"平方根非法-输入值小于0"并返回0；库函数Print-Line可以用来输出错误信息。

　　2) 等价类划分：

　　I.可以考虑作出如下划分：

　　a、输入 (i)<0 和 (ii)>=0

　　b、输出 (a)>=0 和 (b) Error

　　II.测试用例有两个：

　　a、输入4，输出2。对应于 (ii) 和 (a) 。

　　b、输入-10，输出0和错误提示。对应于 (i) 和 (b) 。

　　3) 边界值分析：

　　划分(ii)的边界为0和最大正实数；划分(i)的边界为最小负实数和0。由此得到以下测试用例：

　　a、输入 {最小负实数}

　　b、输入 {绝对值很小的负数}

　　c、输入 0

　　d、输入 {绝对值很小的正数}

　　e、输入 {最大正实数}

　　5) 相应地，以上类型的边界值应该在：最大/最小、首位/末位、上/下、最快/最慢、最高/最低、 最短/最长、 空/满等情况下。

　　6) 利用边界值作为测试数据

项	边界值	测试用例的设计思路
字符	起始-1个字符/结束+1个字符	假设一个文本输入区域允许输入1个到255个 字符，输入1个和255个字符作为有效等价类；输入0个和256个字符作为无效等价类，这几个数值都属于边界条件值。
数值	最小值-1/最大值+1	假设某软件的数据输入域要求输入5位的数据值，可以使用10000作为最小值、99999作为最大值；然后使用刚好小于5位和大于5位的 数值来作为边界条件。
空间	小于空余空间一点/大于满空间一点	例如在用U盘存储数据时，使用比剩余磁盘空间大一点（几KB）的文件作为边界条件。

　　在多数情况下，边界值条件是基于应用程序的功能设计而需要考虑的因素，可以从软件的规格说明或常识中得到，也是最终用户可以很容易发现问题的。然而，在测试用例设计过程中，某些边界值条件是不需要呈现给用户的，或者说用户是很难注意到的，但同时确实属于检验范畴内的边界条件，称为内部边界值条件或子边界值条件。

　　内部边界值条件主要有下面几种：

　　a) 数值的边界值检验：计算机是基于二进制进行工作的，因此，软件的任何数值运算都有一定的范围限制。

　　 b) 字符的边界值检验：在计算机软件中，字符也是很重要的表示元素，其中ASCII和Unicode是常见的编码方式。下表中列出了一些常用字符对应的ASCII码值。

　　6. 基于边界值分析方法选择测试用例的原则

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

　　例如，如果程序的规格说明中规定："重量在10公斤至50公斤范围内的邮件，其邮费计算公式为……"。作为测试用例，我们应取10及50，还应取10.01,49.99,9.99及50.01等。

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

　　3) 将规则1）和2）应用于输出条件，即设计测试用例使输出值达到边界值及其左右的值。

　　例如，某程序的规格说明要求计算出"每月保险金扣除额为0至1165.25元"，其测试用例可取0.00及1165.24、还可取一0.01及1165．26等。

　　再如一程序属于情报检索系统，要求每次"最少显示1条、最多显示4条情报摘要"，这时我们应考虑的测试用例包括1和4，还应包括0和5等。

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

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

　　6) 分析规格说明,找出其它可能的边界条件。

　　二.实战演习

　　1.现有一个学生标准化考试批阅试卷,产生成绩报告的程序。其规格说明如下:程序的输入文件由一些有80个字符的记录组成,如右图所示，所有记录分为3组：

　　② 试卷各题标准答案记录：每个记录均在第80个字符处标以数字"2"。该组的第一个记录的第1至第3个字符为题目编号（取值为1一999）。第10至第59个字符给出第1至第50题的答案（每个合法字符表示一个答案）。该组的第2，第3……个记录相应为第51至第100，第101至第150，…题的答案。

　　③ 每个学生的答卷描述：该组中每个记录的第80个字符均为数字"3"。每个学生的答卷在若干个记录中给出。如甲的首记录第1至第9字符给出学生姓名及学号，第10至第59字符列出的是甲所做的第1至第50题的答案。若试题数超过50，则第2，第3……纪录分别给出他的第51至第100，第101至第150……题的解答。然后是学生乙的答卷记录。

　　④ 学生人数不超过200，试题数不超过999。

　　⑤ 程序的输出有4个报告：

　　a) 按学号排列的成绩单，列出每个学生的成绩、名次。

　　b) 按学生成绩排序的成绩单。

　　c) 平均分数及标准偏差的报告。

　　d) 试题分析报告。按试题号排序，列出各题学生答对的百分比。

　　解答：分别考虑输入条件和输出条件，以及边界条件。给出下表所示的输入条件及相应的测试用例。

　　输出条件及相应的测试用例表。

　　2.三角形问题的边界值分析测试用例

　　在三角形问题描述中，除了要求边长是整数外，没有给出其它的限制条件。在此，我们将三角形每边边长的取范围值设值为[1, 100] 。

　　

测试用例	a	b	c	预期输出
Test1 Test2 Test3 Test4 Test5	60 60 60 50 50	60 60 60 50 50	1 2 60 99 100	等腰三角形 等腰三角形 等边三角形 等腰三角形 非三角形
Test6 Test7 Test8 Test9	60 60 50 50	1 2 99 100	60 60 50 50	等腰三角形 等腰三角形 等腰三角形 非三角形
Test10 Test11 Test12 Test13	1 2 99 100	60 60 50 50	60 60 50 50	等腰三角形 等腰三角形 等腰三角形 非三角形

　　3.NextDate函数的边界值分析测试用例

　　在NextDate函数中，隐含规定了变量mouth和变量day的取值范围为1≤mouth≤12和1≤day≤31，并设定变量year的取值范围为1912≤year≤2050 。

测试用例	mouth	day	year	预期输出
Test1 Test2 Test3 Test4 Test5 Test6 Test7	6 6 6 6 6 6 6	15 15 15 15 15 15 15	1911 1912 1913 1975 2049 2050 2051	1911.6.16 1912.6.16 1913.6.16 1975.6.16 2049.6.16 2050.6.16 2051.6.16
Test8 Test9 Test10 Test11 Test12 Test13	6 6 6 6 6 6	-1 1 2 30 31 32	2001 2001 2001 2001 2001 2001	day超出[1…31] 2001.6.2 2001.6.3 2001.7.1 输入日期超界 day超出[1…31]
Test14 Test15 Test16 Test17 Test18 Test19	-1 1 2 11 12 13	15 15 15 15 15 15	2001 2001 2001 2001 2001 2001	Mouth超出[1…12] 2001.1.16 2001.2.16 2001.11.16 2001.12.16 Mouth超出[1…12]

　　1.定义

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

　　2.划分等价类：

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

　　1)有效等价类

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

　　2)无效等价类

　　与有效等价类的定义恰巧相反。无效等价类指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。对于具体的问题，无效等价类至少应有一个，也可能有多个。

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

　　3.划分等价类的标准：

　　1)完备测试、避免冗余;

　　2)划分等价类重要的是：集合的划分，划分为互不相交的一组子集，而子集的并是整个集合;

　　3)并是整个集合：完备性;

　　4)子集互不相交：保证一种形式的无冗余性;

　　5)同一类中标识（选择）一个测试用例，同一等价类中，往往处理相同，相同处理映射到"相同的执行路径"。

　　4.划分等价类的方法

　　1)在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类。如：输入值是学生成绩，范围是0～100；

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

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

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

　　例：输入条件说明学历可为:专科、本科、硕士、博士四种之一，则分别取这四种这四个值作为四个有效等价类，另外把四种学历之外的任何学历作为无效等价类。

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

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

　　5.设计测试用例

　　在确立了等价类后,可建立等价类表,列出所有划分出的等价类输入条件：有效等价类、无效等价类，然后从划分出的等价类中按以下三个原则设计测试用例：

　　1)为每一个等价类规定一个唯一的编号；

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

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

　　1.某程序规定："输入三个整数 a 、 b 、 c 分别作为三边的边长构成三角形。通过程序判定所构成的三角形的类型，当此三角形为一般三角形、等腰三角形及等边三角形时，分别作计算 … "。用等价类划分方法为该程序进行测试用例设计。（三角形问题的复杂之处在于输入与输出之间的关系比较复杂。）

　　分析题目中给出和隐含的对输入条件的要求：

　　（1）整数 （2）三个数 （3）非零数 （4）正数

　　（5）两边之和大于第三边 （6）等腰 （7）等边

　　如果 a 、 b 、 c 满足条件（ 1 ） ~ （ 4 ），则输出下列四种情况之一：

　　1)如果不满足条件（5），则程序输出为 " 非三角形 " 。

　　2)如果三条边相等即满足条件（7），则程序输出为 " 等边三角形 " 。

　　3)如果只有两条边相等、即满足条件（6），则程序输出为 " 等腰三角形 " 。

　　4)如果三条边都不相等，则程序输出为 " 一般三角形 " 。

　　列出等价类表并编号

　　 覆盖有效等价类的测试用例：

　　a b c 覆盖等价类号码

　　3 4 5 （1）--（7）

　　4 4 5 （1）--（7），（8）

　　4 5 5 （1）--（7），（9）

　　5 4 5 （1）--（7），（10）

　　4 4 4 （1）--（7），（11）

　　覆盖无效等价类的测试用例：

　　1)划分等价类并编号,下表等价类划分的结果

输入等价类	有效等价类	无效等价类
日期的类型及长度	①6位数字字符	②有非数字字符 ③少于6位数字字符 ④多于6位数字字符
年份范围	⑤在1990~2049之间	⑥小于1990 ⑦大于2049
月份范围	⑧在01~12之间	⑨等于00 ⑩大于12

　　2)设计测试用例，以便覆盖所有的有效等价类在表中列出了3个有效等价类，编号分别为①、⑤、⑧，设计的测试用例如下：

　　测试数据 期望结果 覆盖的有效等价类

200211 输入有效 ①、⑤、⑧

　　3)为每一个无效等价类设计一个测试用例，设计结果如下：

　　测试数据 期望结果 覆盖的无效等价类

95June 无效输入 ② 20036 无效输入③ 2001006无效输入 ④ 198912 无效输入 ⑥ 200401 无效输入 ⑦ 200100 无效输入 ⑨ 200113 无效输入 ⑩

　　3.NextDate 函数包含三个变量：month 、 day 和 year ，函数的输出为输入日期后一天的日期。 例如，输入为 2006年3月 7日，则函数的输出为 2006年3月8日 。要求输入变量 month 、 day 和 year 均为整数值，并且满足下列条件：

①1≤month≤12 ②1≤day≤31 ③1920≤year≤2050

　　1)有效等价类为：

　　

M1＝{月份：1≤月份≤12} D1＝{日期：1≤日期≤31} Y1＝{年：1812≤年≤2012}

　　2)若条件 ① ~ ③中任何一个条件失效，则 NextDate 函数都会产生一个输出，指明相应的变量超出取值范围，比如 "month 的值不在 1-12 范围当中 " 。显然还存在着大量的 year 、 month 、 day 的无效组合， NextDate 函数将这些组合作统一的输出： " 无效输入日期 " 。其无效等价类为：

M2＝{月份：月份<1} M3＝{月份：月份>12} D2＝{日期：日期<1} D3＝{日期：日期>31} Y2＝{年：年<1812} Y3＝{年：年>2012} 弱一般等价类测试用例 月份 日期 年 预期输出 6 15 1912 1912年6月16日

　　强一般等价类测试用例同弱一般等价类测试用例

　　注：弱--有单缺陷假设；健壮--考虑了无效值

　　(一)弱健壮等价类测

　　

用例ID 月份 日期 年 预期输出 WR1 6 15 1912 1912年6月16日 WR2 -1 15 1912 月份不在1～12中 WR3 13 15 1912 月份不在1～12中 WR4 6 -1 1912 日期不在1～31中 WR5 6 32 1912 日期不在1～31中 WR6 6 15 1811 年份不在1812～2012中 WR7 6 15 2013 年份不在1812～2012中

　　(二)强健壮等价类测试

　　

用例ID 月份 日期 年 预期输出 SR1 -1 15 1912 月份不在1～12中 SR2 6 -1 1912 日期不在1～31中 SR3 6 15 1811 年份不在1812～2012中 SR4 -1 -11912 两个无效一个有效 SR5 6 -1 1811 两个无效一个有效 SR6 -1 15 1811 两个无效一个有效 SR7 -1 -11811 三个无效

　　4.佣金问题等价类测试用例，它是根据佣金函数的输出值域定义等价类，来改进测试用例集合。

输出销售额≤1000元 佣金10％ 　　1000<销售额≤1800 佣金=100+(销售额-1000)*15% 　　销售额>1800 佣金=220+(销售额-1800)*20% 　　测试用例 枪机(45) 枪托(30) 枪管(25) 销售额 佣金

　　

1 5 5 5 500 50 2 15 15 15 1500 175 3 25 25 25 2500 360

　　根据输出域选择输入值，使落在输出域等价类内，可以结合弱健壮测试用例结合。

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

　　2. 错误推测方法的基本思想：

　　列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。

　　1) 例如, 输入数据和输出数据为0的情况；输入表格为空格或输入表格只有一行。 这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例。

　　2) 例如，前面例子中成绩报告的程序，采用错误推测法还可补充设计一些测试用例：

　　I.程序是否把空格作为回答

　　II. 在回答记录中混有标准答案记录

　　III.除了标题记录外，还有一些的记录最后一个字符即不是2也不是3

　　IV.有两个学生的学号相同

　　V. 试题数是负数。

　　3) 再如，测试一个对线性表（比如数组）进行排序的程序，可推测列出以下几项需要特别测试的情况：

　　I.输入的线性表为空表；

　　II. 表中只含有一个元素；

　　III.输入表中所有元素已排好序；

　　IV.输入表已按逆序排好；

　　V. 输入表中部分或全部元素相同。

　　二. 实战演习

　　 暂无

　　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列作为确定测试用例的依据。

　　现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。

　　基本流和备选流：如下图所示，图中经过用例的每条路径都用基本流和备选流来表示，直黑线表示基本流，是经过用例的最简单的路径。备选流用不同的色彩表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中（如备选流1和3）；也可能起源于另一个备选流（如备选流2），或者终止用例而不再重新加入到某个流（如备选流2和4）。

　　二.实战演习

　　1. 例子描述

　　下图所示是ATM例子的流程示意图。

　　2.场景设计：下表所示是生成的场景。

表3-8 场景设计

　　注：为方便起见，备选流3和6（场景3和7）内的循环以及循环组合未纳入上表。

　　对于这7个场景中的每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。下面显示了一种通用格式，其中各行代表各个测试用例，而各列则代表测试用例的信息。本示例中，对于每个测试用例，存在一个测试用例ID、条件（或说明）、测试用例中涉及的所有数据元素（作为输入或已经存在于数据库中）以及预期结果。

　　一旦确定了所有的测试用例，则应对这些用例进行复审和验证以确保其准确且适度，并取消多余或等效的测试用例。

　　测试用例一经认可，就可以确定实际数据值（在测试用例实施矩阵中）并且设定测试数据，如表3-10所示。