Documentos de Académico
Documentos de Profesional
Documentos de Cultura
SENA
APRENDIZ
Evidencia
Diseño y ejecución de plan de pruebas del sistema de información.
Evidencia
Diseño y ejecución de plan de pruebas del sistema de información.
DESCRIPCIÓN DE LA EVIDENCIA.
2. Elaborar el plan de pruebas: en este paso se debe realizar una lectura y análisis del
documento de requerimientos del proyecto, se debe tener construido el sistema de
información, se debe elaborar el plan de pruebas con base a el documento de casos de
pruebas que a su vez es basado en los casos de uso que fue presentado como
material en esta guía.
3. Ejecutar el plan de pruebas: en este paso una vez se ha realizado el plan de pruebas
se debe ejecutar cada uno de los casos de prueba, registrando los resultados
esperados y los resultados obtenidos junto con las recomendaciones a realizar.
PRODUCTO(S) ENTREGABLE(S)
Informe de diseño del diseño y ejecución de las pruebas del sistema de información,
documento electrónico con la siguiente estructura:
● Introducción.
SERVICIO NACIONAL DE APRENDIZAJE SENA
Formato para Desarrollo de Evidencia
DESARROLLO
Introducción
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.
Definiciones y acrónimos
SERVICIO NACIONAL DE APRENDIZAJE SENA
Formato para Desarrollo de Evidencia
Un primer bosquejo del proceso de prueba de caja negra sería el siguiente, que
refinaremos en números subsiguientes:
1. Hacer
a) Diseñar casos de prueba
b) Aplicar casos de prueba
c) Reportar métricas y dar seguimiento
d) Reportar análisis de resultados
El SUT (System Under Testing) se refiere en general al elemento a probar. Por otro
lado, las herramientas que utiliza el tester para llevar a cabo las actividades anteriores
son cobijados bajo el acrónimo CAST (Computer Aided Software Testing).
Claridad. Que evidencien fallas de manera clara. Con calidad nos referimos a
[2]: el grado en que el producto satisface los requerimientos funcionales y no-
funcionales explícitamente establecidos; el nivel al que se siguieron los
estándares de desarrollo explícitos y documentados; que el producto muestre
las características implícitas que se espera de todo software desarrollado
profesionalmente.
El plan de prueba: describe todos los métodos que se utilizarán para verificar que el
software satisface la especificación del producto y las necesidades del cliente. Incluye
los objetivos de calidad, necesidades de recursos, cronograma, asignaciones,
métodos, etc.
Casos de prueba: lista los ítems específicos que serán probados y describe los pasos
detallados que serán seguidos para verificar el software.
Referencias
Algunos documentos del proyecto, son la base de este documento inicial de plan de
pruebas, que a continuación se especifican:
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.
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.
Las condiciones que deben estar dadas para que el código funcione las llamamos
precondiciones y las condiciones sobre el estado en que quedan las variables y él o
los valores de retorno, las llamamos postcondiciones.
Esta estipulación es mayormente para que la utilicen otros programadores, por lo que
es particularmente útil cuando se encuentra dentro de la documentación. En ciertos
casos, además, puede quererse que el programa revise si las condiciones realmente
se cumplen y de no ser así, actúe en consecuencia.
Con las pruebas unitarias todos ganan. La vida de desarrollador será mucho más fácil,
ya que la calidad de su código mejorará, se reducirán los tiempos de depuración y la
corrección de incidencias y por tanto el cliente estará mucho más contento porque la
aplicación hace lo que él quiere que haga, por lo que ha pagado.
Las pruebas nos ayudan a entender mejor el código, ya que sirven de documentación.
A través de las pruebas podemos comprender mejor qué hace un módulo y que se
espera de él.
Cliente.java:import java.util.Vector;
Vector mFacturas;
mFacturas.addElement(f);
((Factura) mFacturas.elementAt(i)).show();
System.out.println("-------------------\n\n");}
Linea mLineas[];
mNumero=n; mFecha=f;
mLineas=new Linea[10];
int i=0;
mLineas[i]=l;
SERVICIO NACIONAL DE APRENDIZAJE SENA
Formato para Desarrollo de Evidencia
mLineas[i].mArticulo=null;
mLineas[i].mPrecio=0;
double total=0;
mLineas[i].show();
total+=mLineas[i].mPrecio;
Linea.java:
String mArticulo;
double mPrecio;
SERVICIO NACIONAL DE APRENDIZAJE SENA
Formato para Desarrollo de Evidencia
mArticulo=a;
mPrecio=p;
características del ambiente de pruebas SIT, restricciones que deben aplicarse sobre
el ambiente, homologación con producción, procedimientos a implementar para una
buena gestión de los ambientes y prácticas que deben tener en cuenta los equipos de
pruebas de los diferentes proyectos.
Ajustes y Recomendaciones
Una vez que el analista identifica los flujos de datos y comienza a construir el
diccionario de datos es tiempo de pasar a las especificaciones de proceso y análisis
de decisiones. Los tres métodos para el análisis de decisiones y la descripción de la
lógica de proceso tratados en este capítulo son: lenguaje estructurado, tablas de
decisión y árboles de decisión. Las especificaciones de proceso (o mini
especificaciones) son creadas para los procesos primitivos en un diagrama de flujo de
datos, así como para algunos procesos de alto nivel que explotan a diagramas hijos.
Estas especificaciones explican la lógica de toma de decisiones y las fórmulas que
transformarán los datos de entrada al proceso en salida.
SERVICIO NACIONAL DE APRENDIZAJE SENA
Formato para Desarrollo de Evidencia
Bibliografía
www.e_magister.com
www.monografias.com
www.postgrado.inea.org
www.inea.uva.es
www.tu_discovery.com
www.aulafacil.com
www.tecniciencia.com
www.wikipedia.com
Cordialmente,
SERVICIO NACIONAL DE APRENDIZAJE SENA
Formato para Desarrollo de Evidencia