软件测试帖(1-14）


--------------------------------------------------------------------------------

Jerry选自51Testing.com的每日贴

第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

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

　

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

　

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

　

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

　

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

第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）哈希表在插入前为空

这些就是测试需求，而非测试用例，因为它们没有对被插入元素进行描述。另外你也不能马上就着手书写用例，就好象软件需求完成后不能立即进行编码一样。还需要对测试需求进行评审，确保正确和没有需求遗漏。

这应该只是对测试需求的一个方面的理解

测试需求应该包含两个方面的内容：

1、确定测什么，就是上面这位仁兄所说。

2、测试对产品的需求，解决需要产品为测试提供什么特性，可以更好的去测试的问题，就是我们常说的可测试性需求。

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

Roger S. Pressman

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

窗口：

·窗口是否基于相关的输入和菜单命令适当地打开？

·窗口能否改变大小、移动和滚动？

·窗口中的数据内容能否用鼠标、功能键、方向键和键盘访问？

·当被覆盖并重新调用后，窗口能否正确地再生？

·需要时能否使用所有窗口相关的功能？

·所有窗口相关的功能是可操作的吗？

·是否有相关的下拉式菜单、工具条、滚动条、对话框、按钮、图标和其他控制可为窗口使用，并适当地显示？

·显示多个窗口时，窗口的名称是否被适当地表示？

·活动窗口是否被适当地加亮？

·如果使用多任务，是否所有的窗口被实时更新？

·多次或不正确按鼠标是否会导致无法预料的副作用？

·窗口的声音和颜色提示和窗口的操作顺序是否符合需求？

·窗口是否正确地被关闭？

　

下拉式菜单和鼠标操作：

·菜单条是否显示在合适的语境中？

·应用程序的菜单条是否显示系统相关的特性（如时钟显示）？

·下拉式操作能正确工作吗？

·菜单、调色板和工具条是否工作正确？

·是否适当地列出了所有的菜单功能和下拉式子功能？

·是否可以通过鼠标访问所有的菜单功能？

·文本字体、大小和格式是否正确？

·是否能够用其他的文本命令激活每个菜单功能？

·菜单功能是否随当前的窗口操作加亮或变灰？

·菜单功能是否正确执行？

·菜单功能的名字是否具有自解释性？

·菜单项是否有帮助，是否语境相关？

·在整个交互式语境中，是否可以识别鼠标操作？

·如果要求多次点击鼠标，是否能够在语境中正确识别？

·光标、处理指示器和识别指针是否随操作恰当地改变？

　

数据项：

·字母数字数据项是否能够正确回显，并输入到系统中？

·图形模式的数据项（如滚动条）是否正常工作？

·是否能够识别非法数据？

·数据输入消息是否可理解？


　

软件测试知识帖(15-28）


--------------------------------------------------------------------------------

Jerry选自51Testing.com的每日贴

　

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

Roger S. Pressman

　

通常，客户/服务器软件的测试发生在三个不同的层次：

（1）个体的客户端应用以“分离的”模式被测试--不考虑服务器和底层网络的运行；

（2）客户端软件和关联的服务器端应用被一起测试，但网络运行不被明显的考虑；

（3）完整的C/S体系结构，包括网络运行和性能，被测试。

　

下面的测试方法是C/S应用中经常用到的：

应用功能测试--客户端应用被独立地执行，以揭示在其运行中的错误。

服务器测试--测试服务器的协调和数据管理功能，也考虑服务器性能（整体反映时间和数据吞吐量）。

数据库测试--测试服务器存储的数据的精确性和完整性，检查客户端应用提交的事务，以保证数据被正确地存储、更新和检索。

事务测试--创建一系列的测试以保证每类事务被按照需求处理。测试着重于处理的正确性，也关注性能问题。

网络通信测试--这些测试验证网络节点间的通信正常地发生，并且消息传递、事务和相关的网络交通无错的发生。

第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-42）


--------------------------------------------------------------------------------

Jerry选自51Testing.com的每日贴

　

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

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

TCL提供以下接口：

1、用户接口

对用户提供语言特性，如循环、条件判断等控制结构，通过它用户可以灵活的书写测试用例；当然只 提供语言特性远远不够，因为业务千差万别，所以用户需要业务接口，从而完成特定的测试任务。 而业务接口，是通过下面的程序员接口实现。

2、程序员接口

用户可以编写自己命令，它包括用户层（即名字）和实现层（通过C语言实现），然后用TCL提供的注册 函数登记，以后命令就可灵活的嵌入到脚本中了。

TCL测试模型分三部分：

被测试程序（由开发人员编写）----测试人员应搞清楚程序结构和业务功能，指导扩展命令的设计。

测试代码（由测试设计人员编写） ---通过程序员接口，提供给脚本扩展命令。

测试用例（TCL脚本形式，由测试执行人员编写）---通过脚本对扩展命令进一步组合。

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

CMM为企业的软件过程能力提供了一个阶梯式的进化框架，阶梯共有五级。第一级只是一个起点，任何准备按CMM体系进化的企业都自然处于这个起点上，并通过它向第二级迈进。除第一级外，每一级都设定了一组目标，如果达到了这组目标，则表明达到了这个成熟级别，可以向下一级别迈进。

第一级、初始级：

初始级的软件过程是未加定义的随意过程，项目的执行是随意甚至是混乱的。也许有些企业制定了一些软件工程规范，但若这些规范未能覆盖基本的关键过程要求，且执行没有政策、资源等方面的保证时，那么它仍然被视为初始级。

第二级、重复级：

根据多年的经验和教训，人们总结出软件开发的首要问题不是技术问题而是管理问题。因此，第二级的焦点集中在软件管理过程上。一个可管理的过程则是一个可重复的过程，可重复的过程才能逐渐改进和成熟。可重复级的管理过程包括了需求管理、项目管理、质量管理、配置管理和子合同管理五个方面；其中项目管理过程又分为计划过程和跟踪与监控过程。通过实施这些过程，从管理角度可以看到一个按计划执行的且阶段可控的软件开发过程。

第三级、定义级：

在可重复级定义了管理的基本过程，而没有定义执行的步骤标准。在第三级则要求制定企业范围的工程化标准，并将这些标准集成到企业软件开发标准过程中去。所有开发的项目需根据这个标准过程，裁剪出与项目适宜的过程，并且按照过程执行。过程的裁剪不是随意的，在使用前必须经过企业有关人员的批准。

第四级、管理级：

第四级的管理是量化的管理。所有过程需建立相应的度量方式，所有产品的质量（包括工作产品和提交给用户的最终产品）需要有明确的度量指标。这些度量应是详尽的，且可用于理解和控制软件过程和产品。量化控制将使软件开发真正成为一种工业生产活动。

第五级、优化级：

优化级的目标是达到一个持续改善的境界。所谓持续改善是指可以根据过程执行的反馈信息来改善下一步的执行过程，即优化执行步骤。如果企业达到了第五级，就表明该企业能够根据实际的项目性质、技术等因素，不断调整软件生产过程以求达到最佳。

第31贴【2004－6－16】：CMM 2级KPA的目标

CMM 2级：可重复级

Requirement Management

需求管理

Goal 1 System requiremnets allocated to software are controlled to establish a baseline for software engineering and management use.

目标1：分配到软件部分的系统需求通过建立基线受控。

Goal 2 Software plans, products, and activities are kept consistent with the system requirements allocated to software.

目标2：软件计划、产品和活动与分配到软件部分的系统需求一致。

　

Software Project Planning

软件项目计划

Goal 1 Software estimates are documented for use in planning and tracking the software project.

目标1：用来计划和跟踪软件项目的软件估计文档化。

Goal 2 Software project activities and commitments are planned and documented.

目标2：制定了软件项目活动和任务书的计划，并且有文档记录。

Goal 3 Affected groups and individuals agree to their commitments related to the software project.

目标3：受影响的小组和个人接受和软件项目相关的任务书。

　

Software Project Tracking and Oversight

软件项目跟踪及监控

Goal 1 Actual results and performances are tracked against the software plans.

目标1：按照软件计划跟踪实际结果和性能。

Goal 2 Corrective actions are taken and managed to closure when actual results and performance deviate significantly from the software plans.

目标2：当实际的结果和性能严重偏离软件计划时，采取了正确的行动终止这种状况。

Goal 3 Changes to sofware commitments are agreed to by the affected groups and individuals.

目标3：受影响的小组和个人接受软件任务书的变化。

　

Software Subcontract Management

软件子合同管理

Goal 1 The prime contractor selects qualified software subcontractors.

目标1：主签约人挑选有资格的子签约人。

Goal 2 The prime contractor and the software subcontractor agree to their commitments to each other.

目标2：主签约人和子签约人互相接受他们的任务书。

Goal 3 The prime contractor and the software subcontractor maintain ongoing communications.

目标3：主签约人和子签约人保持持续的沟通。

Goal 4 The prime contractor tracks the software subcontractor's actual results and performance against its commitments.

目标4：主签约人按照任务书跟踪子签约人的实际结果和效能。

　

Software Quality Assurance

软件质量保证

Goal 1 Software quality assurance activities are planned.

目标1：制定了软件质量保证计划。

Goal 2 Adherence of software products and activities to the applicable standards, procedures, and requirements is verified objectively.

目标2：客观地检验软件产品和活动是否符合适用的标准、过程和需求。

Goal 3 Affected groups and individuals are informed of software quality assurance activities and results.

目标3：软件质量保证的活动和结果通知了受影响的小组和个人。

Goal 4 Noncompliance issues that cannot be resolved within the software project are addressed by senior management.

目标4：高层管理着手解决在软件项目内部不能解决的不符合项。

　

Software Configuration Management

软件配置管理

Goal 1 Software configuration management activities are planned.

目标1：制定了软件配置管理活动的计划。

Goal 2 Selected software work products are identified, controlled, and available.

目标2：选定的软件工作产品是被标识的、受控的和可利用的。

Goal 3 Changes to identified software work products are controlled.

目标3：被标识的软件工作产品的变化是受控的。

Goal 4 Affected groups and individuals are informed of the status and content of software baselines.

目标4：软件基线的状态和内容通知受影响的小组和个人。

第32贴【2004－6－17】：Logiscope的功能

LOGISCOPE是为软件的全面质量控制而开发的强大工具，可以用在编程、测试和维护阶段。LOGISCOPE五个模块的功能：

(1) 阅读器(Viewer)：以文件调用图(各部件文件之间的关系)及组件调用图(函数和程序间的调用关系)的形式进行可视化应用软件设计。可以在各种各样的抽象级别上分析应用程序，在不同级别上的引导有助于整个应用程序的理解。

(2) 效果检查器(ImpactChecker)：允许用户检查使用的资源(文件、函数、用户定义类型、全局变量、结构成员常量)。它有助于我们理解函数间的信息流(参数传递)，以及数据和其它应用程序资源间的关系。

(3)规则检查器(RuleChecker)：软件公司应该定义自己的编程规则和质量目标。这样做的好处是公司编程行为保持一致性、易于维护、提高可靠性、易于移植到其它机器上。我们可以用规则检查器(RuleChecker)确立编程标准，保证质量控制。

(4) 测试检查器(TestChecker)：实时度量测试覆盖率、显示未覆盖路径原始数据、生成测试报告、帮助管理测试实例。测试检查器(TestChecker)和动态分析器 (Dynamic Analyzer)通过阅读器产生用于应用程序分析的数据。

(5) 代码检查器(CodeChecker)：验证应用程序与质量模型的一致性。代码检查器和静态分析器(Static Analyzer)通过阅读器(Viewer)产生用于应用程序分析的数据。代码检查器(CodeChecker)可以使我们尽早发现和修改质量缺陷。这对质量控制尤为重要。

第33贴【2004－6－18】：α测试

α测试是由一个用户在开发环境下进行的测试，也可以是开发机构枘部的用户在模拟实际操作环境下进行的测试。软件在一个自然设置状态下使用。开发者坐在用户旁边，随时记下错误情况和使用中的问题。这是在受控制的环境下进行的测试，α测试的目的是评价软件产品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持)。尤其注重产品的界面和特色。α测试人员是除开产品开发人员之外首先见到产品的人，他们提出的功能和修改意见是特别有价值的。 α测试可以从软件产品编码结束之时开始，或在模块（子系统）测试完成之后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程序之后再开始。有关的手册（草稿）等应事先准备好。

第34贴【2004－6－19】：β测试

β测试是由软件的多个用户在一个或多个用户的实际使用环境下进行的测试。这些用户是与公司签定了支持产品预发行合同的外部客户，他们要求使用该产品，并愿意返回有关错位错误信息给开发者。与α测试不同的是，开发者通常不在测试现场。因而，β测试是在开发者无法控制的环境下进行的软件现场应用。在β测试中，由用户记下遇到的所有问题，包括真实的以及主观认定的，定期向开发者报告，开发者在综合用户的报告之后，做出修改，最将软件产品交付给全体用户使用。 β测试主要衡量产品的FLURPS。着重于产品的支持性，包括文档、客户培训和支持产品生产能力。只有当α测试达到一定的可靠程度时，才能开始β测试。由于它处在整个测试的最后阶段，不能指望这时发现主要问题。同时，产品的所有手册文本也应该在此阶段完全定稿。

由于β测试的主要目标是测试可支持性，所以β测试应尽可能由主持产品发行的人员来管理。

第35贴【2004－6－20】：面向对象的集成测试

　　传统的集成测试，是通过各种集成策略集成各功能模块进行测试，一般可以在部分程序编译完成的情况下进行。而对于面向对象程序，相互调用的功能是散布在程序的不同类中，类通过消息相互作用申请和提供服务。类的行为与它的状态密切相关，状态不仅仅是体现在类数据成员的值，也许还包括其他类中的状态信息。由此可见，类相互依赖极其紧密，根本无法在编译不完全的程序上对类进行测试。所以，面向对象的集成测试通常需要在整个程序编译完成后进行。此外，面向对象程序具有动态特性，程序的控制流往往无法确定，因此也只能对整个编译后的程序做基于黑盒子的集成测试。

　　面向对象的集成测试能够检测出相对独立的单元测试无法检测出的那些类相互作用时才会产生的错误。基于单元测试对成员函数行为正确性的保证，集成测试只关注于系统的结构和内部的相互作用。面向对象的集成测试可以分成两步进行：先进行静态测试，再进行动态测试。

　　静态测试主要针对程序的结构进行，检测程序结构是否符合设计要求。现在流行的一些测试软件都能提供一种称为"可逆性工程"的功能，即通过原程序得到类关系图和函数功能调用关系图，例如International Software Automation 公司的Panorama-2 、Rational公司的Rose C++ Analyzer等，将"可逆性工程"得到的结果与OOD的结果相比较，检测程序结构和实现上是否有缺陷。换句话说，通过这种方法检测OOP是否达到了设计要求。

　　动态测试设计测试用例时，通常需要上述的功能调用结构图、类关系图或者实体关系图为参考，确定不需要被重复测试的部分，从而优化测试用例，减少测试工作量，使得进行的测试能够达到一定覆盖标准。测试所要达到的覆盖标准可以是：达到类所有的服务要求或服务提供的一定覆盖率；依据类间传递的消息，达到对所有执行线程的一定覆盖率；达到类的所有状态的一定覆盖率等。同时也可以考虑使用现有的一些测试工具来得到程序代码执行的覆盖率。

　　具体设计测试用例，可参考下列步骤：

　　1. 先选定检测的类，参考OOD分析结果，仔细出类的状态和相应的行为，类或成员函数间传递的消息，输入或输出的界定等。

　　2. 确定覆盖标准。

　　3. 利用结构关系图确定待测类的所有关联。

　　4. 根据程序中类的对象构造测试用例，确认使用什么输入激发类的状态、使用类的服务和期望产生什么行为等。

值得注意，设计测试用例时，不但要设计确认类功能满足的输入，还应该有意识的设计一些被禁止的例子，确认类是否有不合法的行为产生，如发送与类状态不相适应的消息，要求不相适应的服务等。根据具体情况，动态的集成测试，有时也可以通过系统测试完成。

第36贴【2004－6－21】：面向对象的系统测试

通过单元测试和集成测试，仅能保证软件开发的功能得以实现。但不能确认在实际运行时，它是否满足用户的需要，是否大量存在实际使用条件下会被诱发产生错误的隐患。为此，对完成开发的软件必须经过规范的系统测试。换个角度说，开发完成的软件仅仅是实际投入使用系统的一个组成部分，需要测试它与系统其他部分配套运行的表现，以保证在系统各部分协调工作的环境下也能正常工作。　　

系统测试应该尽量搭建与用户实际使用环境相同的测试平台，应该保证被测系统的完整性，对临时没有的系统设备部件，也应有相应的模拟手段。系统测试时，应该参考OOA分析的结果，对应描述的对象、属性和各种服务，检测软件是否能够完全"再现"问题空间。系统测试不仅是检测软件的整体行为表现，从另一个侧面看，也是对软件开发设计的再确认。

　　这里说的系统测试是对测试步骤的抽象描述。它体现的具体测试内容包括：

　　· 功能测试：测试是否满足开发要求，是否能够提供设计所描述的功能，是否用户的需求都得到满足。功能测试是系统测试最常用和必须的测试，通常还会以正式的软件说明书为测试标准。

　　· 强度测试：测试系统的能力最高实际限度，即软件在一些超负荷的情况，功能实现情况。如要求软件某一行为的大量重复、输入大量的数据或大数值数据、对数据库大量复杂的查询等。

　　· 性能测试：测试软件的运行性能。这种测试常常与强度测试结合进行，需要事先对被测软件提出性能指标，如传输连接的最长时限、传输的错误率、计算的精度、记录的精度、响应的时限和恢复时限等。

　　· 安全测试：验证安装在系统内的保护机构确实能够对系统进行保护，使之不受各种非常的干扰。安全测试时需要设计一些测试用例试图突破系统的安全保密措施，检验系统是否有安全保密的漏洞。

　　· 恢复测试：采用人工的干扰使软件出错，中断使用，检测系统的恢复能力，特别是通讯系统。恢复测试时，应该参考性能测试的相关测试指标。

　　· 可用性测试：测试用户是否能够满意使用。具体体现为操作是否方便，用户界面是否友好等。

　　· 安装/卸载测试（install/uninstall test）等等。

　　系统测试需要对被测的软件结合需求分析做仔细的测试分析，建立测试用例。

第37贴【2004－6－22】：TMM介绍

测试是软件开发的重要过程之一，但是CMM没有充分的定义测试，没有提及测试成熟度的概念，没有对测试过程改进进行充分说明，在KPA中没有定义测试问题，与质量相关的测试问题如可测性，充分测试标准，测试计划等方面也没有满意的阐述。

　

TMM是受CMM模型启发产生的，关注于测试的成熟度模型。它描述了测试过程，是项目测试部分得到良好计划和控制的基础。TMM测试成熟度分解为5级别，关注于5个成熟度级别递增：

　

Phase 0 ：测试和调试没有区别，初了支持调试外，测试没有其他目的

Phase 1 ： 测试的目的是为了表明软件能够工作

Phase 2 ：测试的目的是为了表明软件不能够能够正常工作

Phase 3 ： 测试的目的不是要证明什么，而是为了把软件不能正常工作的预知风险降低到能够接受的程度

Phase 4 ： 测试不是行为，而是一种自觉的约束(mental discipline)，不用太多的测试投入产生低风险的软件上的

第38贴【2004－6－23】：软件测试自动化的概念

软件测试自动化，是一项让计算机代替测试人员进行软件测试的技术。他可以让测试人员从繁琐和重复的测试活动中解脱出来，专心从事有意义的测试设计等活动。如果采用自动比较技术，还可以自动完成测试用例执行结果的判断，从而避免人工比对存在的疏漏问题。设计良好的自动化测试，在某些情况下可以实现“夜间测试”和“无人测试”。在大多数情况下，软件测试自动化可以减少开支，增加有限时间内可执行的测试，在执行相同数量测试时节约测试时间。

　

软件测试自动化通常借助测试工具进行。测试工具可以进行部分的测试设计、实现、执行和比较的工作。通过运用测试工具，可以达到提高测试效率的目的。所以测试工具的选择和推广使用应该给予重视。部分的测试工具可以实现测试用例的自动生成，但通常的工作方式为人工设计测试用例，使用工具进行用例的执行和比较。

　

软件测试自动化的设计并不能由工具来完成，必须由测试人员进行手工设计，但是在设计是却必须考虑自动化的特殊要求，否则无法实现利用工具进行用例的自动执行。为此，就必须在测试的设计和内容的组织方面采取一些特殊的方法。

　

对于软件测试自动化的工作，大多数人都认为是一件非常容易的事。其实，软件测试自动化的工作量非常大，而且也并不是在任何情况下都适用，同时软件测试自动化的设计并不比程序设计简单。

第39贴【2004－6－24】：自动化测试的优点

通过自动化测试，可以使某些任务提高执行效率。除此之外，还有其它优点：

　

①对程序的回归测试更方便。这可能是自动化测试最主要的任务，特别是在程序修改比较频繁时，效果是非常明显的。由于回归测试的动作和用例是完全设计好的，测试期望的结果也是完全可以预料的，将回归测试自动运行，可以极大提高测试效率，缩短回归测试时间。

　

②可以运行更多更繁琐的测试。自动化的一个明显的好处是可以在较少的时间内运行更多的测试。

　

③可以执行一些手工测试困难或不可能进行的测试。比如，对于大量用户的测试，不可能同时让足够多的测试人员同时进行测试，但是却可以通过自动化测试模拟同时有许多用户，从而达到测试的目的。

　

④更好地利用资源。将繁琐的任务自动化，可以提高准确性和测试人员的积极性，将测试技术人员解脱出来投入更多精力设计更好的测试用例。有些测试不适合于自动测试，仅适合于手工测试，将可自动测试的测试自动化后，可以让测试人员专注于手工测试部分，提高手工测试的效率。

　

⑤测试具有一致性和可重复性。由于测试是自动执行的，每次测试的结果和执行的内容的一致性是可以得到保障的，从而达到测试的可重复的效果。

　

⑥测试的复用性。由于自动测试通常采用脚本技术，这样就有可能只需要做少量的甚至不做修改，实现在不同的测试过程中使用相同的用例。

　

⑦可以让产品更快面向市场。自动化测试可以缩短测试时间，加快产品开发周期。

　

⑧增加软件信任度。由于测试是自动执行的，所以不存在执行过程中的疏忽和错误，完全取决于测试的设计质量。一旦软件通过了强有力的自动测试后，软件的信任度自然会增加。

　

总之，通过较少的开销获得更彻底的测试，提高软件质量，这是测试自动化的最终目的。

第40贴［2004-6-25］：自动化测试中常见的问题

在软件测试自动化的实施过程中会遇到许多问题，以下是一些比较普遍的问题：

　

①不现实的期望。一般来说，业界对于任何新技术的解决方案都深信不疑，认为可以解决面临的所有问题，对于测试工具也不例外。但事实上，如果期望不现实，无论测试工具如何，都满足不了期望。

　

②缺乏测试实践经验。如果缺乏测试的实践经验，测试组织差，文档较少或不一致，测试发现缺陷的能力较差，那么首先要做的是改进测试的有效性，而不是改进测试效率。只有手工测试积累到一定程度，才能做好自动化测试。

　

③期望自动测试发现大量的新缺陷。测试第一次运行时最有可能发现缺陷。如果测试已经运行，再次运行相同的测试发现新缺陷的概率就小得多。对回归测试而言，再次运行相同的测试只是确保修改是正确的，并不能发现新的问题。

　

④安全性错觉。如果自动测试过程没有发现任何缺陷，并不意味着软件没有缺陷。可能由于测试设计的原因导致测试本身就有缺陷。

　

⑤自动测试的维护性。当软件修改后，通常也需要修改部分测试，这样必然导致对自动化测试的修改。在进行自动化测试的设计和实现时，需要注意这个问题，防止自动化测试带来的好处被高维护成本所淹没。

　

⑥技术问题。商业的测试工具也是软件产品，并不能解决所有问题，通常在某些地方还会有欠缺。测试工具都有适用范围，要很好的利用它，对使用者进行培训是必不可少的。

　

⑦组织问题。自动测试实施并不简单，必须有管理支持及组织艺术。

第41贴【2004－6－27】：测试自动化的限制

测试自动化可以带来非常明显的收益，但也有其限制，主要有：

1.不能取代手工测试

2.手工测试比自动测试发现的缺陷更多

3.对测试质量的依赖性极大

4.测试自动化不能提高有效性

5.测试自动化可能会制约软件开发。由于自动测试比手动测试更脆弱，所以维护会受到限制，从而制约软件的开发。

6.工具本身并无想像力

　

另外，人工测试比测试工具更优越的另一个方面是可以处理意外事件。虽然工具也能处理部分异常事件，但是对真正的突发事件和不能由软件解决的问题就无能为力。

第42贴【2004－6－28】：什么是应首先被自动化的测试？

软件测试的自动化过程是一个渐进的过程，并不需要一开始就对所有的测试进行自动化，这通常也是不现实的。如何选择首先被自动化的测试成了最先遇到的问题。

有些测试，完全没有必要进行自动化，因为自动化它们所需的时间比手工运行它们全部的次数所需的时间总和还长。例如，手工运行一个测试要10分钟，而且一般每个月运行1次，那么一年需要120分钟。但如果自动化这测试需要10小时，那么这个测试需要连续不断运行5年才能收回成本。

有些测试，虽然执行的时间不长，但过程繁琐，需要执行的动作非常多。比 如，一个运行10分钟的测试，可能需要击键150次，打开4～5个窗口，切换操作。如果将其自动化，可以提高可靠性，也是值得的。

对软件进行的功能性测试，是测试软件系统在做什么。这些测试可以明确的知道应该在什么情况下输入什么，会有什么样的输出。这样的测试是非常容易被自动化的，也能从自动化中获得较大的收益。

对软件进行的性能测试，包括在不同的系统负载下进行的测试。这些测试需要采用工具辅助完成，非常适合进行自动化。

如果在测试中，运行10%的测试需要花费90%的时间，那么将这10%的测试自动化是值得的。

以下列出了选择首先进行自动化时要考虑的因素：

非常重要的测试

涉及范围很广的测试

对主要功能的测试

容易自动化的测试

很快有回报的测试

运行最频繁的测试

　

应该注意避免一口气自动化太多的测试。太多的工作导致参与人员工作积极性下降，可维护性下降，增加工作的风险。寻找可快速制胜的测试，尽快让大家看到工作成果，有助于获得更多的工作支持。

　

软件测试知识帖(43-56）


--------------------------------------------------------------------------------

Jerry选自51Testing.com的每日贴

第43贴【2004－6－29】：工具的选择：创建还是购买

在评估了商业市场后，你可能会发现在你的限制之内没有符合你需求的工具。这时需要考虑是否自行开发自己的工具，还是等待市场上出现满足要求的新工具。

自行开发新工具有以下特点：
1、它将是最合适你的需求的
2、可以在工具中补偿被测软件缺乏的可测试性
3、工具可以假设很了解被测程序，因而减少了实现测试自动化所需的工作
4、在文档、帮助和培训方面可以不用提供很好的支持
5、工具可能具有某些典型的问题，如结构、可扩展性等
6、用户界面不友好

商业工具有以下特点：
1、获得一个指定功能和性能标准的工具的费用可能比自行开发一个工具的成本 要低
2、在文档、帮助和培训方面必须提供良好的支持
3、工具通常应该很有吸引力
4、即使使用一个商业工具，可能无法完全避免建立自己的工具

但即使决定自行开发测试工具，也不要试图生产一个可以广泛使用的商业工具。
第44贴【2004－6－30】：自动化脚本之线性脚本
线性脚本是录制手工执行的测试用例得到的脚本。这种脚本包含所有用户的键盘和鼠标输入。如果仅使用线性脚本技术，每个测试用例可以通过脚本完整地被回放。线性脚本中也可能包括比较，比如检查某个窗口是否弹出。

手工运行10分钟的测试用例，可能需要20分钟到2个小时才能完成测试自动化的工作。因为录制的脚本需要维护，尤其是增加部分内容后的维护和测试需要花费很多时间。而且自动化以后的测试执行的时间会大于10分钟。

线性脚本有以下的优点：
1、不需要深入的工作或计划
2、可以加快开始自动化
3、对实际执行操作可以审计跟踪
4、用户不必是编程人员
5、提供良好的（软件或工具）的演示

线性脚本适用于以下情况：
1、演示或培训
2、执行量较少，且环境变化小的测试
3、数据转换，如将数据从Notes数据库中转换到EXCEL表格中

线性脚本有以下缺点：
1、过程繁琐
2、一切依赖于每次捕获的内容
3、测试输入和比较是“捆绑”在脚本中的
4、无共享或重用脚本
5、线性脚本容易受软件变化的影响
6、线性脚本修改代价大，维护成本高
7、非常容易受意外事件的影响，引起整个测试失败
第45贴【2004－7－1】：自动化脚本之结构化脚本
结构化脚本类似于结构化程序设计，含有控制脚本执行的指令。这些指令或为控制结构，或为调用结构。控制结构中包括“顺序”、“循环”和“分支”，和结构化程序设计中的概念相同。调用结构是在一个脚本中调用另外脚本，当子脚本执行完成后再继续运行父脚本。

结构化脚本的优点是健壮性好。也可以通过循环和调用减少工作量。
结构化脚本的缺点是脚本更复杂，而且测试数据仍然“捆绑”在脚本中。
结构化脚本侧重于描述脚本中控制流程的结构化特性。
第46贴【2004－7－3】：自动化脚本之共享脚本
共享脚本是指脚本可以被多个测试用例使用，一个脚本可以被另外一个脚本调用。这样可以节省生成脚本的时间；当重复任务发生变化时，只需修改一个脚本。

建立共享脚本的时间可能更长，因为需要建立更多的脚本，且每个脚本需要进行适当的修改，达到脚本共享的目的。

共享脚本可以是在不同主机、不同系统之间共享脚本，也可以是在同一主机、同一系统之间共享脚本。

共享脚本的优点有：
1、以较少的开销实现类似的测试
2、维护开销低于线性脚本
3、删除明显的重复
4、可以在脚本中增加更智能的功能

共享脚本的缺点有：
1、需要跟踪更多的脚本，给配置管理带来一定的困难
2、对于每个测试，仍然需要特定的测试脚本，因此维护费用比较高
3、共享脚本通常是针对被测软件的某部分，存在部分脚本不能直接运行

要获得高质量的共享脚本，需要接受一定的训练。在开始编写脚本时，多花些时间进行设计是值得的。通过共享脚本技术，还可以建立脚本库，达到最大程度的共享。由于共享脚本需要被多次使用，所以与脚本相配套的文档更应该引起注意。

共享脚本侧重描述脚本中共享的特性。
第47贴【2004－7－4】：自动化脚本之数据驱动脚本
数据驱动脚本技术将测试输入存储在独立的数据文件中，而不是绑定在脚本中。执行时是从数据文件而不是从脚本中读入数据。这种方法最大的好处是可以用同一个脚本允许不同的测试。对数据进行修改，也不必修改执行的脚本。

使用数据驱动脚本，可以以较小的开销实现较多的测试用例，这可以通过为一个测试脚本指定不同的测试数据文件达到。将数据文件单独列出，选择合适的数据格式和形式，可将用户的注意力集中到数据的维护和测试上。达到简化数据，减少出错的概率的目的。

数据驱动脚本的优点有：
1、可以快速增加类似的测试
2、测试者增加新测试不必掌握工具脚本语言的技术
3、对第二个及以后类似的测试无额外的维护开销

数据驱动脚本的缺点有：
1、初始建立的开销较大
2、需要专业（编程）支持
3、必须易于管理


第48贴【2004－7－5】：自动化脚本之关键字驱动脚本


关键字驱动实际上是比较复杂的数据驱动技术的逻辑扩展。将数据文件变成测试用例的描述，用一系列关键字指定要执行的任务。在关键字驱动技术中，假设测试者具有某些被测系统的知识，所以不必告诉测试者如何进行详细的动作，只是说明测试用例做什么，而不是如何做。这样在脚本中使用的是说明性方法和描述性方法。描述性方法将被测软件的知识建立在测试自动化环境中，这种知识包含在支持脚本中。

例如，为完成在网页浏览时输入网址，一般的脚本需要说明在某某窗口的某某控件中输入什么字符；而在关键字驱动脚本中，可以直接是在地址栏中输入网址什么什么；甚至更简单，仅说明输入网址什么什么。

关键字驱动脚本的数量不随测试用例的数量变化，而仅随软件规模而增加。这种脚本还可以实现跨平台的用例共享，只需要更改支持脚本即可。


第49贴【2004－7－6】：脚本预处理


预处理是一种或多种预编译功能，包括美化器、静态分析和一般替换。脚本的预处理是指脚本在被工具执行前必须进行编译。预处理功能通常需要工具支持，在脚本执行前自动处理。

美化器是一种对脚本格式进行检查的工具，必要时将脚本转换成符合编程规范的要求。可以让脚本编写者更专注于技术性的工作。

静态分析对脚本或表格执行更重要的检查功能，检查脚本中出现的和可能出现的缺陷。测试工具通常可以发现一些如拼写错误或不完整指令等脚本缺陷，这些功能非常有效。静态分析可以检查所有的缺陷和不当之处。类似于程序设计中的PC-Lint和LogiScope的功能。

一般替换也就是宏替换。可以让脚本更明确，易于维护。使用替换时应注意不要执行不必要的替换。在进行调试时，应该注意缺陷可能是存在被替换的部分中，而不是原来的脚本中。


第50贴【2004－7－7】：自动比较技术


测试验证是检验软件是否产生了正确输出的过程，是通过在测试的实际输出与预期输出（例如，当软件正确执行时的输出）之间完成一次或多次比较来实现的。进行测试自动化工作时，自动比较就成为一个必须的环节。有计划的进行比较会比随意的比较有更高的效率和发现问题的能力。

自动比较的内容可以是多方面的，包括基于磁盘输出的比较，如对数据文件的比较；基于界面输出的比较，如对显示位图的比较；基于多媒体输出的比较，如对声音的比较；还包括其它输出的内容的比较。

比较器可以检测两组数据是否相同，功能较齐全的比较器还可以标识有差异的内容。但比较器并不能告诉用户测试是否通过或失败，需要用户自行判断。

比较可以是简单的比较，仅匹配实际输出与预期输出是否完全相同，这是自动化比较的基础。智能比较是允许用已知的差异来比较实际输出和预期输出。比如，要求比较包含日期信息的输出报表的内容。如果使用简单比较，显然是不行的，因为每次生成报表的日期信息肯定是不同的。这时就需要智能比较，忽略日期的差别，比较其它内容，甚至还可以忽略日期的具体内容，比较日期的格式，要求日期按特定格式输出。智能比较需要使用到较为复杂的比较手段，包括正则表达式的搜索技术、屏蔽的搜索技术等。



第51贴【2004－7－8】：测试的敏感性和健壮性


敏感的测试是指测试过程能发现微小的，甚至是不起眼的错误。敏感的测试能发现较多的问题，但任何一点微不足道的改动都将导致测试用例及执行过程的更改。健壮的测试是指测试过程能够容忍较多的差别，不会影响测试用例的失败。在自动化测试时，健壮的测试可以较容易通过执行，也就减少了意外情况对测试过程的影响，但会导致发现问题的能力下降，甚至放过应该发现的问题。

应当在测试的敏感性和测试的健壮性之间进行权衡。对大量的自动测试用例而言，过多的敏感性比缺少敏感性更会反面影响失败分析工作。如果运行一组敏感的测试用例，那么有可能其中多数的测试用例由于相同的原因而失败。在这种情况下，每个失败的测试用例都指示相同的错误，但测试人员只是希望获得不同的错误及错误的差异，并不需要重复相同的错误报告。

敏感性和健壮性的测试应当是：
1、无论软件何时发生了变化，主要在高层次，即在作为明智的检验运行测试事例的地方，使用敏感比较
2、考虑多组测试用例，其中的一两组使用敏感比较，而其他组使用健壮比较
3、好的测试自动化策略应该是规划敏感测试和健壮测试的混合体


第52贴【2004－7－9】：TMM2级目标


TMM Level 2 - 阶段定义级目标：
1、区分调试和测试的的各自目标
为了区分调试和测试，需要成立为测试和调试负责的组织，该组织需要建立测试目标和策略，另外该组织还要建立调试目标和策略，这些目标和策略要文字化并确保知会到所有的项目经理和开发人员。

2、引进测试计划过程
完成这个目标，要建立组织范围内的测试计划组织、建立测试计划策略及计划模板、建立把用户需求引入测试计划的正规途径、测试目标作为测试计划基线、对项目管理者进行测试计划培训、对软件工程师进行测试设计和用例设计培训、
计划工具必须被评估、推荐和申购，使用要得到管理层的支持

3、基本的测试技术和方法被制度化
必须明确制定何时、如何应用那些测试技术。为此要成立组织范围内的测试技术研究组，进行学习、评估、推荐基本的测试技术、方法和相应的工具支持，管理者要在政策上保证推荐的技术和方法在组织范围内坚持使用。


第53贴【2004－7－11】：TMM3级目标


TMM Level 3 -集成级目标：
1、建立软件测试的专门组织
建立组织范围内的测试组织，取得高层支持，并且有资金保证；组织范围内明确定义了测试部门的角色和职责，将受过良好培训和激励的员工分配到测试部，测试部员工协助SQA工作，以提高测试效率和软件质量；测试部门能与用户建立沟通渠道，把用户需求引入测试过程

2、建立技术培训流程
管理层必须建立组织范围内的测试培训体制，提供支持和资金，必须建立培训的目标和计划，建立内部培训组织，提供必要的工具、设备和资料

3、测试和软件周期集成
将测试分成若干阶段，以集成到开发过程中；建立并采用 V模型，制定与测试相关的工作标准，为了使集成容易实现，必须建立测试人员和开发人员的工作机制

4、监督和控制软件测试过程
建立相应机构和策略以监控测试过程，建立测试相关活动的度量机制，为测试计划执行过程中的突发事件制定应急措施


第54贴【2004－7－11】：TMM4级目标


TMMLevel 4 -管理和度量级目标
1、建立组织范围内的评审流程
评审能尽早、有效地识别、分类和消除缺陷，高层管理者必须制定评审的政策，支持评审过程，并把评审集成在组织文化中；测试组和SQA必须制定整个生命周期内的评审目标，计划和过程，并文档化，必须指定要评审的项目；参加评审者要接受培训，包括评审的政策，实践和程序

2、建立测试度量流程
建立组织范围内的测试度量政策和目标，必须建立面向数据收集、分析和应用的测试度量计划，根据度量分析结果，制定并记录相应的行动计划以改进测试过程

3、进行软件质量评估
管理者、测试和SQA组织必须定义与软件质量相关的质量政策，质量目标和质量属性（例如可以参照ISO9126制订质量度量模型）；测试过程必须是结构化的，可度量和可评估的，以保证软件质量目标的可达性


第55贴【2004－7－12】：TMM5级目标


TMM Level 5 - 优化级目标
1、进行过程的数据进行缺陷预防
对组织内的所有项目采用缺陷预防策略，在管理者的支持下建立缺陷预防的团队；软件生命周期每个阶段发现的缺陷必须标识和记录；建立分析的机制，保证能弄清楚导致缺陷的根本原因；建立行动计划，采取措施，避免管理人员、开发人员和测试人员工作中重现已发现的缺陷

2、质量控制，测试过程优化
软件测试和SQA组必须建立软件产品的目标，如产品单元缺陷率(product unit defectiveness)，自信级别(confidence levels)和可信性 (trustworthiness )，测试经理必须把这些质量目标分解到测试计划中，必须对测试组进行统计方法培训
收集用户的输入操作，建立使用模型

3、测试过程优化
建立测试过程改进组织，监控测试过程，寻找优化点，持续对测试相关的、需要采用的工具和技术进行评估，测试过程效率要持续进行评估，停止测试的决策必须参考质量目标，并以可度量和优化的方式来制定


第56贴【2004－7－13】：正规检视需要哪些阶段？


检视过程包括七个阶段：
1、计划
用于确定工作产品是否满足正规检视的进入标准，计划检视，召集成立检视小组并分配相应任务、安排正规检视会议，准备和发放正规检视的资料。确定是否有必要举行产品介绍会议。
2、介绍会议
这是可选择阶段。本阶段向正规检视小组介绍产品的背景信息。如果每个检视小组的成员对被检视的对象很熟悉，可不用召开产品介绍会议。
3、会议准备
这是关键阶段。本阶段检视小组的成员单独准备检视会议，检查和发现检视对象中的错误。错误将在正规检视会议期间进行讨论。在检视会议前以问题登记表形式提交给组织者。
4、检视会议
正规检视的小组一起审查产品，发现、分类和记录审查对象中的错误，但不讨论错误的解决方法。
5、第 3小时会议
可选择阶段。主要讨论无法确认问题的解决方法，也包括其它问题的解决方法等。
6、修改错误
修改已确认的错误。
7、问题跟踪
确定错误是否被改正，并且保证修改过程中没有引入新的错误。

软件测试知识帖(57-70）


--------------------------------------------------------------------------------

Jerry选自51Testing.com的每日贴

第57贴【2004－7－14】：正规检视介绍会议


正规检视介绍会议：

介绍会议阶段是评审流程可选择的阶段。如果检视小组成员不熟悉检视对象以及相关的背景，那么这个会议就应当安排举行。在介绍会议上，作者介绍产品的理论基础，产品同被开发的系统其余部分的关系，产品的功能和产品的主要应用，以及在产品开发过程中采用的开发方式。所有的检视者必须参加介绍会议。

召开介绍会议的主要原因如下：
1、正规检视小组不熟悉检视对象
2、检视对象是新开发的或者是首次进行正规检视
3、正规检视工作在检视对象的项目中被首次采用


第58贴【2004－7－15】：软件配置管理介绍


1、软件配置管理概念：
软件配置管理是通过在软件生命周期的不同时间点上对软件配置进行标识并对这些标识的软件配置项的更改进行系统控制，从而达到保证软件产品的完整性和可溯性的过程。
配置：软件系统的功能属性。
配置项：软件系统的逻辑组成，即与某功能属性相对应的文档或代码等。

2、软件配置管理的四个基本过程：
配置标识： 标识组成软件产品的各组成部分并定义其属性，制定基线计划。
配置控制： 控制对配置项的修改。
配置状态发布： 向受影响的组织和个人报告变更申请的处理过程，通过的变更及他们的实现情况等。
配置评审： 确认受控软件配置项满足需求并就绪。

3、配置库：对各基线内容的存储和管理的数据库
开发库：程序员工作空间，始于某一基线，为某一目的开发服务，开发完成后，经过评审回归到基线库。
基线库：包括通过评审的各类基线，各类变更申请的记录和统计数据。
产品库：是某一基线的静态拷贝，基线库进入发布阶段形成产品库。
4、检视对象中应用了最新的技术


第59贴【2004－7－16】：利用PC－LINT进行代码排错


PC-LINT是GIMPEL SOFTWARE公司的产品，是一种软件质量保证工具，用于程序排错，可对windows、unix平台下的C、C++代码进行最仔细的语法检查，可检查一些在普通编译器不易发现的句法、一般逻辑错误等，是程序员不可多得的排错工具。

如果给 PC-LINT工具下一个形象点的定义，那就是：一种更加严格的编译器。它不仅可以象普通编译器那样检查出一般的语法错误，还可以检查出那些虽然完全合乎语法要求，但很可能是潜在的、不易发现的错误。

许多国外的大型专业软件公司，如微软公司，都把它作为程序检查工具，在程序合入正试版本或交付测试之前一定要保证通过了LINT检查，他们要求软件工程师在使用LINT时要打开所有的编译开关，如果一定要关闭某些开关，那么要给出关闭这些开关的正当理由。

在开发、测试过程中，除了正规检视、代码走读、代码审查等活动可以有效的帮助获得正确的代码，运用PC-LINT、LOGISCOPE等工具也是很好的排错手段，尤其是PC-LINT，以其方便、准确、严格的特点在排除程序一般性错误方面有着明显的优势，其付出的工作量比正规检视、代码走读的要少很多。

可想而知，如果从编码后第一次编译程序时就使用LINT来检查程序，并且保证消除所有的LINT告警，程序质量的提高是不言而喻的。


第60贴【2004－7－17】：LOGISCOPE介绍


LOGISCOPE是为软件的全面质量控制而开发的强大工具，可以用在编程、测试和维护阶段。LOGISCOPE五个模块的功能：
(1) 阅读器(Viewer)：以文件调用图(各部件文件之间的关系)及组件调用图(函数和程序间的调用关系)的形式进行可视化应用软件设计。可以在各种各样的抽象级别上分析应用程序，在不同级别上的引导有助于整个应用程序的理解。
(2) 效果检查器(ImpactChecker)：允许用户检查使用的资源(文件、函数、用户定义类型、全局变量、结构成员常量)。它有助于我们理解函数间的信息流(参数传递)，以及数据和其它应用程序资源间的关系。
(3)规则检查器(RuleChecker)：所有关心无质量风险地开发软件的公司(比如航天公司)定义了编程规则和质量目标。这样做的好处是公司编程行为的一致性、确保易于维护、提高可靠性、易于移植到其它机器上，等等。我们可以用规则检查器(RuleChecker)确立编程标准，保证质量控制。
(4) 测试检查器(TestChecker)：实时度量测试覆盖率、显示未覆盖路径原始数据、生成测试报告、帮助管理测试实例。测试检查器(TestChecker)和动态分析器 (Dynamic Analyzer)通过阅读器产生用于应用程序分析的数据。
(5) 代码检查器(CodeChecker)：验证应用程序与质量模型的一致性。代码检查器和静态分析器(Static Analyzer)通过阅读器(Viewer)产生用于应用程序分析的数据。代码检查器(CodeChecker)可以使我们尽早发现和修改质量缺陷。这对质量控制尤为重要。


第61贴【2004－7－19】：软件估计


软件估计、测量、度量过程是软件开发过程的重要组成部分，是开发过程不断改进的原因所在。软件组织如果没有什么有效手段评估和测量开发过程，即使是依赖优秀的个人和开发团体成功的开发了多个产品或项目，也不能将经验和教训记录下来供以后的开发工作参考并用于改进开发过程。产品或项目的成功总是过多的依赖个人的努力而不是丰富的历史经验数据。

软件组织需要制订开发过程相关的软件估计、测量、度量活动规范、模板，并且把软件估计、测量等活动列入了日常的开发工作的一部分。并以阶段性数据形式进行数据估计和测量工作，这些将成为以后开发过程重要的参考资源。

软件估计过程主要包括规模、工作量、进度的估计。规模估计有许多已成为标准的估计方法，常见的有Wideband Delphi Technique、Pert Sizing、功能点、 类比法以及一些估计工具。


第62贴【2004－7－20】：CMM2级之需求管理


任何一个产品都应满足用户相应的需求。但是满足用户需求的同时会存在两个问题：一是需求在开发过程中会发生变化，如何控制与管理这些变化？二是从需求到产品要经过许多步骤，如系统设计、详细设计、具体实现等，如何保证这些步骤没有背离产品的需求？

需求管理关键过程域就是针对这两个问题提出相应的目标。软件需求可能是系统需求的一部分或是全部（纯粹的软件产品），无论是哪种情况，需求管理的第一个目标就是软件需求应能被控制，并可产生一个可用于软件工程过程和管理过程的基线。需求管理的第二个目标是确保软件项目计划、开发活动、产品与需求一致。需求管理的最终目的是在用户与实现用户需求的项目之间达成共识，需求管理活动就是为了建立并维护这种共识。


第63贴【2004－7－21】：CMM2级之软件项目计划


软件项目计划（SPP）常常不能按期完成，主要原因有两个方面：一是由于计划执行和管理的能力不足；二是计划本身是否合理和有效，计划的不合理性和无效性造成了大多数项目拖延，甚至失败。项目的跟踪与监督则是如何保证计划的执行和调整。

建立合理的开发计划的基础是对项目规模、资源要求和风险等要有一个合理的估算。这个估算过程应是规范的，而不是任意的。例如，如果提出一个项目计划需要40个软件工程师工作三个月的计划，那么就要问这些数据是如何得出的。用户提出的时间和费用的要求仅能作为项目计划的约束条件，而不能作为项目计划的基础。开发计划要包括所有项目活动和所有参加方面的责任，这些活动和责任需要文档化，以保证有效地将计划传达给项目的各个参加方。在项目开发计划执行前，各个项目参加方要认同所承担的项目责任，这种认同是项目计划有效性的一个基本保证。


第64贴【2004－7－22】：CMM2级之软件项目跟踪与监控


软件工程项目是否成功的主要因素在于项目管理，而项目是否能有效地进行管理的关键在于项目过程的可见性。由于软件项目过程是一个逻辑活动过程的组合，因此，它不具备一个物理过程那样的可见性。软件项目跟踪与监控的目的就是为项目实际过程提供充分的可见性，以保证当项目执行偏离项目计划时能采取有效的解决措施。

项目跟踪是基于计划的，对一个项目要设定适当的检查点。在检查点上要将执行结果、执行状态和项目开发计划进行比较。若发现较大的差异，则采取适当的步骤进行调整。在必要的情况下，也需要对项目计划本身进行修改和调整。若在修改计划时，改变了某些项目责任，那么这些改变必须得到有关责任方面的重新认同。


第65贴【2004－7－23】：CMM2级之子合同管理


由于CMM是美国国防部投资研究的项目，而美国军方有大量的子合同转包，因此子合同管理也成为了一个基本的KPA。子合同管理的目的就是选择合格的软件承包商，并可进行有效地管理。子承包商选择应由项目责任者负责，子承包商的选择是基于能力的，项目的责任者与子承包商对所承包的项目责任要有一致的认同，并保持不断地交流。项目责任者负责根据合同的责任跟踪子承包商的实际工作结果。


第66贴【2004－7－25】：CMM2级之软件质量保证


软件质量保证是项目管理提供的过程可见性的一个工具。由于用于开发软件系统或软件产品的过程是决定项目成功与否的关键因素，因此软件质量保证的工作是评审和审计软件活动与软件产品。评审和审计的依据是规定用于项目的步骤和相关标准。软件质量保证活动不能是随意的，必须经过充分的讨论和协商。相关的组织和个人要了解质量保证的活动和质量保证活动的结果。为了解决质量保证组织与开发组织对某些项目开发活动或开发出的产品的评价发生的争议和分歧，企业要定义更高层次的管理组织，负责解决这些争议和分歧。


第67贴【2004－7－26】：CMM2级之软件配置管理


产品从需求分析开始到最后提交产品要经历多个阶段，每个阶段的工作产品又会产生出不同的版本，如何在整个生存期内建立和维护产品的完整性是配置管理的目的。配置管理关键过程域的基本工作内容是：标识配置项、建立产品基线库、系统地控制对配置项的更改、产品配置状态报告和审核。同软件质量保证活动一样，配置管理活动必须制定计划，而不是随意的行为。相关的组织和个人要了解配置管理的活动及其结果，并且要认同在配置管理活动中所承担的责任。


第68贴【2004－7－27】：软件过程和项目的度量


测度对于任何工程学科而言都是基本的，软件工程也不例外。在过去十年中，软件工程界终于开始认可测度对于软件开发过程的重要性，但付出的代价也是昂贵的。

软件度量是指计算机软件中范围广泛的测度。测度可以应用于软件过程中，目的是在一个连续的基础上改进它。测度也可以用于整个软件项目中，辅助估算、质量控制、生产率评估及项目控制。最后，软件工程师使用测度帮助评估技术工作产品的质量，且在项目进行中辅助决策。

在软件项目管理中，我们主要关心生产率和质量的度量--根据投入的工作量和时间对软件开发“输出”的测度，对产生的工作产品的“适用性”的测度。为了达到计划及估算的目的，我们的主要兴趣是放在历史数据上：在过去的项目中软件开发生产率是怎样的呢？产生的软件的质量是怎样的？如何从过去的生产率及质量数据推断出现在的状况？过去的信息如何帮助我们更加准确地计划和估算呢？


第69贴【2004－7－28】：软件度量规则



软件过程度量对于一个组织提高其总体的过程成熟度能够提供很大的帮助。不过，就像其他所有度量一样，它们也可能被误用，产生比它们解决的问题更多的问题。基于此，需要建立软件度量规则，该规则可以用于管理者建立过程度量计划：
1、解释度量数据时使用通用的观念，并考虑组织的感受性
2、对收集测量和度量的个人及小组提供定期的反馈
3、不要使用度量去评价个人
4、与开发者和小组一起设定清晰的目标及达到这些目标的度量
5、不要用度量去威胁个人或组织
6、提出某个问题的度量数据不应该被看成是“否定的”含义，这些数据仅仅是过程改进的指标
7、不要被某个与其他重要度量不符合的度量迷惑


第70贴【2004－7－29】：软件故障分析


通过软件故障分析方法可以收集软件开发及使用中所遇到的错误及缺陷的信息。故障分析采用如下方式：
1.根据来源分类所有的错误和缺陷（如规格说明中的错误，逻辑错误，与标准不符合的错误等）
2.记录修改每个错误和缺陷的成本
3.统计每一类错误和缺陷的数目，并按降序排列
4.计算每一类错误和缺陷的总成本
5.分析结果数据，找出造成组织最高成本的错误和缺陷类型
6.产生修正过程的计划，目的是消除（或降低其出现的频率）成本最高的错误和缺陷类型

软件测试知识帖(71-84）


--------------------------------------------------------------------------------

Jerry选自51Testing.com的每日贴

第71贴【2004－7－30】：SQA的职责
SQA的职责

1、组织和协调产品开发组内部的软件技术和开发标准、流程的培训和教育

2、部门的和特定产品的软件开发过程度量（Metrics）以及软件产品质量的度量（Metrics）

3、指出产品开发过程中应该遵循的有关软件开发的标准和流程，并监督开发过程对标准和流程的符合度；

4、软件质量管理，采用Inspection，Review和Audit技术

5、通过软件开发流程及标准的推行以及对软件开发过程的不断总结和优化，使软件开发过程得到持续不断的优化和提高

第72贴【2004－7－31】：验证与确认
在广义上，软件测试是验证和确认VERFICATION AND VALIDATION （V﹠V〕。验证指保证软件正确地实现了一特定功能的一系列活动。确认是指保证所生产的软件可追溯到用户需求的一系列活动。BOEHM对V﹠V的解释是：

VEIFICATION：“Are we building the product right?"

VALIDATION: " Are we building the right product?"



V&V的过程包含了许多内容和活动，如：

软件工程方法提供了质量建立的基础；

分析、设计和编码方法通过提供统一的技术和可预测的结果来提高质量；

正规检视和评审有助于保证软件工程各个阶段产品的质量；

度量和控制被应用到软件配置的每一个部件中；

标准和过程有助于保证开发的一致性；

一个正规的 SQA过程加强整体质量；

测试是保证质量的最后一道措施。但是不能把测试看作一个安全网。质量是贯穿于软件过程的每一个阶段。因此尽管测试在V&V中起着非常重要的作用，但是许多其它活动也是必要的。为了提高软件的全员质量，应该重视V&V中的每一个活动。

第73贴【2004－8－2】：可测试性技术的产生
　　可测试性的概念最早产生于航空电子领域。较早的航空电子设备的测试过程通常采用以分析输入/输出端口为主的“黑箱”方式进行。随着电子设备功能和结构日益复杂，可靠性、维修性要求日益增高，“黑箱”方法已越来越难以满足需求。为此，要求测试人员以更积极的方式介入测试过程，不仅要承担传统测试中激励生成者和响应分析者的角色，而且要成为整个测试过程的主导者和设计者，通过改善被测试对象的设计使其更便于测试，即提高被测对象的可测试性。这种可测试性的思想和概念最早由F.Liour等人于1976年提出。随后，美国国防部相继颁布了MIL-STD-471A通告II--《设备或系统的机内测试、外部测试、故障隔离和可测试性特性要求的验证及评价》、MIL-STD-470A--《系统及设备维修性管理大纲》、MIL-STD-2165--《电子系统及设备的可测试性大纲》等一系列与可测试性相关的标准规范。其中，MIL-STD-2165可测试性大纲将可测试性作为与可靠性及维修性等同的设计要求，并规定可测试性分析、设计及验证的要求及实施方法，该标准的颁布标志着可测试性作为一门独立学科的确立。



可测试性概念提出后，相继用于电子产品诊断电路设计及研究等各个领域。可测试性技术不仅对维修性设计特性产生重大的影响，而且影响到系统的效能及全寿命周期费用。

第74贴【2004－8－3】：可测试性的内涵
1、可测试性描述了测试信息获取的难易程度

　　可测试性包括两方面的含义：一方面，便于对软件的内部状态进行控制，即所谓的可控性；另一方面，能够对软件的内部状态进行观测，即可观测性。实际上，可控性和可观测性所描述的就是对软件进行测试时信息获取的难易程度。传统的“黑箱”功能测试方法的根本缺陷就在于它难以获取有效表征被测对象内部状态的信息。



2、可测试性是软件本身的一种设计特性

　　同可靠性（reliability ）一样，可测试性也是软件本身所固有的一种设计特性。软件的可测试性并不是可测试性设计所赋予的，软件一旦设计生产出，本身就具备了一定的可测试性。正如可靠性可以通过MTBF等可靠性指标度量一样，可测试性也可以通过可控性、可观测性指标来度量。要改善软件的可测试性指标，必须在软件设计阶段就进行良好的可测试性设计。



3、可测试性技术的最终目标是提高软件的质量和可靠性，降低全寿命周期费用

　　降低软件的费用，追求软件的高质量是工业界的永恒主题。目前，单纯合格与否的传统质量标准已转变为综合了性能指标、可靠性及可用性（availability）指标要求的“完整质量”概念，而传统的仅考虑软件设计和生产费用的产品费用则被“全寿命周期费用”的概念所替代。全寿命周期费用包括软件整个生命周期中从概念形成到报废处理全过程的费用。

可测试性技术的应用可以极大地提高软件的“完整质量”，降低其全寿命周期费用。一方面，在软件设计阶段，可以对软件设计原型进行虚拟测试，验证设计方案，排除可能的设计缺陷；在生产阶段，可以对软件进行全面的测试，排除软件的潜在故障，从而降低使用过程中的故障率，提高其质量和可靠性；另一方面，可测试性技术可以缩短软件研制、试验和评价的周期，降低软件的研制费用，提高软件的可用性指标，减少软件的维护和保障费用，从而降低软件的全寿命周期费用

第75贴【2004－8－4】：可测试性度量
要提高产品的可测试性，首先要对产品的可测试性水平进行描述，也就是进行可测试性度量。可测试性度量方法需满足精确性和简单性两个要求。所谓精确性是指可测试性度量方法能准确地预计产品测试程序生成的困难，并且定位到产品的某一部分，从而便于对产品设计进行更改。而简单性要求则是指度量可测试性的计算量应小于测试程序生成的计算量，否则，可测试性度量方法就会失去实际的应用意义。

第76贴【2004－8－5】：可测试性机制的设计与优化
可测试性机制的设计与优化

　　

可测试性设计的过程就是将某种能方便测试进行的可测试性机制引入到软件中，提供获取被测对象内部测试信息的渠道。显然，合理、有效的设计可测试性机制是成功提高软件可测试性水平的基础。可测试性机制的引入可以提高系统的可测试性指标，降低软件的全寿命周期费用，但同时也会在一定程度上提高软件的成本。因此，综合权衡可测试性机制的性能和费用，进行可测试性机制的优化设计是可测试性技术能否成功应用的另一个重要因素。

第77贴【2004－8－6】：测试信息的处理与故障诊断
为了实现提高软件质量和可靠性，降低系统全寿命周期费用的目标，要求可测试性技术能够方便、快捷地获取有关被测软件状态的信息，确定软件工作正常与否、性能是否良好、是否存在故障以及存在何种故障，以便于采取调整设计、排除故障、更换备件等后续行为。

在对复杂的对象进行测试时，难点往往不在于如何获取测试信息，而在于如何对所获取的大量信息进行处理。例如：对于一个具有N个测点的数字电路而言，所能获取的测试信息的总量为N*2N位，随着N的增大，测试信息总量呈指数增长。显然，能否对所获取的测试信息进行有效处理并对可能存在的故障进行精确诊断，是可测试性技术成功应用的关键。

第78贴【2004－8－9】：特定目标可测试性设计
第一代可测试设计技术：特定目标可测试性设计

第一代可测试性设计技术以外部测试和特定目标可测试性设计方法为基础。特定目标可测试性设计是指：针对特定功能和结构进行可测试性预计，判断其是否符合可测试性要求，若不满足，通过改善设计方案来提高其可测试性，直至满足要求。特定目标可测试性设计主要采用外部测试方法，测试向量的输入和测试响应的输出均通过被测设备的输入/输出端口进行操作，对被测对象内部节点的控制和观测则采用以在线（in-line）测试技术。其主要缺点如下：

　　(1) 设计同系统的具体功能和结构紧密相关，对较复杂的系统进行设计的难度大、周期长；

　　(2) 难以实现并行测试；

　　(3) 需要专用测试接口和测试工具，成本高；

　　(4) 随着系统的复杂，采用监控测试方法的适用范围日益减小。

目前，特定目标可测试性设计已逐渐被其他的可测试性技术所代替。尽管如此，对于复杂程度较低的而言，特定目标可测试性设计方法仍然是一种不可或缺的方法。

第79贴【2004－8－10】：基于扫描设计的结构化设计
第一代可测试设计技术：基于扫描设计的结构化设计

　　我们知道，要完成某种系统功能可以采用不同的结构实现。传统的设计思想是尽量选用较为紧凑和简化的结构。然而，由于可测试性同系统的的结构密切相关，上述方法在设计中没有充分考虑结构对系统可测试性的影响，所设计出的系统的可测试性往往较差，将极大地增加可测试性改善设计的难度，这正是特定目标可测试性设计方法的根本缺陷。

　　结构化可测试性设计是一种新的可测试性设计策略，其主要思想是：从可测试性的观点出发，对结构结构提出一定的设计规则，使得所设计的产品更容易测试。结构化可测试性设计通常采用扫描设计的方法进行，有多种具体的实施方法，包括：扫描设计、扫描通路、扫描置位，等等。它依然存在如下的缺点：

　　(1)　可测试性设计的过程仍较复杂，设计周期较长，成本较高；

　　(2) 主要采用外部测试的方法，自动化程度不够，成本仍然较高；

(3) 不同的产品设计厂家采用不同的设计方法，相互之间不兼容，产品的维修性较差。

第80贴【2004－8－11】：基于边界扫描机制的标准化设计
第三代可测试性设计技术：基于边界扫描机制的标准化设计



　　鉴于结构化可测试性设计方法的一些缺点，有必要开发一种更为简单的、标准化的可测试性设计方法。为此，从1986～1988年，以欧洲和北美会员为主的联合测试行动组织（JTAG：joint test action group）率先开展了边界扫描技术的研究，提出了一系列边界扫描标准草案。1990年，IEEE组织和JTAG组织共同推出了IEEE 1149.1边界扫描标准［18,19］。

　　IEEE 1149.1定义了一种标准的边界扫描结构及其测试接口，其主要思想是：通过在内部逻辑之间，即边界上增加边界扫描单元，实现对状态的串行设定和读取，从而提供芯片级、板级、系统级的标准测试框架。边界扫描机制可以实现下列目标：

(1) 测试不同单元之间的连接；

(2) 测试单元的功能；

　　(3) 应用边界扫描寄存器完成其他测试功能，如伪随机测试、特征分析、静态测试等；

边界扫描机制提供了一种完整的、标准化的可测试性设计方法。自从边界扫描标准出现以来，市场上支持边界扫描机制及设计开发软件与日俱增，其应用越来越广泛。需要指出的是，边界扫描机制适用于集成度比较高的单元，对于集成度较低的而言，采用结构化可测试性设计方法有可能会得到更为优化的设计结。

第81贴【2004－8－12】：新的可测试性设计思想
随着科技与经济的发展，为提高产品的质量和竞争力，传统的纵向设计流程必然让位于“并行工程”设计。在并行工程设计环境下，可测试性技术的内涵与设计策略得到了拓展与丰富。在并行工程设计环境下，测试不仅包括了传统意义上的制造阶段以质量保证为目的的测试和使用阶段以诊断维修为目的的测试，而且还包含了产品设计实现阶段以设计验证为目的的测试，以及产品的概念设计和体系结构设计中的可测试性设计过程。并行工程设计环境下可测试性设计策略主要包括：系统可测试性的分级建模与描述策略、可测试性的递阶设计策略以及基于虚拟测试技术的可测试性设计验证策略。

第82贴【2004－8－13】：新的可测试性机制体系结构
90年代中期推出的递阶集成BIT（HIBIT：hierarchical and integrated BIT）是一种新型的系统级可测试性设计策略，它又被称为第四代的测试性设计技术。所谓HIBIT设计是指所设计的可测试性机制具备同系统一样的递阶层次结构，即具备包括系统级、子系统级（LRU）、电路板级、多芯片模块级（MCM）和芯片级的层次结构，不同层次的可测试性机制之间通过测试总线相连，实质上，HIBIT技术是边界扫描技术的一种延伸，在HIBIT中，板级测试利用IEEE 1149.1边界扫描标准进行，而设备级、系统级的测试则通过IEEE 1149.5 MTM总线进行。

　　采用分级递阶与集成可测试性机制便于进行“并行工程”的设计与开发，其主要优点是：便于测试性需求指标的分级分配；便于实现测试复用；便于实现并行分布式的测试进程，提高测试速度。实际上，HIBIT的最大特点就是引入了“并行过程”的设计思想，在HIBIT中采用了并行设计、可复用设计以及虚拟原型设计等并行工程设计方法，这是可测试性设计思想的一次飞跃。

第83贴【2004－8－14】：新的测试信息处理技术与故障诊断方法的应用
可测试性应用的关键在于对测试信息进行有效处理，而现有的测试信息处理方法存在故障诊断能力差、虚警率高等问题。为此，有必要将神经网络、专家系统等智能理论引入可测试性技术中，研究新型的测试信息处理技术与故障诊断方法，这是可测试性技术的未来研究重点之一。智能测试信息处理方法主要体现在三个方面：在测试信息的获取阶段，应用数据层信息融合的方法，对通过不同测试手段获取的测试信息进行证实与融合，提高测试信息获取的质量；在信息处理阶段，综合应用数据压缩方法、基于状态模型方法、谱分析以及神经网络方法等，提取准确表征被测对象故障状态的特征信息；在诊断决策阶段，应用马尔可夫模型、神经网络、专家系统等方法，并综合被测对象的环境信息及历史信息进行智能决策，尽可能地消除测试过程中存在的虚警问题，对故障进行精确定位。

第84贴【2004－8－16】：协议测试
协议测试已经成为计算机网络和分布式系统协议工程学中最活跃的领域之一。近年来，协议一致性测试技术得到了很好的发展和完善，与此同时，互操作测试和性能测试逐渐成为新的研究热点。



协议测试包括四种测试：

1)一致性测试（Conformance ）：检测所实现的系统与协议规范符合程度；

2)性能测试（Performance ）：检测协议实体或系统的性能指标（数据传输率、联接时间，执行速度、吞吐量、并发度等）；

3)互操作性测试（Interoperability ）：检测同一协议不同实现版本之间、或同一类协议（如电子邮件协议X.400和SMTP）不同实现版本之间互通能力和互连操作能力

4)坚固性测试（Robustness ）：检测协议实体或系统在各种恶劣环境下运行的能力(信道被切断、通信技术掉电、注入干扰报文等)。

