domingo, 8 de febrero de 2015

Pruebas de integración y de sistema

Pruebas de Sistema

Objetivo de la Prueba:  

Asegurar la apropiada navegación dentro del sistema, ingreso de datos, procesamiento y recuperación.

Descripción de la Prueba:            

Las pruebas del sistema deben enfocarse en requisitos que puedan ser tomados directamente de casos de uso y reglas y funciones de negocios. El objetivo de estas pruebas es verificar el ingreso, procesamiento y recuperación apropiado de datos, y la implementación apropiada de las reglas de negocios. Este tipo de pruebas se basan en técnicas de caja negra, ésto es, verificar el sistema (y sus procesos internos), la interacción con las aplicaciones que lo usan vía GUI y analizar las salidas o resultados.En esta prueba se determina qué pruebas de Sistema (usabilidad, volumen, desempeño, etc.) asegurarán que la aplicación alcanzará sus objetivos de negocio.
La prueba de Sistema incluye:
  • Prueba funcionalidad
  • Prueba de Usabilidad
  • Prueba de Performance
  • Prueba de Documentación y Procedimientos
  • Prueba de Seguridad y Controles
  • Prueba de Volumen
  • Prueba de Esfuerzo
  • Prueba de recuperación
  • Prueba de múltiples sitios

La prueba de sistema es compleja porque intenta validar un número de características al mismo tiempo, a diferencia de otras pruebas que sólo se centran en uno o dos aspectos del sistema al mismo tiempo.

Técnica:   

Ejecute cada caso de uso, flujo básico o función utilizando datos válidos e inválidos, para verificar que:
  • Los resultados esperados ocurren cuando se utiliza un dato válido.
  • Los mensajes de error o de advertencia aparecen en el momento adecuado, cuando se utiliza un dato inválido.
  • Cada regla de negocios es aplicada adecuadamente.


Criterio de Completitud:     

  • Todas las pruebas planeadas han sido ejecutadas.
  • Todos los defectos que se identificaron han sido tenidos en cuenta.


Prueba de Integración

Objetivo de la Prueba:

  • Identificar errores introducidos por la combinación de programas probados unitariamente.
  • Determina cómo la base de datos de prueba será cargada.
  • Verificar que las interfaces entre las entidades externas (usuarios) y las aplicaciones funcionan correctamente.
  • Verificar que las especificaciones de diseño sean alcanzadas.
  • Determina el enfoque para avanzar desde un nivel de integración de las componentes al siguiente.

Descripción de la Prueba:            

  • Describe cómo verificar que las interfaces entre las componentes de software funcionan correctamente.
  • Determina cómo la base de datos de prueba será cargada.
  • Determina el enfoque para avanzar desde un nivel de integración de las componentes al siguiente.
  • Decide qué acciones tomar cuando se descubren problemas.

Por cada Caso de Prueba ejecutado:

  • Comparar el resultado esperado con el resultado obtenido.

Técnica:

  • Utilizar la técnica top-down. Se empieza con los módulos de nivel superior, y se verifica que los módulos de nivel superior llaman a los de nivel inferior de manera correcta, con los parámetros correctos.
  • Utilizar la técnica down-top. Se empieza con los módulos de nivel inferior, y se verifica que los módulos de nivel inferior llaman a los de nivel superior de manera correcta, con los parámetros correctos.

Criterio de Completitud:  

  • Todas las pruebas planeadas han sido ejecutadas.
  •  Todos los defectos que se identificaron han sido tenidos en cuenta.

jueves, 15 de enero de 2015

Tarea - Tipos de prueba


Introducción 

Conocer los tipos de prueba es algo de suma importancia para cualquier programador, ya que de esta manera podemos optimizar nuestro programa, prever malos funcionamientos y prevenir errores. Realizar las pruebas de manera adecuada representa una tarea fundamental en el momento del desarrollo de cualquier software.


Pruebas de Caja Blanca


La prueba de la caja blanca es un método de diseño de casos de prueba que usa la estructura de control del diseño procedimental para derivar los casos de prueba.
Las pruebas de caja blanca intentan garantizar que:
  • Se ejecutan al menos una vez todos los caminos independientes de cada módulo
  • Se utilizan las decisiones en su parte verdadera y en su parte falsa
  • Se ejecuten todos los bucles en sus límites
  • Se utilizan todas las estructuras de datos internas

Pruebas de Caja Negra

Las pruebas de caja negra se llevan a cabo sobre la interfaz del software, obviando el comportamiento interno y la estructura del programa.
Los casos de prueba de la caja negra pretenden demostrar que:
  • Las funciones del software son operativas
  • La entrada se acepta de forma correcta
  • Se produce una salida correcta
  • La integridad de la información externa se mantiene
Las pruebas de caja negra pretenden encontrar estos tipos de errores:
  • Funciones incorrectas o ausentes
  • Errores en la interfaz
  • Errores en estructuras de datos o en accesos a bases de datos externas
  • Errores de rendimiento
  • Errores de inicialización y de terminación
  • Los tipos de prueba de cana negra que vamos a estudiar son:
  • Prueba de partición equivalente
  • Prueba de análisis de valores límites

