第三章 等价类测试

概要

等价类测试是一种把测试用例的数量减少到可控的范围但是还可以保持合理的测试覆盖率的技术。即使可能没有意识到这是一种正式的测试设计方法，几乎所有的测试人员都使用过这种测试方法。有一些测试人员从理论上认识到了它的有用性，而有的测试人员只是因为没有时间去进行完全的测试才发现了它。

考虑一下下面的情况： 假设我们正在写一个人力资源系统的一个模块，这个系统是用来根据人的年龄确定如何处理求职申请。下面是这个组织的规则：

0-16    不雇用

16-18 只能以兼职的形式雇用

18-55 可以作为全职员工雇用

55-99  不雇用

 

注意：如果你已经发现了这些规则中的问题，那么先不要着急，因为这些需求是故意这么些的，在下一张将进行一些修改。

 

结论

根据这些规则，我们的组织将不会雇用Doogie Houser, M.D. 或者 Col. Harlan Sanders，他们中一个年纪太小，一个年纪太大。

                 

                那么对这个模块的测试我们是不是要测遍以下所有的年龄: 0, 1, 2, 3, 4, 5, 6, 7, 8, ..., 90, 91, 92, 93, 94, 95, 96, 97, 98, 99? 如果我们有足够的时间（而且并不介意这些毫不费脑筋重复动作且是以小时来计酬劳的），我们当然可以这么去做。如果程序员以以下的方式编写了这个模块，那么我们也应该测试每一个年龄.（如果你没有编程的背景也不要着急，这些例子十分简单，通过读这些代码你就能够理解其中的意思。）

        If (applicantAge == 0) hireStatus="NO";

        If (applicantAge == 1) hireStatus="NO";

        …

        If (applicantAge == 14) hireStatus="NO";

        If (applicantAge == 15) hireStatus="NO";

        If (applicantAge == 16) hireStatus="PART";

        If (applicantAge == 17) hireStatus="PART";

        If (applicantAge == 18) hireStatus="FULL";

        If (applicantAge == 19) hireStatus="FULL";

        …

        If (applicantAge == 53) hireStatus="FULL";

        If (applicantAge == 54) hireStatus="FULL";

        If (applicantAge == 55) hireStatus="NO";

        If (applicantAge == 56) hireStatus="NO";

        …

        If (applicantAge == 98) hireStatus="NO";

        If (applicantAge == 99) hireStatus="NO";

 

                如果以上面的方式实现这个模块，已经成功通过测试的并不能告诉我们下一个将要执行的测试会是什么样的结果，它可以会成功通过也可以会失败。

                幸运的是程序员并不会写出这样的代码（至少不会经常这么写）。一个更好的程序要可能会这么编写这段代码：

        If (applicantAge >= 0 && applicantAge <=16)

                  hireStatus="NO";

        If (applicantAge >= 16 && applicantAge <=18)

                  hireStatus="PART";

        If (applicantAge >= 18 && applicantAge <=55)

                  hireStatus="FULL";

        If (applicantAge >= 55 && applicantAge <=99)

                  hireStatus="NO";

                按照这种实现方式，很显然对第一个需求我们并不需要测试0, 1, 2, ... 14, 15以及16，我们只需要测试其中的一个值。那么测试哪个值呢？范围内的任何一个值都可以。这个测试方法对另外几个需求也一样适应。这里讲的范围通常叫做等价类。一个等价类包含了一系列的将被模块以同样的方式处理的或者会产生同样结果的数据。就测试而言，类中的任何一个数值都是类中同其他的值都是等价的。特别地，我们得出这样结论：

                如果等价类中的一个测试用例发现了一个缺陷，那么同一个等价类中的所有的其他测试用例也可能会测试出同样的缺陷。

                如果等价类中的一个测试用例没有发现缺陷，那么同一个等价类中的所有的其他测试用例也不能会测试出这个缺陷。

 

                关键点  如果以下条件成立，那么一组测试就形成了一个等价类：

§         他们测试是同样的东西

§         如果其中的一个测试发现了一个缺陷，那其他的也可能发现这个缺陷

§         如果其中的一个测试不能发现一个缺陷，那其他的测试也可能发现不了这个缺陷。

当然，这个方法假设现有的需求规格说明书定义了不同的要测的等价类。它也假设程序员没有编写类似以下代码的奇怪的代码：

       If (applicantAge >= 0 && applicantAge <=16)

                hireStatus="NO";

       If (applicantAge >= 16 && applicantAge <=18)

                hireStatus="PART";

       If (applicantAge >= 18 && applicantAge <=41)

                hireStatus="FULL";

       // strange statements follow

       If (applicantAge == 42 && applicantName == "Lee")

                hireStatus="HIRE NOW AT HUGE SALARY";

       If (applicantAge == 42 && applicantName <> "Lee")

                hireStatus="FULL";

       // end of strange statements

       If (applicantAge >= 43 && applicantAge <=55)

                hireStatus="FULL";

       If (applicantAge >= 55 && applicantAge <=99)

                hireStatus="NO";

