Evidencia

Diseño y ejecución de plan de pruebas del sistema de información.

.

PRESENTADO POR
RAFAEL RAMOS
DANIEL HERRERA

PRESENTADO A

SENA
SERVICIO NACIONAL DE APRENDISAJE
ANÁLISIS Y DESARROLLO DE SISTEMAS DE INFORMACIÓN
 Introducción.

Los principales objetivos que se buscan con la prueba de software suelen ser:
• Conocer el nivel de calidad de productos intermedios, para actuar a tiempo (v.gr. rehacer un
componente); esto facilita una administración realista del time to market del producto en cuestión.
• No pagar por un producto de software sino hasta que alcance el nivel de calidad pactado; esto
eleva el nivel de certidumbre en el comprador de software, y minimiza riesgos.
• Disminuir la penosa y costosa labor de soporte a usuarios insatisfechos, consecuencia de liberar
un producto inmaduro. Esto puede mejorar la imagen de la organización desarrolladora (y la
credibilidad en ella).
• Reducir costos de mantenimiento (la fase más costosa del desarrollo de software), mediante el
diagnóstico oportuno de los componentes del sistema (v.gr. seguimiento a estándares, legibilidad
del código, integración adecuada de los componentes, rendimiento apropiado, nivel y calidad del
reuso, calidad de la documentación, etc.).
• Obtener información concreta acerca de fallas, que pueda usarse como apoyo en la mejora de
procesos, y en la de los desarrolladores (v.gr. capacitación en áreas de oportunidad).
Entre más pronto se apliquen mecanismos de prueba en el proceso de desarrollo, más fácilmente
podrá evitarse que el proyecto se salga del tiempo y presupuesto planeado, pues se podrán
detectar más problemas originados en las fases tempranas del proceso, que son los que mayor
impacto tienen.

Alcance de las pruebas del sistema información.

El documento suministra una introducción al concepto de cómo crear y ejecutar los casos de
prueba y el seguimiento a las fallas, es importante aclarar que cualquiera que sea la metodología
que se use en el proceso de desarrollo y pruebas al sistema de información todos los casos de
prueba en su entrega final del proyecto educativo.

Definiciones y acrónimos.
El Equipo de Proyecto comprobará cada componente que va generando para detectar posibles
errores y evitar que éstos se reproduzcan en componentes o módulos posteriores. Además, cada
vez que se implemente la comunicación entre dos o más módulos que estén integrados, el equipo
de proyecto comprobará dicha integración. De este modo es más sencillo detectar y corregir los
errores que si el sistema se encuentra totalmente desarrollado y todos sus módulos integrados.
Para ello, deberá realizar las siguientes pruebas:
 Pruebas unitarias. Conjunto de pruebas que comprueban el correcto funcionamiento de cada
componente de código por separado. Esto sirve para asegurar que cada uno de los módulos
funcione correctamente por separado. Posteriormente, con las pruebas de integración, se podrá
asegurar el correcto funcionamiento del sistema o subsistema en cuestión. Para la ejecución de las
pruebas unitarias se deberá utilizar una herramienta que automatice el proceso, por ejemplo, JUnit.
Se propone la siguiente plantilla como ayuda a la definición de las pruebas unitarias.
 Pruebas de integración. Conjunto de pruebas que verifican la correcta integración entre todos los
componentes/módulos del sistema. La necesidad de realizar las pruebas de integración viene dada
por el hecho de que los módulos que forman un programa suelen fallar cuando trabajan de forma
conjunta, aunque previamente se haya demostrado que funcionan correctamente de manera
individual. Por ello se deberán realizar este tipo de pruebas, las cuáles asegurarán que los
módulos que están relacionados se ejecutan correctamente. Con el uso de estas pruebas, se
conseguirá formar el producto global a medida que se comprueba como los distintos componentes
interaccionan y se comunican libres de errores. Para automatizar las pruebas de integración se
pueden emplear las mismas herramientas que para las pruebas unitarias (por ejemplo, JUnit), pero
los casos de pruebas por regla general serán más largos y la verificación de resultados puede
requerir más de una comprobación. Se propone la siguiente plantilla como ayuda a la definición de
las pruebas de integración.
 Pruebas de código estático. Son verificaciones de código estático que todo programador debe
realizar en su código para evitar errores de compilación, ejecución durante las fases posteriores.
Un alto porcentaje de las pruebas se podrán automatizar en herramientas, tales como Checkstyle,
PMD, Findbugs.

Las pruebas unitarias son a bajo nivel (cercanas al código fuente de nuestra aplicación).

Este tipo de testing consiste en probar de forma individual las funciones y/o métodos (de las
clases, componentes y/o módulos que son usados por nuestro software).

Debido a lo específicas que son, generalmente son las pruebas automatizadas de menor coste, y
pueden ejecutarse rápidamente por un servidor de continuous integration (integración continua).

Más detalles acerca de las pruebas unitarias:

Idealmente, cuando planeamos y escribimos pruebas unitarias, debemos aislar la funcionalidad