Prueba del camino básico


El método del camino básico (propuesto por McCabe) permite obtener una medida de la complejidad de un diseño procedimental, y utilizar esta medida como guía para la definición de una serie de caminos básicos de ejecución, diseñando casos de prueba que garanticen que cada camino se ejecuta al menos una vez.

Prueba de bucles

Los bucles son la piedra angular de la inmensa mayoría de los algoritmos implementados en software, por lo que tenemos que prestarles una atención especial a la hora de realizar la prueba del software.
La prueba de bucles es una técnica de prueba de caja blanca que se centra en la validez de las construcciones de los bucles.
      Se pueden definir cuatro tipos de bucles diferentes:
  • Bucles simples
  • Bucles concatenados
  • Bucles anidados
  • Bucles no estructurados

Conclusión

A pesar de no ser todos los tipos de prueba, los presentados en este trabajo nos ayudarán a realizar pruebas eficientes a nuestro software, para así garantizar su optimo rendimiento.

domingo, 31 de agosto de 2014

Calidad

Introducción

Conocer el significado de “calidad” y su respectiva aplicación en el software representa un asunto de vital importancia para cualquier desarrollador. La calidad conlleva una serie de aspectos que deben de ser revisados, bajo distintos  estándares, que garantizan que el software desarrollado es lo suficientemente bueno como para poder ganar una certificación.

¿Qué es calidad?

Es un conjunto de propiedades que una cosa posee y por medio de las cuales es posible caracterizarla y compararla con otras cosas similares, ya sea para bien o para mal de ésta. En el software se aplica la misma definición.

Modelos de calidad


·         Calidad del producto
·         Calidad del proceso
Ø  Se busca analizar las cualidades del proceso que más influyen en la calidad del producto.
Ø  Se modela el proceso para analizarlo mejor.
·         Calidad de uso

ISO 9126

Es un estándar internacional para la evaluación del software, originalmente desarrollado en 1991 para proporcionar un esquema de evaluación de la calidad del software.
La normativa define seis características de la aplicación, las cuales a su vez están divididas en un número de sub-características que representan un modelo detallado para la evaluación de cualquier sistema informático.

Funcionalidad

Capacidad del software de proveer los servicios necesarios para cumplir con los requisitos funcionales.

Confiabilidad

Capacidad del software de mantener las prestaciones requeridas del sistema, durante un tiempo establecido y bajo un conjunto de condiciones definidas.

Usabilidad

Esfuerzo requerido por el usuario para utilizar el producto satisfactoriamente.

Eficiencia

Relación entre las prestaciones del software y los requisitos necesarios para su utilización.

Mantenibilidad

Esfuerzo necesario para adaptarse a las nuevas especificaciones y requisitos del software.

Portabilidad

Capacidad del software ser transferido de un entorno a otro.

Conclusión

Antes, durante y después del desarrollo de un software, se debe de prestar atención a los aspectos que las distintas normativas y estándares evalúan en éste, para poder estar preparados para recibir una certificación, y no solo eso, sino para estar seguros de que nuestro software es competente y merece un lugar en el mercado.

Bibliografía

Desconocido. (1 de 09 de 2011). smartsys. Recuperado el 31 de 09 de 2014, de Norma ISO-9126 para análisis de software: http://bemuserp.blogspot.mx/2011/09/norma-iso-9126-para-analisis-de.html


domingo, 24 de agosto de 2014

Definiciones. Primer tarea


Introducción

Antes de que un determinado software sea distribuido de manera oficial, debe de pasar por una serie de pruebas que garanticen que tiene un funcionamiento óptimo, corrigiendo en la medida de lo posible, los distintos errores que pudiesen generarse.

Ingeniería de pruebas

La ingeniería de pruebas en el software consiste en revisar y probar un proyecto, desde la especificación de los requerimientos, hasta el código fuente y el desempeño del mismo, con el objetivo de encontrar errores para después notificar de estos a los responsables del proyecto.
“…En cuanto al objetivo de las pruebas, en la definición de Kaner no se reduce exclusivamente a detectar fallos sino que se amplia a ofrecer información, datos, relacionados con la calidad de lo que se está probando…” (Fanjul, 2011)

Ciclo de vida de un software

El ciclo de vida de un software se refiere a una serie de fases en el desarrollo de un software. En cada una de las fases existe una revisión con el objetivo de evitar que los posibles errores existentes se acumulen, para que de esta manera, en la última fase, la de implementación, la cantidad de errores sea mínima, y así evitar gastos mayores corrigiéndolos a esas alturas.

Prueba

Una prueba es un análisis o examen de un proyecto, que se realiza con el objetivo de rectificar que éste cumpla con sus especificaciones, y para  garantizar que tiene la menor cantidad de errores posible.

Tipos de prueba

Pruebas Unitarias


Consisten en probar de manera individual cada método o función de un proyecto, revisando únicamente la lógica existente en su código.


