Prueba y documentación de programas. Técnicas.

De MediaWiki
Ir a la navegación Ir a la búsqueda

Introducción

El testing

Qué es

Importancia

7 principios

Error, defecto y fallo

Niveles de testing

Test unitarios

Es la prueba que se realiza sobre la unidad más básica de nuestro código, métodos, funciones, clases, interfaces,...

Las pruebas unitarias son el método por el cual validamos que cada unidad desarrollada está lista para uso.

Los desarrolladores de software escriben estos casos de prueba para asegurar su funcionamiento en términos de diseño e implementación.

En ocasiones también los QAs pueden escribir estos casos de prueba, pero no es común.

Los test unitarios validan el correcto funcionamiento de la unidad más pequeña de código que utiliza nuestro software, por lo tanto lo que estamos consiguiendo es asegurar que para un conjunto de valores de entrada, nuestra función, método o clase devuelve el valor esperado.

Uno de los métodos utilizados es el de pruebas de caja blanca o TDD (Test Driven Development), entre otras, las cuales se detallaran más adelante.

Entre sus ventajas se encuentran:

  1. Los defectos aparecen temprano
  2. Ayuda a mantener el código
  3. Reduce el coste de solución
  4. Facilita las tareas de depuración
  5. ayudan en el proceso de debugging

Hay que tener en cuenta que con su incremento pueden ralentizar los despliegues, y que su uso requiere concimiento: otra mentalidad al momento de escribir las pruebas, aprender el funcionamiento de la librería de pruebas, saber cómo trabajar con datos de prueba, saber abstraer/simplificar unas partes del sistema para poder escribir las pruebas, saber estructurarles, hacerlas resistentes al cambio y comprensibles, etc.

Test de integración

Un test de integración es aquel que combinando diferentes módulos prueba la comunicación entre ellos. Por ejemplo, comunicaciones:

  • Interfaz -> BBDD
  • Interfaz -> API
  • Interfaz -> Interfaz

Como estos sistemas ya tienen sus pruebas unitarias pasadas, los fallos detectados están realacionados con la interoperabilidad y la comunicación entre los mismos.

Normalmente cada equipo, o cada miembro de un equipo, desarrolla una parte del software. Por lo que, deben acordar, por ejemplo el paso de parámetros, o si tenemos que trabajar con una API de terceros, tendremos que seguir lo acordado en el juego de petición respuesta. Uno de los métodos utilizados es el de pruebas de caja negra, caja blanca o caja gris, entre otras, las cuales se detallaran más adelante.

Suelen ser también los desarrolladores los que escriben estos test en fases tempranas del desarrollo, cuando todavía no se implica al QA. Sin embargo, otra práctica habitual, es la de contratar a una empresa tercera especializada en pruebas.

Entre las estrategias de integración, podemos indicar las siguientes:

  1. Big bang
  2. Top down
  3. Bottom up
  4. Hibrido / sandwich

Test de sistemas

Las pruebas de sistema implican las pruebas del sistema al completo, desde que una acción es activada en el producto hasta que acaba.

De esta manera con todos los elementos integrados comprobaremos si el sistema al completo funciona como se espera o no.

Son los QAs especializados, o independientes, los que diseñan y ejecutan estos casos de prueba.

Los tipos de pruebas se pueden clasificar en funcionales y no funcionales.

Entre sus ventajas:

  • No es necesario tener ningún conocimiento de cómo se ha desarrollado el código.
  • Reduce los errores post-despliegue
  • Valoración de la experiencia de usuario
  • Multidisciplinar
  • Testing de navegación (Exploratory Testing)
  • Entornos para reproducir incidencias
  • Se prueban Arquitectura y Requisitos

Test de aceptación

Son las pruebas que se realizan sobre el producto final, si no en el entorno final, en uno practicamente igual.

Esta es la fase en la que el cliente decide el GO/NO GO del producto a un entorno productivo. Es el último paso para finalizar la entrega del producto al cliente.

