Recomendaciones para pruebas de sofware

Testing Wisdom

A test is an experiment designed to reveal information or answer a specific question about the software or system. Stakeholders have questions; testers have answers.  
Don’t confuse speed with progress.  
Take a contrary approach.  
Observation is exploratory.
 The narrower the view, the wider the ignorance.  
Big bugs are often found by coincidence.  
Bugs cluster.  
Vary sequences, configurations, and data to increase the probability that, if there is a problem, testing will find it.  
It’s all about the variables.

Ubicaciones/Archivos

• Nombres Largos (>255 caracteres) 
• Caractéres especiales en el Nombre (espacio * ? / \ | < > , . ( ) [ ] { } ; : ‘ “ ! @ # $ % ^ &)  
• No Existente 
• Ya Existente 
• Sin espacio
• Mínimo Espacio  
• Protegido contra Escritura 
  
• No Disponible
• Bloqueado
• En una Máquina Remota 
  
• Corrupto

Tiempo y Fechas

• Timeouts  
• Time Difference between Machines  
• Crossing Time Zones 
• Leap Days   
• Always Invalid Days (Feb 30, Sept 31)  
• Feb 29 in Non-Leap Years 
• Different Formats (June 5, 2001; 06/05/2001; 06/05/01; 06-05-01; 6/5/2001 12:34) 
• Daylight Savings 
• Changeover  
• Reset Clock Backward or Forward

 

Números

• 0  
• 32768 (215)  
• 32769 (215 + 1)  
• 65536 (216)  
• 65537 (216 +1) 
• 2147483648 (231)
• 2147483649 (231 + 1)  
• 4294967296 (232)  
• 4294967297 (232 + 1)  
• Scientific Notation (1E-16)  
• Negative  
• Floating Point/Decimal (0.0001) 
• With Commas (1,234,567)
• European Style (1.234.567,89)  
• All the Above in Calculations

Cadenas de caracteres

• Long (255, 256, 257, 1000, 1024, 2000, 2048 or more characters)  
• Accented Chars (àáâãäåçèéêëìíîðñòôõöö, etc.) Asian Chars (漢字 )  
• Common Delimiters and Special Characters ( “ ‘ ` | / \ , ; : & < > ^ * ? Tab ) 
• Leave Blank 
• Single Space 
• Multiple Spaces  
• Leading Spaces  
• End-of-Line Characters (^M)  
• SQL Injection ( ‘select * from customer )  
• With All Actions (Entering, Searching, Updating, etc.)

 

General

• Violates Domain-Specific Rules (an ip address of 999.999.999.999, an email address with no “@”, an age of -1)  
• Violates Uniqueness Constraint

Web Tests

 

Navigation

• Back (watch for ‘Expired’ messages and double-posted transactions) 
• Refresh 
• Bookmark the URL  
• Select Bookmark when Logged Out  
• Hack the URL (change/remove parameters; see also Data Type Attacks)  
• Multiple Browser Instances Open

 

Input

• See also Data Type Attacks  
• HTML/JavaScript Injection (allowing the user to enter arbitrary HTML tags and JavaScript commands can lead to security vulnerabilities) 
• Check Max Length Defined on Text Inputs
•  > 5000 Chars in TextAreas

 

Syntax

• HTML Syntax Checker (http://validator.w3.org/) 
• CSS Syntax Checker (http://jigsaw.w3.org/css-validator/)

 

Preferences

• Javascript Off  
• Cookies Off 
• Security High  
• Resize Browser Window 
• Change Font Size

Heuristics 

Variable Analysis

Identify anything whose value can change. 
Variables can be obvious, subtle, or hidden.

 

Touch Points

Identify any public or private interface that provides visibility or control. 
Provides places to provoke, monitor, and verify the system.

 

Boundaries

Approaching the Boundary (almost too big, almost too small), At the Boundary

 

Goldilocks

Too Big, Too Small, Just Right

 

CRUD

Create, Read, Update, Delete

 

Follow the Data

Perform a sequence of actions involving data, verifying the data integrity at each step.
(Example: Enter → Search → Report → Export → Import → Update → View)

 

Configurations

Varying the variables related to configuration (Screen Resolution; Network Speed, Latency, Signal Strength; Memory; Disk Availability; Count heuristic applied to any peripheral such as 0, 1, Many Monitors, Mice, or Printers)

 

Interruptions

Log Off, Shut Down, Reboot, Kill Process, Disconnect, Hibernate, Timeout, Cancel

 

Starvation

CPU, Memory, Network, or Disk at maximum capacity

 

Position

Beginning, Middle, End (Edit at the beginning of the line, middle of the line, end of the line)

 

Selection

Some, None, All (Some permissions, No permissions, All permissions)

 

Count

0, 1, Many (0 transactions, 1 transactions, Many simultaneous transactions)

 

Multi-User

Simultaneous create, update, delete from two accounts or same account logged in twice.

Flood

Multiple simultaneous transactions or requests flooding the queue.

 

Dependencies

Identify “has a” relationships (a Customer has an Invoice; an Invoice has multiple Line Items). Apply CRUD, Count, Position, and/or Selection heuristics (Customer has 0, 1, many Invoices; Invoice has 0, 1, many Line Items; Delete last Line Item then Read; Update first Line Item; Some, None, All Line Items are taxable; Delete Customer with 0, 1, Many Invoices)

 

Constraints

Violate constraints (leave required fields blank, enter invalid combinations in dependent fields, enter duplicate IDs or names). Apply with the Input Method heuristic.

 

Input Method

Typing, Copy/Paste, Import, Drag/Drop, Various Interfaces (GUI v. API)

 

Sequences

Vary Order of Operations Undo/Redo Reverse Combine Invert Simultaneous

 

Sorting

Alpha v. Numeric Across Multiple Pages

 

State Analysis

Identify states and events/transitions, then represent them in a picture or table. Works with the Sequences and Interruption heuristics.

 

Map Making

Identify a “base” or “home” state. Pick a direction and take one step. Return to base. Repeat.

 

Users & Scenarios

Use Cases, Soap Operas, Personae, Extreme Personalities

Frameworks

Judgment

Inconsistencies, Absences, and Extras with respect to Internal, External – Specific, or External – Cultural reference points. (James Lyndsay, Workroom Productions)

 

Observations

Input/Output/Linkage (James Lyndsay, Workroom Productions)

 

Flow

Input/Processing/Output
 

Requirements

Users/Functions/Attributes/Constraints (Gause & Weinberg Exploring Requirements)

 

Nouns & Verbs

The objects or data in the system and the ways in which the system manipulates it. Also, Adjectives (attributes) such as Visible, Identical, Verbose and Adverbs (action descriptors) such as Quickly, Slowly, Repeatedly, Precisely, Randomly. Good for creating random scenarios.

 

Deming’s Cycle 

Plan, Do, Check, Act

Fuente: Blog Test Obsessed  Test Heuristics Cheatsheet Permalink

Programación Orientada a Objetos

La programación orientada al objeto brinda un medio de mejorar la reusabilidad de los
componentes software.

Conceptos Fundamentales

Clase y objetosEl cómputo en un sistema orientado al objeto supone la manipulación de objetos de cierta clase. Una clase es en realidad un medio de empaquetar un tipo abstracto de dato (TAD). Siendo una forma de implementar un TAD, una clase permite encapsular como una única entidad a los elementos y las rutinas de acceso de la implementación de un TAD. Una clase contiene toda la información para construir ejemplares individuales, ejemplares llamados objetos. Una clase es simplemente la especificación para creae objetos. Un objeto, por el contrario, son las entidades reales que serán manipuladas en el programa.
Cada objeto contiene conjuntos de datos llamados variables miembro o miembros de datos que determinan el estado individual de ese objeto. Además, una clase puede almacenar información compartida por todos los ejemplares de la clase en varibles de clase. Las variables miembro y de clase están empaquetadas de manera que sólo pueden accesadas a través de las rutinas aportadas por la clase, las cuales se denominan funciones miembro Herencia

La posibilidad de estructurar un sistema permite su descomposición en componentes. En base a esta descomposición, el herencia es el medio por el cual los objetos de una clase pueden acceder a variables y funciones miembros contenidas en una clase en una clase previamente definida. Esto da la posibilidad de crear una nueva clase que es una extensión o especialización de una clase existente. Así la nueva clase, llamada clase derivada, se dice que deriva de la clase base. Los lenguaje de orientación al objeto debieran soportar herencia múltiple, donde una clase pueda derivar de varias clases. La clase derivada puede añadir nuevas funciones de la clase base o puedde redefinirla. En
el último caso, se dice que la clase derivada redefine a la función miembro con el mismo nombre en la clase base.

Paso de Mensajes
En orientación al objeto, el cómputo de un sistema evoluciona conforme a mensajes. Los objetos de un sistema manipulan otros objetos enviándoles mensajes solicitando que realicen acciones específicas. Estos mensajes invocan a funciones miembro apropiadas de las clases de objetos. Si una función miembro deseada no se encuentra en la clase inmmediata al objeto, entonces se buscan las funciones miembro en la clase base de ese objeto, y así sucesivamente.

Vinculación Dinámica y Polimorfismo
Si el sistema decide en timpo de compilación qué implementación de la operación va a utilizar, realiza una vinculación estática. Si lo hace en tiempo de ejecución, entonces es una vinculación dinámica.

El polimorfismo se refiere a la posibilidad de que un único mensaje pueda referirse en
tiempo de ejecución a objetos de distintas clases. Típicamente en una clase base se declara una función como polimórfica. Entonces, esta función es redefinida en clases que son derivadas de la clase base.  Así, existen funciones e las clases derivadas con el mismo nombre que aquella en la clase base. Si un objeto de la clase base es declarado en un programa, la definición de la función original que se encuentra en la clase base será invocada cuando se llama a la función.  Sin embargo, si un objeto de una clase derivada es posteriormente asignado al objeto de la clase base, entonces la definición de la función para la clase derivada será invocada si es llamada la misma función.


Estructura de un Objeto:

Un objeto puede considerarse como una especie de cápsula dividida en tres partes:
 

1 - Relaciones
2 - Propiedades
3 - Métodos

Cada uno de estos componentes desempeña un papel totalmente independiente:

Las relaciones permiten que el objeto se inserte en la organización y están formadas esencialmente por punteros a otros objetos.

Las propiedades distinguen un objeto determinado de los restantes que forman parte de la misma organización y tiene valores que dependen de la propiedad de que se trate. Las propiedades de un objeto pueden ser heredadas a sus descendientes en la organización.

Los métodos son las operaciones que pueden realizarse sobre el objeto, que normalmente estarán incorporados en forma de programas (código) que el objeto es capaz de ejecutar y que también pone a disposición de sus descendientes a través de la herencia.


Enclapsulamiento y ocultacion:

Como hemos visto, cada objeto es una estructura compleja en cuyo interior hay datos y programas, todos ellos relacionados entre sí, como si estuvieran encerrados conjuntamente en una cápsula. Esta propiedad (encapsulamiento), es una de las características fundamentales en la OOP.

Los objetos son inaccesibles, e impiden que otros objetos, los usuarios, o incluso los programadores conozcan cómo está distribuida la información o qué información hay disponible. Esta propiedad de los objetos se denomina ocultación de la información.

Esto no quiere decir, sin embargo, que sea imposible conocer lo necesario respecto a un objeto y a lo que contiene. Si así fuera no se podría hacer gran cosa con él. Lo que sucede es que las peticiones de información a un objeto. deben realizarse a través de mensajes dirigidos a él, con la orden de realizar la operación pertinente. La respuesta a estas ordenes será la información requerida, siempre que el objeto considere que quien envía el mensaje está autorizado para obtenerla.



Ejemplo De Mensajes: si el objeto pato desea destruir la computadora debe enviar un mensaje al objeto martillo.

El hecho de que cada objeto sea una cápsula facilita enormemente que un objeto determinado pueda ser transportado a otro punto de la organización, o incluso a otra organización totalmente diferente que precise de él. 

Si el objeto ha sido bien construido, sus métodos seguirán funcionando en el nuevo entorno sin problemas. Esta cualidad hace que la OOP sea muy apta para la reutilización de programas.


Organizacion de los Objetos:

En principio, los objetos forman siempre una organización jerárquica, en el sentido de que ciertos objetos son superiores a otros de cierto modo.
Existen varios tipos de jerarquías: serán simples cuando su estructura pueda ser representada por medio de un "árbol". En otros casos puede ser más compleja.
 

En cualquier caso, sea la estructura simple o compleja, podrán distinguirse en ella tres niveles de objetos.

- La raíz de la jerarquía. Se trata de un objeto único y especial. Este se caracteriza por estar en el nivel más alto de la estructura y suele recibir un nombre muy genérico, que indica su categoría especial, como por ejemplo objeto madre, Raíz o Entidad.

- Los objetos intermedios. Son aquellos que descienden directamente de la raíz y que a su vez tienen descendientes. Representan conjuntos o clases de objetos, que pueden ser muy generales o muy especializados, según la aplicación. Normalmente reciben nombres genéricos que denotan al conjunto de objetos que representan, por ejemplo, Ventana, Cuenta, Fichero. En un conjunto reciben el nombre de clases o tipos si descienden de otra clase o subclase.

- Los objetos terminales. Son todos aquellos que descienden de una clase o subclase y no tienen descendientes. Suelen llamarse casos particulares, instancias o ítems porque representan los elementos del conjunto representado por la clase o subclase a la que pertenecen.

Fuente: http://candyluna.galeon.com/aficiones836769.html

Algoritmo

Los algoritmos son independientes de los lenguajes de programación. En cada problema el algoritmo puede escribirse y luego ejecutarse en un lenguaje de diferente programación. 

El algoritmo es la infraestructura de cualquier solución, escrita luego en cualquier lenguaje de programación.

Algoritmo: Un Algoritmo, se puede definir como una secuencia de instrucciones que representan un modelo de solución para determinado tipo de problemas. O bien como un conjunto de instrucciones que realizadas en orden conducen a obtener la solución de un problema. 

Por lo tanto podemos decir que es un conjunto ordenado y finito de pasos que nos permite solucionar un problema.

Programa: Un programa es una serie de instrucciones ordenadas, codificadas en lenguaje de programación que expresa un algoritmo y que puede ser ejecutado en un computador.

Clasificación

Los algoritmos se pueden clasificar en cuatro tipos: 

1. Algoritmo computacional: Es un algoritmo que puede ser ejecutado en una computadora. Ejemplo: Fórmula aplicada para un cálculo de la raíz cuadrada de un valor x.
2. Algoritmo no computacional: Es un algoritmo que no requiere de una computadora para ser ejecutado. Ejemplo: Instalación de un equipo de sonido.
3. Algoritmo cualitativo: Un algoritmo es cualitativo cuando en sus pasos o instrucciones no están involucrados cálculos numéricos. Ejemplos: Las instrucciones para desarrollar una actividad física, encontrar un tesoro.
4. Algoritmo cuantitativo: Una algoritmo es cuantitativo cuando en sus pasos o instrucciones involucran cálculos numéricos. Ejemplo: Solución de una ecuación de segundo grado.

Características

Todo algoritmo debe tener las siguientes características: 

• Debe ser Preciso,
  porque cada uno de sus pasos debe indicar de manera precisa e inequívoca que se debe hacer.
• Debe ser Finito,
  porque un algoritmo debe tener un número limitado de pasos.
• Debe ser Definido,
  porque debe producir los mismos resultados para las mismas condiciones de entrada.
• Puede tener cero o más elementos de entrada. 
• Debe producir un resultado.
  Los datos de salida serán los resultados de efectuar las instrucciones.

Partes

Todo Algoritmo debe tener las siguientes partes:

• Entrada de datos, son los datos necesarios que el algoritmo necesita para ser ejecutado
• Proceso, es la secuencia de pasos para ejecutar el algoritmo.
• Salida de resultados, son los datos obtenidos después de la ejecución del algoritmo.

Técnicas de representación 

Para la representación de un algoritmo, antes de ser convertido a lenguaje de programación, se utilizan algunos métodos de representación escrita, gráfica o matemática. 

Los métodos más conocidos son:

• Diagramación libre (Diagramas de flujo).
• Diagramas Nassi-Shneiderman.
• Pseudocódigo.
• Lenguaje natural (español, inglés, etc.).
• Fórmulas matemáticas.

Fuente: http://informaticafrida.blogspot.mx/2009/03/algoritmo.html

RUP

RUP - Rational Unified Process

El Proceso Unificado Racional (RUP) es un proceso de desarrollo de software que junto con el Lenguaje Unificado de Modelado (UML), constituyen la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos.

El RUP no es un sistema que sigue pasos establecidos para el desarrollo de un proyecto, sino que sigue un conjunto de metodologías que se adaptan a las necesidades de cada uno.

RUP se basa en 6 principios:

•       Adaptar el proceso
•       Balancear prioridades
•       Demostrar valor iterativamente
•       Elevar el nivel de abstracción
•       Enfocarse en la calidad
•       Ciclo de vida

RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en un número variable según el proyecto y en las que se hace un mayor o menor hincapié en las distintas actividades.

1. Concepción
2. Elaboración
3. Construcción
4. Transición

En  la siguiente figura podemos apreciar mejor estas fases:

 
http://xherrera334.blogspot.es/1194229380/rup-i-/

Automatización de pruebas de software.

Las pruebas automatizadas constituyen una necesidad casi absoluta en los proyectos que impliquen la creación y desarrollo de software, estas incluyen una amplia gama de beneficios que no están disponibles para las pruebas manuales.

En la actualidad existe una gran variedad de herramientas para realizar pruebas automatizadas. Estas proporcionan una ventaja evidente partiendo de tiempo y conservación de los recursos, sin comprometer la calidad del procedimiento de prueba, la exactitud de los informes finales y la eficiencia del proceso de pruebas, son efectivas y económicamente factibles. El uso de las mismas permite tener más comodidad en la elaboración de los errores y fallos que se producen antes de que el producto de software es liberado, o en momentos en que hay una necesidad de proporcionar asistencia al cliente para resolver los defectos encontrados.

Las pruebas automatizadas han mejorado enormemente el proceso básico de perfeccionamiento de aplicaciones web y sus beneficios se encuentran disponibles para desarrolladores. A continuación se citan algunas de sus ventajas:

• Confiables: Las pruebas realizan con exactitud diversas operaciones cada vez que se ejecutan, de tal modo que evita posibles errores humanos.
• Recursivas: Evidencian cómo el software reacciona bajo diferentes condiciones, cuando se está probando una misma operación repetidamente.
• Programables: Permiten programar pruebas sofisticadas que pongan en evidencia la robustez del software que se pruebe.
• Abarcadoras: Facilitan la construcción de un ambiente de pruebas que cubra cada característica del software.
• Reutilizables: Permite reutilizar pruebas en diversas versiones.
• Factibles: Se pueden ejecutar más pruebas en menos tiempo y el número de los recursos se reduce.
• Rápidas: Su ejecución es perceptiblemente más rápida.
• Flexibles: Las pruebas deben ser fáciles de entender, de modificar y de extender.

Las pruebas automatizadas se ejecutan mediante el empleo de herramientas que facilitan las tareas de un probador de software.

lgunas pruebas de software tales como las pruebas de regresión intensivas de bajo nivel pueden ser laboriosas y consumir mucho tiempo para su ejecución si se realizan manualmente. Adicionalmente, una aproximación manual puede no ser efectiva para encontrar ciertos tipos de defectos, mientras que las pruebas automatizadas ofrecen una alternativa que lo permite. Una vez que una prueba ha sido automatizada, ésta puede ejecutarse repetitiva y rápidamente en particular con productos de software que tienen ciclos de mantenimiento largo, ya que incluso cambios relativamente menores en la vida de una aplicación pueden inducir fallos en funcionalidades que anteriormente operaban de manera correcta. Existen dos aproximaciones a las pruebas automatizadas:

• Pruebas manejadas por el código: Se prueban las interfaces públicas de las clases, módulos o bibliotecas con una variedad amplia de argumentos de entrada y se valida que los resultados de obtenidos sean los esperados.
• Pruebas de Interfaz de Usuario: Un marco de pruebas genera un conjunto de eventos de la interface de usuario, tales como teclear, hacer click con el ratón e interactuar de otras formas con el software y se observan los cambios resultantes en la interface de usuario, validando que el comportamiento observable del programa sea el correcto.

La elección misma entre automatización y ejecución manual de pruebas, los componentes cuya prueba será automatizada, las herramientas de automatización y otros elementos son críticos en el éxito de las pruebas, y por lo regular deben provenir de una elección conjunta de los equipos de desarrollo, control de calidad y administración. Un ejemplo de mala elección para automatizar, sería escoger componentes cuyas características son inestables o su proceso de desarrollo implica cambios continuos.

En el desarrollo contemporáneo de software existe una tendencia creciente a usar Frameworks como los denominados XUnit (por ejemplo JUnit y NUnit) que permiten la ejecución de pruebas unitarias para determinar cuándo varias secciones del código se comportan como es esperado en circunstancias específicas. Los casos de prueba describen las pruebas que han de ejecutarse sobre el programa para verificar que éste se ejecuta tal y como se espera. La automatización de pruebas es una característica clave del desarrollo ágil de software en donde se le conoce como "desarrollo guiado por pruebas". En ellas, las pruebas unitarias se escriben antes que el código que genera la funcionalidad. Sólo cuando el código pasa exitosamente las pruebas se considera completo. Cuando hay cambios, el programador descubre inmediatamente cualquier defecto que rompa los casos de prueba lo cual baja el costo de la reparación. Dos inconvenientes de este estilo de trabajo son:

1. Algunas veces se "desperdicia" la capacidad del programador escribiendo las pruebas unitarias. El entrecomillado se debe precisamente que asegurar la calidad del producto no es desperdicio alguno.
2. Normalmente se prueban los requerimientos básicos o el flujo normal del caso de uso en vez de todos los flujos alternativos, dado que extender las pruebas más allá de la prueba base eleva el costo del producto. En algunas ocasiones los flujos alternativos son probados por un equipo de pruebas más o menos independiente del equipo de desarrollo.

Muchas herramientas de automatización de pruebas proveen características para grabar y reproducir acciones del usuario para posteriormente ejecutarlas un número indefinido de veces, comparando resultados obtenidos con resultados esperados. La ventaja de ésta aproximación a la automatización es que requiere de menos desarrollo de software, sin embargo el confiar en éstas características del software lo hace menos confiable en la medida que muchas veces dependen de la etiqueta o posición del elemento de interfaz, y, al cambiar, el caso de prueba debe ser adaptado al cambio o probablemente fallar. Una variante de estas pruebas es la prueba de sistemas basados en la web en las que la herramienta de prueba ejecuta acciones sobre el navegador e interpreta el HTML resultante. Una variación más es la automatización sin scripts, que no usa grabación y reproducción de acciones sino que construye un modelo de la Aplicación Bajo Prueba (AUT en sus siglas en inglés, ABP) que permite a la persona que prueba ("tester") que cree pruebas simplemente editando parámetros y condiciones.

Data-driven testing

Una vez teniendo el script para prueba automatizada, con poco esfuerzo más podemos obtener mucho más beneficio de esta misma nave. En este caso, podemos parametrizar la prueba y hacer que cada valor ingresado en cada campo sea tomado de un data pool (fuente de datos de prueba, tal como una tabla o archivo), y así estar probando distintos escenarios.

 Nuestros datos de prueba necesitan pueden ser una tabla con las siguientes columnas, que corresponden a los campos de la forma de registro de cliente: First_Name, Last_Name, Country_Name, City_Name, Address, Balance.

 Entonces tendremos un datapool con estas columnas. Luego podremos pensar distintas combinaciones de valores para probar. Por ejemplo, valores nulos, o valores muy grandes, strings muy largos, balances negativos, etcétera. Así, la misma prueba la puedo ejecutar con todas las combinaciones de datos que se me ocurran con tan solo ingresar los valores en una tabla. Esta ejecución la puedo hacer cada vez que se necesite, obteniendo información sobre el estado de la aplicación en forma casi inmediata.

 Si esta prueba la tuviera que ejecutar en forma manual con cada dato de prueba interesante, me llevaría más tiempo que ejecutarla automáticamente. O sea, los beneficios de este caso de prueba automatizado se ven directamente en este ciclo de pruebas, y no recién en el siguiente ciclo de pruebas de regresión. Son beneficios a corto plazo, con lo cual, visto de esta forma, es muy conveniente comenzar a automatizar.

 De acuerdo a lo que cuenta Cem Kaner en uno de sus artículos automatizar una prueba lleva entre 3 y 10 veces más que ejecutarla en forma manual (este artículo es de 1997, pero es aún vigente, o en tal caso, el costo es menor). Incluso, si en los siguientes ciclos de prueba tenemos cierto costo de mantenimiento de estos casos de prueba, imaginemos que también de 10 veces más que el costo de ejecución manual, también obtendremos beneficios si ejecutamos 11 veces la prueba de regresión.

Pruebas de Integración

La prueba de integración se realiza posteriormente a las pruebas de unidad y su foco de atención es el diseño y la construcción de la arquitectura del software. 

Después de la integración viene la validación y por último la prueba del sistema, ésta última consiste en probar el software junto con los otros elementos de la empresa o entidad, como la gente, departamentos, la base de datos.

Las pruebas de integración pueden ser descendentes o ascendentes o en sandwich, pero estas tienen sentido con ese nombre en los sistemas hechos en lenguajes estructurados, en los que el diagrama de la estructura de módulos del sistema permite definir un tipo dado de integración.
 En los orientados a objeto, otra vez cobra importancia el concepto de caso de uso, pues éste guía a la prueba en cuanto a los requisitos que deben satisfacer un determinado número de clases de programación que tienen que interactuar entre sí gobernadas por alguna clase de control del caso de uso.

Modelo de prototipos

El modelo de prototipos o de prototipaje previo a su desarrollo debe considerar las siguientes partes fundamentales:

• La definición de los objetivos globales para el software.
• Identificar los requisitos conocidos.
• Identificar las áreas del esquema del software en donde sea necesaria una mayor definición.
  

El siguiente esquema represente el proceso que sigue este modelo:

 

Su diseño es rápido y se centra en una representación de aquellos aspectos del software que serán visibles para el cliente o el usuario final (por ejemplo, la configuración de la interfaz con el usuario y el formato de los despliegues de salida).

Ayuda al desarrollador de software y al cliente a entender de mejor manera cuál será el resultado de la construcción cuando los requisitos estén satisfechos y ofrece un mejor enfoque cuando el responsable del desarrollo del software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humano-máquina.

La clave de su éxito esta en definir las reglas del juego desde el principio; es decir, el cliente y el desarrollador se deben poner de acuerdo en:

• Que el prototipo se construya y sirva como un mecanismo para la definición de requisitos
• Que el prototipo se descarte, o al menos en parte.
• Que después se desarrolle el software real con un enfoque hacia la calidad

Cabe resaltar que este modelo solamente es útil cuando tanto el cliente como el desarrollador conocen los objetivos y las necesidades generales para el software.

Modelo Espiral

 Modelo en Espiral

Desarrollado por B. Boehm, básicamente, la idea es Desarrollo Evolutivo, usando el Modelo de Cascada para cada etapa. Está orientado a evitar riesgos de trabajo. 

No define en detalle el sistema completo a la primera. Los desarrollares deberían solamente definir las mas altas prioridades.

El Modelo Espiral mejora el Modelo de Cascada enfatizando la naturaleza iterativa del proceso de diseño. Eso introduce un ciclo de prototipo iterativo. En cada iteración, las nuevas expresiones que son obtenidas transformando otras dadas son examinadas para ver si representan progresos hacia el objetivo.

El proceso se representa como una espiral más que como una secuencia de actividades con vuelta hacia atrás  Es decir: cada iteración integra el resultado anterior. Cada vuelta en la espiral representa una fase del proceso. Cada fase supone un avance en el proceso de desarrollo

No hay “etapas” fijas tradicionales, ligadas a actividades como la especificación o diseño. Cada vuelta en la espiral determina las actividades a realizar.

 Presentación sobre el modelo en espiral Permalink

http://xherrera334.blogspot.es/1193195700/modelos-de-desarrollo-de-software/