El metodo híbrido para pruebas de software

{de donde saqué esta información no encontré el autor. Lo que se decir es que no es mío}
MÉTODO HÍBRIDO


Es el método de prueba más completo que se le puede aplicar a un software, ya que consiste en aplicar los siguientes métodos:


Ø Método de Caja Negra (Análisis de Fronteras): se estudian las salidas del sistema ante diferentes entradas.

Ø Método de Caja Blanca (Cobertura Ciclomática de Caminos): al observar el diagrama y aplicar las ecuaciones sacadas del teorema de Grafos, se obtiene la ecuación NC = E À+2, siendo NC la complejidad del grafo, E los lados y N los nodos.

Ø Pruebas de Malicia: la prueba de malicia consiste en ejecutar casos que no estén contemplados en el diseño. Los datos son valiosos para el desarrollo de software.

AUTÓMATA DE ESTADOS


Los Autómata de Estados reducen significativamente los nodos de un diagrama dinámico, simplificando la lectura y entendimiento del diseño, así se podrá facilitar la detención de los puntos débiles del programa. Los pasos para convertir un diagrama dinámico en un Autómata de Estados son los siguientes:


1) Expandir recursivamente autómatas anidados.

2) Explicitar transiciones implícitas.

3) Eliminar o absorber transiciones .

4) Crear estados iniciales y finales.

5) Se debe probarlas condiciones de los eventos condicionales.

6) Especificar intervalos.

DESARROLLO DE SISTEMAS


Estrategias de Pruebas del Software


Una prueba es un conjunto de actividades que se pueden planificar por adelantado y llevar a cabo sistemáticamente. Una estrategia de prueba de software integra las técnicas de diseño de casos de prueba en un conjunto de pasos bien planeados que dan como resultado la correcta construcción del software. Proporciona una guía para los desarrolladores del software, para la organización de control d calidad y para el cliente.

Prueba de Unidad


La prueba de unidad centra el proceso de verificación en la menor unidad de diseño de software. Se prueba la interfaz del módulo para asegurar que la información fluya de forma adecuada, desde y hacia la unidad del programa que está siendo probada. Se analizan las estructuras de datos, se prueban las condiciones límite, se activan los caminos básicos de las estructuras de control y también se prueban todos los caminos de manejo de errores.


Antes de iniciar cualquier otra prueba, es preciso probar el flujo de los datos del módulo, ya que si los datos no entran correctamente, todas las demás pruebas no tienen sentido.
Prueba de integración


La prueba de integración es una técnica sistemática para construir la estructura del programa mientras al mismo tiempo, se lleva a cabo pruebas para detectar errores asociados con la interacción. El objetivo es tomar los módulos probados en unidad y estructurar un programa que esté de acuerdo con el que dicta el diseño.
Tipos de integración


Ø Integración descendente: es una estrategia de integración incremental a la construcción de la estructura de programas, en el cual se integran los módulos moviéndose en dirección hacia abajo por la jerarquía comenzando por el control principal (Programa principal). Los módulos subordinados de control principal se incorporan en la estructura en la estructura, bien, de forma primero-en-profundidad, bien primero-en-anchura.


Ø Integración ascendente: es donde la construcción del diseño empieza desde los módulos más bajos hacia arriba (módulo principal), el procesamiento requerido de los módulos subordinados siempre esta disponible y elimina la necesidad de resguardo.


La sección de una estrategia de integración depende de las características depende de las características del software y, a veces, del plan del proyecto, en algunos de los casos se puede combinar ambas estrategias.
Prueba de validación y verificación


Al conjunto de actividades que aseguran que el software implementa correctamente una función específica se denomina verificación. La validación se refiere a un conjunto de actividades que aseguran que el software construido se ajusta a los requerimientos y necesidades del cliente.

La definición de verificación validación envuelve lo que se conoce como calidad del software. Las revisiones técnicas formales ayudan (inspección) ayudan a asegurar la calidad de los productos, a lo largo del proceso la medición y l control se aplica sobre cada elemento de una construcción del software. La prueba construye un elemento importante desde el que se puede evaluar la calidad y, de forma más practica, de cubrir los errores.

