• Author / Uploaded
• Luis Vasquez

Citation preview

REPUBLICA BOLIVARIANA DE VENEZUELA MINISTERIO DEL PODER POPULAR PARA LA EDUCACION UNIVERSITARIA INSTITUTO UNIVERSITARIO DE TECNOLOGIA DEL ESTADO BOLIVAR PROGRAMA NACIONAL DE FORMACION EN INFORMATICA TRAYECTO III SEMESTRE VI INGENERIA DEL SOFTWARE

INFORME DE PRUEBAS DE SOFTWARE

Profesor Héctor Molina

Integrantes T.S.U. Luis Vásquez T.S.U. Jonathan Moreno

Ciudad Bolívar Junio del 2014

Los enfoques en las pruebas de software constituyen una de las bases para la determinación de la calidad de un producto de software y dependiendo de las características de éste se puede aplicar uno u otro de los tipos de pruebas definidos. Cada enfoque en las pruebas se especializa según el requisito al que apunte y evalúa el nivel de aceptación de éste y por ende del componente de software. Al realizar las distintas pruebas de software se deben seguir los formatos estándar y la documentación predefinida para realizar el seguimiento de los resultados de las pruebas funcionales del sistema y de todas las demás. Si se observa una falla, se debe generar formalmente un informe del incidente para que éste sea analizado y reparado desde el código. Los encargados no deben perder de vista estos documentos con el propósito de garantizar la calidad del software, y seguir el progreso del proceso de pruebas

 Pruebas de Funcionalidad

En este tipo de pruebas se debe asegurar que el comportamiento del sistema se adhiere a los requisitos funcionales. Las pruebas de funcionalidad de sistema tienen mucho que ver con las pruebas de aceptación. Se dice que un programa es aceptable cuando: 1. Hace lo que debe hacer 2. No hace lo que no debe hacer. Todos los requisitos funcionales del sistema deben ser realizables por el sistema. Por ejemplo, si se requiere un sistema de finanzas con el fin de permitir que los usuarios instalen, agreguen, modifiquen, y supriman entradas en las cuentas, y además impriman los informes, las pruebas de funcionalidad deben asegurarse de que el sistema pueda realizar estas tareas.

Las pruebas de funcionalidad son de caja negra en naturaleza. Se focalizan en las entradas y salidas apropiadas para cada función. Las entradas incorrectas e ilegales se deben manejar también por el sistema. Todas las funciones deben ser probadas. Muchas de las pruebas a nivel sistema incluyendo pruebas de funcionalidad deben ser diseñadas en el tiempo en que se toman los requisitos, e incluirse en el plan maestro de proyecto y por ende en el plan de prueba del sistema. Sin embargo, habrá algunos cambios de requisitos y por ende de las pruebas, que presentan la necesidad de que dichos cambios se vean reflejados en el plan de pruebas.

 Prueba de Casos de Uso

En este tipo de pruebas se debe Asegurar la concordancia entre los casos de uso que hacen parte de los artefactos de análisis y diseño y el producto de software construido. La prueba de casos de uso apunta a determinar si la funcionalidad del sistema en términos de lo descrito por los casos de usos relacionados sea equivalente, es decir, que cada uno de los elementos tanto del caso de uso gráfico (diagrama de casos de uso) como de su tabla explicativa concuerde con el producto de software. En ésta prueba la concordancia entre los casos de uso y el sistema debe ser analizado bidireccionalmente, es decir, desde los casos de uso hacia el producto de software y viceversa hallando y documentando los puntos en que ambos no concuerden. Cabe anotar que los errores hallados pueden pertenecer tanto al producto de software como al caso de uso relacionado según sea el caso.

 Pruebas de Estados del Sistema

Se debe asegurar la concordancia entre el diagrama de estados del sistema que hace parte de los artefactos de análisis y diseño y el producto de software construido.

