第 16 贴【 2004 － 6 － 1 】：软件质量 

“ 每一个程序都能正确地做某件事，但是这并不是我们想要它作的事情。 ” 这样的软件不能算一个质量好的软件。 

我们如何定义软件质量呢？可以从不同的角度来看待软件质量并对其定义，它们有一些共同点：强调软件与得到了清晰描述的功能和性能需求的符合度、明显的文档标准以及被认为是所有专业开发的软件所具备的隐式特征。 

ISO9126 从如下几个方面来衡量软件质量：功能性、可靠性、可用性、可维护性、效率、可移植性。 

如下三个方面应该尤其被重视： 
1 、软件需求是质量测度的基础。需求符合性的缺乏也就是缺乏质量； 
2 、特定的过程定义了一套开发标准，用以指导软件开发的方式。如果标准未能遵守，那么缺少质量就几乎是肯定的结论； 
3 、除了功能需求等显示的需求外，要对非功能的隐式需求重视（例如，对好的可维护性的期望）。如果软件符合其他显式的需求，但是未能满足隐式需求，软件质量仍然是值得怀疑的。 

软件质量是一个多因素的复杂混合，这些因素随着不同的应用和需要它们的用户而变化。测试时需要根据一定的质量标准有针对性的进行测试。 

第 17 贴【 2004 － 6 － 2 】系统测试方法之恢复测试 

Roger S. Pressman 

许多基于计算机的系统必须在一定的时间内从错误中恢复过来，然后继续运行。在有些情况下，一个系统必须是可以容错的，这就是说，运行过程中的错误不能使整个系统的功能都停止。在其他情况下，一个系统错误必须在一个特定的时间段之内改正，否则就会造成严重损失。 

恢复测试是通过各种手段，让软件强制性地发生故障，然后来验证恢复是否能正常进行的一种系统测试方法。如果恢复是自动的（由系统本身来进行的），重新初始化、检查点机制、数据恢复和重启动都要进行正确验证。如果恢复是需要人工干预的，那么要估算修复的平均时间是否在可以接受的范围之内。 

第 18 贴【 2004 － 6 － 3 】：系统测试方法之安全测试 

Roger S. Pressman 

任何管理敏感信息或者能够对个人造成不正当伤害的计算机系统都是不正当或非法侵入的目标。侵入包括了范围很广的活动：只是为练习而试图侵入系统的黑客；为了报复而试图攻破系统的有怨言的雇员；还有为了得到非法的利益而试图侵入系统的不诚实的个人。 

安全测试用来验证集成在系统内的保护机制是否能够在实际中保护系统不受到非法的侵入。引用 Beizer 的话来说： “ 系统的安全当然必须能够经受住正面的攻击 —— 但是它也必须能够经受住侧面的和背后的攻击。 ” 

在安全测试过程中，测试者扮演着一个试图攻击系统的个人角色。测试者可以尝试去通过外部的手段来获取系统的密码，可以使用可以瓦解任何防守的客户软件来攻击系统；可以把系统 “ 制服 ” ，使得别人无法访问；可以有目的地引发系统错误，期望在系统恢复过程中侵入系统；可以通过浏览非保密的数据，从中找到进入系统的钥匙；等等。 

只要有足够的时间和资源，好的安全测试就一定能够最终侵入一个系统。系统设计者的任务就是要把系统设计为想要攻破系统而付出的代价大于攻破系统之后得到的信息的价值。 

第 19 贴【 2004 － 6 － 4 】：系统测试方法之压力测试 

Roger S. Pressman 

在较早的软件测试步骤中，白盒和黑盒技术对正常的程序功能和性能进行了详尽的检查。压力测试（ Stree Testing ）的目的是要对付非正常的情形。在本质上说，进行压力测试的人应该这样问： “ 我们能够将系统折腾到什么程度而又不会出错？ ” 

压力测试是在一种需要反常数量、频率或资源的方式下运行系统。例如， 
（ 1 ）当平均每秒出现 1 个或 2 个中断的情形下，应当对每秒出现 10 个中断的情形来进行特殊的测试； 
（ 2 ）把输入数据的量提高一个数量级来测试输入功能会如何响应； 
（ 3 ）应当执行需要最大的内存或其他资源的测试用例； 
（ 4 ）运行一个虚拟的操作系统中可能会引起大量的驻留磁盘数据的测试用例。 
从本质上来说，测试者是想要破坏程序。 

压力测试的一个变种是一种被成为是敏感测试的技术。在有些情况（最常见的是在数学算法中）下，在有效数据界限之内的一个很小范围的数据可能会引起极端的甚至是错误的运行，或者引起性能的急剧下降，这种情形和数学函数中的奇点相类似。敏感测试就是要发现在有效数据输入里可能会引发不稳定或者错误处理的数据组合。 

第 20 贴【 2004 － 6 － 5 】：系统测试方法之性能测试 

Roger S. Pressman 

