rup软件测试案例,rup软件测试基础.ppt

rup软件测试基础

测试用例(Test Case) 从前面我们知道测试用例是为特定目标开发的测试输入、执行条件和预期结果的集合。测试用例比测试脚本更抽象。另外，它还规定了开始条件、测试过程的条件和结束条件。 测试用例的目的是确定并传达一些条件，这些条件将在测试中执行，并且是核实实施产品需求(用例、性能特征等)是否成功和能否接受所必需的条件。测试用例反映了一种测试覆盖(基于需求的测试覆盖)评测方法，这是因为每个测试用例都可追踪到至少一个测试需求，而这些需求则反映出产品的需求。 测试组(Test Suite) 测试组是一组相关的侧试，它们在一起执行可以给出关于某个方面的更好的评估。一个测试组实现了一个或多个包含测试脚本和测试数据的测试思想或测试用例。 如果只想运行一个测试用例，测试员可以从测试计划中直接运行。对于快速执行少量的测试用例来说，这种方法很好。如果要执行的测试用例比较多，就有点力不从心了，测试组就是一个很好的解决方法，创建一个包含要执行的测试用例的集合(Suite)。集合可以被存储，并在任何时候再次执行。集合也能提供一些附加的功能，如分发测试到远程工作站执行，还允许测试员使用一些功能如随机执行、同步、延迟、分组等等。 3.5RUP 四级测试 RUP 确定了四级测试：单元测试、集成测试、系统测试和验收测试。这些测试级别可以是并列的，也可以是递进的，这取决于主测试计划(在项目级)和迭代测试计划(在迭代级)。 3.5.1 主测试计划和迭代测试计划 RUP 对整个项目使用一个主测试计划，对每次迭代使用一个迭代测试计划。测试经理在先启阶段草拟主测试计划。尽管是从系统测试开始的，但为了排列这些测试级别，在这两种情况中，计划都有可能包括系统测试之外的其它测试级别。这两个计划在内容上有大量的相似之处。只是范围和详细的程度有区别。一个选择是将迭代测试计划与迭代计划集成在一起。在这种情况下，测试的贡献主要是在于指出了确定和执行测试用例所依据的需求。与此迭代相关的其它测试活动也被提出来了；例如，适当的测试工具的选择或创建明确的指导方针。 3.5.2 单元测试(UT) 单元测试用于软件的最小可测试单元。单元测试强调内部结构，例如逻辑和数据流，以及单元的功能和外部可见行为测试。 RUP 中的单元测试是实现人员的明确任务，在对于新的或变更单元的每个迭代中，都是由实现人员来执行实现测试组件和子系统，以及执行单元测试这些活动。这就使得测试成为与此角色相关联活动的主要部分。 尽管RUP 包含了许多关于单元测试的指导方针，但是并没有命名一个项目特定指导方针需要在其中被固化的工件。这就和用例设计和用例建模的指南形成了对比。理论上，单元测试的指导原则被包括在单元测试指南中，指南的开发和执行是过程工程师们的共有责任，并且应当与主测试计划一致。 3.5.3 集成测试(IT) 集成测试取决于当软件组件在被合并起来执行一个用例时，是否功能正确。开发人员将自己单元测试过的组件提交到集成人员那里，集成人员将这些单元合并成一个中间构造。这种一步步的组件集成发生在从下至上的方式中，并且按照集成构建计划规定的顺序进行。在每一步之后，集成人员组成一个中间构造，被提交用于执行集成测试。主要目标是确定这些组件与已经集成组件之间的兼容性。结果，常常会执行集成构建计划的一个子集。这种一步步的方法考虑到足够的问题隔离和分析。 RUP 规定，集成测试由测试角色的人员来执行，也可以合并在集成员角色下面。实际上这些角色为了效率最大化，可以由相同的人员来承担。这意味着，集成人员也可以执行作为其活动主要内容的集成测试。 关于指南和工具，应用于集成测试与单元测试是一样的。主要的差别是，集成测试的指南不会自动成为编程指南的一部分，但会是测试指南的一部分，或遵循集成构建计划。测试经理需要与其他工程师进行一些调整。 3.5.4 系统测试(ST) 当软件功能成为一个系统时，在不同组件的集成(测试)之后，就开始执行系统测试。多个构建可以在一个迭代中交付。通常每个构建都要进行一次系统测试，除非集成测试计划另有规定。主测试计划和更具体的迭代测试计划，需要简要说明哪个构建需要被测试。 RUP 确定了系统测试的测试流程。 3.5.5 验收测试(AT) 验收测试是在软件部署之前的最后的测试。主要的目标是验证软件是否已准备好，可以被最终用户用于执行其设计的任务和功能。 验收测试被放在移交阶段，并且是部署流程的一个主要部分。RUP 定义验收测试不够充分，只是作为系统测试用例子集的重新运行。测试人员需要在一个类似产品的环境中执行这些用例。在验收测试期间，考虑工件产品的产品验收计划是很重要的。项目经理在项目的先启阶段开始编写产品验收计划。验收测试的相关主题是验收标准、接受的工件和评价方法。 RUP 没有提供用于在此阶段部署的工具的许多指导。验收测试