Está en la página 1de 15

SERVICIO NACIONAL DE APRENDIZAJE SENA

Formato para Desarrollo de Evidencia

SERVICIO NACIONAL DE APRENDIZAJE

SENA

IVAN FERNANDO PINTO RAMIREZ

APRENDIZ

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

TECNOLOGO ANALISIS Y DESARROLLO DE SISTEMA DE INFORMACIÓN


SERVICIO NACIONAL DE APRENDIZAJE SENA
Formato para Desarrollo de Evidencia

Santiago de Cali 04 de Noviembre de 2019

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

DESCRIPCIÓN DE LA EVIDENCIA.

Con el fin de obtener el aseguramiento de la calidad del sistema de información desarrollado y


con base en el diseño de las pruebas de software basadas en los casos de prueba, se debe
elaborar un documento donde se especifique el plan de pruebas y el registro del resultado de
las mismas.

1. Elaborar laboratorio de pruebas de software: en este paso se debe realizar los


ejercicios propuestos en el laboratorio de pruebas de software para apropiar los
conceptos antes de elaborar el informe entregable.

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.

4. Elaborar el informe con el resultado de las pruebas: en este paso el aprendiz


elaborará un documento con el informe de lo consignado en la ejecución de pruebas.
Deberá documentar los errores encontrados, las funcionalidades no encontradas, las
funcionalidades no especificadas o con problemas en su funcionamiento, de tal forma
que sea una guía para ejecutar las correcciones por parte del equipo de desarrollo.

Evidencia (De Producto)


Para cumplir con esta evidencia, es importante que haya realizado la actividad de apropiación
referida a la comprensión al material de estudio presentando en esta guía. De acuerdo con las
indicaciones de su instructor, posteriormente debe ingresar y entregar la actividad (evidencia)
desarrollada en la plataforma

PRODUCTO(S) ENTREGABLE(S)

Dentro de los productos entregables se solicitan:

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

● Alcance de las pruebas del sistema información.


● Definiciones y acrónimos.
● Referencias.
● Visión general del documento.
● Descripción del Ambiente de pruebas (precondiciones y postcondiciones).
● Casos de prueba pruebas unitarias.
● Casos de prueba pruebas integrales.
● Registro de resultados de las pruebas unitarias.
● Registro de resultados de pruebas integrales.
● Ajustes y Recomendaciones.
● Anexos.
● Casos de pruebas (Plantilla de casos de prueba).
SERVICIO NACIONAL DE APRENDIZAJE SENA
Formato para Desarrollo de Evidencia

DESARROLLO

Introducción

Un sistema de información es un sistema, automatizado o manual, que engloba a


personas, máquinas y/o métodos organizados para recopilar, procesar, transmitir
datos que representan información. Un sistema de información engloba la
infraestructura, la organización, el personal y todos los componentes necesarios
para la recopilación, procesamiento, almacenamiento, transmisión, visualización,
diseminación y organización de la información.

Todo desarrollador de software independientemente de la metodología que se esta


implementando, es necesario que se influya fase de pruebas, la cual nos permitirá
determinar si el producto a entregar cumple con la calidad especificada y esperada por
el cliente. En la actualidad las personas que nos dedicamos a las pruebas de software
(Testing), necesitamos de un plan de pruebas de software, el cual tiene como
propósito comunicar todos los involucrados del proyecto los entregables, las
características a ser o no ser aprobadas, los aspectos de criterios de aprobación y
fallo, criterios de suspensión y reanuidacion, las necesidades ambientales, las
capacitaciones requeridas para los integrantes del equipo de pruebas, los riesgos y el
laboratorio de usabilidad.

El plan de pruebas de software se puede aplicar a todo proyecto de software, se ajusta


a la necesidad de cada empresa, de software considerando el tamaño del proyecto, el
tiempo, el costo de vida de software, los involucrados, que son algunos por mencionar.
Cada empresa puede definir su propio plan de pruebas de software basándose en las
buenas practicas y en la mejora continua.

La sección inicial de nuestro plan de pruebas, cuyo propósito principal es informar el


alcance de las pruebas para el proyecto en cuestión, dando una breve explicación o
resumen de todas las secciones que integran nuestro plan
SERVICIO NACIONAL DE APRENDIZAJE SENA
Formato para Desarrollo de Evidencia

Alcance de las pruebas del sistema informació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.

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.