在实时系统和嵌入式系统中，提供符合功能需求但不符合性能需求的软件是不能被接受的。性能测试就是用来测试软件在系统中的运行性能的。性能测试可以发生在各个测试阶段中，即使是在单元层，一个单独模块的性能也可以使用白盒测试来进行评估，然而，只有当整个系统的所有成分都集成到一起之后，才能检查一个系统的真正性能。 

性能测试经常和压力测试一起进行，而且常常需要硬件和软件测试设备，这就是说，常常有必要的在一种苛刻的环境中衡量资源的使用（比如，处理器周期）。外部的测试设备可以监测测试执行，当出现情况（如中断）时记录下来。通过对系统的检测，测试者可以发现导致效率降低和系统故障的原因。 

第 21 贴【 2004 － 6 － 6 】：回归测试 

Roger S. Pressman 

每当一个新的模块被当作集成测试的一部分加进来的时候，软件就发生了改变。新的数据流路径建立起来，新的 I/O 操作可能也会出现，还有可能激活了新的控制逻辑。这些改变可能会使原本工作得很正常的功能产生错误。在集成测试策略的环境中，回归测试是对某些已经进行过的测试的某些子集再重新进行一遍，以保证上述改变不会传播无法预料的副作用。 

在更广的环境里，（任何种类的）成功测试结果都是发现错误，而错误是要被修改的，每当软件被修改的时候，软件配置的某些方面（程序、文档、或者数据）也被修改了，回归测试就是用来保证（由于测试或者其他原因的）改动不会带来不可预料的行为或者另外的错误。 

回归测试可以通过重新执行所有的测试用例的一个子集人工地进行，也可以使用自动化的捕获回放工具来进行。捕获回放工具使得软件工程师能够捕获到测试用例，然后就可以进行回放和比较。回归测试集（要进行的测试的子集）包括三种不同类型的测试用例： 
· 能够测试软件的所有功能的代表性测试用例。 
· 专门针对可能会被修改影响的软件功能的附加测试。 
· 针对修改过的软件成分的测试。 

在集成测试进行的过程中，回归测试可能会变得非常庞大。因此，回归测试应当设计为只对出现错误的模块的主要功能进行测试，每当进行一个修改时，就对每一个程序功能都重新执行所有的测试是不实际的而且效率很低的。 

第 22 贴【 2004 － 6 － 7 】：测试与调试 

测试的目的是显示存在错误，而调试的目的是发现错误或导致程序失效的错误原因，并修改程序以修正错误。调试是测试之后的活动。 [Beizer, 1984] 认为，测试和调试在目标、方法和思路上都有所不同，如下： 

1 、测试从一个已知的条件开始，使用预先定义的过程，有预知的结果。调试从一个未知的条件开始，结束的过程不可预计。 

2 、测试过程可以实现设计，进度可实现确定。调试不能描述过程或持续时间。 

3 、测试是显示错误的行为。调试是推理的过程。 

4 、测试显示开发人员的错误。调试是开发人员为自己辩护。 

5 、测试能预期和可控。调试需要想象，经验和思考。 

6 、测试能在没有详细设计的情况下完成。没有详细设计的信息调试不可能进行。 

7 、测试能由非开发人员进行。调试必须由开发人员进行。 

第 23 贴【 2004 － 6 － 8 】：系统测试方法之功能测试 

功能测试又称正确性测试，它检查软件的功能是否符合规格说明。由于正确性是软件最重要的质量因素，所以其测试也最重要。 

基本的方法是构造一些合理输入，检查是否得到期望的输出。这是一种枚举方法。测试人员一定要设法减少枚举的次数，否则测试投入太大。关键在于寻找等价区间，因为在等价区间中，只需用任意值测试一次即可。等价区间的概念可表述如下：记（ A ， B ）是命题 f(x) 的一个等价区间，在（ A ， B ）中任意取 x1 进行测试。如果 f (x1) 错误，那么 f (x) 在整个（ A ， B ）区间都将出错。如果 f (x1) 正确，那么 f (x) 在整个（ A ， B ）区间都将正确。上述测试方法称为等价测试，来源于人们的直觉与经验，可令测试事半功倍。 

还有一种有效的测试方法是边界值测试。即采用定义域或者等价区间的边界值进行测试。因为程序员容易疏忽边界情况，程序也 “ 喜欢 ” 在边界值处出错。例如测试平方根函数的一段程序。凭直觉输入等价区间应是（ 0 ， 1 ）和（ 1 ， +∞ ）。可取 x=0 。 5 以及 x=2 。 0 进行等价测试。再取 x=0 以及 x=1 进行边界值测试。 

有一些复杂的程序，我们难以凭直觉与经验找到等价区间和边界值，这时枚举测试就相当有难度。 

第 24 贴【 2004 － 6 － 9 】：黑盒测试的端口测试模型 