hasta un punto en que no se pueda desglosar más, y entonces escribir pruebas a partir de ello.
Justamente, el nombre de este tipo de testing hace referencia a una "unidad de código", que es
independiente del resto.

Estas pruebas verifican que el nombre de la función o método sea adecuado, que los nombres y
tipos de los parámetros sean correctos, y así mismo el tipo y valor de lo que se devuelve como
resultado.

Dado que las pruebas unitarias no deben tener ningún tipo de dependencia, se suele reemplazar
los llamados a APIs y servicios externos por funcionalidad que los imite (para que no exista
interacción que vaya más allá de la unidad que está siendo probanda).

En muchos casos inclusive se suele reemplazar las consultas a bases de datos, de modo que la
prueba se enfoque en operar a partir de los valores de entrada, sin depender de ninguna fuente
externa.

Si no es factible aislar el uso de bases de datos de nuestras pruebas unitarias, será importante
tener en cuenta el rendimiento y buscar optimizar nuestras consultas.

Referencias.

1. www.e-quallity.net pestaña Definiciones - Conceptos

2. Pressman, R.: Ingeniería de Software. Un Enfoque práctico. McGraw-Hill; 1993
3. Kit, E.: Software Testing in the Real World. ACM Press, 1995

https://sg.com.mx/revista/4/fundamentos-prueba-software-conceptos-justificacion-y-alcance

https://www.juntadeandalucia.es/servicios/madeja/contenido/libro-
pautas/227#Diseno_y_ejecucion_de_pruebas_de_componentes_de_codigo

https://colaboracion.dnp.gov.co/CDTI/Oficina%20Informatica/Sistemas%20de%20informaci%C
3%B3n/Gu%C3%ADas%20Formatos%20Plantillas/Guia%20%20para%20Crear%20y%20Ejec
utar%20casos%20de%20Pruebas.pdf?
Visión general del documento.

La prueba de software tiene limitantes, tanto teóricos como prácticos. Desde el punto de vista
teórico, la prueba es un problema que llamamos no-decidible; esto implica, grosso modo, que no
podemos escribir un programa que pruebe los programas sin intervención humana. Sin embargo,
como mencionábamos anteriormente, la prueba sí es automatizable en muchos aspectos.
Desde el punto de vista práctico, la cantidad de posibilidades para probar exhaustivamente un
sistema es sencillamente inmanejable; es necesario entonces utilizar técnicas adecuadas para
maximizar la cantidad de fallas importantes encontradas con los recursos asignados.
Cada método que se utilice para detectar defectos deja un residuo de defectos más sutiles contra
los cuales ese método es ineficaz (la llamada “Paradoja del Pesticida”). La prueba de software
implica pues, la aplicación de técnicas y herramientas apropiadas en el marco de un proceso bien
definido, determinado por el tipo de proyectos de desarrollo de software que se abordan. En el
siguiente número veremos con mayor detalle las principales técnicas de prueba de software.

Descripción del Ambiente de pruebas (precondiciones y postcondiciones).

Precondiciones
Las precondiciones son las condiciones que deben cumplir los parámetros que una función recibe,
para que esta se comporte correctamente.

Por ejemplo, en una función división las precondiciones son que los parámetros son números, y
que el divisor sea distinto de 0. Tener una precondición permite asumir desde el código que no es
necesario lidiar con los casos en que las precondiciones no se cumplen.

Postcondiciones

Las postcodiciones son las condiciones que cumplirá el valor de retorno, y los parámetros
recibidos, en caso de que hayan sido alterados, siempre que se hayan cumplido las
precondiciones.

Tanto las precondiciones como las postcondiciones son aseveraciones (en inglés assert). Es decir,
afirmaciones realizadas en un momento particular de la ejecución sobre el estado computacional.
Si llegaran a ser falsas significaría que hay algún error en el diseño o utilización del algoritmo.

Para comprobar estas afirmaciones desde el código en algunos casos podemos utilizar la
instrucción assert, está instrucción recibe una condición a verificar y, opcionalmente, un mensaje
de error que devolverá en caso que la condición no se cumpla.
Casos de prueba pruebas unitarias.

Las pruebas unitarias son a bajo nivel (cercanas al código fuente de nuestra aplicación).

Este tipo de testing consiste en probar de forma individual las funciones y/o métodos (de las
clases, componentes y/o módulos que son usados por nuestro software).

Para nuestro caso los enlaces entre modulo.

Casos de prueba pruebas integrales.

Se verifican los enlaces entre módulos o entre el MVC

Registro de resultados de las pruebas unitarias.

Registro de resultados de pruebas integrales.

Ajustes y Recomendaciones.

Un caso de prueba puede ayudarlo a identificar fácilmente cualquier problema, incidencias no

planificadas o detalles omitidos en un proyecto, actualización o prueba. Además, los casos de
prueba ofrecen los siguientes beneficios a las personas o equipos que los llevan a cabo:
 Minimizar las pruebas adhoc
 Facilitar y simplificar la gestión manual de casos de prueba
 Guardar tiempo valioso para probar y analizar los resultados
 Habilitar a los evaluadores para desarrollar casos de prueba individuales para escenarios
