• Author / Uploaded
• Pedro Martin

Citation preview

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. 2. 3. 4.

Establecer alcances, entregables y criterios de éxito Estimar el esfuerzo de prueba Planear el proyecto 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 nofuncionales 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 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