Hoijin Yoon

A TEST CASE PRIORITIZATION BASED ON DEGREE OF RISK EXPOSURE AND ITS EMPIRICAL STUDY

We propose a test case prioritization strategy for risk based testing, in which the risk exposure is employed as the key criterion of evaluation. Existing approaches to risk based testing typically employ risk exposure values as assessed by the tester. In contrast, we employ exposure values that have been determined by experts during the risk assessment stage of the risk management process. If a given method produces greater accuracy in fault detection, that approach is considered more valuable for software testing. We demonstrate the value of our proposed risk based testing method in this sense through its application.

Mutation-based inter-class testing

Faults and failures due to interaction are the bane of testers. Since their subtlety makes them difficult to recognize and even more difficult to reveal by testing, it is important to specify interaction between classes systematically. In this paper, we propose mutation-based inter-class testing technique. Our inter-class testing technique consists of two procedures: test item identification procedure and test case selection procedure. For the test item identification procedure, we develop the Inheritance-Call graph (ICgraph) to identify the taxonomy of interaction of public methods between classes. For the test case selection procedure, we design a new criterion, state-based mutation testing criterion (SMTC), by applying mutation analysis to the state diagram representing class behavior. Mutation analysis is a well-known method for measuring test case adequacy which involves the mutation of a program by the introduction of small syntactic change in the program. The implementation of our proposed technique on a sample program shows that our technique leads to a set of test cases which detect errors in inter-class relation.

Effective test case selection for component customization and its application to Enterprise JavaBeans

Component users need to customize components they obtain from providers, because providers usually develop components for general use. Although the customization is accomplished by modifying the interface of a component, faults from customization appear when the implementation part of a component and the interfaces interact. The implementation part is a black‐box, whose source code is not available to a component user, while the interface is a white‐box, whose source code is available for customization. Therefore, customization faults should be tested using both the black‐box part and the white‐box part of a component.

Component customization testing technique using fault injection technique and mutation test criteria

A testing technique to detect failures caused by component customization is necessary. In this paper, we propose a component customization testing technique by using the fault injection technique and the mutation test criteria. We first define the component customization patterns by considering the syntactic and semantic characteristics of customization. Our technique aims to increase the test case effectiveness, which is the ratio of the number of the test cases, by injecting a fault only a specific part of the component interface. The specific part of the interface is chosen through a component customization pattern defined in this paper and the interaction, which is identified in this paper, between the black-box class and the white-box class of the component. Moreover, we go on to show the applicability of this technique through an example case study, which make it more concrete, using practical component architecture, the EJB.

An effective testing technique for component composition in EJBs

This paper proposes a new testing technique for component composition of EJBs. We define components made by a current developer as white box components and components made by another developer as black box components. Software from CBSD consists of black box components and white box components, and composition errors result from the interaction between black box components and white box components, or the interaction between two white box components. Our technique tests these composition errors. We select test cases by injecting a fault into a specific parts of the white box component. The specific parts we define in this paper lead to the high effectiveness of our technique. We evaluate this effectiveness through an experiment and a theorem. In addition, we provide an example in Enterprise JavaBeans.

Building test steps for SOA service orchestration in web service testing tools

Many SOA developers still stay in the tools supporting Web services. In terms of testing, they rely on some popular open source products, such as SoapUI, JUnit, and TESTMAKER, which were developed for testing Web services. The tools could work well also on SOA, if they test an orchestration of services involved in connections between Business Services and Application Services. This paper first analyzes what the connection is in SOA, and then it proposes what should be included in their test steps to test the connections according to the definition of the connection of services with supporting SOA principles. For the developers who still use the Web service testing tools, this paper contributes on providing the test step supporting the SOA connection testing, which is analyzed to be one of the most important factors for successful SOA products.

Generating Test Requirements for the Service Connections based on the Layers of SOA

This paper presents test requirements for the SOA service connections. Although some testing techniques have been developed for Web service integrations based on the first generation Web service techniques such as SOAP, WSDL, and UDDI, they lack layers supporting the abstraction, which is one of the most important principles of service-orientation. When a system is built as a SOA, each internal service should be deployed in its appropriate layer and be connected with other services across the layers. Also, a test engineer needs to define the test requirements with exact understanding of the connections between services of all the layers. Test requirements for SOA services should be generated according to the SOA connection principles. Drawing the connections in a diagram would help not to communicate the principles. This paper develops a diagram to describe the SOA service connections, from which the test requirement is also defined. Also, it applies the approach for generating test requirements to SOAs of two real companies.

The Context Driven Component Supporting the Context Adaptation and the Content Extension

The context aware applications should focus on the Context adaptation, where the context change is reflected in the application, and the Content extension, where a new content of context is added without rebuilding the whole application. This paper defines Context Driven Component, which implements behaviors required by a context. An application is developed through composing the context driven components. It supports the context adaptation through replacing components or the content extension through adding components implementing behaviors relevant to the extended contents. The development using the context driven components will be analyzed in the following respects; the scale of context, the vertical decomposition compared to the existing way, and the implementation in Ubicomp.

A COM-Based Customization Testing Technique

Component users must customize components they obtain from providers, because providers usually develop components either for general use, or for some other specific purpose. Although the customization is accomplished by modifying the interface of a component, faults caused by customization appear when the implementation part of a component and the interfaces interact. In this paper, we select test cases by inserting faults not into the entire interface but only into specific parts of the interface, which are referred directly by the implementation. They are selected by analyzing the interaction between the interface and the implementation parts. Based on this testing approach, this paper develops a testing technique for a customized COM component. It is applied to a practical component-based system, Chamois. Through an empirical study in this paper, it is shown that the specific parts for injecting a fault brings the test cases’ effectiveness, which is evaluated.