2008/3/27

                用等价类方法，我们能够把测试用例从100（每个年龄都测）减少到4个（每个等价类中测试一个）。

                那么，我们现在是不是已经准备好了可以开始测试了呢？可能还不行，对像969，-42以及&$#!@?这样的输入数据怎么处理呢？我们是不是要为非法输入创建一些测试用例呢？就像任何一个好的咨询师的建议一样，答案是“得视具体情况而定”。为了正确的理解这个答案，我们需要测试一下这个来自于面向对象世界的方法—根据合同设计。

         注意   根据圣经，Methuselah死的时候的年龄是969岁（Gen 5：27）。谢谢Gideons，他使得我能够在我的旅馆里就可以很轻松的获取到这些数据，而不需要高速网络链接。

                从法律的角度来讲，合同就是一个对合同两方（或者多方）具有法律约束力的约定，它描述了每一方承诺要做的和不做的事情，合同中的任何一个承诺都对合同当事人有益。

                在“根据合同设计”的方法里，模块（）是以前提条件和Post-conditions来定义的。Post-donditions定义了一个模块将要实现什么（如计算一个值，打开一个文件，打印一个报告，更新一条数据库记录，改变系统的状态等等）。 Pre-Conditions定义了模块要实现Post-conditions所需要的条件。例如，如果我们有一个叫做openFile的模块，那么我们希望这个模块实现什么样的功能呢？答案就是打开一个文件。那么openFile必要的前提条件是什么呢？首先，要打开的文件必须是存在的；其次，我们必须知道文件的名字（或者其他标识信息）；第三，这个文件必须是可打开的，也就是说它是不能同时只能由一个线程打开的；第四，我们必须具有访问该文件的权限；还有其他条件，等等。Pre-conditions和Post-conditions在模块和其他引发模块中的动作的条件之间建立起了一种合同关系。

                根据合同测试是来源于根据合同设计的思想的。这种方法的思想是只为那些能满足pre-conditions的情况设计测试用例。例如，如果文件不存在我们就不会测试openFile模块。原因很简单，如果文件都不存在，openFile模块肯定不会工作的。如果没有在指定的条件下工作的声明，那么就没有在那种情况下测试的必要。

                如需更多信息  请参见Bertrand Meyer's book Object-Oriented Software Construction for more on design-by-contract。

               

第一部分：黑盒测试技术

章节列表

第三章：等价类测试

第四章：边界值测试

第五章：决策表测试

第六章：Pairwise测试

第七章：状态转移测试

第八章：域分析测试 

第九章：Use Case测试

 

部分概要

定义

黑盒测试是一种仅仅基于需求和规格说明书进行测试的测试策略。不同于它的补充物白盒测试，黑盒测试不需要了解被测软件的内部结构、逻辑以及实现。

通常黑盒测试的流程是这样的：

·         分析需求或者规格说明

·         根据规格说明确定有效的输入值以确定被测系统能够正确的处理这些输入值。测试时还必须选择一些无效的输入以确定 被测系统能够检测到这些无效输入并合理的处理他们。

·         确定不同输入值所对应的预期输出值

·         基于这些被选的输入值构建测试

·         执行测试

·         比较实际的输出结果和预期的输出结果

·         确定被测系统相应的功能

 

适用性

黑盒测试能够应用于系统开发的不同阶段——单元测试、集成测试、系统测试、接收测试。

从上图可以看出，随着开发过程从单元到子系统到系统的不断深入，上面的黑盒变的越来越大，系统的输入和输出变得更加复杂，但是测试的方法是一样的。同时，随着系统规模的不断变大，我们将不得不采用黑盒测试方法，因为对白盒测试有大多的路径需要覆盖。

 

缺点

使用黑盒测试，使用黑盒测试，测试者永远不能确定被测系统被测到了什么程度。不管测试者是多么的聪明和勤劳，总有一些路径是不可能被测试到的。例如，在以下的例子中，测试者会选择选择一条用例去发现问题的可能性有多大呢？

    if (name=="Lee" && employeeNumber=="1234" &&

    employmentStatus=="RecentlyTerminatedForCause") {

    send Lee a check for $1,000,000;

    }

 

