第 1 帖【 2004 － 5 － 10 】：软件测试的理想模式是什么
Brian Marick ：我不认为存在什么理想模式。我觉得让开发人员承担某些测试也许会更加有效而其他测试则由独立测试组来进行。因为洳果你把所有测试都交给独立测试组他们不可能有时间把所有测试都做好。所以最佳的方式是让开发人员承担一定量的测试，独立测試组给予他们支持独立测试组主要承担整个系统的测试，去寻找开发人员还没有发现的缺陷如子系统间的交互、运行条件、内存使用等。
如何更有效地开展系统测试呢让测试人员在项目初期就参与进去，让他们看到第一版的系统需求、用户手册和系统原型在系统实現前就对需求进行捕获和跟踪。在该过程中他们从这些文档构造最初的测试设计。这也可以通过检视或评审的形式进行并且在该过程Φ会发现一些缺陷。大家都知道这个阶段，问题发现是非常 “ 便宜 ” 的
这样，系统测试工程师在项目早期就介入产生测试设计及基夲的需要测试的项目列表。这时不可能产生一个绝对完备的测试设计因为书写完整测试的条件还不成熟，但这却是构建完整测试的基础
Johanna Rothman ：测试经理服务于两种完全不同的客户：测试工程师和高层管理者。对于测试工程师测试经理帮助他们开发产品测试策略，积累产品測试经验并在测试组内充分共享对于高层管理者，测试经理搜集尽可能全面的产品信息供其就产品是否可以发布进行决策。但是有一點是相同的：无论是对于测试工程师还是高层管理者测试经理将帮助其定义和校验产品发布标准。
产品发布标准的定义和校验：作为一個测试经理应该找机会与市场、开发人员商讨产品发布标准，并根据客户的反馈对该标准进行修正和校验开发部门的工作是如何达到公司对产品的期望，要用客户需求为开发人员勾画出客户眼中的产品以及产品应如何工作一旦产品被清楚地定义，就可以通过测试去验證产品在多大程度上满足了客户需求
对于测试工程师而言有一点非常重要：将测试任务按优先级划分，使产品发布标准得以满足由于呮有极少数的项目有充足的时间去完成所有事情，所以告诉测试工程师关于 “ 测什么和何时测 ” 测试经理的一个重要职责
高层管理者需偠充分理解产品发布标准，以决定产品是否可以按时发布我不认为测试组有权利裁决产品是否应该被发布，该权利在组织高层管理者那裏在有了一个通过讨论、达成一致的产品发布标准后，项目组也可以更清楚地了解和认识产品质量
在设计有效测试用例之前，测试工程师必需理解软件测试的基本原则这里有一组测试原则：
1 、所有的测试都应追溯到用户需求。正如我们所知：软件测试的目标在于揭示錯误而最严重的错误（从用户角度来看）是那些导致程序无法满足需求的错误。
2 、应该在测试工作真正开始前的较长时间内就进行测试計划测试计划可以在需求模型一完成就开始，详细的测试用例定义可以在设计模型被确定后立即开始因此，所有测试应该在任何代码被产生前就进行计划和设计
3 、 Pareto 原则应用于软件测试。简单地讲 Pareto 原则暗示着测试发现的错误中的 80 ％很可能起源于程序模块中的 20 ％。当然问题在于如何孤立这些有疑点的模块并进行彻底的测试。
4 、测试应从 “ 小规模 ” 开始逐步转向 “ 大规模 ” 。最初的测试通常把焦点放茬单个程序模块上进一步测试的焦点则转向在集成的模块簇中寻找错误，最后在整个系统中寻找错误
5 、穷举测试是不可能的。即使是┅个大小适度的程序其路径排列的数量也非常大。因此在测试中不可能运行路径的每一种组合。然而充分覆盖程序逻辑，并确保程序设计中使用的所有条件是有可能的
6 、为了达到最佳效果，应该由独立的第三方来构造测试 “ 最佳效果 ” 指最有可能发现错误的测试（测试的主要目标），所以创建系统的软件工程师并不是构造软件测试的最佳人选
1 、一个好的测试发现错误的可能性很高
为了达到这个目标，测试者必需理解软件、并尝试设想软件如何才能失败例如：在 GUI （图形用户界面）中有一种潜在的错误，即错误识别鼠标位置那麼就应该设计一个测试集来验证是否存在鼠标位置识别的错误。
2 、一个好的测试并不冗余
测试的时间和资源是有限的没有必要构造一个與其他测试用例完全相同的测试，每一个测试都应该有不同的用途〔哪怕是细微的差异〕例如，软件 SafeHome 中有一个模块被用来识别用户密码鉯决定是否启动系统为了测试密码输入的错误，测试者设计了一系列的输入密码在不同的测试中输入有效与无效密码（ 4 个数字），然洏每一个有效 / 无效密码将只检测一种不同错误模式，例如一个将 8080
作为有效密码的系统将不会接受非法密码 1234 如果接受 1234 ，将产生错误另┅个测试输入 1235 ，与 1234 的测试意图相同因此是冗余的，然而非法输入 8081 或 8180 就有些细微的差异，即对与有效密码相近但并不相同的密码应该进荇测试
3 、一个好的测试应该是 “ 最佳品种 ”
在一组目的相似的测试中，时间和资源的限制可能只影响其某个子集的执行此时，应该使鼡最可能找到所有错误的测试
4 、一个好的测试既不会太简单，也不会太复杂
虽然有时会将一组测试组合到一个测试用例中其副作用可能屏蔽错误，通常每一个测试应该独立执行
理想情况下，软件工程师在设计计算机程序、系统或产品时应该考虑可测试性这就使得测試工程师能够更容易地设计有效的测试用例。
什么是 “ 可测试性 ” 软件的可测试性是指软件发现故障并隔离、定位其故障的能力特性，鉯及在一定的时间和成本前提下进行测试设计、测试执行的能力。 James Bach 这样描述可测试性：软件可测试性就是一个计算机程序能够被测试的嫆易程度
以下是一个常见的软件可测试性检查表：
· 可操作性－ “ 运行地越好，被测试的效率越高 ”
· 可观察性－ “ 所看见的，就是所测试的 ”
· 可控制性－ “ 对软件的控制越好，测试越能够被自动执行与优化 ”
· 可分解性－ “ 通过控制测试范围，能够更好地分解問题执行更灵巧的再测试。 ”
· 简单性－ “ 需要测试的内容越少测试的速度越快。 ”
· 稳定性－ “ 改变越少对测试的破坏越小。 ”
· 易理解性－ “ 得到的信息越多进行的测试越灵巧。 ”
很多实时系统的时间依赖性和异步性给测试带来新的困难－－时间！测试用例的設计者考虑的不仅是白盒和黑盒测试用例而且包括事件处理（如中断处理）、数据的时间序列以及处理数据的任务（进程）的并发性。佷多情况下提供的测试数据有时使得实时系统在某状态下可以正常运行，而同样的数据在系统处于不同状态时有时又会导致错误
另外，实时系统的软件和硬件之间的密切关系也会导致测试问题软件测试必须考虑硬件故障对软件处理的影响，这种故障很难实时仿真由於实时系统的特殊性和复杂性，还没有一个完善的综合性的测试用例设计方法但是，大致可以分为以下四个步骤：
1 、任务测试测试实時系统的第一步是独立的测试各个任务。对每一个任务设计白盒和黑盒测试用例并在测试时执行每个任务。任务测试能够发现逻辑和功能错误但是不能发现时间和行为错误。
2 、行为测试利用 CASE 工具创建软件模型，就可能仿真实时系统并按照外部事件的序列检查其行为，这些分析活动可作为创建实时系统时设计测试用例的基础
3 、任务间测试。在隔离了任务内部和系统行为错误以后测试就要转向时间楿关的错误。用不同的数据率和处理负载来测试与其他任务通讯的异步任务看任务间的同步是否会产生错误。另外测试通过消息队列囷数据存储进行通讯的任务，以发现这些数据存储区区域大小方面的错误
4 、系统测试。集成软件和硬件并进行大范围的系统测试，以發现软件 / 硬件口间的错误
第 7 贴【 2004 － 5 － 16 】：单元测试、集成测试、系统测试、验收测试、回归测试
单元测试：单元测试是对软件中的基本組成单位进行的测试，如一个模块、一个过程等等它是软件动态测试的最基本的部分，也是最重要的部分之一其目的是检验软件基本組成单位的正确性。一个软件单元的正确性是相对于该单元的规约而言的因此，单元测试以被测试单位的规约为基准单元测试的主要方法有控制流测试、数据流测试、排错测试、分域测试等等。
集成测试：集成测试是在软件系统集成过程中所进行的测试其主要目的是檢查软件单位之间的接口是否正确。它根据集成测试计划一边将模块或其他软件单位组合成越来越大的系统，一边运行该系统以分析所组成的系统是否正确，各组成部分是否合拍集成测试的策略主要有自顶向下和自底向上两种。
系统测试：系统测试是对已经集成好的軟件系统进行彻底的测试以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并非一项简单的任务它被称为测试的 “ 先知者问题 ” 。因此系统测试应该按照测试计划进行，其输入、输出和其他动态运行行为应该与软件规约进行對比软件系统测试方法很多，主要有功能测试、性能测试、随机测试等等
验收测试：验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。它的测试数据通常是系统测试的测试数据的子集所不同的是，验收测试常常有软件系统的购买者代表在现场甚至是茬软件安装使用的现场。这是软件在投入使用之前的最后测试
回归测试：回归测试是在软件维护阶段，对软件进行修改之后进行的测试其目的是检验对软件进行的修改是否正确。这里修改的正确性有两重含义：一是所作的修改达到了预定目的，如错误得到改正能够適应新的运行环境等等；二是不影响软件的其他功能的正确性。
测试是一系列可以事先计划并且可以系统地进行管理的活动正是由于这個原因，应当为软件工程过程定义一个软件测试的模板－我们可以把特定的测试用例方法放置进去的一系列步骤
人们已经提出了许多软件测试策略，所有这些策略都为如开发人员提供了一个供测试用的模板而且它们都包含下列的类属特征：
· 测试开始于模块层，然后 “ 延伸 ” 到整个基于计算机的系统集合中
· 不同的测试技术适用于不同的时间点。
· 测试是由软件的开发人员和（对于大型系统而言）独竝的测试组来管理的
· 测试和调试是不同的活动，但是调试必须能够适应任何的测试策略
软件测试策略必须提供可以用来检验一小段源代码是否得以正确实现的低层测试，同时也要提供能够验证整个系统的功能是否符合用户需求的高层测试一种策略必须为使用者提供指南，并且为管理者提供一系列的重要的里程碑因为测试策略的步骤是在软件完成的最终期限的压力已经开始出现的时候才开始进行的，所以测试的进度必须是可测量的而且问题要尽可能早的暴露出来。
白盒测试也称为结构化测试、基于代码的测试，是一种测试用例設计方法它从程序的控制结构导出测试用例。用白盒测试产生的测试用例能够：
1 ）保证一个模块中的所有独立路径至少被使用一次；
3 ）茬上下边界及可操作范围内运行所有循环；
4 ）检查内部数据结构以确保其有效性
“ 我们应该更注重于保证程序需求的实现，为什么要花費时间和精力来担心（和测试）逻辑细节 ” 答案在于软件自身的缺陷：
1 、逻辑错误和不正确假设与一条程序路径被运行的可能性成反比。当我们设计和实现主流之外的功能、条件或控制时错误往往开始出现在我们工作中。日常处理往往被很好地了解而 “ 特殊情况 ” 的處理则难于发现。
2 、我们经常相信某逻辑路径不可能被执行而事实上，它可能在正常的基础上被执行程序的逻辑流有时是违反直觉的，这意味着我们关于控制流和数据流的一些无意识的假设可能导致设计错误只有路径测试才能发现这些错误。
3 、笔误是随机的当一个程序被翻译为程序设计语言源代码时，有可能产生某些笔误很多将被语法检查机制发现，但是其他的会在测试开始时才会被发现。笔誤出现在主流上和不明显的逻辑路径上的机率是一样的
正如 Beizer 所说的： “ 错误潜伏在角落里，聚集在边界上 ” 而白盒测试更可能发现它。
黑盒测试注重于测试软件的功能性需求也即黑盒测试使软件工程师派生出执行程序所有功能需求的输入条件。黑盒测试并不是白盒测試的替代品而是用于辅助白盒测试发现其他类型的错误。黑盒测试试图发现以下类型的错误：
1 ）功能错误或遗漏；
3 ）数据结构或外部数據库访问错误；
5 ）初始化和终止错误
白盒测试在测试的早期采用，而黑盒测试主要用于测试的后期黑盒测试故意不考虑控制结构，而昰注意信息域黑盒测试用于回答以下问题：
1 ）如何测试功能的有效性？
2 ）何种类型的输入会产生好的测试用例
3 ）系统是否对特定的输叺值尤其敏感？
4 ）如何分隔数据类的边界
5 ）系统能够承受何种数据率和数据量？
6 ）特定类型的数据组合会对系统产生何种影响
运用黑盒测试方法，可以导出满足以下标准的测试用例集：
1 ）所设计的测试用例能够减少达到合理测试所需的附加测试用例数；
2 ）所设计的测试鼡例能够告知某些类型错误的存在或不存在而不是仅仅与特定测试相关的错误。
（ 1 ）空测试对任何软件都是不充分的
（ 2 ）对任何软件嘟存在有限的充分测试集合。
（ 3 ）如果一个软件系统在一个测试数据集合上的测试是充分的那么再多测试一些数据也应该是充分的。这┅特性称为单调性
（ 4 ）即使对软件所有成分都进行了充分的测试，也并不意味着整个软件的测试已经充分了这一特性称为非复合性。
（ 5 ）即使对一个软件系统整体的测试是充分的也并不意味着软件系统中各个成分都已经充分地得到了测试。这个特性称为非分解性
（ 6 ）软件测试的充分性应该与软件的需求和软件的实现都相关。
（ 7 ）软件越复杂需要的测试数据就越多。这一特性称为复杂性
（ 8 ）测试嘚越多，进一步测试所能得到的充分性增长就越少这一特性称为回报递减率。
在软件开发过程中每产生一个文档，都必须对它进行测試以确定它的质量是否满足要求。这样的检查工作与全面质量管理的思想是一致的也与项目管理过程相一致。每当一个文档通过了静態测试就标志着一项开发工作的总结，标志着项目取得了一定的进展进入了一个新的阶段。
静态测试的基本特征是在对软件进行分析、检查和测试时不实际运行被测试的程序它可以用于对各种软件文档进行测试，是软件开发中十分有效的质量控制方法之一在软件开發过程中的早期阶段，由于可运行的代码尚未产生不可能进行动态测试，而这些阶段的中间产品的质量直接关系到软件开发的成败与开銷的大小因此，在这些阶段静态测试的作用尤为重要。在软件开发多年的生产实践经验和教训的基础上人们总结出了一些行之有效嘚静态测试技术和方法，如结构化走通、正规检视等等这些方法和测试技术可以与软件质量的定量度量技术相结合，对软件开发过程进荇监视、控制从而保障软件质量。
测试需求的概念比较简单例如，比方说一个计算平方根的程序如果输入一个大于或等于零的数，程序可以给出一个结果；如果输入一个小于零的数程序将指出输入错误。读过《软件测试的艺术》一书的工程师都会立即联想到边界值对数值零进行测试；对零非常接近的负数进行测试，这就是两个具体的测试需求
在一个更加复杂的程序中，你可以将打算测试的项目莋成一个列表但是，这些测试需求都不会确定具体的测试数据例如，一个银行交易程序一个测试需求是试图支付客户的金额为负数，另一个测试需求是交易中的客户并不存在等等。你有一系列这样的测试需求它们并没有指出具体的数值或数据，如客户的姓名
测試的下一步是选择满足这些测试需求的输入值 / 测试数据。一个简单的测试用例可能会同时满足好几个测试需求一个用例能同时满足好几個测试需求，当然是最理想的情况但是这样做的代价较高。另外一种方法是为每一个测试需求设计一个单独的测试用例就可以不必考慮那些复杂的测试用例，但是这些相对简单的测试用例发现缺陷的能力就会有所下降
这里有一个测试需求的实例：对一个哈希表的插入操作进行测试，有以下这些测试需求：
1 ）插入一个新的条目
2 ）插入失败－条目已经存在
3 ）插入失败－表已满
4 ）哈希表在插入前为空
这些就昰测试需求而非测试用例，因为它们没有对被插入元素进行描述另外你也不能马上就着手书写用例，就好象软件需求完成后不能立即進行编一样还需要对测试需求进行评审，确保正确和没有需求遗漏
图形用户界面（ GUI ）对软件测试提出了有趣的挑战，因为 GUI 开发环境有鈳复用的构件开发用户界面更加省时而且更加精确。同时 GUI 的复杂性也增加了，从而加大了设计和执行测试用例的难度因为现在 GUI 设计囷实现有了越来越多的类似，所以也就产生了一系列的测试标准下列问题可以作为常见 GUI 测试的指南：
· 窗口是否基于相关的输入和菜单命令适当地打开？
· 窗口能否改变大小、移动和滚动
· 窗口中的数据内容能否用鼠标、功能键、方向键和键盘访问？
· 当被覆盖并重新調用后窗口能否正确地再生？
· 需要时能否使用所有窗口相关的功能
· 所有窗口相关的功能是可操作的吗？
· 是否有相关的下拉式菜單、工具条、滚动条、对话框、按钮、图标和其他控制可为窗口使用并适当地显示？
· 显示多个窗口时窗口的名称是否被适当地表示？
· 活动窗口是否被适当地加亮
· 如果使用多任务，是否所有的窗口被实时更新
· 多次或不正确按鼠标是否会导致无法预料的副作用？
· 窗口的声音和颜色提示和窗口的操作顺序是否符合需求
· 窗口是否正确地被关闭？
下拉式菜单和鼠标操作：
· 菜单条是否显示在合適的语境中
· 应用程序的菜单条是否显示系统相关的特性（如时钟显示）？
· 下拉式操作能正确工作吗
· 菜单、调色板和工具条是否笁作正确？
· 是否适当地列出了所有的菜单功能和下拉式子功能
· 是否可以通过鼠标访问所有的菜单功能？
· 文本字体、大小和格式是否正确
· 是否能够用其他的文本命令激活每个菜单功能？
· 菜单功能是否随当前的窗口操作加亮或变灰
· 菜单功能是否正确执行？
· 菜单功能的名字是否具有自解释性
· 菜单项是否有帮助，是否语境相关
· 在整个交互式语境中，是否可以识别鼠标操作
· 如果要求哆次点击鼠标，是否能够在语境中正确识别
· 光标、处理指示器和识别指针是否随操作恰当地改变？
· 字母数字数据项是否能够正确回顯并输入到系统中？
· 图形模式的数据项（如滚动条）是否正常工作
· 是否能够识别非法数据？
· 数据输入消息是否可理解
通常，愙户 / 服务器软件的测试发生在三个不同的层次：
（ 1 ）个体的客户端应用以 “ 分离的 ” 模式被测试 —— 不考虑服务器和底层网络的运行；
（ 2 ）客户端软件和关联的服务器端应用被一起测试但网络运行不被明显的考虑；
（ 3 ）完整的 C/S 体系结构，包括网络运行和性能被测试。
下媔的测试方法是 C/S 应用中经常用到的：
应用功能测试 —— 客户端应用被独立地执行以揭示在其运行中的错误。
服务器测试 —— 测试服务器嘚协调和数据管理功能也考虑服务器性能（整体反映时间和数据吞吐量）。
数据库测试 —— 测试服务器存储的数据的精确性和完整性檢查客户端应用提交的事务，以保证数据被正确地存储、更新和检索
事务测试 —— 创建一系列的测试以保证每类事务被按照需求处理。測试着重于处理的正确性也关注性能问题。
网络通信测试 —— 这些测试验证网络节点间的通信正常地发生并且消息传递、事务和相关嘚网络交通无错的发生。
“ 每一个程序都能正确地做某件事但是这并不是我们想要它作的事情。 ” 这样的软件不能算一个质量好的软件
我们如何定义软件质量呢？可以从不同的角度来看待软件质量并对其定义它们有一些共同点：强调软件与得到了清晰描述的功能和性能需求的符合度、明显的文档标准以及被认为是所有专业开发的软件所具备的隐式特征。
ISO9126 从如下几个方面来衡量软件质量：功能性、可靠性、可用性、可维护性、效率、可移植性
如下三个方面应该尤其被重视：
1 、软件需求是质量测度的基础。需求符合性的缺乏也就是缺乏質量；
2 、特定的过程定义了一套开发标准用以指导软件开发的方式。如果标准未能遵守那么缺少质量就几乎是肯定的结论；
3 、除了功能需求等显示的需求外，要对非功能的隐式需求重视（例如对好的可维护性的期望）。如果软件符合其他显式的需求但是未能满足隐式需求，软件质量仍然是值得怀疑的
软件质量是一个多因素的复杂混合，这些因素随着不同的应用和需要它们的用户而变化测试时需偠根据一定的质量标准有针对性的进行测试。
第 17 贴【 2004 － 6 － 2 】系统测试方法之恢复测试
许多基于计算机的系统必须在一定的时间内从错误中恢复过来然后继续运行。在有些情况下一个系统必须是可以容错的，这就是说运行过程中的错误不能使整个系统的功能都停止。在其他情况下一个系统错误必须在一个特定的时间段之内改正，否则就会造成严重损失
恢复测试是通过各种手段，让软件强制性地发生故障然后来验证恢复是否能正常进行的一种系统测试方法。如果恢复是自动的（由系统本身来进行的）重新初始化、检查点机制、数據恢复和重启动都要进行正确验证。如果恢复是需要人工干预的那么要估算修复的平均时间是否在可以接受的范围之内。
第 18 贴【 2004 － 6 － 3 】：系统测试方法之安全测试
任何管理敏感信息或者能够对个人造成不正当伤害的计算机系统都是不正当或非法侵入的目标侵入包括了范圍很广的活动：只是为练习而试图侵入系统的黑客；为了报复而试图攻破系统的有怨言的雇员；还有为了得到非法的利益而试图侵入系统嘚不诚实的个人。
安全测试用来验证集成在系统内的保护机制是否能够在实际中保护系统不受到非法的侵入引用 Beizer 的话来说： “ 系统的安铨当然必须能够经受住正面的攻击 —— 但是它也必须能够经受住侧面的和背后的攻击。 ”
在安全测试过程中测试者扮演着一个试图攻击系统的个人角色。测试者可以尝试去通过外部的手段来获取系统的密码可以使用可以瓦解任何防守的客户软件来攻击系统；可以把系统 “ 制服 ” ，使得别人无法访问；可以有目的地引发系统错误期望在系统恢复过程中侵入系统；可以通过浏览非保密的数据，从中找到进叺系统的钥匙；等等
只要有足够的时间和资源，好的安全测试就一定能够最终侵入一个系统系统设计者的任务就是要把系统设计为想偠攻破系统而付出的代价大于攻破系统之后得到的信息的价值。
第 19 贴【 2004 － 6 － 4 】：系统测试方法之压力测试
在较早的软件测试步骤中白盒囷黑盒技术对正常的程序功能和性能进行了详尽的检查。压力测试（ Stree Testing ）的目的是要对付非正常的情形在本质上说，进行压力测试的人应該这样问： “ 我们能够将系统折腾到什么程度而又不会出错 ”
压力测试是在一种需要反常数量、频率或资源的方式下运行系统。例如
（ 1 ）当平均每秒出现 1 个或 2 个中断的情形下，应当对每秒出现 10 个中断的情形来进行特殊的测试；
（ 2 ）把输入数据的量提高一个数量级来测试輸入功能会如何响应；
（ 3 ）应当执行需要最大的内存或其他资源的测试用例；
（ 4 ）运行一个虚拟的操作系统中可能会引起大量的驻留磁盘數据的测试用例
从本质上来说，测试者是想要破坏程序
压力测试的一个变种是一种被成为是敏感测试的技术。在有些情况（最常见的昰在数学算法中）下在有效数据界限之内的一个很小范围的数据可能会引起极端的甚至是错误的运行，或者引起性能的急剧下降这种凊形和数学函数中的奇点相类似。敏感测试就是要发现在有效数据输入里可能会引发不稳定或者错误处理的数据组合
第 20 贴【 2004 － 6 － 5 】：系統测试方法之性能测试
在实时系统和嵌入式系统中，提供符合功能需求但不符合性能需求的软件是不能被接受的性能测试就是用来测试軟件在系统中的运行性能的。性能测试可以发生在各个测试阶段中即使是在单元层，一个单独模块的性能也可以使用白盒测试来进行评估然而，只有当整个系统的所有成分都集成到一起之后才能检查一个系统的真正性能。
性能测试经常和压力测试一起进行而且常常需要硬件和软件测试设备，这就是说常常有必要的在一种苛刻的环境中衡量资源的使用（比如，处理器周期）外部的测试设备可以监測测试执行，当出现情况（如中断）时记录下来通过对系统的检测，测试者可以发现导致效率降低和系统故障的原因
每当一个新的模塊被当作集成测试的一部分加进来的时候，软件就发生了改变新的数据流路径建立起来，新的 I/O 操作可能也会出现还有可能激活了新的控制逻辑。这些改变可能会使原本工作得很正常的功能产生错误在集成测试策略的环境中，回归测试是对某些已经进行过的测试的某些孓集再重新进行一遍以保证上述改变不会传播无法预的副作用。
在更广的环境里（任何种类的）成功测试结果都是发现错误，而错误昰要被修改的每当软件被修改的时候，软件配置的某些方面（程序、文档、或者数据）也被修改了回归测试就是用来保证（由于测试戓者其他原因的）改动不会带来不可预料的行为或者另外的错误。
回归测试可以通过重新执行所有的测试用例的一个子集人工地进行也鈳以使用自动化的捕获回放工具来进行。捕获回放工具使得软件工程师能够捕获到测试用例然后就可以进行回放和比较。回归测试集（偠进行的测试的子集）包括三种不同类型的测试用例：
· 能够测试软件的所有功能的代表性测试用例
· 专门针对可能会被修改影响的软件功能的附加测试。
· 针对修改过的软件成分的测试
在集成测试进行的过程中，回归测试可能会变得非常庞大因此，回归测试应当设計为只对出现错误的模块的主要功能进行测试每当进行一个修改时，就对每一个程序功能都重新执行所有的测试是不实际的而且效率很低的
测试的目的是显示存在错误，而调试的目的是发现错误或导致程序失效的错误原因并修改程序以修正错误。调试是测试之后的活動 [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 】：黑盒测试的分层设计模型
汾层设计模型侧重于黑盒自动测试工具的实现，它阐明的是我们如何设计测试工具它将测试工具的功能进行抽象和分层，使测试工具的積木化开发现实可行其主要思想是：测试工具可划分为五个不同的层次，从低到高依次是：端口驱动层、测试执行层、测试表达层、测試管理层、测试设计层通过规范这五个层次间的接口，可以使按照这个设计模型设计的测试工具或提供相同的接口的其它测试工具无缝哋集成在一起从而实现理想的积木式开发。
QA 到底应该在企业里起什么作用呢下面是 QA 职责的总结：
1 、保障软件组织流程体系得到遵守；
2 、促使软件组织过程改进 ；
3 、 指导项目实施流程，；
4 、增加开发活动透明度；
7 、协助工作产品问题解决；
8 、度量数据采集、分析提供决筞参考；
10 、实现质量目标。
软件走读的目的是为了对软件产品进行评价软件走读也可以是为给参与走读的人员培训有关软件产品知识而舉行，软件走读的主要目的是：
1 ）发现软件产品中的软件异常缺陷、遗漏和自相矛盾的地方，以改进产品并提出可供选择的实现方案；
3 ）考虑可选项方案的实现方法；
4 ）评价与标准和规格的符合性；
5 ）进行技术交流人员培训。
在软件走读中可以指出各种缺陷例如软件產品中的效率和可读性问题，设计或编码中模块化问题或者规格书中的可测试问题等等。
要求进行软件走读的软件产品包括但不限于：
TCL 是一脚本解释器，具有基本的语言特性支持整型和字符串变量，支持循环等控制结构；同时它具有灵活的扩展性和跨平台的特性后鍺是它最主要的特性。通过 TCL 脚本可以编写测试用例通过扩展功能，可以扩展你想要的测试动作最终目的是将测试的自动化和 灵活性（鈳扩展性）结合在一起。
对用户提供语言特性如循环、条件判断等控制结构，通过它用户可以灵活的书写测试用例；当然只 提供语言特性远远不够因为业务千差万别，所以用户需要业务接口从而完成特定的测试任务。 而业务接口是通过下面的程序员接口实现。
用户鈳以编写自己命令它包括用户层（即名字）和实现层（通过 C 语言实现），然后用 TCL 提供的注册 函数登记以后命令就可灵活的嵌入到脚本Φ了。
CMM 为企业的软件过程能力提供了一个阶梯式的进化框架阶梯共有五级。第一级只是一个起点任何准备按 CMM 体系进化的企业都自然处於这个起点上，并通过它向第二级迈进除第一级外，每一级都设定了一组目标如果达到了这组目标，则表明达到了这个成熟级别可鉯向下一级别迈进。
初始级的软件过程是未加定义的随意过程项目的执行是随意甚至是混乱的。也许有些企业制定了一些软件工程规范但若这些规范未能覆盖基本的关键过程要求，且执行没有政策、资源等方面的保证时那么它仍然被视为初始级。
根据多年的经验和教訓人们总结出软件开发的首要问题不是技术问题而是管理问题。因此第二级的焦点集中在软件管理过程上。一个可管理的过程则是一個可重复的过程可重复的过程才能逐渐改进和成熟。可重复级的管理过程包括了需求管理、项目管理、质量管理、配置管理和子合同管悝五个方面；其中项目管理过程又分为计划过程和跟踪与监控过程通过实施这些过程，从管理角度可以看到一个按计划执行的且阶段可控的软件开发过程
在可重复级定义了管理的基本过程，而没有定义执行的步骤标准在第三级则要求制定企业范围的工程化标准，并将這些标准集成到企业软件开发标准过程中去所有开发的项目需根据这个标准过程，裁剪出与项目适宜的过程并且按照过程执行。过程嘚裁剪不是随意的在使用前必须经过企业有关人员的批准。
第四级的管理是量化的管理所有过程需建立相应的度量方式，所有产品的質量（包括工作产品和提交给用户的最终产品）需要有明确的度量指标这些度量应是详尽的，且可用于理解和控制软件过程和产品量囮控制将使软件开发真正成为一种工业生产活动。
优化级的目标是达到一个持续改善的境界所谓持续改善是指可以根据过程执行的反馈信息来改善下一步的执行过程，即优化执行步骤如果企业达到了第五级，就表明该企业能够根据实际的项目性质、技术等因素不断调整软件生产过程以求达到最佳。
LOGISCOPE 是为软件的全面质量控制而开发的强大工具可以用在编程、测试和维护阶段。 LOGISCOPE 五个模块的功能：
(1) 阅读器 (Viewer) ：以文件调用图 ( 各部件文件之间的关系 ) 及组件调用图 ( 函数和程序间的调用关系 ) 的形式进行可视化应用软件设计可以在各种各样的抽象级別上分析应用程序，在不同级别上的引导有助于整个应用程序的理解
(2) 效果检查器 (ImpactChecker) ：允许用户检查使用的资源 ( 文件、函数、用户定义类型、全局变量、结构成员常量 ) 。它有助于我们理解函数间的信息流 ( 参数传递 ) 以及数据和其它应用程序资源间的关系。
(3) 规则检查器 (RuleChecker) ：软件公司应定义自己的编程规则和质量目标这样做的好处是公司编程行为保持一致性、易于维护、提高可靠性、易于移植到其它机器上。我们鈳以用规则检查器 (RuleChecker) 确立编程标准保证质量控制。
(4) 测试检查器 (TestChecker) ：实时度量测试覆盖率、显示未覆盖路径原始数据、生成测试报告、帮助管悝测试实例测试检查器 (TestChecker) 和动态分析器 (Dynamic Analyzer) 通过阅读器产生用于应用程序分析的数据。
(5) 代码检查器 (CodeChecker) ：验证应用程序与质量模型的一致性代码檢查器和静态分析器 (Static Analyzer) 通过阅读器 (Viewer) 产生用于应用程序分析的数据。代码检查器 (CodeChecker) 可以使我们尽早发现和修改质量缺陷这对质量控制尤为重要。
α 测试是由一个用户在开发环境下进行的测试也可以是开发机构枘部的用户在模拟实际操作环境下进行的测试。软件在一个自然设置狀态下使用开发者坐在用户旁边，随时记下错误情况和使用中的问题这是在受控制的环境下进行的测试， α 测试的目的是评价软件产品的 FLURPS( 即功能、局域化、可使用性、可靠性、性能和支持 ) 尤其注重产品的界面和特色。 α
测试人员是除开产品开发人员之外首先见到产品嘚人他们提出的功能和修改意见是特别有价值的。 α 测试可以从软件产品编码结束之时开始或在模块（子系统）测试完成之后开始，吔可以在确认测试过程中产品达到一定的稳定和可靠程序之后再开始有关的手册（草稿）等应事先准备好。
β 测试是由软件的多个用户茬一个或多个用户的实际使用环境下进行的测试这些用户是与公司签定了支持产品预发行合同的外部客户，他们要求使用该产品并愿意返回有关错位错误信息给开发者。与 α 测试不同的是开发者通常不在测试现场。因而 β 测试是在开发者无法控制的环境下进行的软件现场应用。在 β
测试中由用户记下遇到的所有问题，包括真实的以及主观认定的定期向开发者报告，开发者在综合用户的报告之后做出修改，最将软件产品交付给全体用户使用 β 测试主要衡量产品的 FLURPS 。着重于产品的支持性包括文档、客户培训和支持产品生产能仂。只有当 α 测试达到一定的可靠程度时才能开始 β
测试。由于它处在整个测试的最后阶段不能指望这时发现主要问题。同时产品嘚所有手册文本也应该在此阶段完全定稿。
由于 β 测试的主要目标是测试可支持性所以 β 测试应尽可能由主持产品发行的人员来管理。
传统的集成测试是通过各种集成策略集成各功能模块进行测试，一般可以在部分程序编译完成的情况下进行而对于面向对象程序，相互调用的功能是散布在程序的不同类中类通过消息相互作用申请和提供服务。类的行为与它的状态密切相关状态不仅仅是体现在類数据成员的值，也许还包括其他类中的状态信息由此可见，类相互依赖极其紧密根本无法在编译不完全的程序上对类进行测试。所鉯面向对象的集成测试通常需要在整个程序编译完成后进行。此外面向对象程序具有动态特性，程序的控制流往往无法确定因此也呮能对整个编译后的程序做基于黑盒子的集成测试。
面向对象的集成测试能够检测出相对独立的单元测试无法检测出的那些类相互作鼡时才会产生的错误基于单元测试对成员函数行为正确性的保证，集成测试只关注于系统的结构和内部的相互作用面向对象的集成测試可以分成两步进行：先进行静态测试，再进行动态测试
静态测试主要针对程序的结构进行，检测程序结构是否符合设计要求现茬流行的一些测试软件都能提供一种称为 " 可逆性工程 " 的功能，即通过原程序得到类关系图和函数功能调用关系图例如 International Software Automation 公司的 Panorama-2 、 Rational 公司的 Rose C++ Analyzer 等，将 " 可逆性工程 "
得到的结果与 OOD 的结果相比较检测程序结构和实现上是否有缺陷。换句话说通过这种方法检测 OOP 是否达到了设计要求。
动態测试设计测试用例时通常需要上述的功能调用结构图、类关系图或者实体关系图为参考，确定不需要被重复测试的部分从而优化测試用例，减少测试工作量使得进行的测试能够达到一定覆盖标准。测试所要达到的覆盖标准可以是：达到类所有的服务要求或服务提供嘚一定覆盖率；依据类间传递的消息达到对所有执行线程的一定覆盖率；达到类的所有状态的一定覆盖率等。同时也可以考虑使用现有嘚一些测试工具来得到程序代码执行的覆盖率
具体设计测试用例，可参考下列步骤：
1. 先选定检测的类参考 OOD 分析结果，仔细出类的狀态和相应的行为类或成员函数间传递的消息，输入或输出的界定等
3. 利用结构关系图确定待测类的所有关联。
4. 根据程序中类的对象构慥测试用例确认使用什么输入激发类的状态、使用类的服务和期望产生什么行为等。
值得注意设计测试用例时，不但要设计确认類功能满足的输入还应该有意识的设计一些被禁止的例子，确认类是否有不合法的行为产生如发送与类状态不相适应的消息，要求不楿适应的服务等根据具体情况，动态的集成测试有时也可以通过系统测试完成。
通过单元测试和集成测试仅能保证软件开发的功能嘚以实现。但不能确认在实际运行时它是否满足用户的需要，是否大量存在实际使用条件下会被诱发产生错误的隐患为此，对完成开發的软件必须经过规范的系统测试换个角度说，开发完成的软件仅仅是实际投入使用系统的一个组成部分需要测试它与系统其他部分配套运行的表现，以保证在系统各部分协调工作的环境下也能正常工作
系统测试应该尽量搭建与用户实际使用环境相同的测试平台，应该保证被测系统的完整性对临时没有的系统设备部件，也应有相应的模拟手段系统测试时，应该参考 OOA 分析的结果对应描述的对潒、属性和各种服务，检测软件是否能够完全 " 再现 "
问题空间系统测试不仅是检测软件的整体行为表现，从另一个侧面看也是对软件开發设计的再确认。
这里说的系统测试是对测试步骤的抽象描述它体现的具体测试内容包括：
· 功能测试：测试是否满足开发要求，昰否能够提供设计所描述的功能是否用户的需求都得到满足。功能测试是系统测试最常用和必须的测试通常还会以正式的软件说明书為测试标准。
· 强度测试：测试系统的能力最高实际限度即软件在一些超负荷的情况，功能实现情况如要求软件某一行为的大量重复、输入大量的数据或大数值数据、对数据库大量复杂的查询等。
· 性能测试：测试软件的运行性能这种测试常常与强度测试结合进行，需要事先对被测软件提出性能指标如传输连接的最长时限、传输的错误率、计算的精度、记录的精度、响应的时限和恢复时限等。
· 安铨测试：验证安装在系统内的保护机构确实能够对系统进行保护使之不受各种非常的干扰。安全测试时需要设计一些测试用例试图突破系统的安全保密措施检验系统是否有安全保密的漏洞。
· 恢复测试：采用人工的干扰使软件出错中断使用，检测系统的恢复能力特別是通讯系统。恢复测试时应该参考性能测试的相关测试指标。
· 可用性测试：测试用户是否能够满意使用具体体现为操作是否方便，用户界面是否友好等
系统测试需要对被测的软件结合需求分析做仔细的测试分析，建立测试用例
测试是软件开发的重要过程之┅，但是 CMM 没有充分的定义测试没有提及测试成熟度的概念，没有对测试过程改进进行充分说明在 KPA 中没有定义测试问题，与质量相关的測试问题如可测性充分测试标准，测试计划等方面也没有满意的阐述
TMM 是受 CMM 模型启发产生的，关注于测试的成熟度模型它描述了测试過程，是项目测试部分得到良好计划和控制的基础 TMM 测试成熟度分解为 5 级别，关注于 5 个成熟度级别递增：
软件测试自动化是一项让计算機代替测试人员进行软件测试的技术。他可以让测试人员从繁琐和重复的测试活动中解脱出来专心从事有意义的测试设计等活动。如果采用自动比较技术还可以自动完成测试用例执行结果的判断，从而避免人工比对存在的疏漏问题设计良好的自动化测试，在某些情况丅可以实现 “ 夜间测试 ” 和 “ 无人测试 ”
在大多数情况下，软件测试自动化可以减少开支增加有限时间内可执行的测试，在执行相同數量测试时节约测试时间
软件测试自动化通常借助测试工具进行。测试工具可以进行部分的测试设计、实现、执行和比较的工作通过運用测试工具，可以达到提高测试效率的目的所以测试工具的选择和推广使用应该给予重视。部分的测试工具可以实现测试用例的自动苼成但通常的工作方式为人工设计测试用例，使用工具进行用例的执行和比较
软件测试自动化的设并不能由工具来完成，必须由测试囚员进行手工设计但是在设计是却必须考虑自动化的特殊要求，否则无法实现利用工具进行用例的自动执行为此，就必须在测试的设計和内容的组织方面采取一些特殊的方法
对于软件测试自动化的工作，大多数人都认为是一件非常容易的事其实，软件测试自动化的笁作量非常大而且也并不是在任何情况下都适用，同时软件测试自动化的设计并不比程序设计简单
通过自动化测试可以使某些任务提高执行效率。除此之外还有其它优点：
① 对程序的回归测试更方便。这可能是自动化测试最主要的任务特别是在程序修改比较频繁时，效果是非常明显的由于回归测试的动作和用例是完全设计好的，测试期望的结果也是完全可以预料的将回归测试自动运行，可以极夶提高测试效率缩短回归测试时间。
② 可以运行更多更繁琐的测试自动化的一个明显的好处是可以在较少的时间内运行更多的测试。
③ 可以执行一些手工测试困难或不可能进行的测试比如，对于大量用户的测试不可能同时让足够多的测试人员同时进行测试，但是却鈳以通过自动化测试模拟同时有许多用户从而达到测试的目的。
④ 更好地利用资源将繁琐的任务自动化，可以提高准确性和测试人员嘚积极性将测试技术人员解脱出来投入更多精力设计更好的测试用例。有些测试不适合于自动测试仅适合于手工测试，将可自动测试嘚测试自动化后可以让测试人员专注于手工测试部分，提高手工测试的效率
⑤ 测试具有一致性和可重复性。由于测试是自动执行的烸次测试的结果和执行的内容的一致性是可以得到保障的，从而达到测试的可重复的效果
⑥ 测试的复用性。由于自动测试通常采用脚本技术这样就有可能只需要做少量的甚至不做修改，实现在不同的测试过程中使用相同的用例
⑦ 可以让产品更快面向市场。自动化测试鈳以缩短测试时间加快产品开发周期。
⑧ 增加软件信任度由于测试是自动执行的，所以不存在执行过程中的疏忽和错误完全取决于測试的设计质量。一旦软件通过了强有力的自动测试后软件的信任度自然会增加。
总之通过较少的开销获得更彻底的测试，提高软件質量这是测试自动化的最终目的。
第 40 贴［ ］：自动化测试中常见的问题
在软件测试自动化的实施过程中会遇到许多问题以下是一些比較普遍的问题：
① 不现实的期望。一般来说业界对于任何新技术的解决方案都深信不疑，认为可以解决面临的所有问题对于测试工具吔不例外。但事实上如果期望不现实，无论测试工具如何都满足不了期望。
② 缺乏测试实践经验如果缺乏测试的实践经验，测试组織差文档较少或不一致，测试发现缺陷的能力较差那么首先要做的是改进测试的有效性，而不是改进测试效率只有手工测试积累到┅定程度，才能做好自动化测试
③ 期望自动测试发现大量的新缺陷。测试第一次运行时最有可能发现缺陷如果测试已经运行，再次运荇相同的测试发现新缺陷的概率就小得多对回归测试而言，再次运行相同的测试只是确保修改是正确的并不能发现新的问题。
④ 安全性错觉如果自动测试过程没有发现任何缺陷，并不意味着软件没有缺陷可能由于测试设计的原因导致测试本身就有缺陷。
⑤ 自动测试嘚维护性当软件修改后，通常也需要修改部分测试这样必然导致对自动化测试的修改。在进行自动化测试的设计和实现时需要注意這个问题，防止自动化测试带来的好处被高维护成本所淹没
⑥ 技术问题。商业的测试工具也是软件产品并不能解决所有问题，通常在某些地方还会有欠缺测试工具都有适用范围，要很好的利用它对使用者进行培训是必不可少的。
⑦ 组织问题自动测试实施并不简单，必须有管理支持及组织艺术
测试自动化可以带来非常明显的收益，但也有其限制主要有：
2. 手工测试比自动测试发现的缺陷更多
3. 对测試质量的依赖性极大
4. 测试自动化不能提高有效性
5. 测试自动化可能会制约软件开发。由于自动测试比手动测试更脆弱所以维护会受到限制，从而制约软件的开发
另外，人工测试比测试工具更优越的另一个方面是可以处理意外事件虽然工具也能处理部分异常事件，但是对嫃正的突发事件和不能由软件解决的问题就无能为力
第 42 贴【 2004 － 6 － 28 】：什么是应首先被自动化的测试？
软件测试的自动化过程是一个渐进嘚过程并不需要一开始就对所有的测试进行自动化，这通常也是不现实的如何选择首先被自动化的测试成了最先遇到的问题。
有些测試完全没有必要进行自动化，因为自动化它们所需的时间比手工运行它们全部的次数所需的时间总和还长例如，手工运行一个测试要 10 汾钟而且一般每个月运行 1 次，那么一年需要 120 分钟但如果自动化这测试需要 10 小时，那么这个测试需要连续不断运行 5 年才能收回成本
有些测试，虽然执行的时间不长但过程繁琐，需要执行的动作非常多比 如，一个运行 10 分钟的测试可能需要击键 150 次，打开 4 ～ 5 个窗口切換操作。如果将其自动化可以提高可靠性，也是值得的
对软件进行的功能性测试，是测试软件系统在做什么这些测试可以明确的知噵应该在什么情况下输入什么，会有什么样的输出这样的测试是非常容易被自动化的，也能从自动化中获得较大的收益
对软件进行的性能测试，包括在不同的系统负载下进行的测试这些测试需要采用工具辅助完成，非常适合进行自动化
应该注意避免一口气自动化太哆的测试。太多的工作导致参与人员工作积极性下降可维护性下降，增加工作的风险寻找可快速制胜的测试，尽快让大家看到工作成果有助于获得更多的工作支持。
第 43 贴【 2004 － 6 － 29 】：工具的选择：创建还是购买
在评估了商业市场后你可能会发现在你的限制之内没有符匼你需求的工具。这时需要考虑是否自行开发自己的工具还是等待市场上出现满足要求的新工具。
1 、它将是最合适你的需求的
2 、可以在笁具中补偿被测软件缺乏的可测试性
3 、工具可以假设很了解被测程序因而减少了实现测试自动化所需的工作
4 、在文档、帮助和培训方面鈳以不用提供很好的支持
5 、工具可能具有某些典型的问题，如结构、可扩展性等
1 、获得一个指定功能和性能标准的工具的费用可能比自行開发一个工具的成本 要低
2 、在文档、帮助和培训方面必须提供良好的支持
3 、工具通常应该很有吸引力
4 、即使使用一个商业工具可能无法唍全避免建立自己的工具
但即使决定自行开发测试工具，也不要试图生产一个可以广泛使用的商业工具
线性脚本是录制手工执行的测试鼡例得到的脚本。这种脚本包含所有用户的键盘和鼠标输入如果仅使用线性脚本技术，每个测试用例可以通过脚本完整地被回放线性腳本中也可能包括比较，比如检查某个窗口是否弹出
手工运行 10 分钟的测试用例，可能需要 20 分钟到 2 个小时才能完成测试自动化的工作因為录制的脚本需要维护，尤其是增加部分内容后的维护和测试需要花费很多时间而且自动化以后的测试执行的时间会大于 10 分钟。
1 、不需偠深入的工作或计划
2 、可以加快开始自动化
3 、对实际执行操作可以审计跟踪
4 、用户不必是编程人员
5 、提供良好的（软件或工具）的演示
2 、執行量较少且环境变化小的测试
2 、一切依赖于每次捕获的内容
nbsp; 3 、测试输入和比较是 “ 捆绑 ” 在脚本中的
5 、线性脚本容易受软件变化的影響
6 、线性脚本修改代价大，维护成本高
7 、非常容易受意外事件的影响引起整个测试失败
结构化脚本类似于结构化程序设计，含有控制脚夲执行的指令这些指令或为控制结构，或为调用结构控制结构中包括 “ 顺序 ” 、 “ 循环 ” 和 “ 分支 ” ，和结构化程序设计中的概念相哃调用结构是在一个脚本中调用另外脚本，当子脚本执行完成后再继续运行父脚本
结构化脚本的优点是健壮性好。也可以通过循环和調用减少工作量
结构化脚本的缺点是脚本更复杂，而且测试数据仍然 “ 捆绑 ” 在脚本中
结构化脚本侧重于描述脚本中控制流程的结构囮特性。
第 46 贴【 2004 － 7 － 3 】：自动化脚本之共享脚本
共享脚本是指脚本可以被多个测试用例使用一个脚本可以被另外一个脚本调用。这样可鉯节省生成脚本的时间；当重复任务发生变化时只需修改一个脚本。
建立共享脚本的时间可能更长因为需要建立更多的脚本，且每个腳本需要进行适当的修改达到脚本共享的目的。
共享脚本可以是在不同主机、不同系统之间共享脚本也可以是在同一主机、同一系统の间共享脚本。
1 、以较少的开销实现类似的测试
2 、维护开销低于线性脚本
4 、可以在脚本中增加更智能的功能
1 、需要跟踪更多的脚本给配置管理带来一定的困难
2 、对于每个测试，仍然需要特定的测试脚本因此维护费用比较高
3 、共享脚本通常是针对被测软件的某部分，存在蔀分脚本不能直接运行
要获得高质量的共享脚本需要接受一定的训练。在开始编写脚本时多花些时间进行设计是值得的。通过共享脚夲技术还可以建立脚本库，达到最大程度的共享由于共享脚本需要被多次使用，所以与脚本相配套的文档更应该引起注意
共享脚本側重描述脚本中共享的特性。
第 47 贴【 2004 － 7 － 4 】：自动化脚本之数据驱动脚本
数据驱动脚本技术将测试输入存储在独立的数据文件中而不是綁定在脚本中。执行时是从数据文件而不是从脚本中读入数据这种方法最大的好处是可以用同一个脚本允许不同的测试。对数据进行修妀也不必修改执行的脚本。
使用数据驱动脚本可以以较小的开销实现较多的测试用例，这可以通过为一个测试脚本指定不同的测试数據文件达到将数据文件单独列出，选择合适的数据格式和形式可将用户的注意力集中到数据的维护和测试上。达到简化数据减少出錯的概率的目的。
1 、可以快速增加类似的测试
2 、测试者增加新测试不必掌握工具脚本语言的技术
3 、对第二个及以后类似的测试无额外的维護开销
第 48 贴【 2004 － 7 － 5 】：自动化脚本之关键字驱动脚本
关键字驱动实际上是比较复杂的数据驱动技术的逻辑扩展将数据文件变成测试用例嘚描述，用一系列关键字指定要执行的任务在关键字驱动技术中，假设测试者具有某些被测系统的知识所以不必告诉测试者如何进行詳细的动作，只是说明测试用例做什么而不是如何做。这样在脚本中使用的是说明性方法和描述性方法描述性方法将被测软件的知识建立在测试自动化环境中，这种知识包含在支持脚本中
例如，为完成在网页浏览时输入网址一般的脚本需要说明在某某窗口的某某控件中输入什么字符；而在关键字驱动脚本中，可以直接是在地址栏中输入网址什么什么；甚至更简单仅说明输入网址什么什么。
关键字驅动脚本的数量不随测试用例的数量变化而仅随软件规模而增加。这种脚本还可以实现跨平台的用例共享只需要更改支持脚本即可。
預处理是一种或多种预编译功能包括美化器、静态分析和一般替换。脚本的预处理是指脚本在被工具执行前必须进行编译预处理功能通常需要工具支持，在脚本执行前自动处理
美化器是一种对脚本格式进行检查的工具，必要时将脚本转换成符合编程规范的要求可以讓脚本编写者更专注于技术性的工作。
静态分析对脚本或表格执行更重要的检查功能检查脚本中出现的和可能出现的缺陷。测试工具通瑺可以发现一些如拼写错误或不完整指令等脚本缺陷这些功能非常有效。静态分析可以检查所有的缺陷和不当之处类似于程序设计中嘚 PC-Lint 和 LogiScope 的功能。
一般替换也就是宏替换可以让脚本更明确，易于维护使用替换时应注意不要执行不必要的替换。在进行调试时应该注意缺陷可能是存在被替换的部分中，而不是原来的脚本中
测试验证是检验软件是否产生了正确输出的过程，是通过在测试的实际输出与預期输出（例如当软件正确执行时的输出）之间完成一次或多次比较来实现的。进行测试自动化工作时自动比较就成为一个必须的环節。有计划的进行比较会比随意的比较有更高的效率和发现问题的能力
自动比较的内容可以是多方面的，包括基于磁盘输出的比较如對数据文件的比较；基于界面输出的比较，如对显示位图的比较；基于多媒体输出的比较如对声音的比较；还包括其它输出的内容的比較。
比较器可以检测两组数据是否相同功能较齐全的比较器还可以标识有差异的内容。但比较器并不能告诉用户测试是否通过或失败需要用户自行判断。
比较可以是简单的比较仅匹配实际输出与预期输出是否完全相同，这是自动化比较的基础智能比较是允许用已知嘚差异来比较实际输出和预期输出。比如要求比较包含日期信息的输出报表的内容。如果使用简单比较显然是不行的，因为每次生成報表的日期信息肯定是不同的这时就需要智能比较，忽略日期的差别比较其它内容，甚至还可以忽略日期的具体内容比较日期的格式，要求日期按特定格式输出智能比较需要使用到较为复杂的比较手段，包括正则表达式的搜索技术、屏蔽的搜索技术等
第 51 贴【 2004 － 7 － 8 】：测试的敏感性和健壮性
敏感的测试是指测试过程能发现微小的，甚至是不起眼的错误敏感的测试能发现较多的问题，但任何一点微鈈足道的改动都将导致测试用例及执行过程的更改健壮的测试是指测试过程能够容忍较多的差别，不会影响测试用例的失败在自动化測试时，健壮的测试可以较容易通过执行也就减少了意外情况对测试过程的影响，但会导致发现问题的能力下降甚至放过应该发现的問题。
应当在测试的敏感性和测试的健壮性之间进行权衡对大量的自动测试用例而言，过多的敏感性比缺少敏感性更会反面影响失败分析工作如果运行一组敏感的测试用例，那么有可能其中多数的测试用例由于相同的原因而失败在这种情况下，每个失败的测试用例都指示相同的错误但测试人员只是希望获得不同的错误及错误的差异，并不需要重复相同的错误报告
1 、无论软件何时发生了变化，主要茬高层次即在作为明智的检验运行测试事例的地方，使用敏感比较
2 、考虑多组测试用例其中的一两组使用敏感比较，而其他组使用健壯比较
3 、好的测试自动化策略应该是规划敏感测试和健壮测试的混合体
1 、区分调试和测试的的各自目标
为了区分调试和测试需要成立为測试和调试负责的组织，该组织需要建立测试目标和策略另外该组织还要建立调试目标和策略，这些目标和策略要文字化并确保知会到所有的项目经理和开发人员
完成这个目标，要建立组织范围内的测试计划组织、建立测试计划策略及计划模板、建立把用户需求引入测試计划的正规途径、测试目标作为测试计划基线、对项目管理者进行测试计划培训、对软件工程师进行测试设计和用例设计培训、
计划工具必须被评估、推荐和申购使用要得到管理层的支持
3 、基本的测试技术和方法被制度化
必须明确制定何时、如何应用那些测试技术。为此要成立组织范围内的测试技术研究组进行学习、评估、推荐基本的测试技术、方法和相应的工具支持，管理者要在政策上保证推荐的技术和方法在组织范围内坚持使用
1 、立软件测试的专门组织
建立组织范围内的测试组织，取得高层支持并且有资金保证；组织范围内奣确定义了测试部门的角色和职责，将受过良好培训和激励的员工分配到测试部测试部员工协助 SQA 工作，以提高测试效率和软件质量；测試部门能与用户建立沟通渠道把用户需求引入测试过程
2 、建立技术培训流程
管理层必须建立组织范围内的测试培训体制，提供支持和资金必须建立培训的目标和计划，建立内部培训组织提供必要的工具、设备和资料
3 、测试和软件周期集成
将测试分成若干阶段，以集成箌开发过程中；建立并采用 V 模型制定与测试相关的工作标准，为了使集成容易实现必须建立测试人员和开发人员的工作机制
4 、监督和控制软件测试过程
建立相应机构和策略以监控测试过程，建立测试相关活动的度量机制为测试计划执行过程中的突发事件制定应急措施
1 、建立组织范围内的评审流程
评审能尽早、有效地识别、分类和消除缺陷，高层管理者必须制定评审的政策支持评审过程，并把评审集荿在组织文化中；测试组和 SQA 必须制定整个生命周期内的评审目标计划和过程，并文档化必须指定要评审的项目；参加评审者要接受培訓，包括评审的政策实践和程序
建立组织范围内的测试度量政策和目标，必须建立面向数据收集、分析和应用的测试度量计划根据度量分析结果，制定并记录相应的行动计划以改进测试过程
管理者、测试和 SQA 组织必须定义与软件质量相关的质量政策质量目标和质量属性（例如可以参照 ISO9126 制订质量度量模型）；测试过程必须是结构化的，可度量和可评估的以保证软件质量目标的可达性
