Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

A method for using test level indicators in server software to increase software quality and reduce maintenance overhead in client / server environments

IP.com Disclosure Number: IPCOM000179845D
Original Publication Date: 2009-Feb-27
Included in the Prior Art Database: 2009-Feb-27
Document File: 2 page(s) / 24K

Publishing Venue

IBM

Abstract

We propose a scheme for exploiting the knowledge about provided testing levels for service components. This scheme empowers (a) client developers to assess which design solutions to employ (if several alternatives exist) by considering solutions with higher test level indications and (b) service code developers to receive early (e.g. automatic) warnings about client developers using service code with lower test levels, such that they can increase testing levels for the concerned service code elements. The approach is based on the concept of test level indicators which are associated and/or can be computed for parts of the service code.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 1 of 2

A method for using test level indicators in server software to increase software quality and reduce maintenance overhead in client / server environments

An increasing set of applications is being enabled using the client/service paradigm: a service offers an interface for specific functions and one or more clients exploit service functions according to a logic implemented in the respective client. Service development and client development is frequently performed by disjoint parties, i.e. exploiters of a service are in charge of developing clients according to their needs. Portal and business process management middleware software are examples for such setups.

With increasing service code complexity, covering all possible usage patterns of the code implies substantial overhead for test definition and setup. Due to the complexity implied by exhaustive testing, practical solutions to testing provide only combinatorial incomplete test coverage of service code and its usage patterns. As a side effect, parts of the service code may be tested more intensively than others.

Currently, client development occurs without considering the testing level which has been applied to service code. Inferior reliability of the client software is the result, as less tested code may be employed by the client software. A long troubleshooting cycle is often implied: an unexpected behaviour is reported to the service provider. The latter triggers a debugging sequence, tracks down the issue and sends out a fix to the customer.

In this paper, we propose a scheme for exploiting the knowledge about provided testing levels for service code. This scheme empowers (a) client developers to assess which design solutions to employ (if several alternatives exist) by considering solutions with higher test level indications and (b) service code developers to receive early (e.g. automatic) warnings about client developers using service code with lower test levels, such that they can increase testing levels for the concerned service code elements.

We describe the usage of test level indicators (TLIs) based on three variable types: service element TLIs, invocation path TLIs resp. averaged path TLIs for functions exposed at the service interface.

Element TLIs: any element of the service code can be associated with a test level indicator (TLI) to indicate the degree to which that element was subject to testing. The abstraction level of these elements can vary: a TLI can be defined on the level of a subsystem, class, class method, class method with specific invocation value (ranges), etc. Also, it may be defined based on (some part of ) the invocation path leading to the service element indication. For instance, a distinct TLI could be defined for an element A depending which other element invoked it: e.g. TLI(BA) when element A was invoked by element B, TLI(CA) when element AB was invoked by element C.

PathTLIs: Client developers expl...