El diagrama de transición de estados es útil para modelar los aspectos dinámicos de un sistema, estos aspectos dinámicos pueden comprender el comportamiento ordenado por eventos de cualquier objeto del mismo. Las pruebas de estados del sistema buscan determinar que la existencia y transición de estados del sistema ocurra efectivamente dentro del producto de software lo cual incluye verificar que la condición y la acción correspondiente sean las correctas. Para ésta prueba tanto los estados como las transiciones del sistema son determinables directa o indirectamente a través de interfaces o mediante pruebas explícitas al código fuente, es por esto que éste tipo de prueba puede ser caja blanca o caja negra, aclarando que en el caso que se utilicen ambas perspectivas será caja gris. Es importante aclara en éste punto que ésta técnica tiene mayor o menor cobertura sobre el producto de software según la forma en que sea aplicada de acuerdo a la orientación de las técnicas usadas (caja blanca, caja negra ). Para realizar pruebas de caja negra (black box), que prueben los estados del sistema, se deben obviar mucha información que posee el diagrama de estados. Así pues, la mejor forma de probar los estados del sistema será mediante pruebas de caja blanca (white box).

 Prueba de Entradas

Asegurar que el sistema este diseñado para que el usuario ingrese los datos necesarios de forma clara y correcta según las funcionalidades requeridas para el mismo. Son consideradas entradas del sistema cualquier información que el usuario suministre y esté dispuesto en:  Cajas de texto (textbox, passwordfield).  Áreas de texto (textarea).  Listas de selección (list).  Barra de selección deslizable (slider).  Arboles de entrada (tree).

 Caja de ajuste de valor (Spinner).  Caja de opciones (combox).  Campos en tablas modificables (Grid).  Botones (button).  Botones de opción (radiobutton).  Botones de selección (checkbox).

 Pruebas de Salidas

Asegurar que el sistema este diseñado para que los datos entregados por este sean claros y correctos según los requerimientos funcionales relacionados. Son consideradas salidas del sistema cualquier información que el sistema suministre y esté dispuesto en:  Cajas de texto (textbox, passwordfield).  Áreas de texto (textarea).  Listas de selección (list).  Barra de selección deslizable (slider).  Arboles de entrada (tree).  Caja de ajuste de valor (Spinner).  Caja de opciones (combox).  Campos en tablas (Grid).  Botones (button).  Botones de opción (radiobutton).  Botones de selección (checkbox).  Vínculos (link).  Archivos (files).  Dispositivos externos de hardware (devices).  Otros que apliquen la definición (ver observaciones).

En esta prueba se realizan varias comprobaciones que tienen en cuenta el comportamiento el cual está relacionado con los requisitos funcionales del sistema - de cada una de las salidas

 Prueba de Ortografía y Gramática

Asegurar la utilización correcta del lenguaje (ortografía y gramática) utilizada en el producto de software Ésta prueba revisa aspectos como: ortografía, gramática, concordancia semántica, sintáctica y en general buen uso del lenguaje. En éste caso, la prueba se realiza en mayoría de los casos de forma transversal a otros tipos de prueba y en ella se revisa cualquier componente o elemento del producto de software que provea algún tipo de información mediante un lenguaje escrito, por ejemplo:  Imágenes con textos  Títulos.  Etiquetas.  Explicaciones.  Ayudas.  Entre otras. Se debe comprobar que el producto de software no tenga extranjerismos sin traducción inmediata debido a que esto es fuente de confusiones para el usuario final.

 Prueba de Stress

Encontrar el pico en cuanto al límite del rendimiento del producto de software se refiere, que garantice un funcionamiento aceptable bajo ciertos rangos preestablecidos.

Cuando se ejecuta un sistema y se prueba la carga de procesos en él y los resultados relacionados con la asignación de recursos en cantidades máximas, se está hablando de una prueba de stress o de tensión o prueba en condiciones forzadas. La meta de la prueba de tensión es intentar romper el sistema; la idea es encontrar las circunstancias bajo las cuales se colapsará. La prueba de stress es importante porque puede revelar defectos en tiempo real, así como las áreas débiles donde el diseño defectuoso podría causar la indisponibilidad del servicio

 Prueba de Seguridad

Asegurar que el producto de software cumple con los estándares exigidos en los requisitos no funcionales y además que contemple los esquemas de seguridad mínimos reconocidas en la industria de software. La prueba de la seguridad evalúa las características del sistema que se relacionan con la disponibilidad, integridad, y confidencialidad de los datos y de los servicios del sistema. La seguridad del software y los datos puede estar comprometida por:  Criminales que puedan hacer daño, robando datos e información, causando la negación del servicio.  Errores por parte del usuario en donde la aplicación permite el acceso, creación, modificación o destrucción a datos debido a información falsa, y mal manejo de privilegios. Los daños que se pueden hacer a la producto de software pueden ser usando algunos de los siguientes medios:  Virus.  Caballos de Troya.  Puertas traseras abiertas.  Canales ilícitos.  Entre otros.