测试用例设计方法：因果法（上）

　　ABSTRACT - In order to perform full coverage on sub system testing, Cause and Effect (CE) Technique is being used to design test cases. In this technique, the functional specifications are transformed into cause and effect matrices. The matrix contains a row for each cause (inputs stimulus) and effect (output response). Each column of the matrix containing 0’s, 1’s and blanks specifies a test case which is a combination of the causes and effects. The CE technique is highly recommended as it traces the requirements to the test cases in a matrix form. This technique is suitable for black box testing, and as far as coverage is concerned, this technique will guarantee more than 80% coverage.

　　摘要：

　　为了使子系统测试能够完全被覆盖，可以使用因果法(Cause and Effect，CE)来设计测试用例。这种方法将功能说明书转换为因果矩阵。该矩阵中，每一行由原因(输入激励)和结果(输出应答)组成，而每一列则是由一些0、1或者空位组成，它们对应着由一系列原因和结果组合而来的测试用例。因果法之所以受到推崇，其原因是它以一种矩阵的形式跟踪着测试用例的需求。该方法十分适合于黑盒测试，并且在测试覆盖方面，它能保证80%以上的覆盖率。

　　1. Introduction

　　1. 简介

　　Software testing is part of software development process. The ultimate aim of the system testing on a deliverable product, is to achieve Motorola’s fundamental goals of six sigma quality, total customer satisfaction and 5NINES availability. One of the questions that has always been in the mind of software system test engineer is that whether he/she has thoroughly tested the software. One of the main factors that determine the coverage of system is the technique used in designing test cases.

　　软件测试是软件开发工程的重要组成部分。对可交付产品的系统测试的最终目标就是要达到摩托罗拉公司(Motorola)提出的基本质量目标：6σ质量品质、完全顾客满意度以及5NINES有效性。在软件系统测试工程师心里总是存在着一个疑问，即他/她到底能否彻底地对软件进行测试。而决定系统的测试覆盖率的主要因素之一就是设计测试用例时所使用的方法。

　　Even though there are numerous test case design techniques available in current software development world, the most important ingredients of any test design are experience and common sense. Test designers should not let any of the given techniques obstruct the application of experience and common sense. The design of the test cases has to be driven by the specification of the software.

　　尽管现在的软件开发中正使用着众多的测试用例设计方法，然而最重要的测试用例设计因素却是经验和常识。测试用例设计不应该让任何给定的方法阻碍经验和常识的应用。因此，必须由软件说明书来驱动测试用例的开发。

　　Traditionally , test cases are derived by studying the requirements. Most system testers approach this derivation based on their intuition and experiences. They normally do not follow any systematic process to derive test cases. These tests do not guarantee substantial coverage of requirements. At Singapore Software Centre (SSC), we used the Cause-Effect (CE) Technique to derive our test cases for sub-system testing of Network Management Agent software for Cellular Networks.

　　传统上，测试用例生成于对需求的研究。大部分的系统测试者是基于他们的直觉和经验实践着这种做法。他们通常不会遵循任何条条框框来生成测试用例。这种测试无法确保对需求的完全覆盖。而在新加坡软件中心(Singapore Software Centre,，SSC)，我们使用因果法为蜂窝网络的网络管理代理软件的子系统生成测试用例。

　　This paper outlines the use of CE approach in test case design in order to achieve the required levels of coverage. The bottom line of this effort is to be able to investigate the most likely and costly types of defects on a risk priority basis so as to increase our confidence in system readiness for use. This test case design technique has been practiced in one of the on-going projects, called OMC-R Agent Release8.1, in SSC. The OMC-R Agent team has many new features added in each release and this technique has been applied to a case-study on one of the features (Feature 1171: GSD and Status Display) in the OMC-R Agent R8.1.

　　本文论述了为到达所需的覆盖率而在测试用例设计中使用因果法的过程。其实，本次工作是为了研究基于风险优先级的情况下，可能性最大且成本最大的缺陷类型，进而增加我们对系统准备工作的信心。因果法已经在新加坡软件中心的一个正在进行的项目中得到应用，该项目名称是OMC-R Agent 发行版本号8.1。OMC-R Agent的团队在每个新的版本中都加入了很多新的内容，而因果法则是应用在OMC-R Agent R8.1其中一个新特性(特性1171: GSD及状态显示)的用例研究中。

　　2. OMC-R Agent Sub-System Testing

　　2. OMC-R Agent子系统测试

　　2.1 Software Life Cycle

　　2.1 软件生命周期

　　The life-cycle for software development includes requirements gathering, requirements analysis, high/low level design, coding, unit testing, integration testing and sub-system testing (SST). Figure 1 shows the V-shaped software life-cycle which is used in the OMC-R Agent development work in SSC. After the component testing (Unit testing) and Integration testing the code is handed over for the sub-system testing.

　　软件开发的生命周期包括需求搜集、需求分析、高/低端设计、编码、单元测试、集成测试以及子系统测试(sub-system testing ，SST)。图1显示了在SSC的OMC-R Agent开发工作中使用的V形软件开发模型。在组件测试(单元测试)和集成测试之后，代码便移交给子系统测试。

　　图1：V形软件开发模型

　　Our SST phase consists of a number of stages which progressively elaborates the design of tests from initial high level strategy to detailed test procedures. The stages involved in system testing done at SSC are test strategy, test planning, test case design and developing new test procedures. The SST performed on the OMC-R Agent products has always been a Black-box testing to make sure the software product meets the requirements. Full regression testing are performed whenever changes are made

　　子系统测试阶段划分为一些更小的阶段。它们把测试设计逐步细化，使其从最初的高端测试策略演变成详细的测试程序。这些子系统测试涉及到的更小的阶段分别是测试策略、测试计划、测试用例设计以及开发新的测试程序。为OMC-R Agent的产品进行的子系统测试通常是黑盒测试，以此来保证软件产品符合软件需求。而不论何时，只要有变化产生，都要进行回归测试。

　　Black-box test design treats the system as a "black-box", so it doesn’t explicitly use knowledge of the internal structure. The black box is not an alternative to white box testing which is usually performed early in the software development process (unit testing). Black-box test design is usually focused on testing with sets of inputs that will fully exercise all the functional requirements of a system.

　　黑盒测试把系统视为一个“黑盒子”，因此它就不会接触到内部结构。这个黑盒不能替代早期在软件开发过程的单元测试中经常使用的白盒测试。黑盒测试的设计往往集中用一组能完全启动系统功能的输入来测试。

　　2.2 Network Management Overview

　　2.2 网络管理概述

　　In a cellular network, a managing system such as Universal Network Operations (UNO) manager, provides a single platform for centralized monitoring and control of devices. The ITU (X.730/X.740) defines the standard management function such as configuration management, fault management, security management, aclearcase/" target="_blank" >ccounting management, and performance management.

　　在蜂窝网络中，像通用网络系统(Universal Network Operations，UNO)管理者这样的管理系统为设备的集中监控提供了一个简单的CC%A8" target=_blank>平台。国际电信联盟(International Telecommunications Union，ITU)X.730/X.740定义了例如配置管理、错误管理、安全管理、计费管理以及性能管理这样的标准管理功能。

　　Figure 2 shows the relationship between managing processes and managed processes. The managing system communicates with it’s managed objects to carry out the appropriate operation through CMIP agent. The CMIP protocol is an open standard interface that will allow applications to access managed objects in a common way. CMIP agent on OMC-R platform provides some functions namely:

　　图2显示了管理过程与被管理过程之间的关系。管理系统与它管理着的对象进行交互，并通过CMIP代理执行适当的操作。CMIP协议是一个开放标准，它允许各种应用软件以一种公共的方式来访问被管理对象。OMC-R 平台的CMIP代理提供了如下一些功能：

　　1. Notifications - events report, object creation/ object deletion, attributes value change, state change.

　　1. 通知—事件报告、对象创建/销毁、属性值变更、状态变更

　　2. Management Operation- m_set, m_create, m_delete, M-action (enable or disable all the devices).

　　2. 管理操作—m_set, m_create, m_delete, M-action(所有设备可用或不可用)

　　图2 网络管理系统

　　2.3 Test Environment/Test Bed

　　2.3 测试环境/测试床

　　Test software/simulators are required to execute the test cases. The two test simulators used are as shown in Figure . CTM is tool that will simulate a network manager which sends and receives messages to and from the CMIP Agent process on the OMC. And HARN is a tool to simulate the events from devices such as alarms, notifications and command responses. Perl scripts are written for automation during SST, automation is done in order to achieve Cycle Time Reduction.

　　测试软件/模拟器都会执行一些测试用例。图3中显示了两个测试模拟器，CTM是一个模拟网络管理者的模拟器，它与OMC的CMIP代理程序相互发送信息。HARN模拟器则模拟了从设备发送来的事件，例如警报、通知、命令响应等。在子系统测试中，为使测试自动化我们编写了Perl代码，以到达周期时间缩短的目的。

　　图3 测试环境

原文转自：http://www.ltesting.net