La metodologÃÂa de Pruebas Orientada a Objetos para
el Ciclo de Vida Completo(en ingles "Full Life-Cycle Object-Oriented
Testing", FLOOT) es una colección de tÃcnicas para verificar y
validar software orientado a objetos. El ciclo de vida FLOOT, que se
puede ver en la Figura 1 , indica una amplia
variedad de tÃcnicas (descritas en la Tabla 1
) que estan disponibles en todos los aspectos del desarrollo de
software. La lista de tÃcnicas no pretende ser completa - por el
contrario su objetivo es hacer explÃÂcito el hecho de que usted
cuenta con un amplio rango de opciones disponibles .
Es importante entender que aunque el metódo FLOOT es presentado como
una colección de fases secuenciales no necesariamente tiene que ser
asÃÂ: las tÃcnicas de FLOOT pueden ser aplicadas tambiÃn con procesos
agiles/evolutivos. La razón por la que presento FLOOT de una forma
"traditional" es para volver explicito el hecho de que en realidad
usted puede realizar pruebas en todos los aspectos del desarrollo de
software no solamente durante la codificación.
TÃcnica
FLOOT |
Descripción |
Prueba de Caja-Negra |
La prueba verifica que el ÃÂtem que se esta
probando, cuando se dan las entradas apropiadas produce los
resultados esperados. |
Prueba de Valores-Frontera |
Es la prueba de situaciones extremas o inusuales
que el ÃÂtem debe ser capaz de manejar. |
Prueba de Clases |
Es el acto de asegurar que una clase y todas sus
instancias cumplen con el comportamiento definido . |
Prueba de Integración de Clases |
Es el acto de asegurar que las clases, y sus
instancias, conforman un software que cumple con el
comportamiento definido. |
Revisión de Código |
Una forma de revisión tÃcnica en la que el
entregable que se revisa en el código fuente. |
Prueba de Componente |
Es el acto de validar que un componente funciona
tal como esta definido. |
Prueba de Cubrimiento |
Es
el acto de asegurar que toda lÃÂnea de código es ejercita al
menos una vez. |
Revisión de Diseño |
Una revisión tÃcnica en la cual se inspecciona un
modelo de diseño. |
Prueba de Regresión de Herencia |
Es el acto de ejecutar casos de prueba de las
súper clases, tanto de forma directa como indirecta, en una
subclase especifica. |
Prueba de Integración |
Consiste en realizar pruebas para verificar que
un gran conjunto de partes del software funcionan juntas. |
Prueba de MÃtodo |
Consiste en realizar pruebas para verificar que un mÃtodo (función
miembro) funciona tal como esta definido. |
Revisión de Modelos |
Un tipo de inspección, que puede ser desde un
revisión tÃcnica formal hasta un recorrido informal , realizado
por personas diferentes a las que estuvieron directamente
involucradas en el desarrollo del modelo. |
Prueba de Caminos |
Es el acto de asegurar que todos los caminos
lógicos en el código se ejercitan al menos una vez. |
Revisión de Prototipos |
Es un proceso mediante el cual los usuarios
trabajan a travÃs de una colección de casos de uso, utilizando
un prototipo como si fuera el sistema real. El objetivo
principal es probar si el diseño del prototipo satisface las
necesidades de esos usuarios. |
Demostrar con el código |
La mejor forma de determinar si un modelo
realmente refleja lo que se necesita, o lo que se debe construir,
es construyendo software basado en el modelo para mostrar que el
modelo esta bien |
Prueba de Regresión |
El acto de asegurar que los comportamientos
previamente probados todavÃÂa trabajan como se espera luego que
se han realizado cambios a la aplicación. |
Prueba de Stress |
El acto de asegurar que el sistema funciona como
se espera bajo grandes volúmenes de transacciones, usuarios,
carga y demás. |
Revisión TÃcnica |
Una tÃcnica de aseguramiento de la calidad en la
cual el diseño de tu aplicación es revisado de forma exhaustiva
por un grupo de tus compañeros. Una revisión tÃÂpicamente se
enfoca en la precisión, calidad, facilidad de uso y completitud.
A este proceso usualmente se le llama recorrido, inspección, o
revisión de compañeros. |
Prueba de Escenarios de Uso |
Una tÃcnica de prueba en la cual una o mas
personas validan un modelo siguiendo la lógica de los escenarios
de uso. |
Prueba de Interfaz de Usuario |
Consiste en probar la interfaz de usuario para
garantizar que cumple los estándares y requerimientos definidos.
Usualmente se refiere a la prueba de interfaz de usuario gráfica. |
Prueba de Caja-Blanca |
Consiste en realizar pruebas para verificar que
lÃÂneas especificas de código funcionan tal como esta definido.
TambiÃn se le conoce como prueba de caja-transparente. |
Quisiera compartir algunas de
mis filosofÃÂas personales con respecto a las pruebas: