PRUEBAS DEL SOFTWARE

Pruebas de software

Las pruebas de software (en inglés software testing) son las investigaciones empíricas y técnicas cuyo objetivo es proporcionar información objetiva e independiente sobre la calidad del producto a la parte interesada o stakeholder. Es una actividad más en el proceso de control de calidad.

Las pruebas son básicamente un conjunto de actividades dentro del desarrollo de software. Dependiendo del tipo de pruebas, estas actividades podrán ser implementadas en cualquier momento de dicho proceso de desarrollo. Existen distintos modelos de desarrollo de software, así como modelos de pruebas. A cada uno corresponde un nivel distinto de involucramiento en las actividades de desarrollo.

Historia

El objetivo de las pruebas es presentar información sobre la calidad del producto a las personas responsables de éste. Las pruebas de calidad presentan los siguientes objetivos: encontrar defectos o bugs, aumentar la confianza en el nivel de calidad, facilitar información para la toma de decisiones, evitar la aparición de defectos.

Teniendo esta afirmación en mente, la información que puede ser requerida es de lo más variada. Esto hace que el proceso de testing sea completamente dependiente del contexto1 en el que se desarrolla.

El ambiente ideal de las pruebas de testing es aquel que es independiente del desarrollo del software, de esta manera se logra objetividad en las pruebas.

A pesar de lo que muchos promueven, no existen las "mejores prácticas" como tal. Toda práctica puede ser ideal para una situación pero completamente inútil o incluso perjudicial en otra.

Por esto, las actividades, técnicas, documentación, enfoques y demás elementos que condicionarán las pruebas a realizar, deben ser seleccionados y utilizados de la manera más eficiente según contexto del proyecto.

Pruebas estáticas

Son el tipo de pruebas que se realizan sin ejecutar el código de la aplicación.

Puede referirse a la revisión de documentos, ya que no se hace una ejecución de código. Esto se debe a que se pueden realizar "pruebas de escritorio" con el objetivo de seguir los flujos de la aplicación.

Pruebas dinámicas

Todas aquellas pruebas que para su ejecución requieren la ejecución de la aplicación.

Las pruebas dinámicas permiten el uso de técnicas de caja negra y caja blanca con mayor amplitud. Debido a la naturaleza dinámica de la ejecución de pruebas es posible medir con mayor precisión el comportamiento de la aplicación desarrollada.

Tipos de pruebas

Hay todo tipo de pruebas, pero nos centraremos en tres de ellas:

Pruebas de Compatibilidad

Se comprueba el funcionamiento del software desarrollado en muchas plataformas: sistemas operativos, navegadores, redes, hardware...entre otros

Pruebas de Regresión

Se evalúa el correcto funcionamiento del software desarrollado frente a evoluciones o cambios funcionales. El propósito de éstas es asegurar que los casos de prueba que ya habían sido probados y fueron exitosos permanezcan así. Se recomienda que este tipo de pruebas sean automatizadas para reducir el tiempo y esfuerzo en su ejecución.

Pruebas de Integración

Es el nivel de pruebas posterior a las pruebas modulares de los componentes de un sistema. Se centra principalmente en probar la comunicación entre los componentes de un mismo sistema, comunicación entre sistemas o entre hardware y software.

Tipos de pruebas por su ejecución

·         Pruebas manuales

·         Pruebas automáticas

·         Enfoques de pruebas[editar]

·         Pruebas de Caja blanca

·         Pruebas de Caja negra

·         Testing aleatorio2

Niveles de pruebas

·         Pruebas unitarias

·         Pruebas modulares

·         Pruebas de integración

·         Pruebas de sistema

·         Pruebas de aceptación de usuario UAT

Pruebas funcionales

·         Pruebas funcionales

·         Pruebas de humo

·         Pruebas de regresión

·         Pruebas de aceptación

·         Alpha testing

·         Beta testing

Pruebas no funcionales

·         Pruebas no funcionales

·         Pruebas de seguridad

·         Pruebas de usabilidad

·         Pruebas de rendimiento

·         Pruebas de internacionalización y localización

·         Pruebas de escalabilidad

·         Pruebas de mantenibilidad

·         Pruebas de instalabilidad

·         Pruebas de portabilidad

METRICAS DEL PRODUCTO SOFTWARE OO

Métricas para Sistemas Orientados a Objetos

El Software Orientado a Objetos (OO) es fundamentalmente distinto del software que se desarrolla utilizando métodos convencionales. Las métricas parasistemas OO deben de ajustarse a las características que distinguen el software OO del software convencional. Estas métricas hacen hincapié en el encapsulamiento, la herencia, complejidad de clases y polimorfismo. Por lo tanto las métricas OO se centran en métricas que se pueden aplicar a las características de encapsulamiento, ocultamiento de información, herencia y técnicas de abstracción de objetos que hagan única a esa clase. Como en todas las métricas los objetivos principales de las métricas OO se derivan del software convencional: comprender mejor la calidad del producto, estimar la efectividad del proceso y mejorar la calidad del trabajo realizado a nivel del proyecto.

Se conoce que las medidas y las métricas son componentes clave de cualquier disciplina de la ingeniería; la ingeniería de software orientada a objetos no es una excepción. Lamentablemente, la utilización de métricas para sistemas orientados a objetos ha progresado con mucha más lentitud que la utilización de los demás métodos OO [Luis A. Laranjeira ‘90]. Sin embargo, a medida que los sistemas OO van siendo más habituales, resulta fundamental que los ingenieros del software dispongan de mecanismos cuantitativos para estimar la calidad de los diseños y la efectividad de los programas 00.