端口测试模型侧重于对被测对象的抽象，它阐明的是我们要测试什么。它将被测试者间的共性抽象出来，使测试者和被测者可以最大程度地分离开来。其主要思想是：被测试者可以用测试端口集来表达。测试功能体现在测试端口对外协议（称为端口协议）的实现，对不同系统的测试或对同一系统中不同子系统的测试都表现为对不同端口的测试。端口协议一般是非确定的有限自动机（ NFA) ，它可以分解成确定的有限自动机（ DFA) 的集合（对应于功能迁移路径集），并可以用结构化语言描述在测试用例中。这样，端口协议的差异就不会影响测试者的内部实现（与被测者的接口除外）。 

第 25 贴【 2004 － 6 － 10 】：黑盒测试的对象测试模型 

对象测试模型注重于测试内容的表达，它 阐明的是如何表达我们的测试内容。它把分散的功能测试单元有机地组合起来，使实际测试更逼近真正的系统测试。其主要思想是：测试内容及测试的实现方法（指对测试数据的处理）可以被封装在一个个的测试对象中。测试对象有三个层次：数据对象、业务对象和事务对象，它们的关系是逐级被包含。简单来说， 数据对象是指业务（或功能）数据的载体，它通常有物理对应，其主要测试内容是一个状态迁移图；业务对象指共同实现一种业务（或功能）的数据对象集合，它一般都只有逻辑对应，其主要测试内容是一个时间追踪图；事务对象是指一组业务相关的业务对象的有序组合，其主要测试内容是业务间的关系图，准确地说是业务结果间的布尔关系图。 

第 26 贴【 2004 － 6 － 11 】：黑盒测试的分层设计模型 

分层设计模型侧重于黑盒自动测试工具的实现，它阐明的是我们如何设计测试工具。它将测试工具的功能进行抽象和分层，使测试工具的积木化开发现实可行。其主要思想是：测试工具可划分为五个不同的层次，从低到高依次是：端口驱动层、测试执行层、测试表达层、测试管理层、测试设计层。通过规范这五个层次间的接口，可以使按照这个设计模型设计的测试工具或提供相同的接口的其它测试工具无缝地集成在一起，从而实现理想的积木式开发。 

第 27 贴【 2004 － 6 － 12 】： QA 的职责 

QA 到底应该在企业里起什么作用呢？下面是 QA 职责的总结： 

1 、保障软件组织流程体系得到遵守； 
2 、促使软件组织过程改进 ； 
3 、 指导项目实施流程，； 
4 、增加开发活动透明度； 
5 、评审项目活动； 
6 、审核工作产品； 
7 、协助工作产品问题解决； 
8 、度量数据采集、分析，提供决策参考； 
9 、进行缺陷预防； 
10 、实现质量目标。 

第 28 贴【 2004 － 6 － 13 】：软件走读 

软件走读的目的是为了对软件产品进行评价，软件走读也可以是为给参与走读的人员培训有关软件产品知识而举行，软件走读的主要目的是： 
1 ）发现软件产品中的软件异常，缺陷、遗漏和自相矛盾的地方，以改进产品并提出可供选择的实现方案； 
2 ）改进软件产品； 
3 ）考虑可选项方案的实现方法； 
4 ）评价与标准和规格的符合性； 
5 ）进行技术交流，人员培训。 

在软件走读中可以指出各种缺陷，例如软件产品中的效率和可读性问题，设计或编码中模块化问题，或者规格书中的可测试问题等等。 

要求进行软件走读的软件产品，包括但不限于： 
1 ）软件需求规格， 
2 ）软件设计文档， 
3 ）源代码， 
4 ）软件测试文档， 
5 ）软件用户文档， 
6 ）维护手册， 
7 ）安装过程 

第 29 贴【 2004 － 6 － 14 】： TCL 简介 

TCL 是一脚本解释器，具有基本的语言特性，支持整型和字符串变量，支持循环等控制结构；同时它具有灵活的扩展性和跨平台的特性，后者是它最主要的特性。通过 TCL 脚本可以编写测试用例，通过扩展功能，可以扩展你想要的测试动作。最终目的是将测试的自动化和 灵活性（可扩展性）结合在一起。       

     TCL 提供以下接口： 
     1 、用户接口 
      对用户提供语言特性，如循环、条件判断等控制结构，通过它用户可以灵活的书写测试用例；当然只 提供语言特性远远不够，因为业务千差万别，所以用户需要业务接口，从而完成特定的测试任务。 而业务接口，是通过下面的程序员接口实现。 
      2 、程序员接口 
       用户可以编写自己命令，它包括用户层（即名字）和实现层（通过 C 语言实现），然后用 TCL 提供的注册 函数登记，以后命令就可灵活的嵌入到脚本中了。 

      TCL 测试模型分三部分： 
       被测试程序（由开发人员编写） ---- 测试人员应搞清楚程序结构和业务功能，指导扩展命令的设计。 
       测试代码（由测试设计人员编写）   --- 通过程序员接口，提供给脚本扩展命令。 
       测试用例（ TCL 脚本形式，由测试执行人员编写） --- 通过脚本对扩展命令进一步组合。 

第 30 贴【 2004 － 6 － 15 】： CMM 的五级简介 

CMM 为企业的软件过程能力提供了一个阶梯式的进化框架，阶梯共有五级。第一级只是一个起点，任何准备按 CMM 体系进化的企业都自然处于这个起点上，并通过它向第二级迈进。除第一级外，每一级都设定了一组目标，如果达到了这组目标，则表明达到了这个成熟级别，可以向下一级别迈进。 
第一级、初始级： 
      初始级的软件过程是未加定义的随意过程，项目的执行是随意甚至是混乱的。也许有些企业制定了一些软件工程规范，但若这些规范未能覆盖基本的关键过程要求，且执行没有政策、资源等方面的保证时，那么它仍然被视为初始级。 
第二级、重复级： 
      根据多年的经验和教训，人们总结出软件开发的首要问题不是技术问题而是管理问题。因此，第二级的焦点集中在软件管理过程上。一个可管理的过程则是一个可重复的过程，可重复的过程才能逐渐改进和成熟。可重复级的管理过程包括了需求管理、项目管理、质量管理、配置管理和子合同管理五个方面；其中项目管理过程又分为计划过程和跟踪与监控过程。通过实施这些过程，从管理角度可以看到一个按计划执行的且阶段可控的软件开发过程。 
第三级、定义级：         
       在可重复级定义了管理的基本过程，而没有定义执行的步骤标准。在第三级则要求制定企业范围的工程化标准，并将这些标准集成到企业软件开发标准过程中去。所有开发的项目需根据这个标准过程，裁剪出与项目适宜的过程，并且按照过程执行。过程的裁剪不是随意的，在使用前必须经过企业有关人员的批准。 
第四级、管理级：         
       第四级的管理是量化的管理。所有过程需建立相应的度量方式，所有产品的质量（包括工作产品和提交给用户的最终产品）需要有明确的度量指标。这些度量应是详尽的，且可用于理解和控制软件过程和产品。量化控制将使软件开发真正成为一种工业生产活动。 
第五级、优化级：         
      优化级的目标是达到一个持续改善的境界。所谓持续改善是指可以根据过程执行的反馈信息来改善下一步的执行过程，即优化执行步骤。如果企业达到了第五级，就表明该企业能够根据实际的项目性质、技术等因素，不断调整软件生产过程以求达到最佳。 

第 8 贴【 2004 － 5 － 17 】：软件测试策略 

Roger S. Pressman 
测试是一系列可以事先计划并且可以系统地进行管理的活动。正是由于这个原因，应当为软件工程过程定义一个软件测试的模板－我们可以把特定的测试用例方法放置进去的一系列步骤。 

人们已经提出了许多软件测试策略，所有这些策略都为如开发人员提供了一个供测试用的模板，而且它们都包含下列的类属特征： 
· 测试开始于模块层，然后 “ 延伸 ” 到整个基于计算机的系统集合中。 
· 不同的测试技术适用于不同的时间点。 
· 测试是由软件的开发人员和（对于大型系统而言）独立的测试组来管理的。 
· 测试和调试是不同的活动，但是调试必须能够适应任何的测试策略。 

软件测试策略必须提供可以用来检验一小段源代码是否得以正确实现的低层测试，同时也要提供能够验证整个系统的功能是否符合用户需求的高层测试。一种策略必须为使用者提供指南，并且为管理者提供一系列的重要的里程碑。因为测试策略的步骤是在软件完成的最终期限的压力已经开始出现的时候才开始进行的，所以测试的进度必须是可测量的，而且问题要尽可能早的暴露出来。 

第 9 贴【 2004 － 5 － 18 】：白盒测试 

Rex Black 
白盒测试，也称为结构化测试、基于代码的测试，是一种测试用例设计方法，它从程序的控制结构导出测试用例。用白盒测试产生的测试用例能够： 
1 ）保证一个模块中的所有独立路径至少被使用一次； 
2 ）对所有逻辑值均需测试 true 和 false ； 
3 ）在上下边界及可操作范围内运行所有循环； 
4 ）检查内部数据结构以确保其有效性。 

“ 我们应该更注重于保证程序需求的实现，为什么要花费时间和精力来担心（和测试）逻辑细节？ ” 答案在于软件自身的缺陷： 
1 、逻辑错误和不正确假设与一条程序路径被运行的可能性成反比。当我们设计和实现主流之外的功能、条件或控制时，错误往往开始出现在我们工作中。日常处理往往被很好地了解，而 “ 特殊情况 ” 的处理则难于发现。 
2 、我们经常相信某逻辑路径不可能被执行，而事实上，它可能在正常的基础上被执行。程序的逻辑流有时是违反直觉的，这意味着我们关于控制流和数据流的一些无意识的假设可能导致设计错误，只有路径测试才能发现这些错误。 
3 、笔误是随机的。当一个程序被翻译为程序设计语言源代码时，有可能产生某些笔误，很多将被语法检查机制发现，但是，其他的会在测试开始时才会被发现。笔误出现在主流上和不明显的逻辑路径上的机率是一样的。 