específicos
 Verificar el éxito de las actualizaciones o cambios
 Hacer que sea más sencillo compartir resultados con los participantes y obtener la aceptación de
todas las partes involucradas
 Disminuir el esfuerzo y la tasa de error involucrados en las pruebas
 Definir y desarrollar todos los resultados o comportamientos positivos y negativos de las pruebas
 Dividir las pruebas en segmentos positivos y negativos
 Eliminar la cantidad de errores en un producto final
 Comunicar todas las condiciones específicas desde el principio para eliminar la confusión
 Mantener la gestión actualizada sobre el estado de calidad de una prueba
 Los evaluadores de ayuda generan resúmenes e informes detallados sobre el estado de la prueba,
los defectos, los errores, etc.
 Realice un seguimiento de la productividad y rastree todos los problemas hasta la fuente
 Ayude a los evaluadores a escribir e informar sobre los resultados de los casos de prueba más
completos

Anexos.

Casos de pruebas (Plantilla de casos de prueba).

Plantilla #1

 Pruebas de interfaz de Usuario: El resultado de las pruebas de interfaz de

usuario se verá reflejado en el siguiente informe o lista de chequeo

Elemento a Revisar SI NO No Observaciones

Aplica

¿Se realizaron las pruebas de interfaz de usuario

con alguna herramienta especializada?

¿Cuál fue el porcentaje de cobertura de la prueba

con relación al sistema total?

¿Existe constancia de la ejecución de las pruebas?

¿Qué páginas se cubrió con la prueba?

¿Se estableció un criterio para la ejecución de las

pruebas? ¿Cuál?

¿Se cumplió la estrategia de ejecución de la

prueba?
  Pruebas de Seguridad: El resultado de las pruebas de seguridad se verá reflejado
en el siguiente informe o lista de chequeo:

Elemento a Revisar SI NO No Observaciones

Aplica

¿Se realizaron las pruebas de seguridad con

alguna herramienta especializada?

¿Cuál fue el porcentaje de cobertura de la prueba

con relación al sistema total?

¿Existe constancia de la ejecución de las pruebas?

¿Qué capas o componentes de la arquitectura se

cubrió con la ejecución de las pruebas?

¿Se estableció un criterio para la ejecución de las

pruebas? ¿Cuál?

¿Se cumplió la estrategia de ejecución de la

prueba?

 Pruebas de Configuración: El resultado de las pruebas de configuración se verá

reflejado en el siguiente informe o lista de chequeo

Elemento a Revisar SI NO No Observaciones

Aplica

¿Se realizaron las pruebas de Configuración con

alguna herramienta especializada?

¿Cuál fue el porcentaje de cobertura de la prueba

con relación al sistema total?

¿Existe constancia de la ejecución de las pruebas?

¿Qué páginas se cubrió con la prueba?

¿Se estableció un criterio para la ejecución de las

pruebas? ¿Cuál?

¿Se cumplió la estrategia de ejecución de la

prueba?

 Pruebas de Recuperación a Fallas: El resultado de las pruebas de Recuperación

a Fallas se verá reflejado en el siguiente informe o lista de chequeo

Elemento a Revisar SI NO No Observaciones

Aplica

¿Se realizaron las pruebas de recuperación a

fallas con alguna herramienta especializada?

¿Cuál fue el porcentaje de cobertura de la prueba

con relación al sistema total?

¿Existe constancia de la ejecución de las

pruebas?

¿Qué páginas se cubrió con la prueba?

¿Se estableció un criterio para la ejecución de las

pruebas? ¿Cuál?

¿Se cumplió la estrategia de ejecución de la

prueba?

Plantilla#2

INFORMACIÓN GLOBAL DEL CASO DE PRUEBA

<Descripción del tipo de prueba: Código

Carga, Volumen, Estrés, ETC> de la
Tipo de Prueba:
prueba <Codificación de la prueba>

Descripción de la
<Descripción del objetivo de la prueba>
prueba:

Versión de Fecha de
Ejecución Ejecución <Fecha de ejecución en formato
<Versión o iteración de
AAAA/MM/DD diligenciado por el
 ejecución de la prueba> analista de pruebas al momento de su
ejecución>

1. Prerrequisitos de la prueba

<Lista de los prerrequisitos a tener en cuenta antes de ejecutar la prueba>

2. Insumos de la prueba

<Lista de Insumos necesarios para ejecutar la prueba>

3. Lista de chequeo de la prueba

Prueba
satisfactoria
Pasos a Seguir Observaciones
SI NO

<Pasos numerados en orden lógico para la ejecución de

la prueba>

4. Resultados de la prueba
Defectos y desviaciones Veredicto

<Lista de defectos o desviaciones encontrados por el analista o usuario al ejecutar la

prueba> Paso

Falló

Observaciones Probador

<Observaciones generales del analista o usuario sobre la ejecución de la prueba>

Firma:

Nombre:

Fecha: