tester2005

（转贴）

第 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 作为有

tester2005

第 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 】：静态测试

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

静态测试的基本特征是

tester2005

第 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

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

性能测试经常和压力测试一起进行，而且常常需要硬件和软件测试设备，这就是说，常常有必要的在一种苛刻的环境中衡量资源的使用（比如，处理器周期）。外部的测试设备可以监测测试执

tester2005

第 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) 阅读器

tester2005

第 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 贴【 2004 － 6 － 29 】：工具的选择：创建还是购买

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

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

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

   但即使决定自行开发测试工具，也不要试图生产一个可以

tester2005

第 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 】：自动比较技术

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

tester2005

第 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 贴【 2004 － 7 － 14 】：正规检视介绍会议

正规检视介绍会议：

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

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

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

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

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

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

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

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

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

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

   在开发、测试过程中，除了正规检视、代码走读、代码审查

tester2005

第 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 个测点的数字电路而言

tester2005

第 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 ）：导致人员伤亡或系统毁

tester2005

第 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 模型上可以知道，验收测试是以系统需求为基础的，系统测试是以功能测试为基础。每个开发阶段的活动都与相应的测试活动是并行进行的。在需求阶段进行系统（验收）测试计划和设计，除了能指导最终的系统测试和验收测试执行外，其本身也是对需求的一个验证过程。
    通过阅读软件需求规格说明书，通常很难想象在特定环境下的系统行为。以功能需求为基础或者从使用实例派生出来的测试用

tester2005

第 105 贴【 2004 － 9 － 18 】：瀑布模型和螺旋模型

瀑布模型是应用最为广泛的一种模型，也是最容易理解和掌握的模型，然而它的缺陷也是显而易见的。遗漏的需求或者不断变更的需求会使得该模型无所适从。对于那些需求比较稳定、容易理解的项目比较合适。

    螺旋模型是也是一个经典模型，它关注于发现和降低项目的风险。螺旋型项目从小的规模开始，然后探测风险，制定风险控制计划，接着确定下一步项目是否还要继续，然后进行下一个螺旋的反复。该模型的最大优点就是随着成本的增加，风险程度随之降低。然而螺旋模型的缺点是比较复杂，且需要管理人员有责任心，专注以及有管理方面经验。

第 106 贴【 2004 － 9 － 20 】： RUP 模型

RUP （ Rational Unified Process ）是 Rational 公司提出的一套开发过程模型，它是一个面向对象软件工程的通用业务流程。它描述了一系列相关的软件工程流程，它们具有相同的结构，即相同的流程构架。 RUP 为在开发组织中分配任务和职责提供了一种规范方法，其目标是确保在可预计的时间安排和预算内开发出满足最终用户需求的高品质的软件。 RUP 具有两个轴，一个轴是时间轴，这是动态的。另一个轴是工作流轴，这是静态的。在时间轴上， RUP 划分了四个阶段：初始阶段、细化阶段、构造阶段和发布阶段。每个阶段都使用了迭代的概念。在工作流轴上， RUP 设计了六个核心工作流程和三个核心支撑工作流程，核心工作流轴包括：业务建模工作流、需求工作流、分析设计工作流、实现工作流、测试工作流和发布工作流。核心支撑工作流包括：环境工作流、项目管理工作流和配置与变更管理工作流。 RUP 汇集现代软件开发中多方面的最佳经验，并为适应各种项目及组织的需要提供了灵活的形式。作为一个商业模型，它具有非常详细的过程指导和模板。但是同样由于该模型比较复杂，因此在模型的掌握上需要花费比较大的成本。尤其对项目管理者提出了比较高的要求。

第 107 贴【 2004 － 9 － 21 】： IPD 流程

