QUE ES EL PPT COMUNIDAD ONLINE

...

Verificación: ¿Hicimos bien el software?

Si bien parecen similares, la validación corresponde al rol, las expectativas, la corrección y la utilidad que la solución presenta. Mientras que verificación se refiere a la forma en que esta solución se construyó , el cual deberá responder a la altura de las expectativas.

Por consiguiente, validamos cuando comprobamos que estamos realizando el software correcto, verificamos cuando comprobamos que estamos realizando un buen software.

Para ambos casos (validar y verificar), existen técnicas de testing que nos permitirá encontrar fallas/defectos/errores en la solución.

Testing

Se entiende por testing al proceso por el cual se pretenden encontrar defectos en el software mediante diversas técnicas acordes a la naturaleza de la solución. Una premisa del testing es que “permite encontrar defectos, más no la ausencia de estos”.

Para precisar qué es el “defecto” que se busca en el testing, podemos definir con más precisión los conceptos atribuibles a estas situaciones:

- Excepción: Situación no esperada. Que se sale de la regla común.

- Error: es la manifestación de una excepción durante el tiempo de ejecución de la aplicación, son excepciones producto de una decisión equivocada.

- Falla: Es una propiedad de un sistema software que puede causar que el sistema se aparte del comportamiento previsto.

- Defecto: Es un error que manifiesta una falta del cumplimiento de una especificación.

En el lenguaje común, estos cuatro conceptos son intercambiables. Sin embargo, conviene tener presente sus definiciones, para utilizar un lenguaje más preciso cuando sea necesario.

Testing de verificación

Se separan en dos tipos:

- Dinámicas.

- Estáticas.

Pruebas dinámicas

Las pruebas dinámicas se realizan sobre la marcha del sistema (etapa de interpretación, compilación o ejecución).

A su vez se distinguen tres tipos de pruebas dinámicas:

- Funcionales.

- Estructurales.

- Aleatorias

Prueba funcional: Se realiza en base a la observación de los resultados arrojados por las funciones, métodos o componentes del sistema, en base a las entradas. Por lo tanto solo nos basamos en lo que supuestamente debería realizar cierto componente, sin interesarnos como lo realiza.

Se basa en el estudio de caja negra.

Prueba estructural: Se realiza en base a la intervención del software, dado que se cuenta con total conocimiento de su implementación (código fuente o documentación de sus componentes)

Se basa en el estudio de caja blanca.

Prueba aleatoria: Contempla una serie de pruebas funcionales/estructurales autónomas que se aplicarán al software de manera arbitraria. Es ideal en sistemas con muchas entradas o intervenciones (complejos, críticos, tiempo real).

uebas Estáticas

Las pruebas estáticas son aquellas que se realizan en base a la etapa no operacional del software (diseño, desarrollo), siendo clasificada en dos sub-pruebas:

- Técnicas de consistencia.

- Técnicas de medición.

Técnicas de consistencia: Son aquellas que intervienen con la integridad de la lógica, semántica o sintaxis del código fuente. Por tanto es común que para este tipos de prueba el desarrollador se apoye en procesos autónomos que comprueban las integridades.

Técnicas de medición: Son aquellas que que se realizan en base a mediciones de ciertos factores, como es la propensión de errores, la legibilidad (auto-documentación), la estructura (objetos sin uso, interfaces no implementadas, etc.)

Técnicas de validación

Método formal: Estos métodos permiten describir el software mediante el uso de técnicas matemáticas o lógicas. Generalmente se utiliza algún tipo de lenguaje formal (basado en patrones) para la descripción de lo que debería realizar el sistema. Su uso (dado el trabajo y costo que implica) es en el software cuyo cumplimiento de sus requerimientos es crítico.

Inyección de faltas: Permite probar el sistema software mediante la inclusión forzada de faltas al sistema (eliminación de archivos, configuraciones, desconexión de base de datos), esto para observar el comportamiento del sistema frente a posibles faltas. Estas pueden involucrar tanto software como hardware.

---------------------------------------------------------------

Prueba de Programas

Introducción

Una de las últimas fases del ciclo de vida antes de entregar un programa para su explotación, es la fase de pruebas.

Una de las sorpresas con las que suelen encontrar los nuevos programadores es la enorme cantidad de tiempo y esfuerzo que requiere esta fase. Se estima que la mitad del esfuerzo de desarrollo de un programa (tanto en tiempo como en gastos) se va en esta fase. Si hablamos de programas que involucran vidas humanas (medicina, equipos nucleares, etc) el costo de la fase de pruebas puede fácilmente superar el 80%.

Pese a su enorme impacto en el coste de desarrollo, es una fase que muchos programadores aún consideran clasificable como un arte y, por tanto, como difícilmente conceptualizable. Es muy difícil entrenar a los nuevos programadores, que aprenderán mucho más de su experiencia que de lo que les cuenten en los cursos de programación.

¿Qué es probar?

Como parte que es de un proceso industrial, la fase de pruebas añade valor al producto que se maneja: todos los programas tienen errores y la fase de pruebas los descubre; ese es el valor que añade. El objetivo específico de la fase de pruebas es encontrar cuantos más errores, mejor.

Es frecuente encontrarse con el error de afirmar que el objetivo