Actividad de pruebas de codificación
Basado en presentación de :
ANGULO SORIA KARINA
AREBALO SANDOVAL ELIZABETH.
JALDIN MONTAÑO DEICY.
VARGAS VELÁSQUEZ FRANCISCO W.
Introducción:
El objetivo de la prueba de software (tanto del código como de la
especificación) es demostrar la presencia de errores (con el fin de
conseguir su eliminación posterior) pero que no permiten
demostrar su ausencia
Una prueba en concreto consiste en someter al producto de
software (o a una parte del mismo) a una evaluación para conocer
si se comporta de acuerdo con una especificación tomada como
referencia.
Proceso de pruebas
En general la fase de planificación de cualquier
etapa de prueba requiere las siguientes
actividades:
1. Designación del responsable de la etapa.
2. Identificación de los participantes en la etapa y sus roles.
3. Identificación y planificación de los recursos requeridos.
4. Estimación del tiempo y esfuerzo requerido.
5. Documentación del alcance de las pruebas.
6. Documentación de la filosofía de diseño de los casos de
prueba.
7. Generación disciplinada y sistemática de casos de prueba,
según la filosofía adoptada.
8. Documentación de los casos de prueba. Para cada caso de
prueba la documentación debe incluir:
(a) Justificación de su inclusión.
(b) Datos de entrada e indicaciones de cómo correr el caso.
(c) Configuración requerida para la prueba.
(d) Resultados esperados.
(e) (En ejecución se agrega) Resultados obtenidos.
(f) (En ejecución se agrega) Tipo de defecto hallado. Esto puede
constar de una indicación de superada o cómo mínimo una
indicación de la severidad de la falla (falla grave, seria o menor),
una descripción de la falla y una identificación tentativa de la etapa
del desarrollo a que se atribuye (Análisis, Diseño, Codificación, etc).
9. Criterio de culminación de las pruebas
El proceso de prueba de un software
orientado por objetos
Consta de las siguientes etapas
1.Inspección del análisis (verifica si se cometieron errores o
falla en la etapa de análisis).
2. Inspección del diseño (debe ser completo y eficiente).
3. Inspección del código (observar el entendimiento y
facilidad del código).
4. Pruebas unitarias (probar cada método de las clases
implementadas por separado).
5. Pruebas de integración (probar todas las clases, verificando
que compaginen entre sí).
6. Pruebas de validación de requerimientos (verificar que
cumple con todos los requerimientos exigidos por el cliente).
7. Pruebas de sistema (ejecutar el programa para verificar si
cumple con los requisitos exigidos).
A) Una descripción de la prueba.
La descripción debe indicar el propósito de la prueba
(para qué se hace), el componente de software sobre
el que se realiza (podría ser un módulo, subsistema o
el sistema completo), los datos de prueba que se van
a entregar y los resultados esperados.
B) Una ejecución de la prueba.
Si se dispone de una descripción ejecutable del sistema
(por ejemplo, código) la ejecución de la prueba implica la ejecución
de ese módulo en un entorno controlado. Posiblemente, ni el sistema
final ni el resto del producto están disponibles y deberán ser
simulados. Esta situación obliga a disponer de un entorno específico
(conjunto de herramientas que simulen a efectos de la validación el
entorno de ejecución del producto de software) para la ejecución de
las pruebas.
C) Una valoración de los resultados obtenidos.
Una vez obtenidos los resultados de la prueba, éstos deben
compararse con otros considerados como referencia.
En muchos casos, esta referencia es una especificación a partir de la
cual se ha generado el programa.
En otros casos son heurísticos que los diseñadores han
seleccionado.
Intuitivamente, podemos decir que cuantas más pruebas se realicen
mayor será nuestra confianza en el producto. Cada prueba debe
cubrir un aspecto concreto y una secuencia de pruebas nos da la
cobertura del producto conseguida
Desde el punto de vista técnico, las pruebas se enmarcan en la
revisión del diseño y del código.
Los métodos más conocidos son los siguientes:
A) Inspección de código. Procedimiento para la revisión por un
equipo humano de la implementación de un producto software.
Así la técnica de sala limpia («clean room») ha demostrado
su utilidad en forma de una reducción significativa de
defectos finales.
B) Paseos por el código («walk-throughs»). Proceso menos formal
que el anterior en el que participan usuarios y desarrolladores con el
objetivo de descubrir y resolver omisiones e incomprensiones de lo
que hace una parte del código.
C) Revisiones personales.
Recupera la «vieja» práctica de releer cuidadosamente el
código antes de compilar.
Cuando se dice que un proceso de pruebas ha sido
exitoso?
Decimos que un caso de prueba es exitoso cuando logra poner
en evidencia defectos. Esto pone en manifiesto un hecho
importante acerca de la prueba:
“La prueba de programas demuestra la presencia y no la
ausencia de errores”.
Verificación y Validación
V&V: Procesos de comprobación y análisis para tratar de
asegurar que el software esté acorde con su especificación
y cumpla las necesidades de los
Clientes
Un sistema de software debe ser sujeto a V&V en cada
una de las etapas de su desarrollo. Por lo tanto, la V&V
comienza con las revisiones de los requerimientos,
y continua a través de las revisiones del diseño y del
código hasta la prueba (o testing) del producto.
Verificación
• conjunto de actividades que aseguran que el software
cumple su especificación (hace lo que se supone que tiene
que hacer).
¿estamos construyendo el producto correctamente?
Validación
• conjunto (diferente) de actividades que aseguran que el
software construido se corresponde con los requisitos del
cliente.
¿estamos construyendo el producto correcto?
Ejemplo de Verificación y Validación
VyV de un programa que permite gestionar los alumnos
matriculados en los cursos de una academia
Verificación:
• ¿las operaciones de gestión de las listas de alumnos funcionan
correctamente?
• ¿las operaciones de gestión de cursos funcionan
correctamente?
Validación:
• ¿El programa proporciona todas las operaciones que el usuario
necesita?
• ¿Las operaciones hacen lo que el usuario espera?
• ¿La interfaz con el usuario es la apropiada?
Para satisfacer los objetivos de V&V, existen técnicas de
control estáticas y dinámicas que pueden ser aplicadas.
* Las técnicas Estáticas tienen que ver con el análisis y
control de las representaciones del sistema, es decir de
los diferentes modelos construidos durante el proceso
de desarrollo de software tales como documentos de
requerimientos, diagramas de análisis, diseño, y código
fuente.
* Las técnicas dinámicas, también conocidas como
testing (o prueba en español) se basan en ejercitar una
implementación.
La figura muestra donde se aplican las técnicas
dinámicas y estáticas durante el proceso de desarrollo
de software. Las dinámicas, sin embargo, solo pueden
ser usadas cuando disponemos de un prototipo o una
versión ejecutable del producto
Prueba de métodos
Principales mecanismos para la prueba de métodos:
• Pruebas funcionales o de “caja negra”
- El método de la caja negra se centra en los requisitos
fundamentales del software y permite obtener entradas que
prueben todos los requerimientos del programa. Con este equipo
de pruebas se intenta encontrar:
· Funciones incorrectas o ausentes.
· Errores de interfaz.
· Errores en estructuras de datos o en accesos a la bases de datos
externas
· Errores de rendimiento.
• Pruebas estructurales o
de “caja blanca” o
“caja de cristal”
Principia con la observación de que un programa difícilmente puede
considerarse como probado por completo si su código contiene partes que
nunca han sido ejecutadas. Este método analiza la estructura lógica del
programa y, para cada alternativa que puede presentarse, los datos de prueba
ideados conducirán a ella. Se procura escoger los que verifiquen cada
posibilidad en las proposiciones case, las cláusulas de cada proposición if y la
condición de terminación de cada ciclo.
En un programa extenso, este método es impráctico, pero en un modulo
pequeño constituye un excelente medio de prueba y depuración.
En el contexto del software, la prueba de caja blanca,
también conocida como prueba de caja de cristal o
prueba estructural, a diferencia de la prueba funcional o
de caja negra, se basa en lo que el programa hace y no
en lo que debería hacer, ya que para derivar sus casos
de prueba se concentra en el análisis del código del
programa y no en sus requerimientos como lo hace la
prueba de caja negra.
Ambos enfoques no se contraponen sino que más bien
se complementan para construir un buen conjunto de
casos de prueba.
RELACION DE CONCEPTOS
EL ÉXITO EN ESTAS ACTIVIDADES ES ENCONTRAR
LOS ERRORES
Manual de Usuario
y
Manual Técnico
PDSW
DEFINICION
ACT.
ANALISIS
1
DESARROLLO
PLANIFICACION
2
DOC. REQUE.
ACT.
DISEÑO
DOC. DISEÑO
EXPLICA
1
2
3
MANTENIMIENTO
CODIFICA
R
CODIGO
PRUEBAS
3
MANUAL DE
USUARIO
MAPEO
MANUAL
TECNICO
¿QUÉ ES EL MANUAL DE USUARIO?
El manual de usuario expone los procesos que el usuario
puede realizar con el sistema implantado. Reúne la
información, normas y documentación necesaria para que el
usuario conozca y utilice adecuadamente la aplicación
desarrollada.
Objetivos:
Que el usuario conozca cómo preparar los datos de entrada.
Que el usuario aprenda a obtener los resultados y los datos de
salida.
Servir como manual de aprendizaje.
Servir como manual de referencia.
Definir las funciones que debe realizar el usuario.
Informar al usuario de la respuesta a cada mensaje de error.
Contenido.
Diagrama general del sistema
Diagrama particular detallado
Explicación Genérica De Las Fases Del Sistema
Instalación Del Sistema
Iniciación Al Uso Del Sistema
Manual De Referencia
Contenido Mínimo
1.Introducción.
2.Descripción del sistema.
3.Instalación del sistema.
4.Guía de utilización.
5.Índice de referencia.
6.Índice de Comandos.
Contenido Máximo
1.Introducción.
2.Descripción del sistema.
3.Descripción del entorno.
4.Instalación del sistema.
5.Guía de utilización.
6.Mensajes de error.
7.Ejemplos.
8.Índice de referencia.
9.Índice de comandos.
10.Anexos.
Ojo:
Debe redactarse de
forma clara y sencilla
para que lo entienda
cualquier tipo de
usuario.
¿QUÉ ES UN MANUAL TÉCNICO?
En la guía técnica o manual técnico se reflejan el diseño
del proyecto, la codificación de la aplicación y las pruebas
realizadas para su correcto funcionamiento.
Objetivos:
El principal objetivo es el de facilitar el desarrollo,
corrección y futuro mantenimiento de la aplicación de una
forma rápida y fácil
Este manual esta compuesta por tres apartados:
Cuaderno de carga
Programa fuente
Doc. Requerimientos
Pruebas
Doc. Diseño
Código (Fuente, Objeto)
Estructura del documento Manual Técnico
1-Índice.
2-Introducción.
2.1-Objetivo general del sistema
2.2-Objetivos específicos
3-Contenido técnico.
Contenido Mínimo
1.Introducción.
2.Índice.
3.Descripción.
4.Herramientas.
5.Diccionario de datos.
6.Codificación.
“La risa es el sol que ahuyenta el
invierno del rostro humano”
Descargar

Diapositiva 1