牵着老婆满街逛

严以律己,宽以待人. 三思而后行.
GMail/GTalk: yanglinbo#google.com;
MSN/Email: tx7do#yahoo.com.cn;
QQ: 3 0 3 3 9 6 9 2 0 .

常见测试术语

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 －－桩         
一个软件模块的框架或特殊目标实现，主要用于开发和测试一个组件，该组件调用或依赖这个模块。

symbolic evaluation －－符号评价         
参考符号执行（ symbolic execution ）

symbolic execution －－符号执行         
通过符号表达式来执行程序路径的一种静态分析设计技术。其中，程序的执行被用符号来模拟，例如，使用变量名而不是实际值，程序的输出被表示成包含这些符号的逻辑或数学表达式。

symbolic trace －－符号轨迹         
一个计算机程序通过符号执行是经过的语句分支结果的一个记录。

syntax testing －－语法分析         
根据输入语法来验证一个系统或组件的测试用例设计技术。

system analysis －－系统分析         
对一个计划的或现实的系统进行的一个系统性调查以确定系统的功能以及系统与其它系统之间的交互。

system design －－系统设计         
一个定义硬件和软件构架、组件、模块、接口和数据的过程以满足指定的规格。

system integration －－系统集成         
一个系统组件的渐增的连接和测试，直到一个完整的系统。

System Testing －－系统测试         
从一个系统的整体而不是个体上来测试一个系统，并且该测试关注的是规格，而不是系统内部的逻辑。

第 135 贴【 2004 － 11 － 7 】：常见测试术语十七

technical requirements testing －－技术需求测试         
参考非功能需求测试（ non-functional requirements testing ）

test automation －－测试自动化         
使用工具来控制测试的执行、结果的比较、测试预置条件的设置、和其它测试控制和报告功能。

test case －－测试用例         
用于特定目标而开发的一组输入、预置条件和预期结果。

test case design technique －－测试用例设计技术         
选择和导出测试用例的技术。

test case suite －－测试用例套         
对被测软件的一个或多个测试用例的集合。

test comparator －－测试比较器         
一个测试工具用于比较软件实际测试产生的结果与测试用例预期的结果。

test completion criterion －－测试完成标准         
一个标准用于确定被计划的测试何时完成。

test coverage －－测试覆盖         
参考覆盖率（ Coverage ）

test driver －－测试驱动         
一个程序或测试工具用于根据测试套执行软件。

test environment －－测试环境         
测试运行其上的软件和硬件环境的描述，以及任何其它与被测软件交互的软件，包括驱动和桩。

第 136 贴【 2004 － 11 － 8 】：常见测试术语十八

test execution －－测试执行         
一个测试用例被被测软件执行，并得到一个结果。

test execution technique －－测试执行技术         
执行测试用例的技术，包括手工、自动化等。

test generator －－测试生成器         
根据特定的测试用例产生测试用例的工具。

test harness －－测试用具         
包含测试驱动和测试比较器的测试工具。

test log －－测试日志         
一个关于测试执行所有相关细节的时间记录。

test measurement technique －－测试度量技术         
度量测试覆盖率的技术。

Test Plan －－测试计划         
一个文档，描述了要进行的测试活动的范围、方法、资源和进度。它确定测试项、被测特性、测试任务、谁执行任务，并且任何风险都要冲突计划。

test procedure －－测试规程         
一个文档，提供详细的测试用例执行指令。

test records －－测试记录         
对每个测试，明确的记录被测组件的标识、版本，测试规格，和实际结果

test report －－测试报告         
一个描述系统或组件执行的测试和结果的文档。

Test Script －－测试脚本         
一般指的是一个特定测试的一系列指令，这些指令可以被自动化测试工具执行。

Test Specification －－测试规格         
一个文档，用于指定一个软件特性、特性组合或所有特性的测试方法、输入、预期结果和执行条件。

第 137 贴【 2004 － 11 － 9 】：常见测试术语十九

test strategy －－测试策略         
一个简单的高层文档，用于描述测试的大致方法，目标和方向。

test suite －－测试套         
测试用例和 / 或测试脚本的一个集合，与一个应用的特定功能或特性相关。

test target －－测试目标         
一组测试完成标准。

testability －－可测试性         
一个系统或组件有利于测试标准建立和确定这些标准是否被满足的测试执行的程度。

Testing －－测试         
IEEE 给出的定义是： 1 ）一个执行软件的过程，以验证其满足指定的需求并检测错误。 2 ）一个软件项的分析过程以检测已有条件之间的不同，并评价软件项的特性。

thread testing －－线程测试         
自顶向下测试的一个变化版本，其中，递增的组件集成遵循需求子集的实现。

