en DESARROLLO DE SOFTWARE

Tipos de pruebas automatizadas de software

Hablaba el otro día sobre la necesidad de utilizar un servidor de integración contínua en el desarrollo de una aplicación, para poder entregar software con cierta garantía de calidad. Un servidor de integración continua se encarga de ejecutar una serie de procedimientos automatizados que chequean el código en busca de errores, aplicando métricas (sintaxis del código, etc.) y realizando tareas regulares como la documentación.

Centremonos en los tipos de pruebas:

  • Pruebas unitarias: se encargan de probar una clase en concreto, testeando cada uno de sus métodos y viendo si dados unos parámetros de entrada, la salida es la esperada.
  • Pruebas funcionales: como su propio nombre indican, prueban una funcionalidad completa, donde pueden estar implicadas una o varias clases, la propia interfaz de usuario y, en el caso del desarrollo web, llamadas AJAX.
  • : son aquellas pruebas cuyo objetivo es comprobar por qué ha dejado de funcionar algo que ya funcionaba. El objetivo de las pruebas de regresión es no tener que “volver atrás”.
  • Pruebas de aceptación: son pruebas funcionales, pero vistas directamente desde el cliente. Digamos que son aquellas pruebas que demuestran al cliente que la funcionalidad está terminada y funciona correctamente.
  • Pruebas de integración: conjunto de pruebas unitarias, funcionales, de regresión y/o de aceptación que se realizan las probar el software. Incluye también comprobar que lo programado por los diferentes desarrollados no “choca” entre sí y que funcionará en un entorno real.

Conceptos relacionados:

  • TDD – Test Driven Development: son pruebas unitarias que siguen el principio “test-first”. Esto es, la prueba unitaria se crea ANTES de crear la propia clase. La idea es que, al pensar en cómo probarás la clase, estás pensando en la propia clase desde el punto de vista de su interfaz (qué métodos tendrá y con qué parámetros), ayudando a desarrollar antes un mejor diseño. De ésta manera, además, te aseguras de que no exista ninguna clase que no esté probada.
  • BDD – Behaviour Driven Development: sus defensores la consideran una evolución de TDD, con una forma de escribir las pruebas más centrada en el comportamiento (behaviour) que debe tener la clase.
  • Code Coverage: métrica que mide la cantidad de código que está probado unitariamente.

En un entorno de integración continua, las pruebas (unitarias, funcionales, etc.) y las métricas (code coverage, syntax check, etc.) se ejecutan de manera regular con el objetivo de probar que la evolución del software desarrollado funciona perfectamente, tanto para las funcionalidades nuevas como para aquellas que ya existían. Una de las claves es que las pruebas sean automatizadas, porque si se ejecutaran manualmente, el coste de hacerlo “continuamente” sería inabordable.

Escribe un comentario

Comentario

  1. ¿que relacion tienen los tipos de pruebas de software con los tipos de casos de pruebas de software? o son lo mismo ??

  2. por favor cuales y cuantas son las tecnicas de pruebas del software

  3. porfavor
    me podrias colaboral con las tecnicas de pruebas del software y desirme cuantas y cuales son y cual es la similitud en la caja negra y blanca
    muchas gracias