关键点  使用黑盒测试，测试者永远不能确定被测系统被测到了什么程度。

 

为了使用黑盒测试检测出被测系统的每一个缺陷，测试必须尽可能的测试被测系统的各种合法的以及不合法的输入值的组合。然而，穷尽所有输入值的测试几乎是完全不可能的，因此我们只能选取这些组合输入值的子集（通常是非常小的子集）。

 

在《测试的艺术》一书中，Glenford Myers为彻底测试的无用性举了一个很好的例子：你怎么去完全测试一个编译器？难道通过编写每一种可能的合法以及不合法的程序吗？而且对那些必须记住以前的状态的系统（例如，记住他们的状态）这个问题会变得更加难办，因为对这些系统你不但要测试每种可能的输入值，而且你还必须测试每种可能的输入值的每种可能的顺序。

 

关键点 尽管我们不可能穷尽所有的测试。但是黑盒测试可以给测试者提供一些指导以选择那些能够更快、更有效发现系统缺陷的测试子集。

 

优点

管我们不可能穷尽所有的测试。但是黑盒测试可以给测试者提供一些指导以选择那些能够更快、更有效发现系统缺陷的测试子集。这些测试子集比相同数量的随机测试能够找出更多的缺陷，因此黑盒测试能够使我们最大可能的提高测试投入的回报值。

 

参考

Myers, Glenford J. (1979). The Art of Software Testing. John Wiley & Sons.

今天在SQL Server2005上restore数据的时候发现报这个错：

The backup set holds a backup of a database other than the existing 'Check21' database.
RESTORE DATABASE is terminating abnormally. (Microsoft SQL Server, Error: 3154)

后来在网上查资料后发现不少人遇到这个问题，通过实践最后得出结论：有两种方法解决这个问题.

1. 使用SQL语句：

USE master
RESTORE DATABASE DB
   FROM DISK = 'g:\back.Bak'
   WITH MOVE 'DBTest' TO 'E:\Program Files\Microsoft SQL Server2005\Data\DB.mdf',
   MOVE 'DBTest_log' TO 'E:\Program Files\Microsoft SQL Server2005\Data\DB_log.ldf',
STATS = 10, REPLACE
GO

2. 在使用SQL server 2005 UI restore数据的时候要选择overwrite原来的数据库，否则就会报上面的错。

暂无

第二章 用例学习

什么是用例学习

      本书的附件有两个用例学习的例子。附件A讲述的是“Brown@Donaldson”,这是一家网上经纪公司。附件B描述的是非州立大学注册系统。这些用例学习的例子解释了本书所讲述的测试用例设计技巧。另外，书中的一些练习也是基于用例学习的。接下来的章节简要的讲述了一下用例学习。如果需要详细的信息请参考附件A和附件B。

Brown & Donaldson

Brown & Donaldson(B&D)是一个虚拟的的在线经纪公司，通过这个例子你可以练习本书中讲述的测试用例的设计方法。B&D原本是为软件质量工程中的Web/电子商务测试课程而设计的（具体信息请参考http://www.sqe.com）。

                附件A中包含很多页面的抓屏，本书中经常会有一些对这些抓屏的引用。实际的(B&D)网站可以通过http://bdonline.sqe.com访问到。如果这些图片和任何在线经纪公司的实际网站雷同，那纯属偶然。

                实际上你可以直接访问B&D网站。第一次登录的用户需要创建一个DBonline用户帐号。这个帐号不是真实的—任何通过该帐号申请的或者执行的事务请求都是虚拟的。一旦你创建了帐号，你就可以用你的用户名和密码去登录系统，而不要再创建新的帐号。创建用户的时候你需要提供一些提供一个授权码，这个授权码是11111111.

                这个网站还包含一些可供下载的B&D用例学习的文档，这些将帮助你为你的Web项目设计测试用例。

非州立大学注册系统

                每个州都有州立大学，这个用例学习的例子讲述了一个虚拟的非州立大学学生注册系统。请不要试图从Brown & Donaldson 套现你的股票以注册到一个非州立大学。

                附件B的文档讲述了一个设计好的非州立大学注册系统的用户界面。它以常用的使用顺序展示了用户操作界面：先是登录界面，然后是数据库创建字段，增加/修改/删除学生记录，增加/修改/删除课程，增加/修改/删除班级等，在最后的数据输入界面用户可以给每一个学生选择特定的课程。另外，这些用户界面还包含了管理功能。

