2 research outputs found

    A Non-Parametric Comparison between Advances Software Engineering Process Model

    Get PDF
    Software development process provides detailed guideline for development testing and maintenance of software products. It deals with the risks associated withsoftware development and a road map to manage its complexities. In other words, software development processes are considered as optimized solution specific to any particular software product development. There are many software process models available in literature. This research performs a non-parametric comparison between formal process model, agile process model and agent based process model to aid software community in developing quality software product

    Lenguaje de dominio específico para la generación de pruebas basadas en máquinas de estados

    Full text link
    Muchos elementos software (típicamente un objeto de una clase) pasan por estados, sin embargo, entre las pruebas más comunes y utilizadas no están las que comprueban que las transiciones entre estos estados son correctas. Este documento trata de las pruebas basadas en máquinas de estados, y aunque dicho concepto no es nuevo, no es usual realizar este tipo de pruebas. Las pruebas basadas en máquinas de estados se caracterizan por ser repetitivas, ya que las distintas rutas o caminos que se pueden realizar sobre una máquina de estados tienen un grado muy alto de solapamiento. El objetivo de este TFG es automatizar la creación de estas pruebas. Se ha desarrollado para tal objetivo un lenguaje de dominio específico, cuyo nombre es Mech, que permite definir los distintos estados de una máquina de estados así como las transiciones entre ellos. Sin embargo, no basta con definir la máquina, ya que hace falta indicar como vamos a recorrer el grafo que representa la máquina para que las pruebas sean lo más exhaustivas posible. Básicamente hay dos formas de recorrer este tipo de grafos. Una consiste en recorrer todos los nodos al menos una vez, la cual se conoce como cobertura de nodos. La otra consiste en recorrer todas las transiciones al menos una vez, la cual se conoce como cobertura de aristas. Aunque depende la topografía exacta del grafo, la cobertura de aristas suele ser más exhaustiva que la cobertura de nodos. Cada transición tiene asociado un método y una serie de comprobaciones, por lo que ejecutar una transición equivale a ejecutar el método y las comprobaciones asociadas. Cada camino obtenido con el criterio de recorrido seleccionado se traduce a un test, en el que se realizan las transiciones y comprobaciones correspondientes, en el orden en que aparecen en el camino.Many software elements (typically an object of a class) has states, however, checking if transition between states are correct isn’t amongst the most usual and used testing methodologies. This document is about state machine based testing, which is not a new concept, but not a popular one neither. State machine based testing is characterized by being repetitive, since the several paths through a state machine are very likely to overlap. This document’s objective is to make state machine based tests automatically. For that purpose, we have developed a domain specific language, whose name is Mech, that allow us to define the states and transitions of a state machine. However, defining the state machine is not enough, since we have to specify how the graph representing the state machine must be traversed, so the testing is as exhaustive as possible. Basically, there are two ways of traversing the graph. The first one is about traversing each node at least once, known as node coverage. The other one is about traversing each edge at least once, known as edge coverage. Even though it depends on the graph topology, edge coverage is usually more exhaustive than node coverage. Each transition is associated to a method and a list of asserts, so that executing a transition consists on executing a method and the associated asserts. Each path got by selected coverage criteria is translated into a test, in which methods and assert are executed in the order given by the path
    corecore