IPD （ Integrated Product Development ）流程是由 IBM 提出来的一套集成产品开发流程，非常适合于复杂的大型开发项目，尤其涉及到软硬件结合的项目。 IPD 从整个产品角度出发，流程综合考虑了从系统工程、研发（硬件、软件、结构工业设计、测试、资料开发等）、制造、财务到市场、采购、技术支援等所有流程。是一个端到端的流程。在 IPD 流程中总共划分了六个阶段（概念阶段、计划阶段、开发阶段、验证阶段、发布阶段和生命周期阶段），四个个决策评审点（概念阶段决策评审点、计划阶段决策评审点、可获得性决策评审点和生命周期终止决策评审点）以及六个技术评审点。 IPD 流程是一个阶段性模型，具有瀑布模型的影子。该模型通过使用全面而又复杂的流程来把一个庞大而又复杂的系统进行分解并降低风险。一定程度上，该模型是通过流程成本来提高整个产品的质量并获得市场的占有。由于该流程没有定义如何进行流程回退的机制，因此对于需求经常变动的项目该流程就显得不大适合了。并且对于一些小的项目，也不是非常适合使用该流程。

第 108 贴【 2004 － 9 － 22 】：流程和技术

流程和成功不是等价的。没有流程就成功就不可能得到保证，但有了流程并不意味着肯定能够成功。这恐怕是很多迷信于流程的人所不能接受的。但这的确是个事实。记得有个做了将近 30 多年的需求分析专家说过：即使是一个已经达到 CMM4 级的公司，也完全有可能做不好需求分析。为什么？技术，技术是成功的另外一个必要条件。就好比现在你要从上海到北京去，流程给你指出了最短的路径，技术提供给你最快的交通工具。两者结合就是完美。
    对于软件开发来说，要保证软件的质量，需要掌握多方面的技术，包括分析技术、设计技术、编码技术和测试技术等等。在国内有一个普遍的非正常现象，就是大家觉得只有编程能力才是玩电脑的真正技能。就好像造一套房子，其它都不重要，只要砖瓦匠有高超的技能就行了。尽管这个比喻会打击很多程序员的自尊心，但这的确是一个事实。我们缺少系统级的工程师，在分析和设计方面的工作做得很不扎实。
    需求是一个项目的灵魂。模棱两可的需求带来不可避免的后果便是返工 — 重做一些你认为已做好的事情。返工会耗费开发总费用的 4 0 % ，而 7 0 % ～ 8 5 % 的重做是由于需求方面的错误所导致的。
    设计是最能体系一个工程师能力的地方。一个好的设计基本上决定了产品的最终质量。设计是把需求转换成系统的一个关键步骤，它需要从自然语言描述的需求中寻找出设计的基础单元，构建出整个系统的构架。关于设计方面的技能涉及面是很广的，包括传统的结构化设计到面向对象设计。
    总之流程很关键，技术也很重要，鱼和熊掌，两者都不能放。

第 109 贴【 2004 － 9 － 23 】： Deming 质量原则一

Deming 质量原则一：要有一个坚定不移的目标
   
    许多公司趋向于解决当前的问题而忽略将来的目标。根据 Deming 的原则： “ 对于一个公司，在没有一个针对未来的计划的前提下，它是不能存在于商业领域中的。 ” ，一个坚定不移的

tester2005

第 114 贴【 2004 － 10 － 5 】： Deming 质量原则六

Deming 第六原则：建立培训和再培训制度

    在很多公司，通常只有很少甚至没有培训，员工们不知道何时才能正确的完成他们的工作。消除不适合的培训是非常困难的。 Deming 强调：只要工作成果还无法受到统计控制，并且还能获得更大的好处的时候，培训就不应当被中止。
为了应用该原则，一个质量保证组织可以：
    1 、建立现代的培训辅助和实践
    2 、鼓励质量工作者通过参加研讨班或上课不断的提高质量和测试方面的技术知识
    3 、奖励工作者建立新的研讨班和特殊的兴趣小组
    4 、使用统计技术确定何时培训被需要，并且何时培训可以结束

第 115 贴【 2004 － 10 － 8 】： Deming 质量原则七

Deming 第七原则：建立良好的组织结构
   
    “ 没有任何一个借口可以把人放到他们不知道如何做的岗位上。绝大多数所谓的 ‘ 无事可做的人 ' 是因为他们被放置在不适合的工作上或者由于不善的管理造成的 ” 。管理者有责任去寻找是什么原因造成员工不以工作为自豪。从一个信息技术的眼光来看，开发人员经常认为质量这种事应当是质量部门的责任。 QA 作为质量领导者应当敢作敢为，并且指出质量是每一个人的责任。
    为了应用该原则，一个质量保证组织可以：
    1 、如果一个开发人员有大量的错误被 QA 测试发现，那么需要化时间来培训他（她）如何进行单元测试或如何更有效的编码
    2 、提高对流程规范的监督，这是管理者的责任
    3 、允许项目管理者有更多的时间在工作上去帮助项目组内的人
    4 、使用统计技术来揭示哪里存在缺陷
    5 、加强组织结构内的各种沟通
    6 、加强质量计划的制订、执行和反馈
    7 、质量部门保持一定的独立性

第 116 贴【 2004 － 10 － 9 】： Deming 质量原则八

第八原则：打破不同领域间的障碍

    当各部门有不同的目标的时候，很多的问题就随之产生了。这些部门不会象一个有效的小组一样去解决问题、设定政策和定义新的方向。 “ 人们在自己的部门内可以工作的非常好，但如果他们的目标发生冲突的时候，他们将对公司造成损害。此时最好成立一个联合工作组，他们对公司负责 ”
    为了应用该原则，一个质量保证组织可以：
    1 、质量保证部门和其它部门需要紧密的工作在一起。 QA 应当被视为好的伙伴，他们致力于使软件产品最终成为最优秀的产品。
    2 、质量保证组织应当指出缺陷应当在产品最终到达用户手上之前被发现

第 117 贴【 2004 － 10 － 10 】： Deming 质量原则九

Deming 第九原则：排除为工作努力而设置的口号、训示及目标

    “ 口号是不会帮助任何一个人做好工作的，它们会产生挫折和怨恨 ” 。像 “ 零缺陷 ” 或 “ 在第一时间把事情做好 ” 等口号在表面上看是好的，问题是它们被视为一种信号，即管理者不理解或不关心雇员的实际问题。设定了目标但不描述如何去完成该目标，在实践中是经常发生的。
    为了应用该原则，一个质量保证组织应该：
    1 、鼓励管理人员避免使用口号，而应该制订指导实践的规范；
    2 、 QA 组织应当开发文档标准、过程和步骤，而不是产生一些无用的口号，其它组织成员可以使用这些标准、过程和步骤得到最大的质量。

第 118 贴【 2004 － 10 － 11 】： Deming 质量原则十

Deming 第十原则：建立一个教育和再培训的有力的过程

    质量是由制造产品的人决定的，而最终是由人的知识和技能来决定的。人们必须获得新的知识和技能。教育和再培训是对人的一种投资，这是一个长期的计划。教育和再培训必须使得人们到新的工作岗位上并承担新的责任。
    为了应用该原则，一个质量保证组织可以：
    1 、鼓励质量工作者通过参加研讨班或上课不断的提高质量和测试方面的技术知识
    2 、奖励工作者建立新的研讨班和特殊的兴趣小组
    3 、在新的质量技术方面对个人进行再培训

第 119 贴【 2004 － 10 － 12 】：常见测试术语一

Acceptance Testing －－可接受性测试
一般由用户 / 客户进行的确认是否可以接受一个产品的验证性测试。

actual outcome －－实际结果         
被测对象在特定的条件下实际产生的结果。

Ad Hoc Testing －－随机测试         
测试人员通过随机的尝试系统的功能，试图使系统中断。

algorithm －－算法         
（ 1 ）一个定义好的有限规则集，用于在有限步骤内解决一个问题；（ 2 ）执行一个特定任务的任何操作序列。

algorithm analysis －－算法分析         
一个软件的验证确认任务，用于保证选择的算法是正确的、合适的和稳定的，并且满足所有精确性、规模和时间方面的要求。

Alpha Testing －－ Alpha 测试         
由选定的用户进行的产品早期性测试。这个测试一般在可控制的环境下进行的。

analysis －－分析         
（ 1 ）分解到一些原子部分或基本原则，以便确定整体的特性；（ 2 ）一个推理的过程，显示一个特定的结果是假设前提的结果；（ 3 ）一个问

tester2005

第 123 贴【 2004 － 10 － 20 】：常见测试术语五

embedded software －－嵌入式软件         
软件运行在特定硬件设备中，不能独立于硬件存在。这类系统一般要求实时性较高。

emulator －－仿真         
一个模仿另一个系统的系统或设备，它接受相同的输入并产生相同的输出。

End-to-End testing －－端到端测试         
在一个模拟现实使用的场景下测试一个完整的应用环境，例如和数据库交互，使用网络通信等。

entity relationship diagram －－实体关系图         
描述现实世界中实体及它们关系的图形。

entry point        －－入口点         
一个组件的第一个可执行语句。

Equivalence Class －－等价类         
组件输入或输出域的一个部分，在该部分中，组件的行为从组件的规格上来看认为是相同的。

equivalence partition coverage －－等价划分覆盖         
在组件中被测试执行到的等价类的百分比。

equivalence partition testing －－等价划分测试         
根据等价类设计测试用例的一种技术。

Equivalence Partitioning －－等价划分         
组件的一个测试用例设计技术，该技术从组件的等价类中选取典型的点进行测试。

error －－错误         
IEEE 的定义是：一个人为产生不正确结果的行为。

error guessing －－错误猜测         
根据测试人员以往的经验猜测可能出现问题的地方来进行用例设计的一种技术。

error seeding －－错误播种 / 错误插值         
故意插入一些已知故障（ fault ）到一个系统中去的过程，目的是为了根据错误检测和跟踪的效率并估计系统中遗留缺陷的数量。

exception －－异常 / 例外         
一个引起正常程序执行挂起的事件。

executable statement －－可执行语句         
一个语句在被编译后会转换成目标代码，当程序运行是会被执行，并且可能对程序数据产生动作。

Exhaustive Testing －－穷尽测试         
测试覆盖软件的所有输入和条件组合。

exit point －－出口点         
一个组件的最后一个可执行语句。

expected outcome －－期望结果         
参考预期结果（ predicted outcome ）。

第 124 贴【 2004 － 10 － 21 】：常见测试术语六

failure －－失效         
软件的行为与其期望的服务相背离。

fault －－故障         
在软件中一个错误的表现。

feasible path －－可达路径         
可以通过一组输入值和条件执行到的一条路径。

feature testing －－特性测试         
参考功能测试（ Functional Testing ）

FMEA －－失效模型效果分析（ Failure Modes and Effects Analysis ）
可靠性分析中的一种方法，用于在基本组件级别上确认对系统性能有重大影响的失效。

FMECA －－失效模型效果关键性分析 (Failure Modes and Effects Criticality Analysis)
FMEA 的一个扩展，它分析了失效结果的严重性。

FTA －－故障树分析 (Fault Tree Analysis)
引起一个不需要事件产生的条件和因素的确认和分析，通常是严重影响系统性能、经济性、安全性或其它需要特性。

functional decomposition －－功能分解         
参考模块分解（ modular decomposition ）

Functional Specification        －－功能规格说明书         
一个详细描述产品特性的文档。

Functional Testing －－功能测试         
测试一个产品的特性和可操作行为以确定它们满足规格。

第 125 贴【 2004 － 10 － 22 】：常见测试术语七

glass box testing －－玻璃盒测试         
参考白盒测试（ White Box Testing ）

IEEE －－美国电子与电器工程师学会（ Institute of Electrical and Electronic Engineers ）

incremental testing －－渐增测试         
集成测试的一种，组件逐渐被增加到系统中直到整个系统被集成。

infeasible path －－不可达路径         
不能够通过任何可能的输入值集合执行到的路径。

input domain －－输入域         
所有可能输入的集合。

inspection －－检视         
对文档进行的一种评审形式。

installability testing －－可安装性测试         
确定系统的安装程序是否正确的测试。

instrumentation －－插装         
在程序中插入额外的代码以获得程序在执行时行为的信息。

instrumenter －－插装器         
执行插装的工具

Integration Testing －－集成测试         
测试一个应用组合后的部分以确保它们的功能在组合之后正确。该测试一般在单元测试之后进行。

interface －－接口         
两个功能单元的共享边界。

interface analysis －－接口分析         
分析软件与硬件、用户和其它软件之间接口的需求规格。

interface testing －－接口测试         
测试系统组件间接口的一种测试。

invalid inputs －－无效输入         
在程序功能输入域之外的测试数据。

isolation testin

tester2005

第 131 贴【 2004 － 11 － 1 】：常见测试术语十三

SLA －－服务级别协议（ service level agreement ）
服务提供商与客户之间的一个协议，用于规定服务提供商应当提供什么服务。