Definiciones y acrónimos
SERVICIO NACIONAL DE APRENDIZAJE SENA
Formato para Desarrollo de Evidencia

Complementando nuestro primer acercamiento a una definición, que tuvimos en el


número anterior, podemos argüir que la prueba de software:

Es un proceso en el que se revisa el sistema a probar (el SUT) bajo condiciones


definidas explícitamente, y se le aplica (eventualmente con apoyo de software
especializado de tipo CAST) un conjunto de estímulos (los casos de prueba)
diseñados de manera sistemática utilizando técnicas apropiadas, con el objetivo de
detectar niveles inadecuados de calidad. Este proceso debe llevarse a cabo
disciplinadamente, y respaldarse en métricas bien definidas. Todas estas actividades y
sus resultados son documentados, en especial las fallas detectadas [1].

Precisemos cada uno de los conceptos de esta definición. Intuitivamente, un proceso


puede verse como una secuencia de actividades, cada una de las cuales genera
productos, tiene insumos asociados, e involucra gente (roles) y otros recursos (v.gr.
hardware y software).

Un primer bosquejo del proceso de prueba de caja negra sería el siguiente, que
refinaremos en números subsiguientes:

1. Establecer alcances, entregables y criterios de éxito


2. Estimar el esfuerzo de prueba
3. Planear el proyecto
4. Reproducir el contexto del SUT

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

2. Mientras no (criterio de terminación)


a) Hacer el cierre del proyecto

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).

En cuanto a los casos de prueba, es deseable que presenten las siguientes


características:

 Ortogonalidad. No tener casos que incluyan segmentos de otros

 Efectividad. Que detecten fallas.

 Ejemplaridad. Que “con poco se pruebe mucho”.


SERVICIO NACIONAL DE APRENDIZAJE SENA
Formato para Desarrollo de Evidencia

 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.

Una equivocación es una acción incorrecta cometida por un humano (v.gr. no


presionar [shift]), que ocasiona que se genere una falta (sin el [shift], queda “<” en vez
de “>” en el código fuente); al ser ejecutada, la falta se evidencia en forma de lo que
llamamos una falla. El error es la magnitud de la diferencia entre el resultado esperado
y el obtenido

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.

Reporte de pruebas: describen los problemas encontrados al ejecutar los casos de


prueba.

Herramientas de pruebas y automatización: documentación de las herramientas


empleadas en el proceso de pruebas.

Referencias

Algunos documentos del proyecto, son la base de este documento inicial de plan de
pruebas, que a continuación se especifican:

 Alcances del Proyecto


 Documentos de Especificación de Requerimientos.
 Lista de Casos de Usos
 Casos de Usos
 Diagramas de clases

Visión general del documento


SERVICIO NACIONAL DE APRENDIZAJE SENA
Formato para Desarrollo de Evidencia

Este documento consta de tres secciones. La sección 1 muestra la introducción y


proporciona una visión general acerca de la Especificación de Requerimientos. En la
sección 2 se proporciona una descripción general del sistema, con el fin de conocer
las principales funciones que debe efectuar, los datos asociados y los factores,
restricciones, supuestos y dependencia que afecta al desarrollo, sin entrar en
excesivos detalles. En la sección 3 se define detalladamente los requisitos que debe
tener nuestro sistema al momento del desarrollo y la implementación.

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

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.

En el ejemplo anterior, la función división con las precondiciones asignadas, puede


asegurar que devolverá un número correspondiente al cociente solicitado.

Cuando hablamos de contratos o programación por contratos, nos referimos a la


necesidad de estipular tanto lo que necesita como lo que devuelve nuestro código

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.

En definitiva, este concepto es similar al ya mencionado con respecto a la


documentación de funciones, es decir que se debe documentar cómo deben ser los
parámetros recibidos, cómo va a ser lo que se devuelve, y qué sucede con los
parámetros en caso de ser modificados.

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.

Existen herramientas en algunos lenguajes de programación que facilitan estas


SERVICIO NACIONAL DE APRENDIZAJE SENA
Formato para Desarrollo de Evidencia

acciones, en el caso de Python, es posible utilizar la instrucción.

Casos de prueba pruebas unitarias

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 fomentan el cambio y la refactorización. Si consideremos que nuestro


código es mejorable podemos cambiarlo sin ningún problema. Si el cambio no
estuviera realizado correctamente las pruebas nos avisarán de ello. Seguramente la
frase “si funciona no lo toques” a más de uno familiar les resultará familiar. Si hubiera
pruebas unitarias, no sería necesario pronunciarla.

