persist的个人空间_首页_51Testing软件测试网

persist

用户菜单

日历

存档

搜索标题

我的好友

jackei

统计信息

访问量: 1877
日志数: 18
书签数: 1
建立时间: 2007-08-24
更新时间: 2008-03-26

RSS订阅

我的最新日志

2008/3/26-27 等价类测试

2008-3-26
第三章等价类测试

概要

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

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

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。
查看(101) 评论(0)
2008/3/25 黑盒测试技术

2008-3-25
第一部分：黑盒测试技术

章节列表

第三章：等价类测试

第四章：边界值测试

第五章：决策表测试

第六章：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.
查看(963) 评论(2)
SQL server2005 restore数据报错

2008-3-24

今天在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原来的数据库，否则就会报上面的错。

查看(31) 评论(0)
周末在家带锦锦玩，没有时间做英语作业没有时间翻译。

2008-3-24

暂无

查看(17) 评论(0)
2008/3/24

2008-3-24

第二章用例学习

什么是用例学习

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

查看(25) 评论(0)
2008/3/21 测试的不完全性

2008-3-21
测试的不完全性

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种输入值中只有四种输入能够找出程序的缺陷，那么你会选取这四个值的几率有多大呢？你会选取这四种输入值中的一种的几率有多大呢？你会强力球彩票的几率有多大呢？是不是你对以上三个问题的答案都是一样的呢？
查看(41) 评论(0)
2008/3/20 测试类型、测试级别

2008-3-20

测试类型

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

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

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

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

测试级别

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

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

不同的编程语言具有不同的单元：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测试人员通常采用另外一套测试划分级别：代码质量、功能性、可用性、性能、安全。

查看(71) 评论(0)
2008/03/19 测试面临的挑战/测试用例

2008-3-19

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

查看(71) 评论(0)
2008-3-18 第一章测试过程—测试

2008-3-18

第一章   测试过程

概要

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

查看(55) 评论(0)
2008-3-17 序言

2008-3-18

序言

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

测试设计的重要性

用户菜单

日历

存档

搜索标题

最新来客

我的好友

最新评论

统计信息

RSS订阅

我的最新日志

2008/3/26-27 等价类测试

第三章等价类测试

概要

2008/3/25 黑盒测试技术

章节列表

部分概要

定义

适用性

缺点

优点

参考

SQL server2005 restore数据报错

周末在家带锦锦玩，没有时间做英语作业没有时间翻译。

2008/3/24

第二章用例学习

什么是用例学习

Brown & Donaldson

非州立大学注册系统

2008/3/21 测试的不完全性

2008/3/20 测试类型、测试级别

2008/03/19 测试面临的挑战/测试用例

2008-3-18 第一章测试过程—测试

2008-3-17 序言

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

用户菜单

日历

存档

搜索标题

最新来客

我的好友

最新评论

统计信息

RSS订阅

我的最新日志

第三章 等价类测试

概要

章节列表

部分概要

定义

适用性

缺点

优点

参考

第二章 用例学习

什么是用例学习

Brown & Donaldson

非州立大学注册系统

第三章等价类测试

第二章用例学习