Objetivo de las métricas Orientados a Objetos

Los objetivos principales de las métricas orientadas a objetos son los mismos que los existentes para las métricas surgidas para el software estructurado:

· Comprender mejor la calidad del producto

· Estimar la efectividad del proceso

· Mejorar la calidad del trabajo realizado en el nivel del proyecto.

Cada uno de estos objetivos es importante en sí, pero para el ingeniero de software, la calidad del producto debe de ser lo esencial. ¿Cómo se puede medir la calidad de un sistema 0.0? ¿Qué características del modelo de diseño se pueden estimar para decretar si el sistema será o no fácil de implementar, se podrá probar, que será fácil de modificar, y lo que es más importante, resultará tolerable para los usuarios finales? [Laranjeira 1990]. Estos argumentos se tratarán de resolver a lo largo de este capítulo

Características del software Orientado a Objetos

El software orientado a objetos es esencialmente distinto del software que se desarrolla utilizando métodos convencionales. Por esta razón, las métricas para sistemas 00 deben de concordarse a las características que distinguen el software 00 del software convencional.

Berard [Laranjeira ‘90] define cinco características que dan lugar a unas métricas especializadas:

· Localización,

· Encapsulamiento,

· Ocultamiento de información,

· Herencia y

· Técnicas de abstracción de objetos.

Localización

La localización es una característica del software que indica la forma que se concentra la información dentro de un programa. En el contexto OO, la información se concentra mediante el encapsulamiento tanto de datos como de procesos dentro de los límites de una clase u objeto.

Dado que el software convencional hace hincapié en las funciones como mecanismos de localización, las métricas de software se han centrado en la estructura interna o complejidad de las funciones (p. ej.: longitud del módulo, cohesión, o complejidad ciclomática) o bien en la forma en que las funciones se conectan entre sí (p. ej.: acoplamiento de módulos).

Dado que las clases constituyen la unidad básica de los sistemas 00, la localización está basada en los objetos. Por tanto, las métricas deberían de ser aplicables a la clase (objeto) como si se tratara de una entidad completa. Además, la relación entre operaciones (funciones) y clases no es precisamente uno-a-uno.

Por tanto, las métricas que reflejan la forma en que colaboran las clases deben de ser capaces de adaptarse a las relaciones uno-a-muchos y muchos-a-uno.

Encapsulamiento

Berard [Pressman ‘98] define el encapsulamiento como “el empaquetamiento (o enlazado) de una colección de elementos. Entre los ejemplos de encapsulamiento de bajo nivel (software convencional) se cuentan los registros y matrices, y los subprogramas (por ejemplo, procedimientos, funciones, subrutinas y párrafos) son mecanismos de nivel medio para el encapsulamiento”.

Para los sistemas 00, el encapsulamiento comprende las responsabilidades de una clase, incluyendo sus atributos (y otras clases para objetos agregados) y operaciones, y los estados de la clase, según se definen mediante valores específicos de atributos.

El encapsulamiento influye en las métricas cambiando el objetivo de la medida, que pasa de ser un único módulo a ser un paquete de datos (atributos) y de módulos de procesamiento (operaciones). Además, el encapsulamiento impulsa a la medida hasta un nivel de abstracción más elevado.

Ocultamiento de información

El ocultamiento de información suprime los detalles operativos de un componente de un programa. Tan sólo se proporciona la información necesaria para acceder a ese componente o a aquellos otros componentes que deseen acceder a él.

Un sistema 00 bien diseñado debería de impulsar al ocultamiento de información. Por tanto, aquellas métricas que proporcionen una indicación del grado en que se ha logrado el ocultamiento proporcionarán una indicación de la calidad del diseño 00.

Herencia

La herencia es un mecanismo que hace posible que los compromisos de un objeto se difundan a otros objetos. La herencia se produce a lo largo de todos los niveles de la jerarquía de clases, bien es sabido que en general, el software convencional, no admite esta característica.

Dado que la herencia es una característica fundamental de muchos sistemas 00, hay muchas métricas 00 que se centran en ella. Esto se conocerá entre los ejemplos que se tratarán más adelante: se cuentan el número de descendientes (número de instancias inmediatas de una clase), número de predecesores (número de generalizaciones inmediatas), y grado de anidamiento de la jerarquía de clases (profundidad de una clase dentro de una jerarquía de herencia) y otros.

Abstracción

La abstracción es un mecanismo que permite al diseñador centrarse en los detalles esenciales de algún componente de un programa (tanto si es un dato como si es un proceso) sin preocuparse por los detalles de nivel inferior. Cuando los niveles de abstracción van elevándose, se ignoran más y más detalles, por lo tanto, se proporciona una visión más general de un concepto u objeto. A medida que pasamos a niveles más reducidos de abstracción, se muestran más detalles, esto es, se proporciona una visión más específica de un concepto u objeto.

Dado que una clase es una abstracción que se puede visualizar con muchos niveles distintos de detalles, y de muchas maneras diferentes, las métricas OO representan la abstracción en términos de medidas de una clase (p.ej.: número de instancias por clase por aplicación).