Se reducen drásticamente los problemas y tiempos dedicados a la integración. En las


pruebas se simulan las dependencias lo que nos permite que podemos probar nuestro
código sin disponer del resto de módulos. Por experiencia puede decir que los
procesos de integración son más de una vez traumáticos, dejándolos habitualmente
para el final del proyecto. La frase “sólo queda integrar” haciendo referencia a que el
proyecto está cerca de terminar suele ser engañosa, ya que el periodo de integración
suele estar lleno de curvas.

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.

Se desean realizar las pruebas unitarias y de integración de las 3 clases cuyo


código se ofrece a continuación:

Cliente.java:import java.util.Vector;

public class Cliente {

String mNIF, mNombre;

Vector mFacturas;

public Cliente(String nif, String nombre) {


SERVICIO NACIONAL DE APRENDIZAJE SENA
Formato para Desarrollo de Evidencia

mNIF=nif; mNombre=nombre; mFacturas=new Vector();

public void add(Factura f) {

mFacturas.addElement(f);

public void show() {

System.out.println("Facturas del cliente " + mNombre + ":");

for (int i=0; i<mFacturas.size(); i++) {

System.out.println("Factura " + (i+1));

((Factura) mFacturas.elementAt(i)).show();

System.out.println("-------------------\n\n");}

}}Factura.java:import java.util.Vector;public class Factura implements Euro


{

String mNumero, mFecha;

Linea mLineas[];

public Factura(String n, String f) {

mNumero=n; mFecha=f;

mLineas=new Linea[10];

public void add(Linea l) {

int i=0;

for (i=0; mLineas[i]!=null; i++) ;

mLineas[i]=l;
SERVICIO NACIONAL DE APRENDIZAJE SENA
Formato para Desarrollo de Evidencia

public void quitar(int i) {

mLineas[i].mArticulo=null;

mLineas[i].mPrecio=0;

public void show() {

double total=0;

System.out.println(mNumero + "; " + mFecha);

for (int i=0; mLineas[i]!=null; i++) {

mLineas[i].show();

total+=mLineas[i].mPrecio;

System.out.println("\tTotal .... " + total + " pts.");

System.out.println("\t " + (total/kCambio) + " euros");

Linea.java:

public class Linea {

String mArticulo;

double mPrecio;
SERVICIO NACIONAL DE APRENDIZAJE SENA
Formato para Desarrollo de Evidencia

public Linea(String a, double p) {

mArticulo=a;

mPrecio=p;

public void show() {

System.out.println("\t" + mArticulo + " ..... " + mPrecio + " pts");

Casos de prueba pruebas integrales

Pruebas integrales o pruebas de integración son aquellas que se realizan en el ámbito


del desarrollo de software una vez que se han aprobado las pruebas unitarias y lo que
prueban es que todos los elementos unitarios que componen el software, funcionan
juntos correctamente probándolos en grupo. Se centra principalmente en probar la
comunicación entre los componentes y sus comunicaciones ya sea hardware o
software.

La prueba de subsistemas es un tipo de prueba de integración donde se prueba el


contenido de un subsistema

El desarrollo de software hoy en día está caracterizado por múltiples equipos de


proyectos y mantenimientos trabajando de forma simultánea, bajo cronogramas cada
vez más exigentes y desarrollando sistemas que interoperan con variedad de otras
aplicaciones y plataformas. Bajo un escenario como este, la gestión de los ambientes
(entornos) de pruebas integrales (System Integration Tests, o SIT), adquiere gran
importancia para asegurar que el Software sea puesto en producción con los niveles
necesarios de calidad.

En este artículo se exploran una serie de buenas prácticas en la administración de


ambientes de prueba integrales de sistema (SIT). Abarcan la definición de
SERVICIO NACIONAL DE APRENDIZAJE SENA
Formato para Desarrollo de Evidencia

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.

En esta sección se detallan los Casos de prueba y procedimientos de prueba para


verificar la integración de Subsistemas, de acuerdo al Plan de Verificación de la
Iteración. Incluye la verificación de requerimientos funcionales y no funcionales de
cada subsistema y las pruebas de interacción entre el subsistema y otros elementos
del sistema

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

Iván Fdo, Pinto R.


Aprendiz
Cali .-Valle

También podría gustarte