软件测试知识帖(85-98）


--------------------------------------------------------------------------------

Jerry选自51Testing.com的每日贴

第85贴【2004－8－17】：可接受测试
用户可接受性测试（User Acceptance Testing）有时也叫验收测试。在通过了内部系统测试及软件配置审查之后，就可以开始该项测试了。验收测试是以用户为主的测试。软件开发人员和QA（质量保证）人员也应参加。由用户参加设计测试用例，使用用户界面输入测试数据，并分析测试的输出结果，一般使用生产中的实际数据进行测试。在测试过程中，除了考虑软件的功能和性能外，还应对软件的可移植性、兼容性、可维护性、错误的恢复功能等进行确认。验收测试实际上是对整个测试计划进行一种“走读（Walkthrough）”。

用户可接受测试具有下列特点：

Ø1、必须要有用户参与，且以用户为主；

2、可接受测试在不同的组织之间，随目标的不同及工作量的不同而不同；

Ø3、在软件开发过程当中，可接受测试是最容易变化的一个测试；

Ø4、用户可接受测试只有按照既定的目标进行的时候才能有真正的效果；

Ø5、很少有组织能够真正理解如何处理测试中人的方面问题，他们同时还缺乏必要的培训来进行计划和执行一个有效的可接受性测试

第86贴【2004－8－19】：标杆测试
系统指标能够描述该产品的基本特性的性能，该指标也可以称为性能指标。系统指标在系统设计初期就会提出来，但是最终产品详细指标如何必须通过严格的测试才可以得到。要根据系统稳定性测试模型，结合系统运行的实际情况对系统进行指标测试或标杆测试（Benchmark Testing）。

系统标杆测试的基本概念可以分为两部分：

Ø 在系统基本配置或最优化配置条件下，通过测试工具等模拟系统环境和提供单一或标准负荷模型，从而得到系统各种表征特性的指标，进一步可以验证系统需求和设计规格中的指标是否达到；

Ø 在多任务并接近实际网上运行等复杂条件下，由于受CPU ，内存，存储器，通道，网络，系统配置等资源的影响而测试出系统性能在各方面潜在的低效和限制，比如系统瓶颈，系统指标上限。

第86贴【2004－8－21】：在线帮助测试
用户在使用系统时候，如果出现问题，首先求助的就是在线帮助。一个糟糕的在线帮助会很大的打击用户对系统的信心。因此一个好的系统，必须要有完备的帮助体系，包括用户操作手册，实时在线帮助等。在线帮助的测试（Online Help Testing）主要用于验证系统的实时在线帮助的可用性和正确性。



在实际操作过程中，在线帮助测试可以和文档测试（或资料测试）一起进行。在进行在线帮助测试的时候，测试人员需要关注下面这些问题：

Ø 1、帮助文件的索引是否正确？

Ø 2、帮助文件的内容是否正确？

Ø 3、在系统运行过程中帮助能否被正常的激活？

Ø 4、在系统不同的位置激活的帮助内容与当前操作内容是否相关联？

Ø 5、帮助是否足够详细并能解决需要被解决的问题？

第87贴【2004－8－23】：软件可靠性
软件可靠性（Software Reliability）可以定义为：在规定环境，规定时间内（自然单元或时间单元），一个系统或其功能无故障运行的可能性。

其中：

Ø 规定的环境包括硬件环境和软件环境。软件环境包括允许的操作系统、应用程序、编译系统、数据库系统等；硬件环境包括CPU、内存、I/O等。

Ø 规定的时间一般分为执行时间、日历时间和时钟时间。其中执行时间（Executing Time）是指执行一个程序所用的实际时间和中央处理器时间，或者是程序处于执行过程中的一段时间；日历时间（Calendar time）指的是编年时间，包括计算机可能未运行的时间；时钟时间（Clock time）是指从程序执行开始到程序执行完毕所经历的钟表时间。

Ø 自然单元除时间外，跟软件产品处理数目相关的单元如运行、电话呼叫、API调用等都可以看作是一个自然单元。

第88贴【2004－8－24】：软件可靠性的层次
从用户角度来看，软件可靠性可以分四个层次来看：

第一个层面：软件不出现故障；

第二个层面：软件即使出现故障，也仅对性能有部分影响，而设备的功能不受损失；

第三个层面：软件出现故障并造成部分功能受损失，但是能够很快恢复业务；

第四个层面：软件出现较大故障，并造成大部分功能受损、业务中断或瘫痪，但能够尽快恢复业务（无论是手工恢复还是自动恢复）；



对应于不同的可靠性层次，要求系统有相应的层次设计要求和维护要求，例如：

对于第一个层面：要求系统能够按照充分的规范来进行设计，加强各种异常处理能力和环境适应能力等；

对于第二个层面：要求系统有较高的容错能力，使用冗余技术和备份技术等；

对于第三个层面：要求系统有很好的可测试性，能迅速隔离问题和定位问题等；

对于第四个层面：要求系统有较高的可维护性等

第89贴【2004－8－25】：软件的失效
失效是指功能部件执行其规定功能的能力丧失。

从失效本身的类型来分，又可以分为：

Ø 1、独立失效（Independent Failure）：指不是由于另一个产品失效而引起的失效；

Ø 2、从属失效（Dependent Failure）：由于另一产品失效而引起的失效。

Ø 3、系统性失效（Systematic Failure）：由某一固有因素引起，以特定形式出现的失效。它只能通过修改设计、制造工艺、操作程序或其它关联因素来消除。注：无改进措施的修复性维修通常不能消除其失效原因。系统性失效可以通过模拟失效原因来诱发。

Ø 4、偶然失效（Random Failure）：产品由于偶然因素引起的失效。只能通过概率或统计方法来预测。

Ø 5、单点失效（Single-point Failure）：引起产品失效的，且没有冗余或替代的工作程序作为补救的局部失效。

Ø 6、间歇故障（Intermittent Failure）：产品发生故障后，不经修理而在有限时间内自行恢复功能的故障。

Ø 7、渐变失效（Gradual Failure）：通过事前的检测或监测可以预测到的失效，它是由于产品的规定性能随寿命单位数增加而逐渐变化引起的。对电子产品也称漂移失效(Drift Failure)。

Ø 8、致命性失效（Critical Failure）：使产品不能完成规定任务的或可能导致人或物重大损失的失效或失效组合。

Ø 9、灾难性失效（Catastrophic Failure）：导致人员伤亡或系统毁坏的失效。

Ø 10、非关联失效（Non-relevant Failure）：已经证实是未按规定的条件使用而引起的失效。或已经证实仅属某项将不采用的设计所引起的失效。

Ø 11、非责任失效（Non-chargeable Failure）：非关联失效或事先已经规定不属某组织机构责任范围内的关联失效。

第90贴【2004－8－26】：可靠性指标分配
可靠性指标分配是指把系统的可靠性指标分配给系统、子系统、模块、元器件（或函数）。其主要目的是使各级设计人员明确其可靠性设计要求，并研究实现这些要求的可能性及方法。它也是可靠性试验和评估的依据。

对于电子设备，可靠性可以从整机一直分配到各个元器件。可靠性分配的目的就是使各级设计人员明确其可靠性设计要求，根据要求估计所需的人力、时间和资源，并研究实现这个要求的可能性及方法。然而对于软件来说，可靠性分配却有很大的不同，因为把可靠性分解到每一行源代码是没有意义的。对于一个系统，软件可靠性可以作为一个整体来进行考虑，它和硬件可靠性一起组成了整个系统的可靠性。它们直接的关系可以用下面公式表示：



1/MTBF（系） = 1/MTBF（硬） + 1/MTBF（软）



在硬件方面，可靠性分配的时候需要考虑各器件的组合方式（并联还是串联），同时还要考虑各种加权因子（例如重要性因子、复杂因子、环境因子、标准化因子、维修性因子和元器件质量因子）。一般来说，重要的单元应分配较高的可靠性，复杂度高的单元应分配较低的可靠性，处于恶劣环境下的单元应分配较低的可靠性，技术上不成熟的单元应分配较低的可靠性。

总之，对可靠性指标的分配必须做到合理协调、技术上可行、经济上合算。分配的可靠性指标，必须进行可靠性分析，如果分配给分系统的可靠性指标为当前技术水平和条件所限，而无法实现者，必须修改方案，重新分配，直到满足要求为止。

第91贴【2004－8－27】：FMEA
故障模式影响分析（FMEA）就是在产品设计过程中，通过对产品各组成单元潜在的各种故障模式及其对产品功能的影响进行分析，并把每一个潜在故障模式按它的严酷程度予以分类，提出可以采取的预防改进措施，以提高产品可靠性的一种设计分析方法【178】。尽管预计每一个失效模式是不现实的，但是开发组应当尽可能广泛的制定潜在故障模式列表。

通过FMEA可以达到如下目的：

Ø 能帮助设计者和决策者从各种方案中选择满足可靠性要求的最佳方案；

Ø 保证所有元器件的各种故障模式及影响都经过周密考虑；

Ø 能找出对系统故障有重大影响的元器件和故障模式，并分析其影响程度；

Ø 有助于在设计审议中对有关措施（如冗余措施）、检测设备等作出客观的评价；

Ø 能为进一步定量分析提供基础；

Ø 能为进一步更改产品设计提供资料；

Ø 在设计阶段评价来自客户或其他参与者的需求，避免引入潜在的故障；

Ø 在设计阶段跟踪和管理潜在的风险；

Ø 保证任何可能产生的失效不会伤害产品或过程的顾客；

Ø 提高客户满意度；

Ø 为测试和开发提供关注点

第92贴【2004－8－30】：故障树分析树
故障树分析（FTA）在产品设计过程中，通过对可能造成产品故障的各种因素（包括硬件、软件、环境、人为因素等）进行分析，画出逻辑框图（即故障树），从而确定产品故障原因的各种可能组合方式的一种可靠性分析技术。是用于分析大型复杂系统可靠性、安全性以及故障诊断的一个有力工具。

该方法存在两个问题：

Ø 1、不能表示实时问题；

Ø 2、不能表示系统状态或操作模式；



在使用FTA时，需要注意以下问题：

Ø 1、输入的可能性很小；

2、被动的组件；

Ø 3、对故障树进行定量分析（尽管可以对FTA进行量化，但FTA不是一个量化分析方法）；

Ø 4、把故障树代替任何别的分析方法；

Ø 5、小心使用布尔表达式；

Ø 6、独立的失效模式与非独立的失效模式对应起来；

Ø 7、确保顶部的事件具有高优先级

第93贴【2004－8－31】：事件分析树
事件树分析（ETA）可以在FTA分析之后开始，它通过分析系统中的一个初始事件，然后考虑这个事件所有可能出现的后续事件，尤其是那些可能导致事故的事件。ETA的起始点是那些扰乱正常系统操作的事件，接着它跟踪事件的传递，确定后继系统组件的失效，计算它们失效的可能性及可能的组合（与/或）。



ETA的缺点是：Ø

1、一个事件的所有可能的后继考虑起来是有困难的；

Ø2、对于一个复杂的系统，事件树将变得非常复杂，这是因为正常和不正常的所有操作都会显示在事件树中

第94贴【2004－9－1】：可靠性测试
可靠性测试是从验证的角度出发，检验系统的可靠性是否达到预期的目标，同时给出当前系统可能的可靠性增长情况。可靠性测试需要从用户角度出发，模拟用户实际使用系统的情况，设计出系统的可操作视图，在这个基础上，根据输入空间的属性及依赖关系导出测试用例，然后在仿真的环境或真实的环境下执行测试用例并记录测试的数据。对可靠性性测试来说，最关键的测试数据包括失效间隔时间，失效修复时间，失效数量，失效级别等。根据获得的测试数据，应用可靠性模型，可以得到系统的失效率及可靠性增长趋势。常用的可靠性模型可以从黑盒（占主要地位）和白盒两个角度出发。黑盒方面的可靠性模型包括了Musa基本执行模型，Jelinski-Moranda的分离富化模型，Goel-Okumoto 的NHPP模型，增强的NHPP模型以及Littlewood-Verrall的贝叶斯判定模型。在白盒方面的可靠性模型包括了Krishna-murthy 和 Mathur的基于路径的模型和 Gokhale et al.的基于状态的模型。业界流行的可靠性模型还有很多种，不同的可靠性模型其依赖的假设条件也不同，适用范围也不同，因此对于一个产品，其所适合使用的可靠性模型需要根据实际出发，尽可能选择与可靠性模型假设条件相近的模型。

第95贴【2004－9－2】：需求测试
软件测试V模型要求我们在需求阶段就开始制定系统测试的计划，开始考虑系统测试的方法。但这还不是足够的。全面的质量管理要求我们在每个阶段都要进行验证和确认的过程。因此在需求阶段我们还需要对需求本身进行测试。这个测试是必要的，因为在许多失败的项目中，7 0 %～8 5 %的返工是由于需求方面的错误所导致的。并且因为需求的缘故而导致大量的返工，造成进度延迟、缺陷的发散，这是一件及其痛苦的事情。因此我们要求在项目的源头（需求）就开始测试。这类测试更多的还只是静态手工方面的测试，当然也有一些自动化的工具，但这些工具会要求我们按照某个固定的格式进行需求的表述（例如形式化的方法），因此在适用性上会受到限制。通过静态手工方法进行需求测试中最常使用的手段是同行评审。

第95贴【2004－9－4】：通过评审来测试需求
同行评审是业界公认的最有效的排错手段之一。我们在需求测试过程当中，使用最多的也是同行评审（Peer Review），尤其是正规检视（Inspection）。正规检视是由Michael Fagan 在I B M 制定出来的一种非常严格的评审过程。

需求评审的参与者当中，必须要有用户或用户代表参与，同时还需要包括项目的管理者，系统工程师和相关开发人员、测试人员、市场人员、维护人员等。在项目开始之初就应当确定不同级别、不同类型的评审必须要有哪些人员的参与，否则，评审可能会遗漏掉某些人员的意见，导致今后不同程度的返工。

第96贴【2004－9－6】：好的需求应当具有的特点
一个良好的需求应当具有一下特点：

Ø 完整性。每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。

Ø 正确性。每一项需求都必须准确地陈述其要开发的功能。

Ø 一致性。一致性是指与其它软件需求或高层（系统，业务）需求不相矛盾。

Ø 可行性。每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。

Ø 无二义性。对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。

Ø 健壮性。需求的说明中是否对可能出现的异常进行了分析，并且对这些异常进行了容错处理。

Ø 必要性。“必要性”可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户的输入，如Use Case或别的来源。

Ø 可测试性。每项需求都能通过设计测试用例或其它的验证方法来进行测试。

Ø 可修改性。每项需求只应在S R S 中出现一次。这样更改时易于保持一致性。另外，使用目录表、索引和相互参照列表方法将使软件需求规格说明书更容易修改。

Ø 可跟踪性。应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好（f i n e - g r a i n e d ）的方式编写并单独标明，而不是大段大段的叙述。



另外应当对所有的需求分配优先级。如果把所有的需求都看作同样的重要，那么项目管理者在开发或节省预算或调度中就丧失控制自由度

第97贴【2004－9－8】：通过用例设计来测试需求
我们从V模型上可以知道，验收测试是以系统需求为基础的，系统测试是以功能测试为基础。每个开发阶段的活动都与相应的测试活动是并行进行的。在需求阶段进行系统（验收）测试计划和设计，除了能指导最终的系统测试和验收测试执行外，其本身也是对需求的一个验证过程。

通过阅读软件需求规格说明书，通常很难想象在特定环境下的系统行为。以功能需求为基础或者从使用实例派生出来的测试用例可以使项目参与者看清系统的行为。虽然没有在运行系统上执行测试用例，但是设计测试用例的简单动作可以解释需求的许多问题。如果你在部分需求稳定时就开始开发测试用例，那么就可以及早发现问题并以较少的费用解决这些问题。

设计概念性测试用例可以发现需求的错误、二义性、不可测性、遗漏等方面问题，为了获得最大的效果，要求测试人员能够独立的去对需求进行思维，从一个不同于开发的角度上进行分析，这可能会是一个逆向的思维过程，在这个过程中，测试人员可能会设计出不同于需求的测试用例，而这最终可能会有两个解释：

Ø1、需求不完整或者需求有错；

Ø2、遗漏了测试用例或者测试用例本身有错误；

不管是哪种解释，最终肯定会提高整个系统的质量。但这个质量的获得是通过冗余的人员来完成的，即：开发人员在对系统需求进行进一步分析的时候，有一组独立的测试人员也在对系统需求进行独立的思维，并从中获取测试用例。尽管这两种思维可能会出现重复，但由于思维的方式不同，最终肯定会使得需求变得更清晰和更完善。

第98贴【2004－9－9】：需求建模测试
需求的建模包括把需求转换成图形模型或形式化语言模型。需求的图形化分析模型包括数据流图（Data Flow Diagram，DFD）、实体关系图（Entity-Relationship Diagram，ERD）、状态转化图（State-Transition Diagram，STD）、对话图（Dialog Map）和类图（Class