Una vez que se culmino la etapa de integración se puede decir que el software esta completamente ensamblado, se ha encontrado y corregido errores de la interfaces y se puede comenzar una serie final de prueba del software. La prueba de validación se logra cuando la expectativas razonable del cliente se cumplen en donde incluye la especificación de requisitos, documentos en donde se describen los atributos del software que son visibles para el usuarios, esta información forma la base del enfoque a la prueba de validación.

Cuando se construye el software para llevar a cabo de validación es casi imposible que el desarrollador pueda prever como un cliente usara realmente el programa es por ello se hace una serie de prueba de aceptación que puede permitir que un cliente valide todos los requisitos, se puede dar el caso de las pruebas alfa y beta.
Prueba del Sistema


Un clásico problema de la prueba del sistema es la delegación de culpabilidad. Esto ocurre cuando se descubre un error t cada uno de los creadores de cada elemento del sistema echa la culpa del problema a otros, para evitar esto se debe prever y tomar medidas correctivas tomando en cuenta lo siguiente:


Ø Diseñar caminos de manejo de errores que prueben toda la información procedente de otros elementos del sistema.

Ø Lleva a cabo una serie de pruebas que simulan la presencia de datos en mal estado o de otros posibles errores en la interfaz del software.

Ø Registrar los resultados de las pruebas como “evidencias” en el caso de señalamientos informales.

Ø Participar en la planificación y diseño de las pruebas del sistema para asegurarse de que el software es probado en forma adecuada.


La prueba del sistema se basa en otras técnicas de pruebas, aunque la finalidad de cada prueba es distinta, sirven para verificar que se hayan integrado correctamente cada uno de los elementos del sistema:


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

2) 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 intentando encontrar una clave de acceso al sistema.

3) Prueba de Resistencia: está 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 esto 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.
Prueba de Validación de Requerimientos


Luego de culminarlas pruebas de integración, se realiza la última etapa de pruebas, la cual evaluará el sistema final con miras a su presentación frente al cliente. En esta prueba se verificará si el programa cumple con las especificaciones formales establecidas por el cliente. El primer paso es evaluar el sistema colocándose en la posición del diente, verificando la funcionalidad y requisitos de rendimiento, luego se revisa cuidadosamente la configuración que consiste en ver que todos los elementos se han desarrollado apropiadamente y están suficientemente detallados para soportarlas fases de mantenimiento durante el ciclo de vida del software.


Para finalizar, se realizarán las pruebas alfa y beta, donde el usuario estará en contacto directo con el software. El la prueba alfa, el usuario (o usuarios) probaran el sistema con la presencia directa del programador, el cual anotará todos los problemas que haya tenido el cliente. En la prueba beta, el sistema es cedido al usuario para que lo use as su ámbito común, sin la presencia del programador, pasando por escrito los errores encontrados al sistema.
Depuración


La depuración es el proceso que resulta en la eliminación de un error, ya que intenta hacer corresponder el sistema con una causa, llevando así a la corrección del error. El proceso de depuración siempre tiene uno de los dos resultados:


Ø Se encuentra el error, se corrige y elimina.

Ø No se encuentra la causa del error: en este caso es cuando la persona encargada de la depuración debe sospechar la causa, en donde debe diseñar casos de prueba que ayuden a confirmar sus sospechas y el trabajo se regresa a la corrección del error de una forma interactiva.


La depuración tiene como objetivo principal encontrar y corregir la causa de un error en el software, existen 3 enfoques que se pueden proponer en la depuración los cuales son:


Ø Eliminación de causas: se manifiesta mediante inducción o deducción. Los datos relacionados con la ocurrencia del error se organizan para llegar a las posibles causas; se desarrolla una lista de las causas y se llevan a cabo las pruebas para eliminar cada una.

Ø Fuerza bruta: es la categoría probablemente la mas común y la menos eficiente en le momento de aislar la causa del error del software en donde se confía que en algún lugar de la gran cantidad de información producida nos puede llevar finalmente al éxito, lo mas frecuente es que se desperdicie tiempo y esfuerzo.

Ø Vuelta atrás: es el enfoque más normal para la depuración, que se puede usar con gran éxito en programas pequeños. Partiendo de donde se detecta el error hacia atrás en el código fuente hasta llegar al a posición del error.

