Check out Songsterr guitar tabs website and iOS app

Check out Songsterr guitar tabs website and iOS app

Pruebas de Sistema e Integración

Pruebas de Sistema e Integración 

Introducción 

Con la siguiente investigación se pretende definir, entender e implementar  las pruebas de integración y de sistema para algún proyecto futuro para que de esta manera funcione de manera correcta y cumpla con todas las expectativas que tuvo el cliente.

Desarrollo

Pruebas de Integración: Este tipo de pruebas verifican que los componentes de la aplicación funcionan correctamente actuando en conjunto. Las pruebas de integración son dependientes del entorno en el que se ejecutan. Si fallan, puede ser porque el código esté bien, pero haya un cambio en el entorno. Estas pruebas pueden ayudarnos a detectar errores como:

• Problemas de configuración
• Procesos faltantes
• Uso incorrecto de archivos
• Violaciones de integridad de la base de datos
• Parámetros erróneos

Pruebas de sistema: Su objetivo es asegurar la perfecta navegación, ingreso, proceso y recuperación de datos e información.  

Estas son las principales pruebas de sistema:

• Prueba de Recuperación: 

Es una prueba que se hace al sistema forzando a que produzca   fallas de software de   muchas maneras y verificando que la   recuperación se lleve a cabo, ya sea automáticamente o   manual, tomando en cuenta los recursos que se requieran para   efectuar la recuperación .

• Prueba de Seguridad:  

Intenta verificar la aplicación de los mecanismos de protección   incorporados en el sistema. Durante la prueba el encargado   desempeña el papel de intruso tratando de violar la seguridad   del sistema, intentando obtener las claves de acceso por   cualquier medio externo; debe bloquear el sistema negando así   el servicio a otras personas a demás de producir errores a   propósito en el sistema o debe curiosear los datos públicos i  intentando encontrar una clave de acceso al sistema.

 

• Prueba de Resistencia:

Esta diseñada para enfrentar a los problemas en situaciones   anormales, es decir ejecutar el sistema en forma que demande   recursos en cantidad, frecuencia o volúmenes anormales. El   encargado de la prueba debe intentar tirar el sistema.

Para lograr la calidad se puede tomar en consideración lo   siguiente:

• Diseñar pruebas especiales que generen 10 o mas interrupciones por segundo.

• Incrementar la frecuencia de datos de entrada en un orden de magnitud con el fin de comprobar como responden las funciones de entrada.

• Ejecutar casos de prueba que requieran al máximo de memoria o de espacio en disco. Diseñar casos de prueba que produzcan excesivas búsquedas de datos almacenados en el disco.

Conclusión 

A partir de estas pequeñas definiciones de las pruebas de sistema e integración pude darme una idea de lo que se debe de hacer para realizar un buen plan de pruebas para que le proyecto que se este realizando tenga calidad y no fracase.

Fuentes

• http://www.uv.mx/personal/jfernandez/files/2010/07/Pruebas-de-Integracion.pdfhttp://www.javiergarzas.com/2014/07/tipos-de-pruebas-10-min.html
• https://sites.google.com/site/jojooa/analisis-de-sistemas/definicion-de-pruebas-de-sistemas-que-son-las-pruebas-de-sistemas

Diagrama de grafos

Diagrama de Grafos 

Introducción 

Un diagrama de flujo es una representación gráfica de un proceso. Cada paso del proceso es representado por un símbolo diferente que contiene una breve descripción de la etapa de proceso. Los símbolos gráficos del flujo del proceso están unidos entre sí con flechas que indican la dirección de flujo del proceso. 

En ciencias de la computación, un grafo de control de flujo es una representación, en forma de grafo dirigido, de todos los caminos que pueden ser atravesados ​​a través de un programa durante su ejecución. El segundo deriva del primero y serán utilizados en un futuro para diseñar casos de prueba. 

A continuación presentare un ejemplo de ambos diagramas

Desarrollo 

El diagrama de flujo es el siguiente:

Su diagrama de grafos es el siguiente:

Todos sus posibles caminos son:

1. Inicio-Fin
2. Inicio-P4-P5-Fin
3. Inicio-P4-P6-Fin
4. Inicio-P2-Fin
5. Inicio-P3-Fin
6. Inicio-P1-Fin
7. Inicio-P1-P2-Fin
8. Inicio-P1-P3-Fin

Conclusión

Como pudimos observar el hacer diagramas de flujo nos permite observar de una manera clara el proceso que se tendrá que realizar. el diagrama de grafo deriva de un diagrama de flujo y sirve para representar cada uno de los procesos y todos los posibles caminos por los que puede pasar un programa, además de ser muy importantes para diseñar los casos de prueba para nuestro software. 