time sharing －－时间共享         
一种操作方式，允许两个或多个用户在相同的计算机系统上同时执行计算机程序。其实现可能通过时间片轮转、优先级中断等。

top-down design －－由顶向下设计         
一种设计策略，首先设计最高层的抽象和处理，然后逐步向更低级别进行设计。

top-down testing －－自顶向下测试         
集成测试的一种策略，首先测试最顶层的组件，其它组件使用桩，然后逐步加入较低层的组件进行测试，直到所有组件被集成到系统中。

traceability －－可跟踪性         
开发过程的两个或多个产品之间关系可以被建立起来的程度，尤其是产品彼此之间有一个前后处理关系。

traceability analysis －－跟踪性分析         
（ 1 ）跟踪概念文档中的软件需求到系统需求；（ 2 ）跟踪软件设计描述到软件需求规格，以及软件需求规格到软件设计描述；（ 3 ）跟踪源代码对应到设计规格，以及设计规格对应到源代码。分析确定它们之间正确性、一致性、完整性、精确性的关系。

traceability matrix －－跟踪矩阵         
一个用于记录两个或多个产品之间关系的矩阵。例如，需求跟踪矩阵是跟踪从需求到设计再到编码的实现。

第 138 贴【 2004 － 11 － 10 】：常见测试术语二十

transaction －－事务 / 处理         
（ 1 ）一个命令、消息或输入记录，它明确或隐含的调用了一个处理活动，例如更新一个文件。（ 2 ）用户和系统之间的一次交互。（ 3 ）在一个数据库管理系统中，完成一个特定目的的处理单元，如恢复、更新、修改或删除一个或多个数据元素。

transform analysis －－事务分析         
系统的结构是根据分析系统需要处理的事务获得的一种分析技术。
trojan horse －－特洛伊木马         
一种攻击计算机系统的方法，典型的方法是提供一个包含具有攻击性隐含代码的有用程序给用户，在用户执行该程序的时候，其隐含的代码对系统进行非法访问，并可能产生破坏。

truth table －－真值表         
用于逻辑操作的一个操作表格。

Unit Testing －－单元测试         
测试单个的软件组件，属于白盒测试范畴，其测试基础是软件内部的逻辑。

Usability Testing －－可用性测试         
测试用户使用和学习产品的容易程度。

validation －－确认         
根据用户需要确认软件开发的产品的正确性。

verification －－验证         
评价一个组件或系统以确认给定开发阶段的产品是否满足该阶段开始时设定的标准。

version －－版本         
一个软件项或软件元素的一个初始发布或一个完整的再发布。

volume testing －－容量测试         
使用大容量数据测试系统的一种策略。

Walkthrough －－走读         
一个针对需求、设计或代码的非正式的同行评审，一般由作者发起，由作者的同行参与进行的评审过程。

waterfall model －－瀑布模型         
软件开发过程模型的一种，包括概念阶段、需求阶段、设计阶段、实现阶段、测试阶段、安装和检查阶段、操作和维护阶段，这些阶段按次序进行，可能有部分重叠，但很少会迭代。

White Box Testing －－白盒测试         
根据软件内部的工作原理分析来进行测试。

第 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 】：测试是不可能穷尽的，当测试出口条件满足时就可以停止测试

有测试大师说测试是为了发现错误，一个好的测试是发现以前没有发现的错误。但是这个要求可能会使人走入极端。其实，不同的系统有着不同的质量要求，对于质量要求严格的系统，可能需要进行长时间的，全面的测试，尽可能的去挖掘系统中的缺陷。然而对于质量要求不是很严格的系统，系统是允许可以出现错误的，因此我们通过测试是要使得系统的缺陷数量能够降到可接受的范围内。
    测试是不可能穷尽的，资源和时间是有限的。因此我们在做测试的时候需要分析哪些功能是对用户很关键的，在这些功能中出现某类型错误对用户是不可接受的，而相对其它一些功能，出现的错误是可以容忍的，这样，我们在测试的时候，重点就应当去寻找那些用户不可接受的错误，而不是漫无目的的去搜索错误。同时我们应当对测试定义合理的出口标准，这是因为测试是没有穷尽的，系统中的问题你总是可以一直发现下去，然而我们不能无休止的去寻找这些问题。当条件满足的时候，我们就应当停止测试。而测试出口条件的设置需要考虑系统的质量要求及系统的资源要求。曾经有人说过：当时间和资源用尽的时候，测试也就停止了。这是没有办法的最好办法。

第 144 贴【 2004 － 11 － 18 】：测试是开发的朋友，不是开发的敌人