正如 Beizer 所说的： “ 错误潜伏在角落里，聚集在边界上 ” ，而白盒测试更可能发现它。 

第 10 贴【 2004 － 5 － 19 】：黑盒测试 

黑盒测试注重于测试软件的功能性需求，也即黑盒测试使软件工程师派生出执行程序所有功能需求的输入条件。黑盒测试并不是白盒测试的替代品，而是用于辅助白盒测试发现其他类型的错误。黑盒测试试图发现以下类型的错误： 
1 ）功能错误或遗漏； 
2 ）界面错误； 
3 ）数据结构或外部数据库访问错误； 
4 ）性能错误； 
5 ）初始化和终止错误。 

白盒测试在测试的早期采用，而黑盒测试主要用于测试的后期。黑盒测试故意不考虑控制结构，而是注意信息域。黑盒测试用于回答以下问题： 
1 ）如何测试功能的有效性？ 
2 ）何种类型的输入会产生好的测试用例？ 
3 ）系统是否对特定的输入值尤其敏感？ 
4 ）如何分隔数据类的边界？ 
5 ）系统能够承受何种数据率和数据量？ 
6 ）特定类型的数据组合会对系统产生何种影响？ 

运用黑盒测试方法，可以导出满足以下标准的测试用例集： 
1 ）所设计的测试用例能够减少达到合理测试所需的附加测试用例数； 
2 ）所设计的测试用例能够告知某些类型错误的存在或不存在，而不是仅仅与特定测试相关的错误。 

第 11 贴【 2004 － 5 － 20 】：软件测试充分性准则 

（ 1 ）空测试对任何软件都是不充分的。 
（ 2 ）对任何软件都存在有限的充分测试集合。 
（ 3 ）如果一个软件系统在一个测试数据集合上的测试是充分的，那么再多测试一些数据也应该是充分的。这一特性称为单调性。 
（ 4 ）即使对软件所有成分都进行了充分的测试，也并不意味着整个软件的测试已经充分了。这一特性称为非复合性。 
（ 5 ）即使对一个软件系统整体的测试是充分的，也并不意味着软件系统中各个成分都已经充分地得到了测试。这个特性称为非分解性。 
（ 6 ）软件测试的充分性应该与软件的需求和软件的实现都相关。 
（ 7 ）软件越复杂，需要的测试数据就越多。这一特性称为复杂性。 
（ 8 ）测试得越多，进一步测试所能得到的充分性增长就越少。这一特性称为回报递减率。 

第 12 贴【 2004 － 5 － 21 】：静态测试 

在软件开发过程中，每产生一个文档，都必须对它进行测试，以确定它的质量是否满足要求。这样的检查工作与全面质量管理的思想是一致的，也与项目管理过程相一致。每当一个文档通过了静态测试，就标志着一项开发工作的总结，标志着项目取得了一定的进展，进入了一个新的阶段。 

静态测试的基本特征是在对软件进行分析、检查和测试时不实际运行被测试的程序。它可以用于对各种软件文档进行测试，是软件开发中十分有效的质量控制方法之一。在软件开发过程中的早期阶段，由于可运行的代码尚未产生，不可能进行动态测试，而这些阶段的中间产品的质量直接关系到软件开发的成败与开销的大小，因此，在这些阶段，静态测试的作用尤为重要。在软件开发多年的生产实践经验和教训的基础上，人们总结出了一些行之有效的静态测试技术和方法，如结构化走通、正规检视等等。这些方法和测试技术可以与软件质量的定量度量技术相结合，对软件开发过程进行监视、控制，从而保障软件质量。 

第 13 贴【 2004 － 5 － 22 】：什么是测试需求？ 

Brian Marick 
测试需求的概念比较简单。例如，比方说一个计算平方根的程序，如果输入一个大于或等于零的数，程序可以给出一个结果；如果输入一个小于零的数，程序将指出输入错误。读过《软件测试的艺术》一书的工程师都会立即联想到边界值。对数值零进行测试；对零非常接近的负数进行测试，这就是两个具体的测试需求。 

在一个更加复杂的程序中，你可以将打算测试的项目做成一个列表。但是，这些测试需求都不会确定具体的测试数据。例如，一个银行交易程序，一个测试需求是试图支付客户的金额为负数，另一个测试需求是交易中的客户并不存在，等等。你有一系列这样的测试需求，它们并没有指出具体的数值或数据，如客户的姓名。 

测试的下一步是选择满足这些测试需求的输入值 / 测试数据。一个简单的测试用例可能会同时满足好几个测试需求。一个用例能同时满足好几个测试需求，当然是最理想的情况，但是这样做的代价较高。另外一种方法是为每一个测试需求设计一个单独的测试用例，就可以不必考虑那些复杂的测试用例，但是这些相对简单的测试用例发现缺陷的能力就会有所下降。 

