14 ago 2010

PRUEBAS DE SOFTWARE-FUNDAMENTOS Y OBJETIVOS.

Estas pruebas deben concentrarse en:
1. Probar si el software no hace lo que debe hacer.
2. Probar si al realizar estos errores, provoca efectos secundarios.
De acuerdo a Glen Myles, hay que señalar de un proceso que:

1. Una prueba sólo es exitosa si se descubre un defecto que pueda originar un error en el futuro, sin haber sido descubierto antes.

2. Una prueba es un proceso para detectar errores en este caso, en el software.
Lo cual trae como objetivos principales:
1. Encontrar el error o falla y corregirlo a tiempo con el menor esfuerzo y tiempo empleados posibles.
2.Reconocer que en todo procedimiento habrá algún error que puede ser corregido, garantizando satisfacción al cliente.
DEFINICIONES:

-PRUEBA: Es una actividad que se debe hacer para la confirmación de funcionalidad de un sistema con sus condiciones específicas.
-CASOS DE PRUEBA: Condiciones dadas para un objetivo particular.
-EQUIVOCACIÓN: Acción humana que da como resultado un error.
-ERROR: Diferencia entre lo yá acordado en planes y los resultados disparejos.
-FALLO: Incapacidad de un sistema para realizar la tarea designada.
-DEFECTO: Distorsión de lo que quería el cliente, fase incorrecta cometido por la computadora.
-DEPURACIÓN: Proceso por el cual se detecta defectos del software.
-VERIFICACIÓN: Evaluación ejecutada para comprobar la aseguración correcta de las funciones del software.
-VALIDACIÓN: Paso final de la prueba del software, ya que aquí se consta de la funcionalidad de éste.

 
ASOCIADOS EN LAS PRUEBAS DE SOFTWARE:
De acuerdo con William Perry los grupos asociados al proceso de prueba son:

• Cliente del software (Software customer): grupo u organización que realiza la contratación para el software que va a ser desarrollado.
• Usuario del software (Software user): individuo o grupo que usará el software una vez este puesto en funcionamiento.
• Desarrollador de software (Software developer): individuo o grupo que aprueba o asiste la redacción de los requerimientos, el diseño del software, la construcción del software, la gestión de cambios y el mantenimiento del software según lo solicitado.
• Probador de software (Software tester): individuo o grupo que realiza las funciones de verificación en el software. (Éste puede ser un subgrupo de desarrolladores, un grupo independiente ó la combinación de los dos.)
• Gerencia en informática (Information technology management): individuo o grupo con la responsabilidad de cumplir con la misión informática. (Las pruebas ayudan a cumplir esta misión.)
• Alta gerencia de la organización (Senior organization management): director general de la organización y otros altos ejecutivos quienes tienen la responsabilidad de cumplir con la misión de la organización. (La informática es una actividad que ayuda a cumplir esta misión.)
• Auditor (Auditor): Uno o más individuos que tienen la responsabilidad de evaluar la efectividad, eficiencia, y eficacia de los controles en el área de la informática. Las pruebas son consideradas un control por la función de auditoría.
 
Características de una buena prueba
De acuerdo con lo citado en , Kaner, Falk y Nguyen sugieren algunas de las características que debe tener una «buena prueba»:

• Una buena prueba tiene un alta probabilidad de encontrar un error. El ingeniero de software debe tener un alto nivel de entendimiento del software a construir para poder diseñar buenos casos de prueba que encuentren el mayor número de defectos.
• Una buena prueba no debe ser redundante. Uno de los objetivos de las pruebas es «encontrar el mayor número de errores con la menor cantidad de tiempo y esfuerzo posibles», por lo cual no se deben diseñar casos de prueba que tengan el mismo propósito que otros sino que se debe buscar diseñar el menor número de casos de prueba que permitan probar adecuadamente el software y que permitan optimizar los recursos.
• Una buena prueba debería ser la mejor de la cosecha. La limitación en tiempo y recursos puede impedir que se ejecuten todos los casos de prueba de un grupo de pruebas similares por lo cual en estos casos se debería seleccionar la prueba que tenga la mayor probabilidad de descubrir errores.
 
Una buena prueba no debería ser ni demasiado sencilla ni demasiado compleja.

13 ago 2010

PROCESOS DE PRUEBA DE SOFTWARE




PROCESOS DE PRUEBA DE SOFTWARE


Se define como Proceso al conjunto ordenado de pasos a seguir para llegar a la solución de un problema u obtención de un producto, en este caso particular, para lograr la obtención de un producto software que resuelva un problema.

El proceso de creación de software puede llegar a ser muy complejo, dependiendo de su porte, características y criticidad del mismo. Por ejemplo la creación de un sistema operativo es una tarea que requiere proyecto, gestión, numerosos recursos y todo un equipo disciplinado de trabajo. En el otro extremo, si se trata de un sencillo programa (por ejemplo, la resolución de una ecuación de segundo orden), éste puede ser realizado por un solo programador (incluso aficionado) fácilmente. Es así que normalmente se dividen en tres categorías según su tamaño líneas de código o costo: de Pequeño, Mediano y Gran porte. Existen varias metodologías para estimarlo, una de las más populares es el sistema como que provee métodos y un software (programa) que calcula y provee una estimación de todos los costos de producción en un "proyecto software" (relación horas/hombre, costo monetario, cantidad de líneas fuente de acuerdo a lenguaje usado, etc.).

