Saludos.
Para quién le interese. A continuación pongo algunos enlaces sobre documentación para generar pruebas a partir de casos de uso.
En mi página web ha puesto los reusltados de un enlace comparativo con casos prácticos:
http://www.lsi.us.es/~javierj/publications.html
(descargar "Generación de casos de prueba a partir de la especificación funcional")
En STORM es posible encontrar varias listas de herramientas de prueba. Aunque no conozco ninguna herramienta de acceso público para generar pruebas, sí
se pueden encontrar algunas herramientas muy interesante para implementar las pruebas. Se puede encontrar alguna herramienta de libre descarga para
TSL, pero está a añados luz de distancia de WinRunner.
http://www.mtsu.edu/~storm/
Algunos artículos que pueden ser interesantes. Son fáciles de encontrar en Google. Si alguien no los localiza que no dude en pedírmelos:
Axel Ruder et-al. 2004. A Model-based Approach to Improve System Testing of Interactive Applications. ISSTA’04. Boston, USA.
L. Briand, Y. Labiche. 2002. A UML-Based Approach to System Testing. Carleton University Inner Report.
Heumann , Jim, 2002. Generating Test Cases from Use Cases. Journal of Software Testing Professionals.
Nebut, C. Fleurey, et-al. 2003. Requirements by contract allow automated system testing. Procedings of the 14th International symposium of Software Reliability Engineering (ISSRE'03). Denver, Colorado. EEUU.
UCTSystem. http://www.irisa.fr/triskell/results/ISSRE03/UCTSystem/UCTSystem.html
Espero que los disfruteis.
Si alguien tiene interés en el tema y quiere más información que no dude en comunicármelo.
Programación en general y tonterías en particular.
4.4.06
22.3.06
Materiales de cursos
Saludos.
Estoy poniendo en mi página web materiales relacionados sobre algunos y seminarios que he tenido la suerte de poder impartir. Por si a alguien le interesa la dirección es:
http://www.lsi.us.es/~javierj/cursos.htm
Aún hay poco material. Espero ir subiendo más cosas a lo largo de estas semanas.
Nos leemos.
Estoy poniendo en mi página web materiales relacionados sobre algunos y seminarios que he tenido la suerte de poder impartir. Por si a alguien le interesa la dirección es:
http://www.lsi.us.es/~javierj/cursos.htm
Aún hay poco material. Espero ir subiendo más cosas a lo largo de estas semanas.
Nos leemos.
3.3.06
Trabajando con HipersonicDB
Saludos.
Existen varias bases de datos libres implementadas en Java. Una de ellas, la que uso habitualmente, es HipersonicSQL DB (http://hsqldb.org/).
¿Por qué utilizar una base de datos pequeña escrita en Java cuando existen sistemas como MySQL, PostgreSQL o Firebird?. En mi caso, la respuesta es comodidad. Puedo distribuir junto con mis programas todo el servidor de bases de datos (sólo son 200-300 KB de más) evitando que los usuarios tengan que instalar ni configurar nada. En las primeras etapas de desarrollo es una opción muy interesante, ya que podemos tener nuestra base de datos funcionando de manera autónoma sin depender de la instalación y configuración de ningún servidor.
Además, HSQLDB es bastante completa soportando vistas, integridad referencial, transacciones, consultas batch, etc. (verificar esto).
HipersonicSQL tiene varios modos de funcionamiento. Los dos principales son local y servidor. En el primer modo, el servidor se inicia y termina a la misma vez que el programa. En el segundo, hemos de iniciar y terminar el servidor a mano (como en cualquier otro sistema). La principal diferencia entre ambos es su cadena de conexión, como se muestra a continuación
Modo servidor: jdbc:hsqldb:hsql://localhost/base_de_datos
Modo local: jdbc:hsqldb:ruta_a_la_base_de_datos
A continuación pongo el código de un sencillo ejemplo que se conecta a una base de datos en modo local, realiza una consulta y muestra el resultado. Lo único necesario para que este ejemplo funcione (además de la base de datos), es tener hsqldb.jar en el CLASSPATH.
No todos son ventajas trabajando con HSQLDB. Por ejemplo, las bases de datos de la versión 1.7 no son compatibles con la versión 1.8, lo cuál es malo. Sin embargo, tampoco he encontrado la necesidad de actualizar, por lo que he seguido trabajando con el 1.7 sin problemas.
Existen varias bases de datos libres implementadas en Java. Una de ellas, la que uso habitualmente, es HipersonicSQL DB (http://hsqldb.org/).
¿Por qué utilizar una base de datos pequeña escrita en Java cuando existen sistemas como MySQL, PostgreSQL o Firebird?. En mi caso, la respuesta es comodidad. Puedo distribuir junto con mis programas todo el servidor de bases de datos (sólo son 200-300 KB de más) evitando que los usuarios tengan que instalar ni configurar nada. En las primeras etapas de desarrollo es una opción muy interesante, ya que podemos tener nuestra base de datos funcionando de manera autónoma sin depender de la instalación y configuración de ningún servidor.
Además, HSQLDB es bastante completa soportando vistas, integridad referencial, transacciones, consultas batch, etc. (verificar esto).
HipersonicSQL tiene varios modos de funcionamiento. Los dos principales son local y servidor. En el primer modo, el servidor se inicia y termina a la misma vez que el programa. En el segundo, hemos de iniciar y terminar el servidor a mano (como en cualquier otro sistema). La principal diferencia entre ambos es su cadena de conexión, como se muestra a continuación
Modo servidor: jdbc:hsqldb:hsql://localhost/base_de_datos
Modo local: jdbc:hsqldb:ruta_a_la_base_de_datos
A continuación pongo el código de un sencillo ejemplo que se conecta a una base de datos en modo local, realiza una consulta y muestra el resultado. Lo único necesario para que este ejemplo funcione (además de la base de datos), es tener hsqldb.jar en el CLASSPATH.
import java.sql.*;
public class SQLStatement {
public static void main(String args[]) {
try {
Class.forName("org.hsqldb.jdbcDriver");
} catch(java.lang.ClassNotFoundException e) {
System.err.println(e.getMessage());
}
try {
Connection con = DriverManager.getConnection("jdbc:hsqldb:./testdb/testdb",
"sa", "");
String query = "select COF_NAME from COFFEES";
Statement stmt = con.createStatement();
ResultSet rs = stmt.executeQuery(query);
ResultSetMetaData rsmd = rs.getMetaData();
int numberOfColumns = rsmd.getColumnCount();
System.out.println("Columns: "+numberOfColumns);
while (rs.next()) {
System.out.println("Fila " + rowCount + ": ");
for (int i = 1; i <= numberOfColumns; i++) {
System.out.print(" Columna " + i + ": ");
System.out.println(rs.getString(i));
}
System.out.println("");
}
stmt.execute("Shutdown");
stmt.close();
con.close();
} catch(SQLException ex) {
System.err.println(ex.getMessage());
}
}
}
No todos son ventajas trabajando con HSQLDB. Por ejemplo, las bases de datos de la versión 1.7 no son compatibles con la versión 1.8, lo cuál es malo. Sin embargo, tampoco he encontrado la necesidad de actualizar, por lo que he seguido trabajando con el 1.7 sin problemas.
6.2.06
Mutaciones y Java.
Saludos.
Una técnica de prueba de código bastante antigua (de los 70) y famosa son las mutaciones. Sin embargo, esta técnica no suele ser muy conocida. Voy a hacer un breve resumen de ella y después comentaré una herramienta para Java.
A grandes rasgos, la técnica de las mutaciones surge de la idea de que todos los fallos de un programa vienen motivados por pequeños cambios en el código, como un error al escribir un número, un operador matemático o una comprobación. Obviamente, un fallo grande es un conjunto de fallos pequeños.
La técnica de las mutaciones propone un conjunto de operadores para obtener código mutado: por ejemplo cambiar un '>' por un '<' o un '+' por un '-'. Con esto, el código mutado que se genera es erróneo (aunque no siempre, puede dar la casualidad de que siga estando bien).
¿Pero para qué sirve el código mutado?. Principalmente tiene dos usos: 1) guiar la construcción de pruebas, 2) validar un conjunto de pruebas. Comentémoslos brevemente.
En primer lugar, el código mutado nos dice qué prueba hemos de construir. Por ejemplo, si hemos cambiado un '+' por un '-', debemos construir una prueba que sea capaz de detectar ese error. A más mutaciones, más pruebas y más fiable será nuestro código.
Además, las mutaciones pueden indicarnos lo bueno que es un conjunto de pruebas ya existente. Así, generamos un conjunto de mutaciones, ejecutamos las pruebas sobre el conjunto y, según el número de mutaciones detectadas podemos tener una idea de la eficacia de las pruebas.
Como ya he comentado, esta es una técnica antigua, por lo que ya existen muchos trabajos que describen operadores "mutacionales" para obtener mutaciones de código en muchos lenguajes como Fortran, C, o Java. También existen varias herramientas, aunque, personalmente, no conozco ninguna muy famosa, ni libre, ni fácil de usar.
La última que he visto (MuJava http://www.isse.gmu.edu/faculty/ofut/mujava/) es gratuita pero no libre. El trabajo con esta herramienta se divide en dos partes: en primer lugar la herramienta es capaz de generar ella sola un conjunto de mutantes a partir de las clases y métodos originales. Después, la herramienta permite ejecutar un conjunto de pruebas sobre los mutantes y detectar los mutantes eliminados (aquellos detectados con alguna prueba). Por desgracia, las pruebas hemos de escribirlas a mano. A la hora de la verdad, la herramienta se comía la primera letra de mis clases y solo era capaz de generar un montón de NullPointerException. Lástima que no sea libre y pueda corregir el código.
Aunque las herramientas que conozco no permitan sacar todo el jugo de la técnica de mutaciones, creo que los fundamentos son muy importantes para cualquier que escriba pruebas para código. Conocer los operadores para crear mutaciones nos va a dar muchas buenas ideas sobre qué pruebas escribir para verificar que nuestro código funciona y siga funcionando en el futuro.
Una técnica de prueba de código bastante antigua (de los 70) y famosa son las mutaciones. Sin embargo, esta técnica no suele ser muy conocida. Voy a hacer un breve resumen de ella y después comentaré una herramienta para Java.
A grandes rasgos, la técnica de las mutaciones surge de la idea de que todos los fallos de un programa vienen motivados por pequeños cambios en el código, como un error al escribir un número, un operador matemático o una comprobación. Obviamente, un fallo grande es un conjunto de fallos pequeños.
La técnica de las mutaciones propone un conjunto de operadores para obtener código mutado: por ejemplo cambiar un '>' por un '<' o un '+' por un '-'. Con esto, el código mutado que se genera es erróneo (aunque no siempre, puede dar la casualidad de que siga estando bien).
¿Pero para qué sirve el código mutado?. Principalmente tiene dos usos: 1) guiar la construcción de pruebas, 2) validar un conjunto de pruebas. Comentémoslos brevemente.
En primer lugar, el código mutado nos dice qué prueba hemos de construir. Por ejemplo, si hemos cambiado un '+' por un '-', debemos construir una prueba que sea capaz de detectar ese error. A más mutaciones, más pruebas y más fiable será nuestro código.
Además, las mutaciones pueden indicarnos lo bueno que es un conjunto de pruebas ya existente. Así, generamos un conjunto de mutaciones, ejecutamos las pruebas sobre el conjunto y, según el número de mutaciones detectadas podemos tener una idea de la eficacia de las pruebas.
Como ya he comentado, esta es una técnica antigua, por lo que ya existen muchos trabajos que describen operadores "mutacionales" para obtener mutaciones de código en muchos lenguajes como Fortran, C, o Java. También existen varias herramientas, aunque, personalmente, no conozco ninguna muy famosa, ni libre, ni fácil de usar.
La última que he visto (MuJava http://www.isse.gmu.edu/faculty/ofut/mujava/) es gratuita pero no libre. El trabajo con esta herramienta se divide en dos partes: en primer lugar la herramienta es capaz de generar ella sola un conjunto de mutantes a partir de las clases y métodos originales. Después, la herramienta permite ejecutar un conjunto de pruebas sobre los mutantes y detectar los mutantes eliminados (aquellos detectados con alguna prueba). Por desgracia, las pruebas hemos de escribirlas a mano. A la hora de la verdad, la herramienta se comía la primera letra de mis clases y solo era capaz de generar un montón de NullPointerException. Lástima que no sea libre y pueda corregir el código.
Aunque las herramientas que conozco no permitan sacar todo el jugo de la técnica de mutaciones, creo que los fundamentos son muy importantes para cualquier que escriba pruebas para código. Conocer los operadores para crear mutaciones nos va a dar muchas buenas ideas sobre qué pruebas escribir para verificar que nuestro código funciona y siga funcionando en el futuro.
Subscribe to:
Posts (Atom)