Mantenimiento del Software
Etapas del Mantenimiento


El mantenimiento es mucho más que una corrección de errores. Se puede describir en tres actividades:


Ø Mantenimiento correctivo: esta actividad del mantenimiento es debido a que no es razonable que en la prueba de software se haya descubierto los errores de un gran sistema de software. Durante el uso de cualquier programa se encuentran errores y estos son informados al personal de desarrollo. Este proceso incluye el diagnóstico y corrección de uno o más errores.

Ø Mantenimiento adaptativo: es una actividad que modifica el software para que interaccione adecuadamente ante un cambio en su entorno (hardware nuevo, sistemas operativos avanzados, cambios monetarios, etc.).

Ø Mantenimiento perfectivo: La tercera actividad del mantenimiento se da cuando existe software que tiene un gran éxito. A medida que se utiliza el software algunos usuarios hacen observaciones sobre recomendaciones para nuevas posibilidades ó sobre modificaciones a las funciones ya existentes ó sobre mejoras en general. Para satisfacer estas peticiones se lleva a cabo el mantenimiento perfectivo siendo una actividad que genera un mayor esfuerzo empleado en el mantenimiento de software.
Características del Mantenimiento


La fase del mantenimiento abarca dos aspectos importantes:


Ø Mantenimiento no estructurado: es cuando sólo se dispone del código fuente. Se evalúa a menudo como complicado, debido a la pobre documentación interna, que causa una mala interpretación de características delicadas como estructuras de datos, interfaces, etc.

Ø Mantenimiento estructurado: Si existe una detallada información del software, se inicia el mantenimiento con la evaluación de la documentación del diseño, se determinan las características estructurales más importantes, el rendimiento y la interfaz de software.


El costo de mantenimiento genera algunas veces insatisfacción al cliente cuando la petición o modificación no se puede atender en un tiempo razonable.
Efectos Secundarios del Mantenimiento


La modificación al software en los códigos fuente es peligrosa. Algunas veces hemos escuchado “pero si todo lo que realicé fue cambiarle una sentencia”, lamentablemente cada vez que se introduce un cambio en un proceso lógico muy complejo, la posibilidad del error aumenta. FREEDMAN y WEINBERG definen tres grandes categorías de efectos secundarios del mantenimiento:


Ø Efectos secundarios sobre el código: con el hecho de realizar un sencillo cambio sobre una sola sentencia puede a veces tener resultados desastrosos. El cambio inadvertido de algún símbolo muchas veces pueden acarrear problemas trágicos.

Ø Efectos secundarios sobre las bases de datos: Durante el mantenimiento frecuentemente se hacen cambios sobre determinados elementos de una estructura de datos o sobre la propia estructura de datos. Los efectos secundarios sobre las bases de datos regularmente suceden por las modificaciones sobre la estructura de la información del software.

Ø Efectos secundarios sobre la documentación: los efectos secundarios en la documentación son debidos a que no se reflejan las modificaciones hechas en el código fuente sobre la documentación respectiva, no llevando a cabo un registro y/o actualización de los códigos fuente modificados.

Implantación
Conversión


La conversión consiste en el cambio del sistema anterior con el sistema nuevo así como los métodos para llevarla a cabo y verificación de que la conversión se haya efectuado correctamente

Existen cuatro métodos para efectuar una conversión en un sistema, en donde cada método tiene ventajas y desventajas entre los mismos:


Ø Sistemas paralelos: este método es un modelo seguro, ya que el sistema nuevo funciona al mismo tiempo que el sistema anterior; debido a que si encuentran fallas en al sistema nuevo, al anterior permanece en constante funcionamiento sin perdidas de tiempo, ni de información. Una desventaja muy notable as que este método de conversión es muy costoso ya que se duplican los recursos humanos.

Ø Conversión directa: el sistema anterior será reemplazado por el nuevo sistema, ya que la organización confía plenamente en el nuevo sistema. Obligando así a los usuarios a que hagan funcionar al nuevo sistema encontrando en él nuevos métodos y controles.

Ø Enfoque piloto: en este método se implanta el nuevo sistema en una parte de la organización. Con base a retroalimentación se hacen cambios y el sistema se instala en el resto de la organización mediante algunos otros métodos. La desventaja es que el nuevo sistema puede dar la impresión de que el nuevo sistema no es confiable, ni está libre de errores.