Considerando los de gran porte, es necesario realizar tantas y tan complejas tareas, tantas técnicas, de gerenciamiento, fuerte gestión y análisis diversos (entre otras) que toda una ingeniería hace falta para su estudio y realización: es la ingeniería de software
En tanto que en los de mediano porte, pequeños equipos de trabajo (incluso un avezado analista programador solitario) pueden realizar la tarea. Aunque, siempre en casos de mediano y gran porte (y a veces también en algunos de pequeño porte, según su complejidad), se deben seguir ciertas etapas que son necesarias para la construcción del software. Tales etapas, si bien deben existir, son flexibles en su forma de aplicación, de acuerdo a la metodología o proceso de desarrollo escogido y utilizado por el equipo de desarrollo o por el analista-programador solitario (si fuere el caso).


DISEÑO DE CASOS DE PRUEBAS

El diseño de casos de prueba se puede realizar basándose en los enfoques y en sus técnicas y las estrategias de prueba.
Objetivo:Conseguir confianza aceptable en que se encontraran todos defectos existentes, sin consumir una cantidad excesiva de recursos.
"diseñar las pruebas que tengan la mayor probabilidad de encontrar el mayor numero de errores con la mínima cantidad de esfuerzo y tiempo posible"



TÉCNICAS DE DISEÑO DE CASOS DE PRUEBA


PROPÓSITO

  • Producir el número de casos de prueba manteniendo la efectividad de la prueba.
ENFOQUES PRINCIPALES
  • Caja blanca (como lo hace)
  • Caja negra (que es lo que hace)


PRUEBAS DE CAJA BLANCA




Consiste en realizar pruebas para verificar que líneas específicas del código funcionan tal como esta definido.
También usa la estructura de control del diseño procedimental para obtener los casos de prueba .



  • Estos casos deben garantizar:


-Que se ejercita por lo menos una vez todos los caminos independientes de cada moduló.
-Que se ejerciten todas las decisiones lógicas de su vertientes verdadera y falsa.
-Que se ejecuten todos los bucles en sus límites operacionales.
-Que se ejerciten las estructuras internas de datos para asegurar su valides.


PRUEBAS DE CAMINOS BÁSICOS
  • Es una técnica que obtiene casos de prueba caja blanca.
  • Este método permite obtener una medida de la complejidad lógica de un diseño procedimental .
  • Esta medida puede ser usada como guia a la hora de definir un conjunto básico de camino de ejecución(diseño de casos de prueba).
  • Para la obtención desde la complejidad lógica o ciclomática emplearemos una representación del flujo de control en forma de grafo.




PRUEBA DE CAJA NEGRA


La prueba verifica que el ítem que se esta probando, cuando se dan las entradas apropiadas produce los resultados esperados.
Los datos de prueba se escogerán atendiendo a las especificaciones al problema, sin importar los detalles internos del programa, al fin de verificar que el programa corra bien.
  • Enfoque de caja negra.
-También denominada pruebas de comportamiento.
-Considerar la función específica para la cuál fue creado el producto(lo que hace).
-la prueba se llevan acabo sobre la interfaz del sistema.
-Reduce el número de casos de prueba mediante la elección de condiciones de entradas y salidas válidas y no válidas que ejercitan toda la funcionalidad del sistema.
TIPO DE ERRORES QUE DETECTA
  • Funciones incorrectas o ausentes.
  • Errores de la interfaz.
  • Errores de estructuras de datos o acceso a base de datos.
  • Errores de rendimiento.
  • Errores de inicialización y terminación.

Estrategias de aplicacion

Una estrategia de prueba de software integra los métodos de diseño de caso de pruebas del software en una serie bien planeada de paso que desembocara en la eficaz construcción de software.
Con frecuencia, la prueba requiere una mayor cantidad del esfuerzo dedicado al proyecto que cualquier otra actividad de ingeniería del software. Si se realiza sin un plan, se desperdicia tiempo, se dedica un esfuerzo innecesario y, aun peor, es posible que no se detecten errores. Por lo tanto, lo razonable seria establecer una estrategia sistemática para probar el software.
El jefe de proyecto, los ingenieros de software o los especialistas en pruebas son quienes desarrollan la estrategia para prueba del software.
La estrategia de pruebas suele seguir las siguientes etapas:
• Las pruebas comienzan a nivel de modulo.
• Una vez terminadas, progresan hacia la integración del sistema completo y su instalación.
• Culminan cuando el cliente acepta el producto y se pasa a su explotación inmediata.
En la prueba del software es posible aplicar muchas estrategias, a continuación se expondrán algunas de estas clases de prueba.

Prueba de unidad: es la prueba de cada módulo, que normalmente realiza el propio personal de desarrollo en su entorno.
Prueba de integración: con el esquema del diseño del software, los módulos probados se integran para comprobar sus interfaces en el trabajo conjunto.
Prueba del sistema: el software ya validado se integra con el resto del sistema (rendimiento, seguridad, recuperación y resistencia).
Prueba de aceptación: el usuario comprueba en su propio entorno de explotación si lo acepta como está o no.
• Pruebas alfa y beta.





Biblografia

Análisis y diseño de aplicaciones informáticas de gestión, una perspectiva de ingeniería del software,
Mario G. Piattini, Jose A. Calvo-Manzano, Joaquin Cervera Bravo, and Luis Fernandez Sanz.
Alfaomega, 2004.

Ingeniería del software, un enfoque práctico
Roger S. Pressman.
McGrawHill, sexta edition, 2007.

http://gemini.udistrital.edu.co/comunidad/grupos/arquisoft/fileadmin/Estudiantes/Pruebas/HTML%20-%20Pruebas%20de%20software/node1.html