Smoke Testing －－冒烟测试         
对软件主要功能进行快餐式测试。最早来自于硬件测试实践，以确定新的硬件在第一次使用的时候不会着火。

software development process －－软件开发过程         
一个把用户需求转换为软件产品的开发过程。

software diversity －－软件多样性         
一种软件开发技术，其中，由不同的程序员或开发组开发的相同规格的不同程序，目的是为了检测错误、增加可靠性。

software element －－软件元素         
软件开发或维护期间产生或获得的一个可交付的或过程内的文档。

software engineering －－软件工程         
一个应用于软件开发、操作和维护的系统性的、有纪律的、可量化的方法。

software engineering environment －－软件工程环境         
执行一个软件工程工作的硬件、软件和固件。

software life cycle －－软件生命周期         
开始于一个软件产品的构思，结束于该产品不再被使用的这段期间。

SOP －－标准操作过程（ standard operating procedures ）
书面的步骤，这对保证生产和处理的控制是必须的。

source code －－源代码         
用一种适合于输入到汇编器、编译器或其它转换设备的计算机指令和数据定义。

source statement －－源语句         
参考语句（ statement ）

第 132 贴【 2004 － 11 － 2 】：常见测试术语十四

specification －－规格         
组件功能的一个描述，格式是：对指定的输入在指定的条件下的输出。

specified input －－指定的输入         
一个输入，根据规格能预知其输出。

spiral model        －－螺旋模型         
软件开发过程的一个模型，其中的组成活动，典型的包括需求分析，概要设计，详细设计，编码，集成和测试等活动被迭代的执行直到软件被完成。

SQL －－结构化查询语句（ structured query language ）
在一个关系数据库中查询和处理数据的一种语言。

state －－状态         
一个系统、组件或模拟可能存在其中的一个条件或模式。

state diagram －－状态图         
一个图形，描绘一个系统或组件可能假设的状态，并且显示引起或导致一个状态切换到另一个状态的事件或环境。

state transition －－状态转换         
一个系统或组件的两个允许状态之间的切换。

state transition testing        －－状态转换测试         
根据状态转换来设计测试用例的一种方法。

statement －－语句         
程序语言的一个实体，是典型的最小可执行单元。

statement coverage －－语句覆盖         
在一个组件中，通过执行一定的测试用例所能达到的语句覆盖百分比。

statement testing －－语句测试         
根据语句覆盖来设计测试用例的一种方法。

Static Analysis －－静态分析         
分析一个程序的执行，但是并不实际执行这个程序。

第 133 贴【 2004 － 11 － 3 】：常见测试术语十五

Static Analyzer －－静态分析器         
进行静态分析的工具。

Static Testing －－静态测试         
不通过执行来测试一个系统。

statistical testing －－统计测试         
通过使用对输入统计分布进行分析来构造测试用例的一种测试设计方法。

stepwise refinement －－逐步优化         
一个结构化软件设计技术，数据和处理步骤首先被广泛的定义，然后被逐步的进行了细化。

storage testing －－存储测试         
验证系统是否满足指定存储目标的测试。

Stress Testing －－压力测试         
在规定的规格条件或者超过规定的规格条件下，测试一个系统，以评价其行为。类似负载测试，通常是性能测试的一部分。

structural coverage －－结构化覆盖         
根据组件内部的结构度量覆盖率。

structural test case design －－结构化测试用例设计         
根据组件内部结构的分析来设计测试用例的一种方法。

structural testing －－结构化测试         
参考结构化测试用例设计（ structural test case design ）

structured basis testing －－结构化的基础测试         
根据代码逻辑设计测试用例来获得 100 ％分支覆盖的一种测试用例设计技术。

structured design －－结构化设计         
软件设计的任何遵循一定纪律的方法，它按照特定的规则，例如：模块化，有顶向下设计，数据逐步优化，系统结构和处理步骤。

structured programming －－结构化编程         
在结构化程序开发中的任何包含结构化设计和结果的软件开发技术。

structured walkthrough －－结构化走读         
参考走读（ walkthrough ）

第 134 贴【 2004 － 11 － 4 】：常见测试术语十六

stub －－桩         
一个软件模块

tester2005

第 139 贴【 2004 － 11 － 11 】：测试是一个持续进行的过程，而不是一个阶段

在传统的瀑布式开发模型中定义了专门的测试阶段，如单元测试阶段，集成测试阶段或系统测试阶段。然而，这并不意味着测试只有在这个时候才进行。我遇到过很多项目，在这些项目中，对测试的理解都基于了阶段这个概念，在他们的思维中，测试只有在适当的时候才开始，并且在某个点就可以结束了。这是一个错误的理解，并且对产品的质量来说是很危险的。现代的测试已经发展成为一个全过程的验证和确认活动，它贯穿于整个开发生命周期的始末。为了获得最大的受益，测试的开发和准备必须在编码之前就应当开始，同时为了保证最终的质量，我们必须在开发过程的每个阶段保证其过程的质量。

第 140 贴【 2004 － 11 － 12 】：测试必须被计划、被控制，并且被提供时间和资源

测试并不是一个随机的活动，测试必须被计划，并且被安排足够的时间和资源。测试活动应当受到控制，测试的中间产物应当被评审并纳入配置管理。
      测试计划是一个关键的管理功能，它定义了各个级别的测试所使用的策略、方法、测试环境、测试通过或失败准则等内容。测试计划的目的是要为有组织的完成测试提供一个基础。从管理的角度来看，测试计划是最重要的文档，这是由于它帮助管理测试项目。如果一个测试计划是完整并且经过深思熟虑的，那么测试的执行和分析将平滑的进行。
      测试计划可以分级，也可以是一个总的计划，并且测试计划是一个不断演进的文档。如果不考虑应用软件的最初来源（复用的组件或已实现的组件），软件需求是测试活动的驱动。因此，测试计划应当关注于文档化的需求。此外，支持测试的过程应当被文档化下来以创建一个可重复的过程，该过程将保证开发工作产品的质量。
      一个好的测试计划应当：
1 、在检测主要缺陷方面有一个好的选择
2 、提供绝大部分代码的覆盖率
3 、是灵活的
4 、易于执行、回归和自动化
5 、定义要执行测试的种类
6 、清晰的文档化了期望的结果
7 、当缺陷被发现的时候，提供缺陷核对
8 、清晰的定义测试的目标
9 、明确测试的策略
10 、清晰定义测试的出口标准
11 、没有冗余
12 、确认风险
13 、文档化测试的需求
14 、定义可交付的测试件

第 141 贴【 2004 － 11 － 15 】：测试应该有重点

尽管我们的测试是需要按照一定的级别进行，但资源和时间是有限的，实际上我们不可能无休止的进行测试，因此在有限的时间和资源下如何有重点的进行测试是测试管理者需要充分考虑的事情。例如，在单元测试的时候，对于哪些函数我们需要重点测试，哪些函数可以粗略测试，哪些函数可以不测试；而对于系统测试，则要考虑首先应当保证哪些功能的测试，其次应当保证哪些功能的测试等等。测试的重点选择需要根据多个方面考虑，包括测试对象的关键程度，可能的风险，质量要求等等。这些考虑与经验有关，随着实践经验的增长，你的判断也会更有效。

第 142 贴【 2004 － 11 － 16 】：测试不是为了证明程序的正确性

正如 Mayer 所说的，测试的目的是证伪而不是证真。事实上，证明程序的正确性是不可能的，一个大型的集成化的软件系统不能被穷尽测试以遍历其每条路径。即使遍历了所有的路径，错误仍有可能隐藏。我们做测试是为了尽可能的去发现错误。因此，测试必须包含一系列测试级别。这些测试级别能最大化对被测对象的覆盖。
    必须有一些标准可以用于平均所有的测试活动。所有可以跟踪到需求的测试可以通过三个方式进行执行：
在正常的数据流量下的有效信息；
在一个控制环境中使用超量的数据输入速率；
使用一个预先计划的正常数据和异常数据的组合；
    理想的测试环境要能够使得一个系统在可控的方式下被破坏。例如，数据及数据组合必须不断变化直到系统不能够以正常的方式接受。系统支持变得不可接受的点必须被确认并文档化下来。
    必须在所有的测试级别上运行测试，且同时使用正常条件和异常条件。这是很严格的，即使在测试环境难以建立的情况下。

第 143 贴【 2004 － 11 － 17 】：测试是不可能穷尽的，当测试出口条件满足时就可以停止测试