Ø Conversión por etapas: se implanta el nuevo sistema de manera gradual, reemplazando partes del sistema anterior, permitiendo a los primeros usuarios aprovechar las ventajas del nuevo sistema, así como la capacitación de los mismos, llevando a cabo la instalación de una nueva etapa una vez que fue aceptada sin hacer uso necesario de recursos extras.
Plan de Conversión


El plan de conversión incluye une lista de actividades para llevar a acabo la implantación del nuevo sistema y ponerlo en operación.

El plan de conversión debe prevenir los posibles problemas y la forma de enfrentarlos implementando planes de emergencia adecuados. Algunos problemas que se presentan comúnmente son:

Ø Documentos perdidos.

Ø Variación entre datos de los formatos nuevos y anteriores.

Ø Errores en la conversión de datos Extravío de datos o pérdida de archivos.

Ø Omisión en algunos pasos de la conversión.


Acondicionamiento De Las Instalaciones


El cliente o el ingeniero de sistemas presentará una lista de especificaciones para el cableado eléctrico y los contactos, necesidades de aire acondicionado, controles de humedad y exigencias de espacio, lo más recomendable es tener el local antes de la llegada del equipo.
Capacitación De Operadores Y Usuarios Para Operar El Sistema


Como consecuencia la calidad de capacitación recibida por el personal que manipulará el sistema ayuda u obstruye, y puede llegar a impedir, la implantación exitosa de un sistema de información. Tanto operadores como los usuarios del sistema requieren de capacitación.
Capacitación de operadores


La mayoría de los sistemas dependen del personal de Centro de Cómputo. La capacitación que el personal reciba debe de asegurar que puedan manejar todas las operaciones posibles, tanto rutinarias como extraordinarias. La capacitación que reciba el operador también debe contemplar al personal de capture de datos,

Como parte de la capacitación se le debe dar al personal una lista de formas de resolver los problemas y que identifique los posibles problemas y solución, así como datos personales de las personas a quién buscar cuando surjan problemas inesperados.
Capacitación de usuarios


La capacitación de usuarios incluye la identificación de problemas, determinando si el problema que surge es ocasionado por hardware o por software, o por algo realizado por los mismos usuarios que ocasione la falla del sistema,

No hay nada más desesperante que trabajar con un sistema y que suceda un problema y no ser capaz de determinar si es falla del propio sistema, del equipo o de los usuarios. El lugar para prevenir estos casos es durante la capacitación.

Las actividades de manipulación de los datos que recibe le mayor atención en le capacitación de usuarios son la captura de datos, la formulación de consultas y el borrados de los registros de datos. Le mayor parte de le capacitación de los usuarios tiene que ver con la operación del sistema en sí. La capacitación en la codificación de los datos marca la paute en el proceso de captures partir de las transacciones, o en la preparación de datos necesarios para las actividades de apoyo a les decisiones.
Métodos de capacitación


La capacitación a operadores y usuarios se puede manifestar de diferentes formas. Las actividades de capacitación se pueden llevar a cabo en las instalaciones de los proveedores, locales rentados. Los métodos y contenido de la capacitación varia de acuerdo e la fuente y del lugar de le capacitación
Instalación Y Pruebas Del Usuario Para Aceptación Del Sistema

En la instalación y prueba del usuario, son algunas actividades que realiza el usuario con el fin de verificar el sistema si funciona con el hardware diferente al hardware de desarrollo, tal como su instalación y funcionamiento en general, en esta etapa se abarcan cuatro aspectos importantes:

Ø La prueba de entrada: implica asegurarse que las formas electrónicas e impresas, junto con la estructuras de codificación cumple con las guías y especificaciones de diseño. También se prueba si el usuario final ingresa bien los datos.

Ø La prueba de salida: consiste en la generación de un reporte, su entrega al usuario y la determinación que satisface las necesidades de información.

Ø La prueba de la base de datos: son un conjunto de pruebas que aseguran que la base de datos contempla la satisfacción total de las demandas planteadas.

Ø La prueba de los controles: su propósito fundamental es asegurar que los mismos se encuentren en su lugar y trabajen según se planteó.