Fuentes

• Instituto Tecnológico del ISTMO (2013). Teoría de Grafos. [ONLINE] Available at: http://es.slideshare.net/isaiastoledo7/teora-de-grafos-14694334. [Last Accessed 16 de enero del 2015].
• e.g. Microsoft Corporation (2012). Grafos Conceptuales . [ONLINE] Available at: http://revistas.udem.edu.co/index.php/ingenierias/article/view/238. [Last Accessed 16 de enero del 2015].

Pruebas de Caja Blanca y Caja Negra

Pruebas de Caja Blanca y Caja Negra 

Introducción

La prueba es un proceso de ejecución con la función de descubrir un error. Un caso de prueba es aquel que tiene una alta probabilidad de descubrir un error. Las pruebas no pueden ser usadas como demostración de la ausencia de errores. En el siguiente trabajo presentare dos de los tipos de prueba mas famosos y mas útiles: las pruebas de caja blanca y de caja negra.

Desarrollo 

Prueba de Caja Blanca: 

Son pruebas que se enfocan en los mecanismos internos de un sistema o componente, el 32% de los defectos corresponden a errores en la lógica de los componentes. 

Se requieren poder representar la ejecución de un programa, para ello se apoya de los grafos de flujo. Una vez que se tiene el diagrama, es posible diseñar casos de prueba para cada rama. 

A pesar de que este enfoque permite diseñar pruebas que cubran una amplia variedad de casos de prueba, podría pasar por alto partes incompletas de la especificación o requisitos faltantes, pese a garantizar la prueba exhaustiva de todos los flujos de ejecución del código analizado.

Las principales técnicas de diseño de pruebas de caja blanca son:

• Pruebas de flujo de control
• Pruebas de flujo de datos
• Pruebas de bifurcación (branch testing)
• Pruebas de caminos básicos

Prueba de Caja Negra: 

Estas pruebas permiten obtener un conjunto de condiciones de entrada que ejerciten completamente todos los requisitos funcionales de un programa. En ellas se ignora la estructura de control, concentrándose en los requisitos funcionales del sistema y ejercitándolos.

Las pruebas de caja negra no buscan reemplazar a las pruebas de caja blanca, sino que pretenden ser un enfoque complementario para encontrar errores diferentes a los de la primera prueba mencionada. Se considera que las pruebas de caja negra permiten encontrar errores como:

• Funciones incorrectas o ausentes.
• Errores de interfaz.
• Errores en estructuras de datos o en accesos a las Bases de Datos externas.
• Errores de rendimiento.
• Errores de inicialización y terminación.

Conclusión 

Como pudimos observar el implementar pruebas a nuestros proyectos nos permite optimizar las funciones que debe realizar para brindar a nuestro cliente la oportunidad de erradicar sus problemas laborales. Para ello debemos realizar dos tipos de pruebas principales las de caja blanca y las de caja negra, las primeras sirven para evaluar los componentes internos de nuestro sistema para detectar aproximadamente hasta un 32% de errores. Por su parte las de caja negra buscan complementar  a las primeras evaluando los datos de entrada con los datos de salida esperados, brindándonos algunos errores que no detectamos a primera vista. Por esto y muchas cosas más es bueno hacer pruebas.

Fuentes

• Globe Testing (2012). Pruebas de caja negra. [ONLINE] Available at: http://www.globetesting.com/2012/08/pruebas-de-caja-negra/. [Last Accessed 16 de enero del 2015].
• Roger S. (2013). Pruebas de caja negra. [ONLINE] Available at: http://www.ecured.cu/index.php/Pruebas_de_caja_negra. [Last Accessed 16 de enero del 2015].
• CBSE. (2003). Pruebas. 16 de enero 2015, de CBSE Sitio web: https://sistemas.uniandes.edu.co/~isis4713/dokuwiki/lib/exe/fetch.php?media=isis4713-pruebas3.pdf

Tarea 2

INTRODUCCIÓN

El siguiente trabajo pretende dejar en claro las dudas que pueden llegar a existir en el camino del aprendizaje hacía el estándar ISO 9216.

DESARROLLO 

ISO 9126 es un estándar internacional para la evaluación del Software, fue originalmente desarrollado en 1991 para proporcionar un esquema para la evaluación de calidad del software.

La normativa define seis características de la aplicación, estas seis características son dividas en un número de sub- características, las cuales representan un modelo detallado para la evaluación de cualquier sistema informático.

3.1.1  CARACTERÍSTICAS NORMA ISO 9126

El modelo establece diez características, seis que son comunes a las vistas interna y externa y cuatro que son propias de la vista en uso.

