测试用例设计(一)

1.                概述

This document has been compiled from a number of testing related sources and provides a general process for developing unit test specifications. It describes some specific techniques for designing unit test cases. It serves as a tutorial for those who are new to formal testing. In addition, it also serves as a reminder of some finer points for experienced software testers.

本文档描述了一系列测试的相关的来源并为开发提供一个一般过程单元测试规格。它描述设计单元测试用例的一些具体技术。对于那些新接触正式测试的人员，它起到讲解作用。对于那些有经验的测试人员，它能提供一些有益的提示信息。

 

2.                介绍

The design of tests is subject to the same basic engineering principles as the design of software. Good design consists of a number of stages, which progressively elaborate the design. Good test design consists of a number of stages, which progressively elaborate the design of tests:

 

测试设计和软件设计一样遵循基本工程学原理。好的设计包括一系列的阶段, 逐步地详细描述设计。好的测试设计包括一系列的阶段, 逐步地详细描述测试设计：

• Test strategy
• Test planning
• Test specification
• Test procedure

 

• 测试策略
• 测试计划
• 测试规格
• 测试步骤

 

These four stages of test design apply to all levels of testing, from unit testing through to system testing. This document concentrates on the specification of unit tests; i.e. the design of individual unit test cases within unit test specifications.

 

测试设计四阶段适用于所有层次的, 从单元测试到系统试验。本文档集中于单元测试的规格; 即各自的单元测试用例设计在单元测试规格之内

 

The design of tests has to be driven by the specification of the software. For unit testing, tests are designed to verify that an individual unit implements all design decisions made in the unit's design specification. A thorough unit test specification should include positive testing (prove that the unit does what it is supposed to do), and negative testing (prove that the unit does not do anything that it is not supposed to do).

 

测试设计必须依据于软件规格说明书。对于单元测试, 测试是用来核实设计的。一个详尽的单元测试规格应该包括正向测试(证明, 单元做什么), 和反向测试(单元不做什么)。

 

Producing a test specification, including the design of test cases, is the level of test design, which has the highest degree of creative input. Furthermore, unit test specifications will usually be produced by a large number of staff with a wide range of experience, not just a few experts.

 

开发测试规格, 包括测试用例设计, 是测试设计的水平, 有高度创造性的输入。而且单元测试规格通常由很多有不同经验的员工共同开发而不仅是几位专家。

 

3.                Developing Unit Test Specifications（开发单元测试规格）

Once a unit has been designed, the next development step is to design the unit tests. An important point here is that it is more rigorous to design the tests before the code is written. If the code was written first, it would be too tempting to test the software against what it is observed to do (which is not really testing at all), rather than against what it is specified to do.

 

一旦一个单元设计完成，下一步就是设计单元测试。重要的一点是严谨的测试设计应该在代码开发之前，反之，它会使测试人员依据他们所观察到的来测试 (不是真正地测试), 而不是根据软件应该作什么。

 

A unit test specification comprises a sequence of unit test cases. Each unit test case should include four essential elements:

 

单元测试规格包括单元测试用例的顺序。各个单元测试用例应该包括以下四要素:

 

• A statement of the initial state of the unit, the starting point of the test case (this is only applicable where a unit maintains state between calls)
• The inputs to the unit, including the value of any external data read by the unit
• What the test case actually tests, in terms of the functionality of the unit and the analysis used in the design of the test case (for example, which decisions within the unit are tested)
• The expected outcome of the test case (the expected outcome of a test case should always be defined in the test specification, prior to test execution)
• 单元, 测试用例的起点的初始状态的声明
• 单元测试的输入, 包括任何需要输入的外在数据
• 测试用例要测试什么是根据单元功能并在单元测试用例设计中分析(例如, 决定在单元之内被测试)
• 测试用例的期望的结果(测试用例的期望的结果应该测试规格中定义，在测试施行之前)

 

The following subsections of this document provide a six step general process for developing a unit test specification as a set of individual unit test cases. For each step of the process, suitable test case design techniques are suggested. (Note that these are only suggestions. Individual circumstances may be better served by other test case design techniques). Section 3 of this document then describes in detail a selection of techniques, which can be used within this process to help design test cases.

 

本文档以下分部提供六步过程来开发单元测试规格作为一套各自的单元测试用例。过程中的每一步，都会给出适当的测试用例设计技术。本文档的第三节详细描述的技术可能使用在这个过程之内帮助设计测试用例。

 

3.1.           Step 1 - Make it run (步骤一、使测试用例能够运行)

The purpose of the first test case in any unit test specification should be to execute the unit under test in the simplest way possible. When the tests are actually executed, knowing that at least the first unit test will execute is a good confidence boost. If it will not execute, then it is preferable to have something as simple as possible as a starting point for debugging.

 

第一个测试用例的目的在于任一个单元测试规格应该用最简单的可能方式执行单元测试。当测试实际上被执行时，至少第一个单元测试将提供很好的信息。

 

Suitable techniques:

• Specification derived tests
• Equivalence partitioning

 

可用的技术：

• 规格导出测试
• 等价类划分法

 

3.2.           Step 2 - Positive testing

Test cases should be designed to show that the unit under test does what it is supposed to do. The test designer should walk through the relevant specifications; each test case should test one or more statements of specification. Where more than one specification is involved, it is best to make the sequence of test cases correspond to the sequence of statements in the primary specification for the unit.

 

设计单元测试应该说明单元在测试之下应该做什么。测试设计人员应阅读相关的规格；每个测试用例应该测试规格中的一个或多个声明。如果测试多个规格,最佳方法是将测试用例的顺序与单元的主要规格声明顺序保持一致。

 

Suitable techniques:

• Specification derived tests
• Equivalence partitioning
• State-transition testing

 

可用的技术

• 规格导出测试
• 等价类划分法
• 状态迁移法

3.3.           Step 3 - Negative testing

Existing test cases should be enhanced and further test cases should be designed to show that the software does not do anything that it is not specified to do. This step depends primarily upon error guessing, relying upon the experience of the test designer to anticipate problem areas.

 

现有的测试用例应该被提高并且后续的测试用例应该被设计成与软件规格相一致，软件不能具有规格中没有提到的功能。这步取决于主要错误猜测, 依靠测试设计人员的经验期望问题范围

 

Suitable techniques:

• Error guessing
• Boundary value analysis
• Internal boundary value testing
• State-transition testing

 

可用的技术

• 错误猜测法
• 边界值分析法
• 内部边界值测试
• 状态迁移法

3.4.           Step 4 - Special considerations

Where appropriate, test cases should be designed to address issues such as performance, safety requirements and security requirements.

 

如果需要, 测试用例应该被考虑其他问题譬如表现、安全需要和安全要求。

 

Particularly in the cases of safety and security, it can be convenient to give test cases special emphasis to facilitate security analysis or safety analysis and certification. Test cases already designed which address security issues or safety hazards should be identified in the unit test specification. Further test cases should then be added to the unit test specification to ensure that all security issues and safety hazards applicable to the unit will be fully addressed.

 

在需要特别考虑安全的情况下,测试用例应该将重点放在促进安全分析或安全分析和证明上。在单元测试规格的测试用例应该识别出安全问题或安全危险。更进一步的测试用例应该增加来单元测试规格保证, 所有安全问题和安全危险可适用对单元充分地将验证。

 

Suitable techniques:

• Specification derived tests

 

可用的技术

• 规格导出测试

 

3.5.           Step 5 - Coverage tests

The test coverage likely to be achieved by the designed test cases should be visualised. Further test cases can be added to the unit test specification to cover specific test objectives. Once coverage tests have been designed, the test procedure can be developed and the tests executed.

 

测试覆盖面由被设计的测试用例达到应该可能形象化。更加进一步的测试用例可能增加来单元测试规格报道具体测试宗旨。一旦覆盖面测试被设计了, 试验过程可能被开发并且测试被执行。

 

Suitable techniques:

• Branch testing
• Condition testing
• Data definition-use testing
• State-transition testing

 

可用的技术

• 分支测试
• 条件测试
• 数据定义测试
• 状态迁移测试

 

 

3.6.           Step 6 - Test execution

A test specification designed using the above five steps should in most cases provide a thorough test for a unit. At this point the test specification can be used to develop an actual test procedure, and the test procedure used to execute the tests.

 

设计测试规格使用上述五步应该为单元在许多情况下提供一个详尽的测试。这时测试规格可能使用开发一个实际试验过程和试验过程被使用执行测试。

 

Execution of the test procedure will identify errors in the unit, which can be corrected, and the unit re-tested. Dynamic analysis during execution of the test procedure will yield a measure of test coverage, indicating whether coverage objectives have been achieved. There is therefore a further coverage completion step in the process of designing test specifications.

 

执行测试过程在于发现单元中的错误，这些错误需要修订，并且对这个单元重新进行测试。在测试执行过程中动态的分析度量测试覆盖率，来说明是否达到了覆盖率目标。

3.7.           Step 7 - Coverage completion

Depending upon an organization’s standards for the specification of a unit, there may be no structural specification of processing within a unit other than the code itself. There are also likely to have been human errors made in the development of a test specification. Consequently, there may be complex decision conditions, loops and branches within the code for which coverage targets may not have been met when tests were executed. Where coverage objectives are not achieved, analysis must be conducted to determine why. Failure to achieve a coverage objective may be due to the following:

 

单元规格取决于组织的标准，可能在单元内除了代码没有结构化的规格书。有可能在开发测试规格的时候出现人为的错误。或许由于代码的条件、循环和分支等的复杂性不同导致测试执行的覆盖率目标没有达到。如果没有达到覆盖率目标，需要进行分析确定为什么没有达到覆盖率的目标，归结于以下几点：

 

• Infeasible paths or conditions - the corrective action should be to annotate the test specification to provide a detailed justification of why the path or condition is not tested.
• Unreachable or redundant code - the corrective action will probably be to delete the offending code. It is easy to make mistakes in this analysis, particularly where defensive programming techniques have been used. If there is any doubt, defensive programming should not be deleted.
• Insufficient test cases - test cases should be refined and further test cases added to a test specification to fill the gaps in test coverage.

 

• 不可行的路径或条件 – 纠正措施应该说明测试规格提供详细的为什么路径或条件无法测试的原因
• 不可达或冗余代码-纠正措施是删除有问题的代码。但是在特殊的保护编程技术被使用的情况，有可能会被误认成是冗余代码。如果在不确定的情况下，保护编程不应该被删除。
• 测试用例不足- 测试用例应该被并优化且在接下来的测试过程中增加测试用例来防止测试规格不足，以达到测试覆盖率。

 

Ideally, the coverage completion step should be conducted without looking at the actual code. However, in practice some sight of the code may be necessary in order to achieve coverage targets. It is vital that all test designers should recognize that use of the coverage completion step should be minimized. The most effective testing will come from analysis and specification, not from experimentation and over dependence upon the coverage completion step to cover for sloppy test design.

 

理想情况下，上述步骤应该在没有看到实际代码之前完成。但是，对代码的检视也是达到覆盖率目标的必要手段。重要的是，所有测试设计人员应该认为对覆盖率完成步骤的用途应该减到最小。最有效的测试来自分析和规格。而不是为了满足覆盖率而进行的盲目测试。

 

Suitable techniques:

• Branch testing
• Condition testing
• Data definition-use testing
• State-transition testing

 

可用的技术

• 分支测试
• 条件测试
• 数据定义测试
• 状态迁移测试

3.8.           General Guidance

Note that the first five steps in producing a test specification can be achieved:

 

注意前五步在导致测试规格需要做到以下几点：

 

• Solely from design documentation
• Without looking at the actual code
• Prior to developing the actual test procedure

 

• 只依据设计文档
• 不看实际代码
• 开发实际测试步骤之前

 

It is usually a good idea to avoid long sequences of test cases, which depend upon the outcome of preceding test cases. An error identified by a test case early in the sequence could cause secondary errors and reduce the amount of real testing achieved when the tests are executed.

 

通常避免那些依赖于先前测试用例结果的测试用例长的序列。序列中处于前列的测试用例所引发的缺陷会导致次要错误并减少很多测试用例被执行时真正的测试所达到的情况。

 

The process of designing test cases, including executing them as "thought experiments", often identifies bugs before the software has even been built. It is not uncommon to find more bugs when designing tests than when executing tests.

 

设计测试用例的过程包括作为执行用例当"thought experiments"，通常在软件build之前就识别出缺陷。通常在设计测试用例过程中发现的缺陷比在执行测试用例过程中发现的缺陷还要多。

 

Throughout unit test design, the primary input should be the specification documents for the unit under test. While use of actual code as an input to the test design process may be necessary in some circumstances, test designers must take care that they are not testing the code against itself. A test specification developed from the code will only prove that the code does what the code does, not that it does what it is supposed to do.

 

单元测试设计过程中，需要测试的单元的输入应该被规格化。测试设计人员必须注意, 他们不应该依据代码来测试。测试规格应该来验证，代码是否是符合需求的。

 

4.                Test Case Design Techniques

The preceding section of this document has provided a "recipe" for developing a unit test specification as a set of individual test cases. In this section a range of techniques that can be to help define test cases are described.

 

本文档前一部分提供了一个“处方”来指导开发单元测试规格作为一套测试用例。本部分则描述开发测试用例的技术。

 

Test case design techniques can be broadly split into two main categories. Black box techniques use the interface to a unit and a description of functionality, but do not need to know how the inside of a unit is built. White box techniques make use of information about how the inside of a unit works. There are also some other techniques, which do not fit into either of the above categories. Error guessing falls into this category.

 

测试用例设计技术分成两个主要类别。黑盒技术使用接口对单元和功能的描述, 不需要知道单元里面是如何建立的。白盒技术则知晓单元内部的信息。还有些其它技术, 不适合归入上述类别，例如错误推测法。