Profesor Integrantes

Hctor Molina T.S.U. Luis Vsquez

T.S.U. Jonathan Moreno


Ciudad Bolvar Junio del 2014
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

Los enfoques en las pruebas de software constituyen una de las bases para la
determinacin de la calidad de un producto de software y dependiendo de las caractersticas
de ste se puede aplicar uno u otro de los tipos de pruebas definidos.
Cada enfoque en las pruebas se especializa segn el requisito al que apunte y evala el
nivel de aceptacin de ste y por ende del componente de software.
Al realizar las distintas pruebas de software se deben seguir los formatos estndar y la
documentacin predefinida para realizar el seguimiento de los resultados de las pruebas
funcionales del sistema y de todas las dems. Si se observa una falla, se debe generar
formalmente un informe del incidente para que ste sea analizado y reparado desde el
cdigo. Los encargados no deben perder de vista estos documentos con el propsito 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
aceptacin. 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 adems 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 funcin. Las entradas incorrectas e ilegales se
deben manejar tambin por el sistema. Todas las funciones deben ser probadas. Muchas de
las pruebas a nivel sistema incluyendo pruebas de funcionalidad deben ser diseadas 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 anlisis y diseo y el producto de software construido.
La prueba de casos de uso apunta a determinar si la funcionalidad del sistema en
trminos de lo descrito por los casos de usos relacionados sea equivalente, es decir, que
cada uno de los elementos tanto del caso de uso grfico (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 segn 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 anlisis y diseo y el producto de software construido.
El diagrama de transicin de estados es til para modelar los aspectos dinmicos de un
sistema, estos aspectos dinmicos pueden comprender el comportamiento ordenado por
eventos de cualquier objeto del mismo.
Las pruebas de estados del sistema buscan determinar que la existencia y transicin de
estados del sistema ocurra efectivamente dentro del producto de software lo cual incluye
verificar que la condicin y la accin correspondiente sean las correctas. Para sta prueba
tanto los estados como las transiciones del sistema son determinables directa o
indirectamente a travs de interfaces o mediante pruebas explcitas al cdigo 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 tcnica tiene mayor o menor cobertura sobre
el producto de software segn la forma en que sea aplicada de acuerdo a la orientacin de
las tcnicas usadas (caja blanca, caja negra ).
Para realizar pruebas de caja negra (black box), que prueben los estados del sistema, se
deben obviar mucha informacin 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 diseado para que el usuario ingrese los datos necesarios de
forma clara y correcta segn las funcionalidades requeridas para el mismo.
Son consideradas entradas del sistema cualquier informacin que el usuario suministre y
est dispuesto en:
Cajas de texto (textbox, passwordfield).
reas de texto (textarea).
Listas de seleccin (list).
Barra de seleccin 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 opcin (radiobutton).
Botones de seleccin (checkbox).

Pruebas de Salidas

Asegurar que el sistema este diseado para que los datos entregados por este sean claros
y correctos segn los requerimientos funcionales relacionados.
Son consideradas salidas del sistema cualquier informacin que el sistema suministre y est
dispuesto en:
Cajas de texto (textbox, passwordfield).
reas de texto (textarea).
Listas de seleccin (list).
Barra de seleccin deslizable (slider).
Arboles de entrada (tree).
Caja de ajuste de valor (Spinner).
Caja de opciones (combox).
Campos en tablas (Grid).
Botones (button).
Botones de opcin (radiobutton).
Botones de seleccin (checkbox).
Vnculos (link).
Archivos (files).
Dispositivos externos de hardware (devices).
Otros que apliquen la definicin (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 Ortografa y Gramtica

Asegurar la utilizacin correcta del lenguaje (ortografa y gramtica) utilizada en el
producto de software
sta prueba revisa aspectos como: ortografa, gramtica, concordancia semntica,
sintctica y en general buen uso del lenguaje. En ste caso, la prueba se realiza en mayora
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 algn tipo de informacin
mediante un lenguaje escrito, por ejemplo:
Imgenes con textos
Ttulos.
Etiquetas.
Explicaciones.
Ayudas.
Entre otras.
Se debe comprobar que el producto de software no tenga extranjerismos sin traduccin
inmediata debido a que esto es fuente de confusiones para el usuario final.

Prueba de Stress

Encontrar el pico en cuanto al lmite 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 asignacin de recursos en cantidades mximas, se est hablando de una
prueba de stress o de tensin o prueba en condiciones forzadas.
La meta de la prueba de tensin 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 dbiles donde el diseo defectuoso
podra causar la indisponibilidad del servicio

Prueba de Seguridad

Asegurar que el producto de software cumple con los estndares exigidos en los
requisitos no funcionales y adems que contemple los esquemas de seguridad mnimos
reconocidas en la industria de software.
La prueba de la seguridad evala las caractersticas 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 dao, robando datos e informacin, causando la
negacin del servicio.
Errores por parte del usuario en donde la aplicacin permite el acceso, creacin,
modificacin o destruccin a datos debido a informacin falsa, y mal manejo de
privilegios.
Los daos 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 ilcitos.
Entre otros.