A continuación se describen las características y subcaracterísticas propias de este estándar que se encuentran dentro de las vistas interna y externa,  las cuales usaremos para evaluar el software de CMI.

Funcionalidad: capacidad del software de proveer los servicios necesarios para cumplir con los requisitos funcionales.

Subcaracterísticas:

Idoneidad.- Hace referencia a que si el software desempeña las tareas para las cuales fue desarrollado.
Exactitud.- Evalúa el resultado final que obtiene el software y si tiene consistencia a lo que se espera de él.
Interoperabilidad.- Consiste en revisar si el sistema puede interactuar con otro sistema independiente.
Seguridad.- Verifica si el sistema puede impedir el acceso a personal no autorizado.

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

Subcaracterísticas:

Madurez.- Se debe verificar las fallas del sistema y si muchas de estas han sido eliminadas durante el tiempo de pruebas o uso del sistema.
Recuperabilidad.- Verificar si  el software puede  reasumir el funcionamiento y restaurar  datos perdidos después de un fallo ocasional.
Tolerancia a fallos.- Evalua si la aplicación desarrollada es capaz de manejar errores.

Usabilidad: esfuerzo requerido por el usuario para utilizar el producto satisfactoriamente.

Subcaracterísticas:

Aprendizaje.- Determina que tan fácil es para el usuario aprender a utilizar el sistema.
Comprensión.- Evalúa que tan fácil es para el usuario comprender el funcionamiento del sistema
Operatividad.- Determina si el usuario puede utilizar el sistema sin mucho esfuerzo.
Atractividad.- Verifica que tan atractiva se ve la interfaz de la aplicación.

Eficiencia: relación entre las prestaciones del software y los requisitos necesarios para su utilización.

Subcaracterísticas:

Comportamiento en el tiempo.- Verifica la rapidez en que  responde el sistema
Comportamiento de recursos.- Determina si el  sistema utiliza los recursos de manera eficiente

Mantenibilidad: esfuerzo necesario para adaptarse a las nuevas especificaciones y requisitos del software.

Subcaracterísticas:

Estabilidad.- Verifica si el sistema puede mantener su funcionamiento a pesar de realizar cambios.
Facilidad de análisis.- Determina si la estructura de desarrollo es funcional con el objetivo de diagnosticar fácilmente las fallas.
Facilidad de cambio.- Verifica si el sistema puede ser fácilmente modificado
Facilidad de pruebas.- .- Evalúa si el sistema puede ser probado fácilmente

Portabilidad: capacidad del software ser transferido de un entorno a otro.

Subcaracterísticas:

Capacidad de instalación.- Verifica si el software se puede instalar fácilmente
Capacidad de reemplazamiento.- Determina la facilidad con la que el software puede remplazar otro software similar.
Adaptabilidad.- El software se puede trasladar a otros ambientes
Co-Existencia.- El software puede funcionar con otros sistemas

Cada una de las características debe ser evaluada dentro del software basándonos en  pruebas de funcionamiento, medición de rendimiento y pruebas con usuarios que harán uso del sistema.

CONCLUSIÓN

Tarea 1

Tarea 1

Introducción 

En el siguiente trabajo daré una breve explicación sobre los conceptos fundamentales que dan vida a la ingeniería de pruebas como los son: prueba,  ingeniería de prueba, ciclo de vida del software y los tipos de prueba del software. Con el fin de obtener una idea clara de su funcionamiento, y así en un futuro poder utilizar este conocimiento en futuros proyectos para su impecable realización. 

Desarrollo

Prueba: Es la acción de experimentar, probar o realizar un breve estudio sobre las cualidades de un objeto cualquiera de nuestro interés, con el fin de obtener información que nos pueda brindar un panorama más amplio sobre su comportamiento y poder sacar provecho de ello. 

Ingeniería de pruebas: Permite al encargado (s) de diseñar el programa , realizar su tarea de construcción de software como un problema de ingeniería haciendo uso de guías, principios y normas que le permitirán el correcto desarrollo de su labor. Además, dispondrá de un conjunto de herramientas que le permitirán la evaluación, validación, depuración y corrección del software desarrollado.

Ciclo de vida del software: Esta es una importante metodología que nos permite realizar con eficacia, calidad, precisión y rapidez un software, puesto que evita que el trabajo se disperse a donde cada persona quiere, manteniendo así un camino firme hacia el mismo objetivo: un software de calidad,  evitando al mismo tiempo perdidas económicas y estatus, y aumentado la productividad de la empresa o institución que lo utilice. 

A continuación describiré los procedimientos básicos que se tienen que realizar en el ciclo de vida del software:

• Definición de objetivos: definir el resultado del proyecto, la estrategia que se empleará para realizarlo y su alcance.
• Análisis de los requisitos y su viabilidad: recopilar, examinar y formular los requisitos del cliente y examinar cualquier restricción que se pueda aplicar.
• Diseño general: requisitos generales de la arquitectura de la aplicación.
• Diseño en detalle: definición precisa de cada subconjunto de la aplicación.
• Programación (programación e implementación): es la implementación de un lenguaje de programación para crear las funciones definidas durante la etapa de diseño.
• Prueba de unidad: prueba individual de cada subconjunto de la aplicación para garantizar que se implementaron de acuerdo con las especificaciones.
• Integración: para garantizar que los diferentes módulos se integren con la aplicación. Éste es el propósito de la prueba de integración que está cuidadosamente documentada.
• Prueba beta: para garantizar que el software cumple con las especificaciones originales.
• Documentación: sirve para documentar información necesaria para los usuarios del software y para desarrollos futuros.
• Implementación
• Mantenimiento: para todos los procedimientos correctivos (mantenimiento correctivo) y las actualizaciones secundarias del software (mantenimiento continuo).

Tipos de prueba del software:

Las pruebas en conjunto tienen como objetivo general verificar y validar un software, independientemente de las características y el entorno donde se desarrollen, además de los recursos y los factores vinculados al proceso de desarrollo. 

Funcionalidad

1. Función: Pruebas fijando su atención en la validación de las funciones, métodos, servicios, caso de uso.
2. Seguridad: Asegurar que los datos o el sistema solamente es accedido por los actores deseados.
3. Volumen: Enfocada en verificando las habilidades de los programas para manejar grandes cantidades de datos, tanto como entrada, salida o residente en la BD.

Usabilidad

Prueba enfocada a factores humanos, estéticos, consistencia en la interfaz de usuario, ayuda sensitiva al contexto y en línea, asistente documentación de usuarios y materiales de entrenamiento.

Fiabilidad

1. Integridad: Enfocada a la valoración exhaustiva de la robustez (resistencia a fallos).
2. Estructura: Enfocada a la valoración a la adherencia a su diseño y formación. Este tipo de prueba es hecho a las aplicaciones Web asegurando que todos los enlaces están conectados, el contenido deseado es mostrado y no hay contenido huérfano.
3. Stress: Enfocada a evaluar cómo el sistema responde bajo condiciones anormales. (extrema sobrecarga, insuficiente memoria, servicios y hardware no disponible, recursos compartidos no disponible).

Rendimiento

1. Benchmark: Es un tipo de prueba que compara el rendimiento de un elemento nuevo o desconocido a uno de carga de trabajo de referencia conocido.
2. Contención: Enfocada a la validación de las habilidades del elemento a probar para manejar aceptablemente la demanda de múltiples actores sobre un mismo recurso (registro de recursos, memoria).
3. Carga: Usada para validar y valorar la aceptabilidad de los límites operacionales de un sistema bajo carga de trabajo variable, mientras el sistema bajo prueba permanece constante. La variación en carga es simular la carga de trabajo promedio y con picos que ocurre dentro de tolerancias operacionales normales.

Soportabilidad

1. Configuración: Enfocada a asegurar que funciona en diferentes configuraciones de hardware y software. Esta prueba es implementada también como prueba de rendimiento del sistema.
2. Instalación: Enfocada a asegurar la instalación en diferentes configuraciones de hardware y software bajo diferentes condiciones (insuficiente espacio en disco, etc.)

Conclusión 

Como pudimos darnos cuenta la ingeniería de pruebas es vital para que nuestro software cumpla con todos los requisitos/objetivos que se definieron para poder entregar a nuestro un cliente un trabajo que le ayude a mejorar u optimizar su forma de trabajo. 


Biografía 

• kioskea. (2012). Ciclo de vida del software. 24 de agosto del 2014, de CCM Benchmark group Sitio web: http://es.kioskea.net/contents/223-ciclo-de-vida-del-software
• Ecured. (2013). Pruebas de calidad de software. 22 de agosto del 2014, de Ecured Sitio web: http://www.ecured.cu/index.php/Pruebas_de_Calidad_de_Software
• Java. (2012). Tipos de prueba para el desarrollo del software . 22 de agosto del 2014, de JavaMéxico Sitio web: http://www.javamexico.org/blogs/emontoya/tipo_de_pruebas_para_desarrollo_de_software
• ¿?. (2013). Ciclo de vida del software. 24 de agosto del 2014, de usrs.code Sitio web: http://img.redusers.com/imagenes/libros/lpcu097/capitulogratis.pdf
• Definición.de. (2008). Definición de prueba. 24 de agosto del 2014, de Definicion.de. Sitio web: http://definicion.de/prueba/