Entre los objetivos de las pruebas de aceptación se encuentran:

  • Ganar confianza en el producto
  • Conseguir el OK para el paso a producción
  • Conseguir la aceptación del cliente de que lo que se ha diseñado y aprobado en las fases anteriores es realmente lo que el cliente pedía
  • Asegurar que el producto sigue los estándares de mercado (Lo prueban diferentes perfiles)
  • Comparar el producto con otros similares del mercado

Algunos de los tipos de test de aceptación son:

  • UAT (User Acceptance Testing)
  • BAT (Business Acceptance Testing)
  • CAT (Contract Acceptance Testing)
  • RAT (Regulations / Compliance Acceptance Testing)
  • OAT (Operational Acceptance Testing)
  • Alfa testing
  • Beta testing

Tipos de prueba

Funcionales

En ellas se comprueba lo que el sistema hace. La funcionalidad puede estar descrita en:

  • Requerimientos
  • Especificaciones funcionales
  • Casos de uso
  • No estar documentadas

Suelen estar relacionadas con las pruebas de caja negra.

No funcionales

Consideran el “comportamiento externo” del sistema comprobando cómo responde en términos de estrés, escalabilidad, carga, seguridad, etc.

Pueden hacer referencia a estándares de calidad, como la ISO 9126.

Podemos clasificar las pruebas no funcionales según el tipo de requisito no funcional que abarcan:

  • Pruebas de compatibilidad
  • Pruebas de seguridad
  • Pruebas de estrés
  • 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

Regresivas

Son cualquier tipo de pruebas de software con el objeto de descubrir errores (bugs), carencias de funcionalidad, o divergencias funcionales con respecto al comportamiento esperado del software, causados por la realización de un cambio en el programa.

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.

Subtipos

El número de tipos de prueba es elevado y depende del autor que se siga. Se mencionarán aquí una lista de subtipos de prueba funcionales y no funcionales:

Técnicas de prueba

Caja blanca

Las técnicas de pruebas de caja blanca analizan las estructuras internas, las estructuras de datos utilizadas, el diseño interno, la estructura de código y el funcionamiento del software.

En este tipo de pruebas el código es accesible por el probador, por lo que tiene que tener conocimientos de codificación para entenderlo y diseñar las pruebas correspondientes.

Comprueban:

  • problemas de seguridad internos
  • mala o inexistente calidad en las estructuras de código
  • el flujo para cada input en el código
  • resultado esperado
  • funcionalidad de los bucles condicionales
  • prueba de cada declaración, objeto y función de forma individual

Se realizan de forma iterativa siguiendo estos tres pasos:

  1. Entender el código fuente
  2. Crear los casos de prueba
  3. Ejecutar los casos de prueba

Las técnicas más conocidas implican:

  • Cobertura de sentencia

Su objetivo es atravesar todos los estados al menos una vez. Por lo tanto, cada línea de código es probada. En el caso de un diagrama de flujo, cada nodo debe ser atravesado al menos una vez. Puesto que todas las líneas de código están cubiertas, ayuda encontrar el código defectuoso.

  • Cobertura de rama

En esta técnica, los casos de prueba se diseñan de manera que cada rama de todos los puntos de decisión se atraviese al menos una vez

Caja negra

Se define como una técnica de prueba en la que la funcionalidad de la aplicación bajo prueba, se prueba sin tener en cuenta la estructura del código interno, los detalles de implementación y el conocimiento de las estructuras internas del software. Este tipo de pruebas se basa completamente en los requisitos y especificaciones del software

Las ténicas más habituales son:

  • Dirigidas por la sintaxis
  • Partición de equivalencia
  • Valores Limite
  • Gráficos efecto causa
  • Basada en Requisitos
  • Pruebas de Compatibilidad

Comparación

Caja blanca Caja negra
¿Qué valida? La estructura interna y el funcionamiento del código Los requisitos funcionales
Respecto al conocimiento del código.... El conocimiento del lenguaje de programación subyacente es esencial Proporcionan abstracción del código y se centran en el esfuerzo de probar el comportamiento del sistema de software
Sobre la comunicación... No facilitan la comunicación de pruebas entre los módulos Facilitan la comunicación de pruebas entre los módulos