测试人员和开发人员经常无法有效的一起工作。这一方面是因为双方工作的性质不同（开发的工作是构建系统，而测试的工作是去破坏系统），另一方面也可能是因为管理的原因造成了测试和开发之间的矛盾。不管是什么原因，这个矛盾，对于产品来说不是一件好事。
    如何处理好测试与开发之间的关系是现代软件管理研究中的一个课题。开发和测试作为一个整体都是服务于产品，都要为产品的质量负责。从这一点上来讲，开发和测试的利益是一致的。要知道，如果在产品交付使用之前，测试人员遗漏了一个问题，而这个问题最终在用户手上被发现，并产生比较严重的后果的时候，那么，我想无论是开发还是测试，最终都逃避不了责任。我们要为质量服务，测试的目的是要去寻找错误，最终提高产品的质量，而不是去找开发的茬，只有当双方都认识到这一点的时候，开发和测试就有共同交流的基础了。测试应当是开发的朋友，他帮助开发寻找遗留在产品中的缺陷，使得开发人员能够产生的更好的产品。测试和开发不应当是敌人。

第 145 贴【 2004 － 11 － 19 】：测试人员应当站在公正的立场上进行测试

我们说测试是开发的朋友，这并不等于测试就应当处处维护开发人员，替开发人员隐瞒缺陷或纵容缺陷的存在。这是对朋友的误解。我们要知道缺陷的存在最终只会影响到整个产品。在开发过程中，测试人员一直承担着质量把关人员的角色，尤其是测试将会是产品最终交付给用户之前的最后一道关卡。如果测试人员不能站在公正的立场上去执行测试，并如实的记录和报告缺陷，那么最后受伤的不仅仅是开发人员，还会包括测试人员自己。对质量负责，不仅仅是对自己负责，也是对开发负责和对产品负责。

第 146 贴【 2004 － 11 － 22 】：测试自动化能解决一部分问题，但不是全部

工具所能发挥的作用依赖于使用工具的人。因此，对工具的过分依赖将降低人的能动性，并最终使测试本身受到损害。适当的使用测试工具能够减轻测试人员的机械性工作，提高工作效率，而滥用工具会降低测试的质量。并不是任何工作都适合自动化的，如何合理的自动化测试，合理的选择适当的测试工具已经是研究人员感兴趣的一个课题。

第 147 贴【 2004 － 11 － 23 】：测试不能仅仅包括功能性的验证，还需要包括非功能性的验证

目前很多公司进行的测试，其范围仅局限在功能领域内进行测试。这一方面可能有产品进度的压力影响，另一方面则是测试人员对测试的理解还比较局限。从用户角度来讲，其需求除了功能性需求外，还包括了非功能性需求，有些非功能需求可能是显性的，而有些非功能需求则是隐性的。我们在测试的时候，应当关注所有的需求，在验证功能的同时，还需要验证产品的性能、可靠性、稳定性、可维护性、安全性、可操作性、可安装性等等。一个产品的缺陷往往会在其性能的边界上产生，如果我们忽视了这部分的测试，很多缺陷将漏过测试进入到用户手上。

第 48 贴【 2004 － 11 － 24 】：尽早的、频繁的进行测试

现代测试的一个重要哲学要求尽可能早的，尽可能频繁的进行测试，尽可能多的从开发那边获得反馈信息。这包含着要求测试尽可能早的进行准备，并且和开发人员一起进行评审、走读、单元测试、原型评价、早期模拟等等。早期测试的目的是尽可能早的发现任何意想不到的坏的消息，并且帮助开发人员产生高质量的单元。
    该方法希望在缺陷产生的时候发现并纠正缺陷，它假设了在早期测试中发现的问题能够被描述并及时修正。许多项目管理人员延迟了缺陷修正的时间直到开发人员已经完成了所有特性的设计和编码。这大大提高了系统出错的可能，也增加了修改的成本。一般来说，一次完成一个特性的设计和编码，并保证其正确性将更加有效一些。
    为什么我们要尽早的发现缺陷和修正缺陷呢？这主要有以下原因：
1 、缺陷的修改成本随着阶段的推移将急剧上升，在产品发布之后修正一个缺陷的成本将是需求阶段的 100 倍，甚至更高；
2 、缺陷具有放大的特点，缺陷修改延迟几个星期甚至几个月将使得系统更容易出错；
3 、设计判定和一些小的代码限制及条件很容易被忘掉；
4 、尽早修正缺陷可以节省重新分析设计的时间；
5 、早期的问题反馈有助于防止类似错误的产生；
6 、大量的缺陷和问题跟踪工作将被减轻；
7 、如果必要的话，可以重新设计和编码，而这个工作越往后期越不可能