这里有一个测试需求的实例：对一个哈希表的插入操作进行测试，有以下这些测试需求： 
1 ）插入一个新的条目 
2 ）插入失败－条目已经存在 
3 ）插入失败－表已满 
4 ）哈希表在插入前为空 
这些就是测试需求，而非测试用例，因为它们没有对被插入元素进行描述。另外你也不能马上就着手书写用例，就好象软件需求完成后不能立即进行编码一样。还需要对测试需求进行评审，确保正确和没有需求遗漏。 

第 14 贴【 2004 － 5 － 30 】： GUI 测试 

Roger S. Pressman 

图形用户界面（ GUI ）对软件测试提出了有趣的挑战，因为 GUI 开发环境有可复用的构件，开发用户界面更加省时而且更加精确。同时， GUI 的复杂性也增加了，从而加大了设计和执行测试用例的难度。因为现在 GUI 设计和实现有了越来越多的类似，所以也就产生了一系列的测试标准。下列问题可以作为常见 GUI 测试的指南： 

窗口： 
· 窗口是否基于相关的输入和菜单命令适当地打开？ 
· 窗口能否改变大小、移动和滚动？ 
· 窗口中的数据内容能否用鼠标、功能键、方向键和键盘访问？ 
· 当被覆盖并重新调用后，窗口能否正确地再生？ 
· 需要时能否使用所有窗口相关的功能？ 
· 所有窗口相关的功能是可操作的吗？ 
· 是否有相关的下拉式菜单、工具条、滚动条、对话框、按钮、图标和其他控制可为窗口使用，并适当地显示？ 
· 显示多个窗口时，窗口的名称是否被适当地表示？ 
· 活动窗口是否被适当地加亮？ 
· 如果使用多任务，是否所有的窗口被实时更新？ 
· 多次或不正确按鼠标是否会导致无法预料的副作用？ 
· 窗口的声音和颜色提示和窗口的操作顺序是否符合需求？ 
· 窗口是否正确地被关闭？ 

下拉式菜单和鼠标操作： 
· 菜单条是否显示在合适的语境中？ 
· 应用程序的菜单条是否显示系统相关的特性（如时钟显示）？ 
· 下拉式操作能正确工作吗？ 
· 菜单、调色板和工具条是否工作正确？ 
· 是否适当地列出了所有的菜单功能和下拉式子功能？ 
· 是否可以通过鼠标访问所有的菜单功能？ 
· 文本字体、大小和格式是否正确？ 
· 是否能够用其他的文本命令激活每个菜单功能？ 
· 菜单功能是否随当前的窗口操作加亮或变灰？ 
· 菜单功能是否正确执行？ 
· 菜单功能的名字是否具有自解释性？ 
· 菜单项是否有帮助，是否语境相关？ 
· 在整个交互式语境中，是否可以识别鼠标操作？ 
· 如果要求多次点击鼠标，是否能够在语境中正确识别？ 
· 光标、处理指示器和识别指针是否随操作恰当地改变？ 

数据项： 
· 字母数字数据项是否能够正确回显，并输入到系统中？ 
· 图形模式的数据项（如滚动条）是否正常工作？ 
· 是否能够识别非法数据？ 
· 数据输入消息是否可理解？ 

第 15 贴【 2004 － 5 － 31 】： Client/Server 测试 

Roger S. Pressman 

通常，客户 / 服务器软件的测试发生在三个不同的层次： 
（ 1 ）个体的客户端应用以 “ 分离的 ” 模式被测试 —— 不考虑服务器和底层网络的运行； 
（ 2 ）客户端软件和关联的服务器端应用被一起测试，但网络运行不被明显的考虑； 
（ 3 ）完整的 C/S 体系结构，包括网络运行和性能，被测试。 

下面的测试方法是 C/S 应用中经常用到的： 
应用功能测试 —— 客户端应用被独立地执行，以揭示在其运行中的错误。 
服务器测试 —— 测试服务器的协调和数据管理功能，也考虑服务器性能（整体反映时间和数据吞吐量）。 
数据库测试 —— 测试服务器存储的数据的精确性和完整性，检查客户端应用提交的事务，以保证数据被正确地存储、更新和检索。 
事务测试 —— 创建一系列的测试以保证每类事务被按照需求处理。测试着重于处理的正确性，也关注性能问题。 
网络通信测试 —— 这些测试验证网络节点间的通信正常地发生，并且消息传递、事务和相关的网络交通无错的发生。

第 1 帖【 2004 － 5 － 10 】：软件测试的理想模式是什么？ 

Brian Marick ：我不认为存在什么理想模式。我觉得让开发人员承担某些测试也许会更加有效，而其他测试则由独立测试组来进行。因为如果你把所有测试都交给独立测试组，他们不可能有时间把所有测试都做好。所以，最佳的方式是让开发人员承担一定量的测试，独立测试组给予他们支持。独立测试组主要承担整个系统的测试，去寻找开发人员还没有发现的缺陷，如子系统间的交互、运行条件、内存使用等。 

如何更有效地开展系统测试呢？让测试人员在项目初期就参与进去，让他们看到第一版的系统需求、用户手册和系统原型，在系统实现前就对需求进行捕获和跟踪。在该过程中，他们从这些文档构造最初的测试设计。这也可以通过检视或评审的形式进行，并且在该过程中会发现一些缺陷。大家都知道，这个阶段，问题发现是非常 “ 便宜 ” 的。 

这样，系统测试工程师在项目早期就介入，产生测试设计及基本的需要测试的项目列表。这时不可能产生一个绝对完备的测试设计，因为书写完整测试的条件还不成熟，但这却是构建完整测试的基础。 

注： Brian Marick 是 Reliability Software 公司的专职测试技术顾问。 

第 2 帖【 2004 － 5 － 11 】：测试经理角色定位 

Johanna Rothman ：测试经理服务于两种完全不同的客户：测试工程师和高层管理者。对于测试工程师，测试经理帮助他们开发产品测试策略，积累产品测试经验并在测试组内充分共享。对于高层管理者，测试经理搜集尽可能全面的产品信息，供其就产品是否可以发布进行决策。但是有一点是相同的：无论是对于测试工程师还是高层管理者，测试经理将帮助其定义和校验产品发布标准。 

产品发布标准的定义和校验：作为一个测试经理，应该找机会与市场、开发人员商讨产品发布标准，并根据客户的反馈对该标准进行修正和校验。开发部门的工作是如何达到公司对产品的期望，要用客户需求为开发人员勾画出客户眼中的产品以及产品应如何工作。一旦产品被清楚地定义，就可以通过测试去验证产品在多大程度上满足了客户需求。 

对于测试工程师而言有一点非常重要：将测试任务按优先级划分，使产品发布标准得以满足。由于只有极少数的项目有充足的时间去完成所有事情，所以告诉测试工程师关于 “ 测什么和何时测 ” 测试经理的一个重要职责。 

高层管理者需要充分理解产品发布标准，以决定产品是否可以按时发布。我不认为测试组有权利裁决产品是否应该被发布，该权利在组织高层管理者那里。在有了一个通过讨论、达成一致的产品发布标准后，项目组也可以更清楚地了解和认识产品质量。 

第 3 贴【 2004 － 5 － 12 】：测试的基本原则 

（美） Roger S. Pressman 
在设计有效测试用例之前，测试工程师必需理解软件测试的基本原则。这里有一组测试原则： 
1 、所有的测试都应追溯到用户需求。正如我们所知：软件测试的目标在于揭示错误。而最严重的错误（从用户角度来看）是那些导致程序无法满足需求的错误。 
2 、应该在测试工作真正开始前的较长时间内就进行测试计划。测试计划可以在需求模型一完成就开始，详细的测试用例定义可以在设计模型被确定后立即开始。因此，所有测试应该在任何代码被产生前就进行计划和设计。 
3 、 Pareto 原则应用于软件测试。简单地讲， Pareto 原则暗示着测试发现的错误中的 80 ％很可能起源于程序模块中的 20 ％。当然，问题在于如何孤立这些有疑点的模块并进行彻底的测试。 
4 、测试应从 “ 小规模 ” 开始，逐步转向 “ 大规模 ” 。最初的测试通常把焦点放在单个程序模块上，进一步测试的焦点则转向在集成的模块簇中寻找错误，最后在整个系统中寻找错误。 
5 、穷举测试是不可能的。即使是一个大小适度的程序，其路径排列的数量也非常大。因此，在测试中不可能运行路径的每一种组合。然而，充分覆盖程序逻辑，并确保程序设计中使用的所有条件是有可能的。 
6 、为了达到最佳效果，应该由独立的第三方来构造测试。 “ 最佳效果 ” 指最有可能发现错误的测试（测试的主要目标），所以创建系统的软件工程师并不是构造软件测试的最佳人选。 

第 4 贴【 2004 － 5 － 13 】：什么是 “ 好 ” 的测试？ 

什么是 “ 好 ” 的测试？ Kaner ， Falk & Nguyen 
1 、一个好的测试发现错误的可能性很高 
为了达到这个目标，测试者必需理解软件、并尝试设想软件如何才能失败，例如：在 GUI （图形用户界面）中有一种潜在的错误，即错误识别鼠标位置，那么就应该设计一个测试集来验证是否存在鼠标位置识别的错误。 
2 、一个好的测试并不冗余 
测试的时间和资源是有限的，没有必要构造一个与其他测试用例完全相同的测试，每一个测试都应该有不同的用途〔哪怕是细微的差异〕。例如，软件 SafeHome 中有一个模块被用来识别用户密码以决定是否启动系统，为了测试密码输入的错误，测试者设计了一系列的输入密码。在不同的测试中输入有效与无效密码（ 4 个数字），然而，每一个有效 / 无效密码将只检测一种不同错误模式，例如一个将 8080 作为有效密码的系统将不会接受非法密码 1234 ，如果接受 1234 ，将产生错误，另一个测试输入 1235 ，与 1234 的测试意图相同，因此是冗余的，然而，非法输入 8081 或 8180 就有些细微的差异，即对与有效密码相近但并不相同的密码应该进行测试。 
3 、一个好的测试应该是 “ 最佳品种 ” 
在一组目的相似的测试中，时间和资源的限制可能只影响其某个子集的执行，此时，应该使用最可能找到所有错误的测试。 
4 、一个好的测试既不会太简单，也不会太复杂 
虽然有时会将一组测试组合到一个测试用例中，其副作用可能屏蔽错误，通常每一个测试应该独立执行。 

第 5 贴【 2004 － 5 － 14 】：软件可测试性 

Roger S. Pressman 
理想情况下，软件工程师在设计计算机程序、系统或产品时应该考虑可测试性，这就使得测试工程师能够更容易地设计有效的测试用例。 

什么是 “ 可测试性 ” ？软件的可测试性是指软件发现故障并隔离、定位其故障的能力特性，以及在一定的时间和成本前提下，进行测试设计、测试执行的能力。 James Bach 这样描述可测试性：软件可测试性就是一个计算机程序能够被测试的容易程度。 

以下是一个常见的软件可测试性检查表： 
· 可操作性－ “ 运行地越好，被测试的效率越高。 ” 
· 可观察性－ “ 所看见的，就是所测试的。 ” 
· 可控制性－ “ 对软件的控制越好，测试越能够被自动执行与优化。 ” 
· 可分解性－ “ 通过控制测试范围，能够更好地分解问题，执行更灵巧的再测试。 ” 
· 简单性－ “ 需要测试的内容越少，测试的速度越快。 ” 
· 稳定性－ “ 改变越少，对测试的破坏越小。 ” 
· 易理解性－ “ 得到的信息越多，进行的测试越灵巧。 ”

第 6 贴【 2004 － 5 － 15 】：实时系统测试 

Roger S. Pressman 

很多实时系统的时间依赖性和异步性给测试带来新的困难－－时间！测试用例的设计者考虑的不仅是白盒和黑盒测试用例，而且包括事件处理（如中断处理）、数据的时间序列以及处理数据的任务（进程）的并发性。很多情况下，提供的测试数据有时使得实时系统在某状态下可以正常运行，而同样的数据在系统处于不同状态时有时又会导致错误。 

另外，实时系统的软件和硬件之间的密切关系也会导致测试问题，软件测试必须考虑硬件故障对软件处理的影响，这种故障很难实时仿真。由于实时系统的特殊性和复杂性，还没有一个完善的综合性的测试用例设计方法，但是，大致可以分为以下四个步骤： 

1 、任务测试。测试实时系统的第一步是独立的测试各个任务。对每一个任务设计白盒和黑盒测试用例，并在测试时执行每个任务。任务测试能够发现逻辑和功能错误，但是不能发现时间和行为错误。 

2 、行为测试。利用 CASE 工具创建软件模型，就可能仿真实时系统，并按照外部事件的序列检查其行为，这些分析活动可作为创建实时系统时设计测试用例的基础。 

3 、任务间测试。在隔离了任务内部和系统行为错误以后，测试就要转向时间相关的错误。用不同的数据率和处理负载来测试与其他任务通讯的异步任务，看任务间的同步是否会产生错误。另外，测试通过消息队列和数据存储进行通讯的任务，以发现这些数据存储区区域大小方面的错误。 

4 、系统测试。集成软件和硬件，并进行大范围的系统测试，以发现软件 / 硬件接口间的错误。

第 7 贴【 2004 － 5 － 16 】：单元测试、集成测试、系统测试、验收测试、回归测试 

Software Research 
单元测试：单元测试是对软件中的基本组成单位进行的测试，如一个模块、一个过程等等。它是软件动态测试的最基本的部分，也是最重要的部分之一，其目的是检验软件基本组成单位的正确性。一个软件单元的正确性是相对于该单元的规约而言的。因此，单元测试以被测试单位的规约为基准。单元测试的主要方法有控制流测试、数据流测试、排错测试、分域测试等等。 

集成测试：集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。它根据集成测试计划，一边将模块或其他软件单位组合成越来越大的系统，一边运行该系统，以分析所组成的系统是否正确，各组成部分是否合拍。集成测试的策略主要有自顶向下和自底向上两种。 

系统测试：系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并非一项简单的任务，它被称为测试的 “ 先知者问题 ” 。因此，系统测试应该按照测试计划进行，其输入、输出和其他动态运行行为应该与软件规约进行对比。软件系统测试方法很多，主要有功能测试、性能测试、随机测试等等。 

验收测试：验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。它的测试数据通常是系统测试的测试数据的子集。所不同的是，验收测试常常有软件系统的购买者代表在现场，甚至是在软件安装使用的现场。这是软件在投入使用之前的最后测试。 

回归测试：回归测试是在软件维护阶段，对软件进行修改之后进行的测试。其目的是检验对软件进行的修改是否正确。这里，修改的正确性有两重含义：一是所作的修改达到了预定目的，如错误得到改正，能够适应新的运行环境等等；二是不影响软件的其他功能的正确性。