Pruebas de Aceptación de Usuario


Sirven para mostrarle al usuario (ajeno al desarrollo del software) el progreso que se ha tenido en el proyecto.

Pruebas Funcionales


Similares a la pruebas de aceptación, con la diferencia de que no van dirigidas a un público no especializado. Consisten en revisar el funcionamiento del software y verificar que cumpla con sus requerimientos funcionales. Deben de hacerse bajo un amiente controlado.

Pruebas de Integración


Se asemejan a las pruebas funcionales, con la diferencia de que se utilizan datos reales y no datos de prueba, con el fin de garantizar que el software ha sido implementado correctamente.

Pruebas No Funcionales


Se utilizan para verificar que un software cumpla con sus requerimientos no funcionales.

Pruebas de Stress

Su objetivo es garantizar que la aplicación puede recibir muchas peticiones sin que su rendimiento se vea afectado.

Pruebas de Calidad de Código


Este tipo de pruebas sirven para garantizar que la calidad del código es realmente óptima y que la probabilidad de tener errores o bugs en la codificación es mínima (nunca dejarán de existir los bugs pero al menos podemos hacer lo pertinente para disminuir la probabilidad).

Conclusión

Conocer el ciclo de vida del software, y realizar las pruebas correspondientes a cada etapa (conociendo a que tipo de pruebas pertenece cada una) es un asunto de vital importancia para nosotros como futuros desarrolladores. Contar con estos conocimientos nos permite evaluar de manera progresiva la calidad de nuestros programas y aplicaciones, y poder estar seguros de que su funcionamiento es óptimo antes de dar por finalizado un proyecto.

Bibliografía

Definición de. (s.f.). Definición de prueba. Recuperado el 24 de 08 de 2014, de Definición de: http://definicion.de/prueba/
emontoya. (11 de 05 de 2012). Tipo de Pruebas para Desarrollo de Software. Recuperado el 24 de 08 de 2014, de JavaMéxico: http://www.javamexico.org/blogs/emontoya/tipo_de_pruebas_para_desarrollo_de_software
Fanjul, J. G. (15 de 06 de 2011). ¿Qué es probar software? Recuperado el 24 de 08 de 2014, de Isof. Ingeniería y Software: http://isof.wordpress.com/2011/06/15/%C2%BFque-es-probar-software/
Kioskea.net. (07 de 2014). Ciclo de vida del software. Recuperado el 24 de 08 de 2014, de Kioskea: http://es.kioskea.net/contents/223-ciclo-de-vida-del-software



miércoles, 9 de abril de 2014

Diccionario de datos



Introducción
Cuando se hace una base de datos, puede suceder que lleguemos a confundirnos con los atributos declarados, es decir, que no sepamos que contiene exactamente cada atributo.
Para esto se crea un diccionario de datos, para saber mejor que información se colocará dentro de cada campo.

Ejercicio1


Ejercicio2

 

Ejercicio3

 

Ejercicio4

 

Ejercicio5

 

Ejercicio6

 

Ejercicio7

 

Ejercicio8

 

Ejercicio9

 

Ejercicio10   





Conclusiones
El diccionario de datos nos ayuda a tener una mejor organizacion para no cometer errores al momento de leer nuestras tablas, y en general, nuestra base de datos, facilitando el manejo y optimizando los tiempos de trabajo.
 

miércoles, 2 de abril de 2014

Ejercicios - Bases de datos en MySQL

Introducción

Cuando se realiza el modelado de una base de datos, suelen cometerse algunos errores como caer en la redundancia de información. Estos errores perjudican a futuro la base de datos, pues si ésta no se planifica correctamente, ocurrirán problemas cuando se intente eliminar una tupla, pues se puede eliminar información adicional. Es por eso que una vez que se tiene el modelo relacional, se debe de seguir el proceso de normalización.



EJERCICIO2

EJERCICIO3



EJERCICIO4


EJERCICIO5

EJERCICIO6


EJERCICIO7


EJERCICIO8


EJERCICIO9


EJERCICIO10




Conclusión

La normalización de las relaciones que se dan en una base de datos permite optimizar éstas, eliminando redundancias y otros problemas que pueden ser perjudiciales en determinado momento. Una vez que el modelado de la base de datos se encuentra normalizado, dicha base puede comenzar a ser creada.

Bibliografía

Hispano, M. (29 de 05 de 2003). Recuperado el 23 de 03 de 2014, de http://www.eet2mdp.edu.ar/alumnos/MATERIAL/MATERIAL/info/infonorma.pdf
Marabini, R. (s.f.). Recuperado el 23 de 03 de 2014, de http://biocomp.cnb.csic.es/~roberto/II/Docencia/SI1/Clase/Reserved/Formas_Normales.pdf
Mora, E. (s.f.). Universidad de Cantabria. Recuperado el 23 de 03 de 2014, de http://personales.unican.es/zorrillm/PDFs/Docencia/BasesDatos/Formas%20Normales.pdf