测试的不完全性

   Robert Binder在他的著作《面向对象系统的测试》一书中用一个很好的例子解释了测试“所有东西”的不可能性。看下面的程序：

               int blech (int j) {

               j = j -1;           // should be j = j + 1

                j = j / 30000;

                return j;

               }

      注意到程序中第二行是错误的，函数blech接收一个整型参数j,然后把它减一后再去除以30000（注意到这是整型之间的除，商也是整型），最后返回得到的商。如果在十六位机上执行这个函数，那么输入值的范围就在-32768到32768之间，因此就这么一个小小的程序它就有65536中输入。实际应用中的程序肯定比这个复杂，你可能有那么多时间和精力去创建65536条测试用例吗？当然不可能。那么我们应该选取什么样的输入值来进行测试呢？先让我们来看一下下面的表格：     

输入值 (j)	期望结果	实际结果
1	0	0
42	0	0
40000	1	1
-64000	-2	-2

      从上面的表格我们可以看出，没有任何一条测试用例测出了程序的缺陷。实际上在65536种输入值中只有四种输入能够找出程序的缺陷，那么你会选取这四个值的几率有多大呢？你会选取这四种输入值中的一种的几率有多大呢？你会强力球彩票的几率有多大呢？是不是你对以上三个问题的答案都是一样的呢？

测试类型

                软件测试通常被分为黑盒测试和白盒测试。

                黑盒测试是一种仅仅基于需求和规格说明书进行测试的测试策略。不同于它的补充物白盒测试，黑盒测试不需要了解被测软件的内部结构、逻辑以及实现。

                白盒测试是一种基于被测软件内部逻辑、结构和是实现的测试策略。不同于它的补充物黑盒测试，白盒测试需要具体的编程技术。

                另外还有一种测试叫做灰盒测试。这种方式要求我们了解被测软件，但是只需要了解它怎么被实现的后再利用我们的知识去选取更有效的黑盒测试方法。

 

测试级别

                通常来讲，测试已经相应的测试用例设计是在不同的级别下进行的。

                单元测试——一个单元是开发人员创建的一个最小的程序片段，它通常是一个程序员的工作成果并且通常保存在一个单独的磁盘文件中。

不同的编程语言具有不同的单元：C++和Java语言的最小单元是类，C语言的最小单元是函数，而那些非结构话的语言如Basic，Cobol其单元就是整个程序。
 关键点：经典的测试级别分为单元测试、集成测试、系统测试、接收测试。
 集成测试-有可能单独的单元能够正常运行，但是把各个单元组装到一起的时候就不能正常运行。以下一个典型的C程序和它的子函数的例子：

 /*主函数*/

 void oops(int);
 int main(){
  oops(42);
  return 0;
 }

      /*函数oops(在一个单独的文件中)*/
      #include <stdio.h>
      void oops(double x){/*参数是一个实数，而不是一个整数*/
      printf("%f\n",x); /*将输出随机的内容(很可能是0)*/
      }
      这些单元在单独测试的时候都能够正常工作，但是两个单元集成起来就会有错误。主函数一个整数给子函数oops，但是oops函数的输入参数是实数，这样错误就产生了。因此，在集成测试是十分重要的。
      系统是指提交给用户的产品所包含的所有软件部分(可能还包括硬件，用户手册，培训材料等)。系统测试致力于发现最高级别的集成后的缺陷。通常系统测试包含多种测试：功能测试、可用性测试/安全测试、国际化和本地化测试、可靠性测试、容量测试、性能测试、备份恢复测试、移动测试以及其他测试。尽管这些测试都很重要，但它们都在本书所讲的范畴外，本书将集中讲述功能测试。
      接收测试是指那种如果通过的话客户将接收产品并付款的测试。从客户的角度来看，他们通常希望能够极尽所能的测试(相当于系统测试)。但是开发商却希望能够进行最少的测试以使客户尽快付款。通常在接收测试前需要解决这些问题：谁定义接收测试的级别、谁创建测试脚本、谁执行测试、测试通过与否的标准是什么、什么时候以什么方式付款等。
      并不是所有的系统都适合采用这种测试级别去进行测试，这种测试级别适应于那种开发单元、集成单元到子系统乃至整个系统有明显的时间阶段的系统。而在Web开发过程中，从构思到编码到产品的成型可能就是数个小时的事情，这种系统并不适应于采用单元-集成-系统的测试划分等级。因此许多Web测试人员通常采用另外一套测试划分级别：代码质量、功能性、可用性、性能、安全。

