测试用例编写指南..doc

测试用例编写指南 Document ID Revision Confidential Copyright Notice Copyright? 2003 - 2005 *** Technologies Ltd. No part of this publication may be copied without the express written Permission of *** Technologies Ltd. Revision History Date Revision Description Author 目录 测试用例编写规范 1 1. 目的： 4 2. 范围： 4 3. 术语解释 4 4. 业务流程测试用例编写原则 5 4.1 系统性 5 4.2 连贯性 5 5. 测试用例设计的方法 5 4.3 等价类划分法 5 3.2.1 确定等价类的原则 5 3.2.2 测试用例的选择原则 5 4.4 边界值分析法 6 3.2.1 测试用例的选择原则 6 6. 测试用例设计的原则 6 4.5 全面性 6 4.6 正确性 6 4.7 符合正常业务惯例 6 4.8 仿真性 6 4.9 可操作性 6 7. 测试用例编写格式细则 7 4.10 测试用例内容 7 4.11 测试用例表格格式 7 8. 测试用例优先级 7 对于A、B 级应重点考虑 7 9. BUG级别 7 目的： 统一测试用例编写的格式和内容，以保证测试用例的有效性和可执行性，保证测试质量。 范围： 适用于公司对产品测试的测试用例的编写。 术语解释 测试用例的作用和需求来源 测试用例的作用 要使最终用户对软件感到满意,最有力的举措就是对最终用户的期望加以明确阐述，以便对这些期望进行核实并确认其有效性。测试用例反映了要核实的需求。然而，核实这些需求可能通过不同的方式并由不同的测试员来实施 选中要核实的需求将是对成本、风险和对该需求进行核实的必要性这三者权衡考虑的结果。 确定测试用例之所以很重要，原因有以下几方面。 测试用例构成了设计和制定测试过程的基础。 测试的“深度”与测试用例的数量成比例。由于每个测试用例反映不同的场景、条件或经由产品的事件流，因而，随着测试用例数量的增加，您对产品质量和测试流程也就越有信心。 判断测试是否完全的一个主要评测方法是基于需求的覆盖，而这又是以确定、实施和/或执行的测试用例的数量为依据的。类似下面这样的说明：“95 % 的关键测试用例已得以执行和验证”，远比“我们已完成 95 % 的测试”更有意义。 测试工作量与测试用例的数量成比例。根据全面且细化的测试用例，可以更准确地估计测试周期各连续阶段的时间安排。 测试设计和开发的类型以及所需的资源主要都受控于测试用例。 测试用例通常根据它们所关联关系的测试类型或测试需求来分类，而且将随类型和需求进行相应地改变。最佳方案是为每个测试需求至少编制两个测试用例： 一个测试用例用于证明该需求已经满足，通常称作正面测试用例； 另一个测试用例反映某个无法接受、反常或意外的条件或数据，用于论证只有在所需条件下才能够满足该需求，这个测试用例称作负面测试用例。 测试用例的需求来源 用例（业务流程） 功能（功能点，界面操作） 非功能性需求（质量目标） 从用例中产生的测试用例 用于功能性测试说明业务流程的测试用例来源于测试目标的用例。应该为每个用例场景编制测试用例。用例场景要通过描述流经用例的路径来确定，这个流经过程要从用例开始到结束遍历其中所有基本流和备选流。?? 例如，下图中经过用例的每条不同路径都反映了基本流和备选流，都用箭头来表示。基本流用直黑线来表示，是经过用例的最简单的路径。每个备选流自基本流开始，之后，备选流会在某个特定条件下执行。备选流可能会重新加入基本流中（备选流 1 和 3），还可能起源于另一个备选流（备选流 2），或者终止用例而不再重新加入某个流（备选流 2 和 4）。 ? 用例的事件流示例 遵循上图中每个经过用例的可能路径，可以确定不同的用例场景。从基本流开始，再将基本流和备选流结合起来，可以确定以下用例场景：? 场景 1 基本流 ? ? ? 场景 2 基本流 备选流 1 ? ? 场景 3 基本流 备选流 1 备选流 2 ? 场景 4 基本流 备选流 3 ? ? 场景 5 基本流 备选流 3 备选流 1 ? 场景 6 基本流 备选流 3 备选流 1 备选流 2 场景 7 基本流 备选流 4 ? ? 场景 8 基本流 备选流 3 备选流 4 ?