第 149 贴【 2004 － 11 － 25 】：尽早的产生一个综合的主测试计划

提供和维护一个主测试计划（ Master Testing Plan ），包含所有预期的测试活动和测试交付物。综合的测试计划应当结合总的项目和程序开发计划，并保证资源和责任在项目中尽可能早的被了解和分配。
      大部分项目没有尽早的描述测试的问题。主测试计划解决了这个问题并且使得测试的工作和策略可以被项目中的每个人看到和理解。主测试计划至少应当包括测试的总工作量，分配所有主要工作的责任以及在所有测试级别上应交付的物件。其目的是要提供一个大的活动图并且协调所有的测试工作。
      主测试计划涉及到项目组所有成员，包括用户、客户和管理人员。在测试评价中所包含的每个人的活动应当被描述，包括那些分配给开发人员的活动，例如：单元评审和测试。产品经理以及那些在项目之外的人员将发现主测试计划有助于把测试过程融合到整个项目开发过程中去。随着项目的进行，主测试计划也将被修正和更新。
      创建主测试计划不需要花费许多工作量，并且它不需要是一个特别冗长的或者严肃的文档。许多内容可以通过类似于 RAD ，头脑风暴等方法在项目早期被完成。

第 150 贴【 2004 － 11 － 26 】：对质量要求较高的产品或大型复杂的产品成立独立的测试组

测试是一个需要专业技能的工作，它需要专门的培训和实践，你不应当把它看作是一个开发之外附带的工作。大部分人认为（尤其是项目管理人员）测试是项目工作中的一部分，因此他们认为只要能够小心的彻底的测试自己的工作，就能够提交高质量的工作结果。我们完全可以理解好的测试是每个人的任务。我们也知道测试是过程的一部分，并且在大部分情况下，我们知道需要做什么，需要得到什么。然而，事实上在进度和竞争的压力下，测试任务经常被第一个延迟、裁减或完全绕开。为什么会这样呢？我们应当做些什么才能使得组内每个人更好的履行他的责任呢？
      大部分问题是心里上的问题：
   当我们知道会有更多的问题被发现的时候，测试会让人沮丧；
   当我们认为每一样东西都已经被完成的时候，测试让人厌烦；
   弱的测试让我们感觉获得比实际上更多的进展；
   对开发人员来说，测试暴露的问题越多，意味着有更多的返工需要进行；
   对管理人员来说，测试看起来像是虚的工作，在项目陷入问题的时候是可以被砍调的；
   开发人员相信用户和客户愿意购买低质量的，但功能更多的产品；

    由一个独立于开发的专业测试组来从事项目的测试是一个比较好的实践，并且能有效解决上面的问题。

第 151 贴【 2004 － 11 － 29 】：在每个开发阶段，使用质量评价标准

许多项目看上去都进行的非常不错，但到它们进入集成测试和系统测试后，这时，甚至一个简单的测试都无法运行起来。如何避免这种现象的产生呢？一个好的方法是尽早测试，并且在每个阶段上通过测试数据来评价其是否能通过阶段的质量标准。当你坚持使用测试来分阶段证明每一个特性或对象被完成，那么你就能保证各阶段的设计和代码被真正的按照质量要求完成。

第 152 贴【 2004 － 11 － 30 】：开发和维护一个测试需求和目标的风险优先级列表

现代测试的一个重要实践是在测试被设计和创建之前建立一个需要覆盖的目标清单。这个清单细化了需要测试的内容，并且被用于指导和驱动测试设计和开发工作。根据风险的优先级（一般分为高、中、低）有助于使测试关注于高风险区域。
    下面是一个如何获取测试清单的指导：
尽可能早的开始并且覆盖所有需求或功能设计规格；
使用头脑风暴和非正式会议来创建一些大家担心的事项列表；
在评审期间，评价清单中的每一项，并设定优先级；
把清单中的内容分成三个主要的增量组：需求、设计和代码；
把每个增量组分解成一个小部分的逻辑组；

    由于清单列表可能会变得非常长，因此把它们分类是很有帮助的。遗漏的目标可以很容易从这些组中被确认。
    随着每个测试被开发，相关的清单目标和组被进行了记录，作为测试描述的一部分。通过一些简单的测试管理工具，你可以报告需求和目标的测试覆盖情况，尤其是哪些还没有被任何测试覆盖到的目标。

posted on 2006-07-27 21:26 杨粼波 阅读(687) 评论(0)  编辑 收藏 引用 所属分类: 软件工程


只有注册用户登录后才能发表评论。
网站导航: 博客园   IT新闻   BlogJava   博问   Chat2DB   管理