当前挑战 当我问学生们他们在测试中面临的挑战有哪些，他们通常会这样回答： · 没有足够的时间去进行正确的测试 · 有太多的输入路径的组合需要测试 · 没有足够的时间好好测试 · 很难确定每一个测试的预期结果 · 没有需求或者需求老是在变更 · 没有时间进行彻底的测试 · 测试流程没有相应的培训 · 没有工具支持 · 管理人员也不懂测试或者（明显）不关心质量 · 没有足够的时间 这本书没有那种能够给你创造更多的时间、更好的需求文档或者更开明的管理的魔力。然而，它确实包含了一些技巧，这些技巧可以帮助你选择、构建更好的测试用例以便使用更少的资源去发现更多的缺陷，从而大大提高你的测试工作效率和效果。 测试用例 为了使工作更有效，测试用例必须是经过设计的，而不是简单的堆砌在一起。这里“设计”一词具有很多定义：在头脑里构想或形成；创造：找一个好的理由去参加明星测试大会。形成一个计划；设计：为新的产品创造一个市场战略。制定一个系统的，通常以文档的形式呈现的计划：设计一座建筑；设计一条测试用例。为一个特定的目标去创造、构想：一个为了迎合各种年龄段而设计的游戏。有一个目标、计划以一种艺术的或者高技巧的方式创造或者执行。 关键点：为了使工作更有效，测试用例必须是经过设计的，而不是简单的堆砌在一起。 以上每一种定义都很适合于测试用例设计。就测试用例设计，Roger Pressman曾这样写道： “对软件或者其他工程产品的测试设计同最初设计产品本身一样充满挑战。然而……软件工程师们经常把测试看作是一种事后行为，通常开发一些感觉不错但是几乎很难保证完成的测试用例。回想一下测试目标，测试设计必须能够使得我们能够在花最小的时间和精力的情况下尽最大可能的发现最多的错误。” 好的测试用例通常包含三个部分： · 输入 · 输出 · 执行步骤 关键点：测试用例包含输入、输出、执行步骤。 输入 输入通常被看作是从键盘上输入的数据。然而尽管那是一种很重要的系统输入数据来源，输入数据还有很多其他来源，如来自于接口系统的数据，来自于接口设备的数据，从文件或者数据库中读取的数据，当数据过来时系统的状态以及系统执行的环境等。 输出 输出同样具有很多样性。通常输出通常只被看成是现实在计算机显示器上的数据。其实不然，输出数据可以是被输出到接口系统或者其他设备的数据。输出数据也可以被写到文件或者数据库中，系统的状态或者环境也可以在系统执行过程中被改变。 所有这些相关的输入和输出都是一个测试用例的重要组成部分。在设计测试用例时，决定预期输出是“Oracle”的功能。 Oracle是那些给测试设计者提供测试预期结果的程序、进程或者数据。 Beizer列举了五种类型的Oracle： Kiddie Oracles-只是运行程序然后看其输出结果，如果输出结果看起来是正确的，那它就是正确的。 回归测试套件——运行程序并比较在不同版本上运行同样测试的输出结果。 确认数据——运行程序并把运行结果同标准结果如表格、公式或者其他被接受的有效输出的定义。 购买测试套件——在一个以前创建的已经被验证的标准化的测试套件中运行程序。编译器、Web浏览器以及SQL处理器都是通过这样的方式测试的。 现存的程序——运行程序并把它的输出结果同其他不同版本的数据结果比较。 执行顺序 按照测试执行顺序的不同，测试用例设计有两种不同的方式：串联测试用例——测试用例之间相互依赖，第一个测试用例执行软件的一个特定的功能以便使得系统处于某种状态，然后第二条测试用例才能够被执行。例如在测试数据库的时候需要考虑这些测试用例： 1. 创建一条记录 2. 读取该条记录 3. 更新该条记录 4. 读取该条记录 5. 删除该条记录 6. 读取被删除的记录每个测试都建立于前面的测试。这种方式的优点就是每一条测试用例都是十分的短小、简单。它的缺点就在如果其中一条用例失败了，那么接下来的测试都是无效的。独立测试用例——每一条测试用例都是独立的，不同的测试之间没有相互依赖性或者并不需要其他的测试成功通过才能执行。这种方式的优点就在于测试可以以任意顺序执行。它的缺点就在于每一个测试都有可能是很大的、很复杂，因此它的设计、创建、维护相比之下要困难许多。

第一章   测试过程

 

概要

                鹅群在头顶上飞出了一个’V’形，这并不是以前流行的的时代新罗曼的’V’形，那种’V’形在’v’字的两个分支的顶上都有一横；也不是那种更现代的线性标楷体的那种很直脆的’V’形（尽管他们在飞，楷体’V’更合适一些）；而是有一点点不匀称，有一点点往一边倾斜，有点点像楷体字速递新样的’V’——LaFonte知道他就是那种能识别出这种细微差别的男人。

 

[1]如果你发现这段引用的文字跟软件测试风马牛不相及那你就对了。具体的解释请参照序言中的“说明”。

 

测试

      什么是测试？尽管已经有很多说法对此进行了定义，但是究其核心而言，测试就是把“现有的”同“应该有的”进行比较的过程。 IEEE标准610.12-1990对此给予一个更加正式的定义,”IEEE软件工程术语标准词汇”对”测试”的定义是这样的：

     

      测试就是在特定条件下操作一个系统或组件，观察或记录其结果，并对系统或组件的某些方面进行评估的过程。

 

      定义中所指的”特定条件”在测试用例中体现出来，这正是本书的主题。

 

                关键点  究其核心而言，测试就是把“现有的”同“应该有的”进行比较的过程。

 

Rick Craig和Stefan Jaskiel在他们合著的《系统化的软件测试》一书中建议给软件测试一个扩充的定义：

测试是一个设计、使用、维护软件以便评估或者提高被测软件质量的并行生命周期过程。

 

这种定义把测试计划、分析、设计以生成测试用例的过程和IEEE强调的测试执行过程都涵盖进来了。

不同的组织以及个人对软件测试的目的有不同的见解。Boris Beizer讲述了测试成熟度的五个级别。（他称他们为五个阶段，但是今天我们都知道应该称之为五个级别。）

0级——根本不区分测试和调试。除了调试，测试没有任何意义。缺陷可能被随手发现，但是没有正式努力去找出他们。

1级——测试的目的是为了证明软件是可用的。这种定义方式是基于软件基本是正确的假设的，它往往容易蒙蔽我们去发现缺陷。Glenford Myers写道那些执行测试的人肯恩潜意识里选择一些能够通过的测试用例去测试，他们将不会创建一些极限的测试以便去发现那些隐藏很深的缺陷。

2级——测试的目的是为了证明软件是不能用的。这是一个非常不同的想法，它假设软件是不可用的并以此要求测试人员去发现它的缺陷。用这种方式，我们将有意识的去选那些在其隐蔽处，边界上，并接近其边缘的魔鬼式的用例去评估系统。

                3级——测试的目的不是去证明任何东西，而是为了减少可以预见的风险。尽管我们可以只用一个测试用例就可以证明系统是不正确的，但是不可能证明它是正确的。要做到这个就要求我们测试每一中有效输入数据的组合以及每一种无效输入数据的组合。我们的目标是以缺陷的方式理解软件的质量，为程序员提供软件缺陷的信息，为管理者提供如果该系统按现在状态提交给客户将会对组织产生多大负面影响的评估。

                4级——测试不是一种行为。它是一种意识，这种意识将使得组织在没有花费大量精力去测试的情况下生产低风险的软件。在这种成熟度级别上，我们将着重于在生产软件的最初阶段就致力去使得软件具有更高可测性。这包括对需求、设计、代码的评审、检查。另外，它将意味着写的代码将帮助测试人员更方便的去检查它。而且，它将意味着写的代码要能够自我诊断，要能够报告错误，而不要等到测试人员去发现他们。

序言

《软件测试设计实践指南》一书把当前重要的测试设计方法囊括在一本书中，而此前测试工程师们往往为了获取这方面的知识需要查找大量书籍、期刊以及网站。

 

                测试设计的重要性

                细致、完整、系统的测试设计能和实际测试找出一样多的Bug，就我个人而言，我认为它是更有效的。

                                                                                                                                                                -Boris Beizer

               

这本书将致力于讲述测试设计，而不会涉及其他测试相关主题如测试计划、测试管理、测试团队发展等等，尽管这些对软件测试也是十分重要的，但是他们经常掩盖住了测试人员真正需要的东西——测试的实用方面，尤其是测试用例的设计。现在市面上有很多十分优秀的讲述软件测试全过程的书，其中我最喜欢的一本是Rick Craig和Stefan Jaskiel和著的《系统的软件测试》。

《软件测试设计实践指南》通过具体的例子和一步一步的操作指南来讲述每一个测试设计的方法。这将使读者对一种测试设计方法有一个清楚的理解。

 

当前测试面临的挑战

                对任何一个有一定规模的系统，测试人员不可能穷尽所有的逻辑路径以及不同的输入数据的组合。在这些无穷无尽的选择中，每一个都是值得去测试的，但是由于资源的限制测试人员只能选取其中十分小的子集去测试。 这本书的目的就是帮助你去分析、设计以及选择这些子集去执行测试以便尽可能多的发现系统的缺陷。

                合理的选择测试用例是十分重要的。如果一个带有缺陷的系统被投入到生产中，那么漏掉一个缺陷将有可能对你的组织造成十分大的损失。

                《软件测试设计实践指南》讲述了一系列的关键的测试设计策略以便提高软件测试人员的工作效率和效果。

 

