Gpi - Prueba y Testeo

UNIDAD 8. PRUEBA O TESTEO.
En esta etapa el sistemas utilizado en forma experimental para asegurar

que el software no falle, es decir, que trabaje de acuerdo a las especificaciones y
de la manera en la que los usuarios esperan que lo haga. En la prueba del sistema
se examinan los datos de entrada de procesamiento y los resultados para localizar
algunos problemas inesperados. Es preferible detectar cualquier falla o anomala
antes de que la empresa ponga en marcha el nuevo sistema. La prueba debe ser
realizada por personas diferentes a aquellas que desarrollaron el sistema
(programadores), ya que de esta manera se asegura una mayor y ms completa
prueba, ya que es imparcial, lo que origina un software ms confiable y de ms
calidad.
La prueba, como su nombre lo indica, involucra ejercitar el sistema para
asegurar que produzca las salidas apropiadas y exhiba el comportamiento
adecuado para una gama amplia de entradas.
Pruebas son un factor crtico para determinar la calidad del software,
entonces el objetivo de una prueba es descubrir algn error. Un caso de prueba es
bueno cuando su ejecucin conlleva una probabilidad elevada de encontrar un
error. El xito de la prueba se mide en funcin de la capacidad de detectar un error
que estaba oculto.
El diseo de casos de prueba para la verificacin del software puede
significar un esfuerzo considerable (cerca del 40% del tiempo total de desarrollo).
Cuando se construye software a medida para un cliente, se lleva a cabo
una serie de pruebas de aceptacin para permitir que el cliente valide todos los
requisitos. La mayora de los desarrolladores de productos de software llevan a
cabo un proceso denominado pruebas alfa y beta para descubrir errores que
parezca que slo el usuario final puede descubrir.
1. Prueba Alfa.
Se lleva a cabo, por un cliente, en el lugar de desarrollo. Se usa el software
de forma natural con el desarrollador como observador del usuario y registrando
los errores y problemas de uso. Las pruebas alfa se llevan a cabo en un entorno
controlado.
En esta etapa se empieza a buscar fallos siguiendo algn criterio para que
"no se escape nada". Los criterios ms habituales son los denominados de caja
negra y de caja blanca. Combinar ambos enfoques permite lograr mayor fiabilidad.
a) Pruebas de caja blanca
La prueba de la caja blanca (pruebas de estructura o caja transparente) usa
la estructura de control del diseo procedural para derivar los casos de prueba. La
idea es confeccionar casos de prueba que garanticen que se verifican todos los
caminos llamados independientes.
Verificaciones para cada camino independiente:
Probar sus dos facetas desde el punto de vista lgico, es decir, verdadera y
falsa.
Ejecutar todos los bucles en sus lmites operacionales
Ejercitar las estructuras internas de datos.
Consideraciones:
Los errores lgicos y las suposiciones incorrectas son inversamente
proporcionales a la probabilidad de que se ejecute un camino del programa.
A menudo creemos que un camino lgico tiene pocas posibilidades de
ejecutarse cuando, de hecho, se puede ejecutar de forma regular.
Los errores tipogrficos son aleatorios.
Tal como apunt Beizer, "los errores se esconden en los rincones y se
aglomeran en los lmites".
b) Pruebas de caja negra
Los mtodos de la caja negra (pruebas de caja opaca, funcionales, de
entrada/salida o inducidas por los datos) se enfocan los requisitos funcionales del
software. La prueba de la caja negra intenta encontrar errores de los siguientes
tipos:
Funciones incorrectas o inexistentes.
Errores relativos a las interfaces.
Errores en estructuras de datos o en accesos a bases de datos externas.
Errores debido al rendimiento.
Errores de inicializacin o terminacin.
Tipos de Pruebas de Caja Negra.
i. Particin Equivalente
La particin equivalente es un mtodo que divide el campo de entrada de
un programa en clases de datos a partir de los cuales se pueden derivar casos de
prueba. La particin equivalente se enfoca pues a definir casos de prueba para
descubrir clases de errores. Se define una condicin de entrada (valor numrico
especfico, rango de valores, conjunto de valores relacionados o condicin lgica).
Las clases de equivalencia se pueden definir de acuerdo a las siguientes
directrices:
Si una condicin de entrada especifica un rango, se define una clase de
equivalencia vlida y dos no vlidas.
Si la condicin de entrada es un valor especfico, se define una clase de
equivalencia vlida y dos no vlidas.
Si la condicin de entrada especifica un miembro de un conjunto, se define
una clase de equivalencia vlida y otra no vlida.
Si la condicin de entrada es lgica, se define una clase vlida y otra no
vlida.
ii. Anlisis de Valores Lmite
La tcnica de Anlisis de Valores Lmites selecciona casos de prueba que
ejerciten los valores lmite dada la tendencia de la aglomeracin de errores en los
extremos. Complementa la de la particin equivalente. En lugar de realizar la
prueba con cualquier elemento de la particin equivalente, se escogen los valores
en los bordes de la clase. Se derivan tanto casos de prueba a partir de las
condiciones de entrada como con las de salida.
Directrices:
Si una condicin de entrada especifica un rango delimitado por los valores a
y b, se deben disear casos de prueba para los valores a y b y para los
valores justo por debajo y justo por encima de ambos.
Si la condicin de entrada especifica un nmero de valores, se deben
desarrollar casos de prueba que ejerciten los valores mximo y mnimo
adems de los valores justo encima y debajo de aqullos.
Aplicar las directrices anteriores a las condiciones de salida. Componer
casos de prueba que produzcan salidas en sus valores mximo y mnimo.
Si las estructuras de datos definidas internamente tienen lmites prefijados
(por ej., un array de 10 entradas), se debe asegurar disear un caso de
prueba que ejercite la estructura de datos en sus lmites.
2. Prueba Beta.
Se llevan a cabo por los usuarios finales del software en los lugares de
trabajo de los clientes. A diferencia de la prueba alfa, el desarrollador no est
presente normalmente. As, la prueba beta es una aplicacin en vivo del software
en un entorno que no puede ser controlado por el desarrollador. El cliente registra
todos los problemas que encuentra durante la prueba beta e informa a intervalos
regulares al desarrollador.
Conclusiones
La aplicacin de casos de pruebas apropiados es esencial para la
validacin y verificacin del sistema construido.
Las pruebas normalmente deberan ocupar cerca del 40% del tiempo total
de desarrollo de una aplicacin. An as, no puede asegurarse un 100% de
fiabilidad para el sistema.
En sistemas donde la fiabilidad y correccin del software es un aspecto
crtico las pruebas deben ser ms exhaustivas. En estos casos pueden
aplicarse tambin pruebas de comparacin.
Las herramientas que reducen los tiempos de prueba son muy valiosas. Se
pueden distinguir varias categoras de herramientas de prueba:
analizadores estticos, auditores de cdigo, generadores de archivos de
prueba, generadores de datos de prueba y controladores de prueba.

Gpi - Prueba y Testeo

Cargado por

Copyright:

Formatos disponibles

Gpi - Prueba y Testeo

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Gpi - Prueba y Testeo

Cargado por

Copyright:

Formatos disponibles

UNIDAD 8. PRUEBA O TESTEO.

En esta etapa el sistemas utilizado en forma experimental para asegurar

También podría gustarte