測試用例設計方法：因果法（上）

　　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.anti-gravitydesign.com