结构和方法        

                《软件测试设计实践指南》简述了当前正在使用的一些最重要的测试设计方法，这些方法中有的是十分经典的、被测试领域所熟知的；而有的却是刚刚出现的并不为大多数测试工程师所了解的；更有一些是不为大多数人说熟悉，但是却是应该被知道的，因为他们能够很大程度上提高测试工作效率。这本书把所有的这些技巧集中在一起讲述以提高测试设计效率和效果。

                每一种测试设计方法都是来自于实践而不是来自于理论，因此每一种测试设计方法的介绍都是通过先讲一个简单的例子再讲理论来进行的，有时候还有能会有一些额外的例子来讲述它的使用。每一种方法的适用性以及局限性都会讲述。并且在每一种测试设计方法的结尾都会总结该测试方法的关键点以及一些习题和参考资料。测试人员能够将这些技巧马上应用到他们的实际工作中去。

              作者注

                我同别的测试人员一样喜欢这个微积分符号，但是我们将更偏重于实践，而不是理论。

 

                每一种测试方法都是用一章节来讲述的，因为这些章节是集中的、简明的并且相互独立的，因此读者可以从其中的任意一章节开始阅读。测试人员可以挑选其中跟他们当前工作最相关的章节来读。

 

读者对象

                测试工程师：测试工程师的首要职责是测试用例设计，这本书详细的讲述了设计测试用例的最有效的方法。

                软件开发工程师：随着极限编程以及其他敏捷开发方法的到来，软件开发工程师被要求对他们开发的软件进行更多的、更好的测试，而许多开发人员从没有接触过书中所讲述的测试设计方法。

                测试及开发管理人员：管理人员至少原则上应该懂得他们下属的工作情况。这本书不仅概述了重要的测试设计方法，而且它将帮助管理人员评估一个好的测试的工作量、时间以及成本。

                品质保证以及过程改进工程师：他们负责定义以及提高软件测试的过程。

                讲师及教授：这本书将为他们的测试设计方法课程提供有价值的参考。

 

致谢

                以下评论人员对本书提供了很大的帮助，我衷心的感谢其中的每一位，但是这本书中的每一个错误也要归咎于他们（开玩笑！）：

                Anne Meilof, Chuck Allison, Dale Perry, Danny Faught, Dorothy Graham, Geoff Quentin, James Bach, Jon Hagar, Paul Gerrard, Rex Black, Rick Craig, Robert Rose-Coutré, Sid Snook, and Wayne Middleton.

 

 

