OOAD - Control de calidad y pruebas

Una vez que se escribe un código de programa, se debe probar para detectar y posteriormente manejar todos los errores en él. Se utilizan varios esquemas con fines de prueba.

Otro aspecto importante es la idoneidad del propósito de un programa que determina si el programa cumple el propósito al que apunta. La aptitud define la calidad del software.

Prueba de sistemas orientados a objetos

Las pruebas son una actividad continua durante el desarrollo de software. En los sistemas orientados a objetos, las pruebas abarcan tres niveles, a saber, pruebas unitarias, pruebas de subsistemas y pruebas del sistema.

Examen de la unidad

En las pruebas unitarias, se prueban las clases individuales. Se ve si los atributos de la clase se implementan según el diseño y si los métodos y las interfaces están libres de errores. Las pruebas unitarias son responsabilidad del ingeniero de aplicaciones que implementa la estructura.

Prueba de subsistema

Esto implica probar un módulo en particular o un subsistema y es responsabilidad del líder del subsistema. Implica probar las asociaciones dentro del subsistema, así como la interacción del subsistema con el exterior. Las pruebas de subsistema se pueden utilizar como pruebas de regresión para cada versión recién lanzada del subsistema.

Prueba del sistema

La prueba del sistema implica probar el sistema en su totalidad y es responsabilidad del equipo de aseguramiento de la calidad. El equipo a menudo usa pruebas del sistema como pruebas de regresión al ensamblar nuevas versiones.

Técnicas de prueba orientadas a objetos

Prueba de caja gris

Los diferentes tipos de casos de prueba que pueden diseñarse para probar programas orientados a objetos se denominan casos de prueba de caja gris. Algunos de los tipos importantes de pruebas de caja gris son:

  • State model based testing - Esto incluye cobertura estatal, cobertura de transición estatal y cobertura de ruta de transición estatal.

  • Use case based testing - Se prueba cada escenario en cada caso de uso.

  • Class diagram based testing - Se prueba cada clase, clase derivada, asociaciones y agregaciones.

  • Sequence diagram based testing - Se prueban los métodos de los mensajes de los diagramas de secuencia.

Técnicas para pruebas de subsistemas

Los dos enfoques principales de las pruebas de subsistemas son:

  • Thread based testing - Todas las clases que se necesitan para realizar un caso de uso único en un subsistema están integradas y probadas.

  • Use based testing- Se prueban las interfaces y servicios de los módulos en cada nivel de jerarquía. Las pruebas comienzan desde las clases individuales hasta los módulos pequeños que comprenden clases, gradualmente a módulos más grandes y finalmente a todos los subsistemas principales.

Categorías de prueba del sistema

  • Alpha testing - Esto lo lleva a cabo el equipo de pruebas dentro de la organización que desarrolla el software.

  • Beta testing - Esto lo lleva a cabo un grupo selecto de clientes que cooperan.

  • Acceptance testing - Esto lo lleva a cabo el cliente antes de aceptar los entregables.

Garantía de calidad del software

Calidad del software

Schulmeyer y McManus han definido la calidad del software como "la aptitud para el uso del producto de software total". Un software de buena calidad hace exactamente lo que se supone que debe hacer y se interpreta en términos de satisfacción de la especificación de requisitos establecida por el usuario.

Seguro de calidad

El aseguramiento de la calidad del software es una metodología que determina hasta qué punto un producto de software es apto para su uso. Las actividades que se incluyen para determinar la calidad del software son:

  • Auditing
  • Desarrollo de estándares y pautas
  • Elaboración de informes
  • Revisión del sistema de calidad

Factores de calidad

  • Correctness - La exactitud determina si los requisitos del software se cumplen de manera adecuada.

  • Usability - La usabilidad determina si el software puede ser utilizado por diferentes categorías de usuarios (principiantes, no técnicos y expertos).

  • Portability - La portabilidad determina si el software puede operar en diferentes plataformas con diferentes dispositivos de hardware.

  • Maintainability - La capacidad de mantenimiento determina la facilidad con la que se pueden corregir los errores y actualizar los módulos.

  • Reusability - La reutilización determina si los módulos y las clases se pueden reutilizar para desarrollar otros productos de software.

Métricas orientadas a objetos

Las métricas se pueden clasificar ampliamente en tres categorías: métricas del proyecto, métricas del producto y métricas del proceso.

Métricas del proyecto

Las métricas del proyecto permiten al gerente de proyectos de software evaluar el estado y el desempeño de un proyecto en curso. Las siguientes métricas son apropiadas para proyectos de software orientados a objetos:

  • Número de guiones de escenarios
  • Número de clases de claves
  • Número de clases de apoyo
  • Numero de subsistemas

Métricas de producto

Las métricas de producto miden las características del producto de software que se ha desarrollado. Las métricas de producto adecuadas para sistemas orientados a objetos son:

  • Methods per Class- Determina la complejidad de una clase. Si se supone que todos los métodos de una clase son igualmente complejos, entonces una clase con más métodos es más compleja y, por tanto, más susceptible a errores.

  • Inheritance Structure- Los sistemas con varias redes de herencia pequeñas están mejor estructurados que los sistemas con una única red de herencia grande. Como regla general, un árbol de herencia no debe tener más de 7 (± 2) niveles y el árbol debe estar equilibrado.

  • Coupling and Cohesion - Se considera que los módulos de bajo acoplamiento y alta cohesión están mejor diseñados, ya que permiten una mayor reutilización y mantenibilidad.

  • Response for a Class - Mide la eficiencia de los métodos que son llamados por las instancias de la clase.

Métricas de proceso

Las métricas de proceso ayudan a medir cómo se está desempeñando un proceso. Se recopilan sobre todos los proyectos durante largos períodos de tiempo. Se utilizan como indicadores para mejoras de procesos de software a largo plazo. Algunas métricas de procesos son:

  • Número de KLOC (Kilo líneas de código)
  • Eficiencia de eliminación de defectos
  • Número promedio de fallas detectadas durante las pruebas
  • Número de defectos latentes por KLOC