Basadas en la experiencia - Alfa y beta testing

El Alpha Testing es un tipo de prueba de aceptación; se realiza para identificar todos los posibles problemas/errores antes de lanzar el producto a los usuarios o al público en general.

El objetivo de esta prueba es simular usuarios reales utilizando técnicas de Caja Negra y Caja Blanca. El objetivo es llevar a cabo las tareas que un usuario típico podría realizar.

El Beta Testing es la segunda fase del Software Testing en la que una muestra de la audiencia objetivo prueba el producto. Las pruebas beta de un software son realizadas por usuarios reales de la aplicación en un entorno real.

Tipo de Beta Testig Descripción
Tradicionales El producto se distribuye al mercado objetivo, y los datos relacionados se recopilan en todos los aspectos. Estos datos pueden ser utilizados para mejorar el producto.
Públicas El producto se da a conocer públicamente al mundo exterior a través de canales en línea y los datos se pueden obtener de cualquier persona
Ensayos Técnicos El producto se entrega al grupo interno de una organización y recoge los comentarios y datos de los empleados de la organización.
Enfocada El producto se lanza al mercado para recabar información sobre las características específicas del programa
Post-Lanzamiento El producto se lanza al mercado y se recopilan datos para hacer mejoras para el futuro lanzamiento del producto

Se puede ver una comparativa sobre las características del alfa y beta testing en la siguiente tabla:

Alfa Beta
Entorno Interno Del cliente
Equipos implicados Analistas de negocio y desarrolladores Solamente el cliente final está implicado en las pruebas y en el reporte
Conocimientos Equipo altamente cualificado en calidad Pueden ser usuarios finales ingenuos o competentes del producto
Caja Blanca y negra Negra
Cuando se realizan Antes del lanzamiento de un producto de software al mercado En el momento de la comercialización del producto de software
Objetivo Asegurar la calidad del producto Además recogen las opiniones de los usuarios sobre el producto y aseguran que este está listo para los usuarios en tiempo real
Fiabilidad y seguridad No se realizan pruebas de fiabilidad y seguridad Pruebas de fiabilidad, seguridad y robustez
Sobre el tiempo de ciclo Puede ser necesario un ciclo de ejecución largo Sólo se requieren unas pocas semanas de ejecución
Sobre cuándo se resuelven los problemas Los problemas críticos o correcciones pueden ser resueltos por los desarrolladores inmediatamente La mayoría de los problemas o comentarios que se recogen se implementarán en futuras versiones del producto

Organización de los casos de prueba y herramientas para su gestión

Es necesario organizar los casos de prueba para:

  1. Facilitar la comprensión del proyecto, desde un punto de vista de las pruebas.
  2. Comprender la funcionalidad y la prioridad fácilmente
  3. Facilitar las regresiones, completas o parciales
  4. Aumentar la calidad
  5. Facilitar la escalabilidad del proyecto

Automatización

Pasos

  1. Elegir la prueba
  2. Precondición
  3. Pasos
  4. Comprobaciones
  5. Reporte estado final

La documentación

Todo el proceso de desarrollo de software debe quedar perfectamente documentado, para pasar así de una fase a otra de forma clara y definida. Además, es importante también para poder acometer futuras revisiones del proyecto.Se distinguen tres grandes documentos en el desarrollo de software:

Guía técnica

Información que contiene:

  • El diseño de la aplicación.
  • La codificación de los programas.
  • Las pruebas realizadas.

Está dirigido a:

  • Personal técnico en informática (analistas y programadores)

El objetivo es:

  • Facilitar un correcto desarrollo, realizar correcciones en los programas y permitir un mantenimiento futuro.

Guía de uso

Información que contiene:

  • Descripción de la funcionalidad de la aplicación.
  • Forma de comenzar a ejecutar la aplicación.
  • Ejemplos de uso del programa.
  • Requerimientos software de la aplicación.
  • Soluciones de los posibles problemas que se pueden presentar.