说明

                这本书包含了大量的对网站的引用，这些引用在本书的原稿提交给出版商的时候是正确，但是有可能很不幸的是在本书到达读者的手上时这些网站已经链接不上了。

                作者在每一章的标题页引入一些有力的引用已经成了作家们的一种标准行为。不幸的是，这些行为变得如此盛行以致几乎所有的引用语都已经被用过了。因此，娱乐起见，我在每一章的标题页引用2003布沃立顿作文大赛中的获奖作品(http://www.bulwer-lytton.com). 自1982年以来，圣荷西州立大学英语系每年主办一次该比赛，比赛要求作家们给所有可能的最差的小说写开头一句。该比赛的灵感来自于爱德华乔治布沃立顿，他以下面的文字起头了他的小说《保罗克利福德》：

      这是一个漆黑的暴风雨晚上，暴雨一直在不停地下。偶尔暴雨停歇的片刻，肆掠的狂风便横扫街道，吹得屋顶发出咯咯的声音。那在黑暗中挣扎的昏暗的路灯在风中剧烈地摇晃着。

     

      我很感谢圣荷西州立大学的斯科特赖斯博士允许我使用这些不良写作范例。希望本书中没有任何东西能够有此殊荣获得这个高的奖项。

 

致谢

      本书中米克的漫画的版权属于马丁奥洛克林，是经过允许使用的。

      Corel公司版权所有的插图也是通过协议许可使用的。

 

参考文献

      Beizer, Boris (1990). 软件测试技术（第二版）Van Nostrand Reinhold

                Craig, Rick D. and Stefan P. Jaskiel (2002). 系统化的软件测试Artech House Publishers

1.       DownLoad FitBookExamples FitBookEx_Net20Fdn.zip from http://www.vlagsma.com/fitnesse/PreInstall.aspx,

2.       Unzip FitBookEx_Net20Fdn.zip to a directory, such as ‘E:\fitnesseWithExamples’

3.       copy folder ‘FitBookExamplesMenu’ from E:\fitnesseWithExamples\FitNesseRoot\ into your FitNesse directory. For example: D:\fitnesse\FitNesseRoot

4.       copy folders from E:\fitnesseWithExamples\FitNesseRoot\files into your FitNesse files directory. For example D:\fitnesse\FitNesseRoot\files

5.       Run FitNesse using command line: run –p 8080

6.     In IE address bar, input ‘http://localhost:8080/FitNesse’. Click the ‘Edit’ button and in the Edit box input ‘!include FitBookExamplesMenu’. Click the save button.

7.     Now you can use the examples of the book- Fit for Developing Software

8.     For more details, you can surf onto the website: http://www.vlagsma.com/fitnesse/

 

The book about FitNesse.

1.     Using command line to add user and user password:

            D:\fitnesse>java -cp fitnesse.jar fitnesse.authentication.Password -f password.txt -c             fitnesse.authentication.HashingCipher  Sophia

            (‘D:\fitnesse>’ is FitNesse’s setup directory)

2.       When the user is added successfully, a password.txt file will be created under FitNesse’s root directory.

3.       Start FitNesse using ordinary mode:

            D:\FitNesse>run –p 8080

4.       Change the pages that you want to use user control

            In the intent page, click the properties button on the left panel. In the properties page, toggle the checkbox before - secure-read/ - secure-write/ - secure-test, and click save

5.       Start FitNesse using authentication mode

            D:\fitNesse>run –p 8080 –a password.txt

            After restarting the server, you’ll see a pop-up dialogue box that reminds you to input your    user name and password after you click the controlled page.

从2008/3/17号开始我决定翻译《软件测试设计实践指南》，做一个《软件测试设计实践指南》的专辑。

还有以前陆陆续续整理的有关测试方面的资料也应该放到Blog上来，以便大家参考。

 

Fit对于业务规则或者涉及组合值的测试很有用，因为可以在表格中定义这些组合，然后通过Fitnesse来自动执行这些组合。

发掘孩子领导才能的最佳方式是观察他们的一举一动。发现他们具有相关潜质后，你需要强化这些特点，直到孩子们养成终身受用的习惯以下我举了反映孩子可能具有领导潜质的18种情况。敬请留意。      

  1.性格；是否会主动插手自己分外的事情表现其责任心和决断力。

  2.敢于大声而坚定地讲话；是否会无所顾忌地表达自己的想法，以及困难时是否流露出胆怯。

  3.创造力；注意在其百般无聊时，所能想出的消遣手段。

  4.解决问题的能力；面对无法回避的问题时，选择分析解决还是发愁焦虑。

  5.交往能力；识别他们谈话中所表现出来的情商和人际交往中的敏感程度。

  6.坚韧的毅力；是否有毅力，能否从错误中恢复。注意其承担的风险，为实现目标而奋斗的能力。

  7.激情；做事的激情就是进步的动力。

  8.沟通能力；领导者75%的工作是口头交际行为，注意观察孩子在交换意见时的调和能力。

  9.倾听和求知的兴趣；未来的领导往往通过倾听和提问来表现他们的好奇心。

  10.永不服输；最能代表领导者特点的品质是毅力，孩子如果永不服输，其领导之路就已经成功一半了。

  11.自信心；敢于表达自己的想法，不人云亦云，能质疑别人的看法

  12.在集体活动中争取主动；是否能在一个群体中迅速作出决定并表明自己的看法，是否渴望并喜欢成为游戏中大家关注的中心。

  13.沉着应对压力；在沉重的压力下，会不会束手无策而导致情况时控，能否保持沉着冷静，给自己时间思考。

  14.刻苦工作；领导们最突出的特点之一就是能为实现更高的目标而刻苦努力地工作。

  15.意志坚定；如果能为了实现自己的想法，而不惜在心理上，肉体上和精神上为之努力奋斗，这一定是一个潜在的领导。

  16.掌控力；是否愿意第一个抢到球，第一个完成任务，倘若发现孩子不惧怕掌控局面，愿意争第一，那么请重视培养孩子的这个特点。

  17.合作和配合能力；是否喜欢和大家一起做事而不是离群独处，是否愿意参与集体的讨论，并表现出协作能力。

  18.积极的态度；是否在为归咎他人而浪费时间，能否看到问题积极的一面，而不是消极面对。

网易CEO丁磊在“激荡互联网十年”论坛上的演讲，觉得很有感触。很同意丁磊的观点：一个人一定要给自己制定一个终生学习计划，要记住看书，要记得不断去思考、探索，不断分析和总结，不要停在人云亦云的角度上，做一个有分析能力的人。