Está dirigido a:

  • Usuarios que van a utilizar la aplicación (clientes).

El objetivo es:

  • Dar a los usuarios finales toda la información necesaria para utilizar la aplicación.

Guía de instalación

Información que contiene:

  • Toda la información necesaria sobre puesta en marcha, explotación y seguridad del sistema.

Está dirigido a:

  • Personal informático responsable de la instalación, en colaboración con los usuarios que van a usar la aplicación (clientes).

El objetivo es :

  • Dar toda la información necesaria para garantizar que la implantación de la aplicación se realice de forma segura, confiable y precisa.

Conclusiones

Se ha presentado una visión global de las tareas de prueba y documentación ya que son de vital importancia durante el desarrollo de software.

Las pruebas permiten verificar que el software que se está creando es correcto y cumple con las especificaciones impuestas por el usuario, garantizando así la calidad del producto entregado.

Y por otra parte, una correcta documentación durante el desarrollo de software influirá también positivamente en la calidad del software, su utilización, soporte y posterior mantenimiento y evolución.

Anexo I - Herramientas Software para la realización de pruebas

Se presenta a continuación una tabla con varias herramientas que permiten la gestión y automatización de ciertos tipos de pruebas de software

Tipo de prueba Herramienta Lenguajes Comentario
Unitaria JUnit 5 Java
Mocha Javascript Test framework que corre en Node.js y en el navegador
PHPUnit PHP La versión 10 está en desarrollo
NUnit .NET
PyUnit Python
BDD Behat PHP Framework libre de Behavior-Driven Development para PHP
Cucumber Herramienta utilizada para ejecutar pruebas de aceptación automáticas creadas en formato BDD. Destaca su capacidad de llevar a cabo descripciones funcionales de texto sin formato (escritas en un lenguaje llamado Gherkin) como pruebas automatizadas.
Chai Javascript
Karma Javascript
Funcional y de regresión Selenium
Cypress Framework de pruebas todo en uno que facilita la integración continua
Integración SoapUI Aplicación de prueba de API para tecnologías SOAP y REST, permite también pruebas funcionales y de rendimiento
Postman Utilizada principalmente para el testing de API REST
Carga y rendimiento Apache JMeter
Gatling Herramienta para pruebas de estrés
LoadRunner
Aceptación FitNesse Herramienta de automatización de test de aceptación mediante su documentación en wiki
Concordion Framework orientado al desarrollo de tests de aceptación. Funciona a través de tests escritos en HTML
Acunetix Software de pruebas automáticas de seguridad web
Nessus Programa de escaneo de vulnerabilidades que permite agilizar pruebas de seguridad
Gestión TestLink
TestRail
Practitest
Múltiples Codeception PHP Permite realización de pruebas unitarias, integración, aceptación, BDD....
TestNG Java Framework para pruebas y testing que. Está basado en JUnit (para Java) y NUnit (para .NET) pero introduciendo nuevas funcionalidades que los hacen más poderosos y fáciles de usar.

Anexo II - Herramientas Software para la documentación

Herramienta Comentario
Atlassian Confluence Módulo de Jira que permite documentar los how-to y las referencias técnicas llegando a asociar Ticket de Jira - Documentación de código – Rama de Git (o Subversion).
Javadoc Generador de documentación para el lenguaje Java para generar documentación de API en formato HTML desde el código fuente de Java.
phpDoc Es una adaptación de javadoc para php que define un estándar oficial para comentar código php.
Read the Docs Plataforma gratuita para el alojamiento de documentación de software con código fuente; facilita la redacción de documentación técnica al automatizar la creación y el control de versiones.
Huddle Centro de colaboración todo-en-uno para los equipos. Utilizado por empresas grandes que necesitan herramientas estar sincronizadas, incluidos el almacenamiento de archivos, la gestión de proyectos y las herramientas de colaboración.

Bibliografía

Referencias

Obtenido de «https://wiki.cifprodolfoucha.es/index.php?title=Prueba_y_documentación_de_programas._Técnicas.&oldid=12385»