Tema 29: Metodología de la programación (II): verificación, validación y control de versiones

Control de versiones

Un sistema de control de versiones (VCS, Version Control System) es una herramienta que registra los cambios realizados sobre uno o varios ficheros a lo largo del tiempo, de modo que pueda recuperarse cualquier estado anterior, compararse revisiones y coordinarse el trabajo de varios desarrolladores sobre la misma base de código. Son herramientas específicas de control de versiones de software: Git, Mercurial y Apache Subversion (SVN), a las que se suman los sistemas históricos CVS (Concurrent Versions System) y Microsoft Visual SourceSafe (VSS).

Conviene no confundir el sistema de control de versiones con la plataforma de alojamiento colaborativo que lo aloja. GitHub, GitLab, Bitbucket o Azure DevOps Server son servicios/plataformas construidos sobre un VCS (normalmente Git), pero Bitbucket no es en sí mismo un sistema de control de versiones, sino una plataforma de Atlassian que aloja repositorios Git y que permite la integración con la herramienta JIRA. Tampoco es un VCS JMeter, que es una herramienta de pruebas de carga y rendimiento de Apache.

Modelos: centralizado frente a distribuido

• Centralizado (CVS, Subversion, VSS): existe un único repositorio central con el que cada desarrollador trabaja directamente; el historial reside en el servidor y suele necesitarse conexión para operar.

• Distribuido (Git, Mercurial): cada desarrollador dispone de una copia local completa del repositorio, con todo el historial. Por ello, es INCORRECTO afirmar que "en el modelo distribuido cada desarrollador trabaja directamente con el repositorio central": precisamente lo característico del modelo distribuido es que el trabajo se realiza contra el repositorio local, y solo se sincroniza con el remoto cuando se desea.

Git

Git es un sistema de control de versiones de código libre y arquitectura distribuida, creado por Linus Torvalds. Al ser distribuido, no es necesario tener conexión a internet para realizar confirmaciones (commits): los commits se registran en el repositorio local. En Git, hacer un commit es la acción de almacenar una nueva instantánea (snapshot) del estado del proyecto en el historial de Git.

Comandos esenciales de Git

El fichero .gitignore especifica qué archivos NO deben ser rastreados (ignorados) por el control de versiones. No es un comando, sino un fichero de configuración por directorio.

Apache Subversion (SVN)

Subversion es un sistema de control de versiones centralizado. Para indicar los ficheros que NO deben ser tenidos en cuenta por el control de versiones se emplea la propiedad svn:ignore, establecida con svn propset sobre un directorio versionado; para consultarla se usa svn propget svn:ignore. La propiedad contiene patrones de nombre de fichero separados por saltos de línea y aplica solo al directorio en el que se define, no a sus subdirectorios.

CVS (Concurrent Versions System)

CVS es un VCS centralizado clásico. Comandos relevantes:

• annotate: si se necesita verificar la revisión en que fue modificada cada línea de un archivo, se utiliza el comando annotate (muestra, línea a línea, la última revisión que la modificó y su autor).

• cvs add -kb miFichero: la opción de expansión de palabras clave -kb marca el fichero como binario; al ejecutarlo se está añadiendo un fichero como binario, evitando la conversión de fines de línea entre plataformas y la sustitución de palabras clave.

Mercurial

Mercurial es un sistema de control de versiones distribuido y multiplataforma, orientado a desarrolladores de software, cuyo cliente de línea de órdenes es hg. El comando outgoing (hg outgoing) permite comprobar qué conjuntos de cambios (changesets) se subirían al repositorio de destino si se ejecutara un push; muestra los cambios locales aún no presentes en el remoto, sin llegar a enviarlos.

Herramientas de Microsoft

• Microsoft Visual SourceSafe (VSS) es una herramienta de control de versiones de Microsoft (hoy descatalogada), de modelo centralizado.

• Azure DevOps Server (antes Team Foundation Server, TFS) es la plataforma de control de versiones de Microsoft actual, que soporta tanto repositorios Git como el control centralizado TFVC, además de gestión de proyectos y CI/CD.

Cuadro resumen de identificación

Fuentes

• Git — Documentación oficial (git-scm.com): https://git-scm.com/docs (git-init, git-clone, git-branch, git-tag, git-diff, git-commit, git-push, gitignore)

• Git Reference / gitignore: https://git-scm.com/docs/gitignore

• Apache Subversion — Version Control with Subversion, "Ignoring Unversioned Items" (svn:ignore, propget/propset): https://svnbook.red-bean.com/en/1.7/svn.advanced.props.special.ignore.html

• Mercurial SCM — Command reference hg outgoing: https://www.mercurial-scm.org/

• CVS — Concurrent Versions System, "Handling binary files" y "Keyword substitution" (-kb, annotate): https://www.gnu.org/software/trans-coord/manual/cvs/html_node/Binary-howto.html

• Atlassian Bitbucket / integración con Jira: https://www.atlassian.com/software/bitbucket

• Microsoft Learn — Azure DevOps Server: https://learn.microsoft.com/azure/devops/

Repositorios: estructura y actualización

Los programas para control de versiones (Git, Mercurial, Subversion, CVS…) guardan el historial en un repositorio. El desarrollador no trabaja directamente sobre él, sino sobre una copia de trabajo (working copy): un árbol de directorios corriente en su equipo, que es su espacio de trabajo privado.

Estructura de un repositorio Subversion: trunk, branches y tags

Subversion no impone ninguna organización de los datos, así que su documentación oficial recomienda una convención de estructura. Cada proyecto tiene una raíz de proyecto en el repositorio, y dentro de ella tres subdirectorios:

Si el repositorio aloja un solo proyecto, su raíz puede hacer de raíz de proyecto. Si aloja varios, cada uno tiene su propia raíz con su trunk, branches y tags.

Estructura de un proyecto Git: las tres secciones

Un proyecto Git tiene tres secciones principales:

• El directorio de Git (Git directory), donde se almacenan los metadatos y la base de datos de objetos del proyecto. Es lo que se copia al clonar un repositorio.

• El directorio de trabajo (working directory): una copia de una versión del proyecto, extraída de esa base de datos para usarla o modificarla.

• El área de preparación (staging area), también llamada índice (index). Es un archivo que guarda qué irá en la próxima confirmación.

De ahí salen los tres estados de un archivo en Git:

• Modificado (modified): ha cambiado desde que se obtuvo del repositorio y no se ha preparado.

• Preparado (staged): se ha añadido al área de preparación para la próxima confirmación.

• Confirmado (committed): está almacenado de forma segura en la base de datos local.

Actualización: el ciclo de trabajo típico

El libro oficial de Subversion describe así el ciclo de trabajo diario:

1. Actualizar la copia de trabajo con svn update.

2. Hacer los cambios: editar ficheros. Los cambios de estructura se hacen con svn add, svn delete, svn copy y svn move.

3. Revisar los cambios con svn status y svn diff.

4. Corregir los errores: svn revert devuelve un fichero o directorio a su estado sin modificar.

5. Resolver los conflictos, es decir, integrar los cambios que otros publicaron mientras tanto. Se hace de nuevo con svn update; si quedan conflictos locales, se resuelven con svn resolve.

6. Publicar (confirmar) los cambios con svn commit, que los envía al repositorio. Si se aceptan, crean las versiones más recientes.

Al ejecutar svn update, Subversion muestra junto a cada elemento un código de una letra que indica qué acción ha hecho para poner al día la copia de trabajo.

En Git, el equivalente es traer los cambios del remoto (git pull) y, en local, preparar los archivos (añadirlos al área de preparación) y confirmarlos (git commit). Confirmar toma los archivos tal como están en el área de preparación y guarda esa instantánea de forma permanente en el directorio de Git.

Fuentes de la estructura y actualización

• Version Control with Subversion (libro oficial de Apache Subversion, 1.7), «Recommended Repository Layout» y «Basic Work Cycle»: https://svnbook.red-bean.com/en/1.7/svn.tour.importing.html y https://svnbook.red-bean.com/en/1.7/svn.tour.cycle.html

• Pro Git (git-scm.com, edición en español), «Fundamentos de Git — Los Tres Estados»: https://git-scm.com/book/es/v2/Inicio---Sobre-el-Control-de-Versiones-Fundamentos-de-Git

Gestión de la configuración

La gestión de la configuración (configuration management, CM) es, según la norma IEEE 828-2012, la disciplina que aplica dirección y vigilancia técnica y administrativa para identificar y documentar las características funcionales y físicas de un elemento de configuración, controlar los cambios de esas características, registrar e informar del tratamiento de los cambios y del estado de su implantación, y verificar el cumplimiento de los requisitos especificados. La misma norma la resume como las actividades técnicas y organizativas de identificación, control, contabilidad de estado y auditoría de la configuración. Aplicada al software a lo largo de todo su ciclo de vida, para ayudar a asegurar la completitud y la corrección de sus elementos de configuración, se denomina gestión de la configuración del software (SCM, software configuration management) (ISO/IEC/IEEE 24765).

El control de versiones descrito en este artículo es una de sus herramientas: la norma ISO/IEC/IEEE 26511 define el control de versiones como el establecimiento y mantenimiento de líneas base y la identificación y control de los cambios sobre ellas, de modo que sea posible volver a la línea base anterior.

Conceptos básicos

• Elemento de configuración (configuration item, CI): elemento o agregación de hardware, de software o de ambos que se designa para la gestión de la configuración y se trata como una sola entidad en ese proceso (ISO/IEC/IEEE 15288). IEEE 828-2012 lo define como la agregación de productos de trabajo designada para la gestión de la configuración y tratada como una sola entidad. No solo el código fuente: también la documentación, las estructuras de datos o los scripts pueden ser componentes de un elemento de configuración (ISO/IEC 16350).

• Línea base (baseline): versión formalmente aprobada de un elemento de configuración, con independencia de su soporte, designada y fijada formalmente en un momento concreto de su ciclo de vida (ISO/IEC/IEEE 12207 y 15288). A partir de ella, los cambios requieren justificación y aprobación (IEEE 1012). Una línea base junto con todos los cambios aprobados sobre ella representa la configuración aprobada vigente.

• Versión: instancia identificada de un elemento de configuración (ISO/IEC TR 18018).

• Comité de control de la configuración (Configuration Control Board, CCB), también llamado comité de control de cambios: grupo de personas responsable de evaluar y aprobar o rechazar los cambios propuestos a los elementos de configuración, y de asegurar la implantación de los cambios aprobados (IEEE 828-2012).

Las cuatro actividades

Entre las auditorías de la configuración, IEEE 828-2012 define estas dos:

• Auditoría funcional (FCA, functional configuration audit): verifica que el desarrollo del elemento de configuración se ha completado satisfactoriamente, que el elemento alcanza las características funcionales y de rendimiento especificadas y que su documentación de operación y de soporte está completa y es satisfactoria.

• Auditoría física (PCA, physical configuration audit): verifica que el elemento de configuración, tal como se ha construido, se ajusta a la documentación técnica que lo define.

Fuente de la gestión de la configuración

• IEEE Computer Society — SEVOCAB, vocabulario de ISO/IEC/IEEE 24765 (definiciones de configuration management, software configuration management, configuration item, baseline, version, version control, configuration identification, configuration control, configuration status accounting, configuration audit, functional configuration audit, physical configuration audit y configuration control board, con su norma de origen: IEEE 828-2012; ISO/IEC/IEEE 12207, 15288, 24765 y 26511; ISO/IEC TR 18018; ISO/IEC 16350; IEEE 1012): https://pascal.computer.org/sev_display/index.action

Pruebas de software

Las pruebas constituyen el conjunto de actividades encaminadas a verificar y validar que un sistema de información cumple los requisitos especificados y funciona correctamente. En el contexto de la Administración española, la metodología de referencia es MÉTRICA Versión 3, que estructura las pruebas a lo largo del ciclo de vida (procesos de Construcción del Sistema de Información —CSI— e Implantación y Aceptación del Sistema —IAS—). Junto a ella conviven numerosas herramientas de software libre para automatizar los distintos niveles y tipos de prueba.

Tipos de pruebas en MÉTRICA V3

MÉTRICA V3 distingue varios tipos de prueba, cada uno con un objetivo diferenciado:

• Pruebas unitarias: verifican el comportamiento de cada componente o módulo de forma aislada.

• Pruebas de integración: su finalidad es verificar que los distintos componentes o subsistemas interactúan correctamente a través de sus interfaces, tanto internas como externas, comprobando que cubren la funcionalidad establecida y se ajustan a los requisitos especificados. En términos de propósito, evalúan la capacidad del software para trabajar de manera efectiva con otros componentes y sistemas.

• Pruebas del sistema: comprueban el sistema completo integrado frente a los requisitos.

• Pruebas de implantación: validan el funcionamiento en el entorno de operación real.

• Pruebas de aceptación: permiten al usuario validar que el software cumple con los requisitos establecidos en la Especificación de Requisitos de Pruebas, desde el punto de vista de su funcionalidad y rendimiento.

• Pruebas de regresión: comprueban que los cambios sobre un componente de un sistema de información no introducen un comportamiento no deseado o errores adicionales en otros componentes no modificados (eliminación del "efecto onda"). Estas pruebas sí pueden automatizarse —afirmar que no es posible automatizarlas es incorrecto—; de hecho, la automatización es lo que las hace viables al repetirse tras cada cambio.

• Pruebas de rendimiento: consisten en determinar que los tiempos de respuesta están dentro de los intervalos establecidos en las especificaciones del sistema.

• Pruebas de carga: evalúan la capacidad del software para manejar grandes volúmenes de datos y usuarios concurrentes.

Documentos y planificación de las pruebas en MÉTRICA V3

MÉTRICA V3 formaliza la actividad de pruebas mediante varios productos:

• Plan de Pruebas: su propósito es establecer la estrategia y los objetivos de las pruebas. Recoge las actividades de prueba a realizar según una planificación y se inicia en fases tempranas del desarrollo.

• Especificación del Plan de Pruebas: detalla el plan e incluye, entre sus tareas, la Definición del Alcance de las Pruebas, la Definición de Requisitos del Entorno de Pruebas y la Definición de las Pruebas de Aceptación del Sistema.

• Especificación de Requisitos de Pruebas: sirve como guía para la realización de las pruebas y permite verificar que el sistema de información cumple las necesidades establecidas por el usuario, con las debidas garantías de calidad. Es la referencia contra la que se validan las pruebas de aceptación.

• Informe de Pruebas (o Evaluación del Resultado de las Pruebas): su propósito es documentar los resultados de las pruebas realizadas.

Verificación y validación del sistema

Las pruebas son el medio principal de dos actividades que conviene no confundir: la verificación y la validación. La norma ISO 9000:2015 (vocabulario de los sistemas de gestión de la calidad) las define así:

• Verificación (3.8.12): «confirmación, mediante la aportación de evidencia objetiva de que se han cumplido los requisitos especificados». La evidencia puede ser el resultado de una inspección o de otras formas de determinación, como realizar cálculos alternativos o revisar los documentos.

• Validación (3.8.13): «confirmación, mediante la aportación de evidencia objetiva, de que se han cumplido los requisitos para una utilización o aplicación específica prevista». Su evidencia es el resultado de un ensayo u otra forma de determinación, y las condiciones de utilización pueden ser reales o simuladas.

La diferencia está en contra qué se comprueba: la verificación confronta el producto con los requisitos especificados (¿se ha construido conforme a lo especificado?) y la validación con el uso previsto (¿sirve para aquello para lo que se pidió?). Por eso, en MÉTRICA V3, las pruebas unitarias, de integración y del sistema son sobre todo actividades de verificación, mientras que las pruebas de aceptación, en las que el usuario comprueba el sistema frente a sus necesidades, son la validación por excelencia.

Técnicas de prueba: caja blanca y caja negra

MÉTRICA V3 distingue dos enfoques para diseñar los casos de prueba:

• Enfoque estructural o de caja blanca: «se verifica la estructura interna del componente con independencia de la funcionalidad establecida para el mismo», por lo que no se comprueba la corrección de los resultados. Ejemplos: ejecutar todas las instrucciones del programa, localizar código no usado o comprobar los caminos lógicos del programa.

• Enfoque funcional o de caja negra: se comprueba el correcto funcionamiento analizando las entradas y salidas y verificando que el resultado es el esperado, sin preocuparse por la estructura interna.

En las pruebas unitarias el enfoque adoptado está orientado claramente a los casos de caja blanca, complementados con caja negra, porque el tamaño del componente permite examinar toda su lógica. Los casos de prueba deben contemplar tanto las condiciones válidas y esperadas como las inválidas e inesperadas.

Mantenimiento de sistemas de información

En MÉTRICA V3 el proceso de Mantenimiento de Sistemas de Información (MSI) tiene como objetivo «la obtención de una nueva versión de un sistema de información» a partir de las peticiones de mantenimiento de los usuarios, motivadas por un problema detectado o por la necesidad de una mejora. Se describen cuatro tipos de mantenimiento:

• Correctivo: los cambios precisos para corregir errores del producto software.

• Evolutivo: las incorporaciones, modificaciones y eliminaciones necesarias para cubrir la expansión o cambio en las necesidades del usuario.

• Adaptativo: las modificaciones que afectan a los entornos en los que el sistema opera (configuración del hardware, software de base, gestores de base de datos, comunicaciones…).

• Perfectivo: las acciones para mejorar la calidad interna del sistema: reestructuración del código, definición más clara del sistema y optimización del rendimiento y la eficiencia.

Solo el correctivo y el evolutivo entran en el ámbito de MÉTRICA V3: el adaptativo y el perfectivo quedan fuera porque requieren actividades y perfiles distintos de los del proceso de desarrollo. Cada modificación da lugar a una nueva versión del sistema, que se controla con la gestión de la configuración y las herramientas de control de versiones, y las pruebas de regresión comprueban que el cambio no ha introducido errores en lo que no se tocó.

Fuentes de este apartado

• ISO 9000:2015, Sistemas de gestión de la calidad — Fundamentos y vocabulario (traducción oficial), entradas 3.8.12 y 3.8.13: https://www.iso.org/obp/ui/es/#iso:std:iso:9000:ed-4:v1:es

• MÉTRICA v3, Técnicas — Pruebas unitarias (enfoques de caja blanca y caja negra): https://manuel.cillero.es/doc/metodologia/metrica-3/tecnicas/pruebas/unitarias/

• MÉTRICA v3, Proceso de Mantenimiento de Sistemas de Información (MSI): https://manuel.cillero.es/doc/metodologia/metrica-3/procesos-principales/msi/

Herramientas de automatización y pruebas

Pruebas unitarias — JUnit

JUnit es el conjunto de bibliotecas para pruebas unitarias de aplicaciones Java. Forma parte de la familia xUnit y permite definir casos de prueba, aserciones y su ejecución automatizada, integrándose habitualmente en los entornos de compilación e integración continua.

Pruebas funcionales web y móviles — Selenium y Appium

Selenium es un entorno (framework) de pruebas de software para aplicaciones basadas en la web, específicamente diseñado para la automatización de pruebas funcionales sobre aplicaciones web. Sus pruebas pueden ejecutarse en Windows, Linux y OSX (macOS), y admite múltiples lenguajes (Java, C#, Python, Ruby, JavaScript, etc.) comunicándose con los navegadores mediante el protocolo WebDriver.

Appium es una herramienta de automatización de código abierto para ejecutar scripts y probar aplicaciones nativas, aplicaciones web y aplicaciones híbridas sobre Android o iOS utilizando un WebDriver. Extiende el modelo de Selenium al ámbito móvil.

Pruebas de carga, estrés y rendimiento

Apache JMeter es una aplicación Java de código abierto para pruebas de carga y estrés, que permite simular escenarios de concurrencia de usuarios sobre servidores, redes u objetos. Puede realizar pruebas de rendimiento y pruebas unitarias. Se define con claridad como una herramienta de pruebas unitarias para conexiones de bases de datos con JDBC, FTP, LDAP, servicios web, JMS, HTTP y conexiones TCP genéricas. Soporta, entre otros, los protocolos HTTP/HTTPS, SOAP/REST, FTP, JDBC, LDAP, JMS, SMTP/POP3/IMAP y TCP; es decir, se puede utilizar con todos ellos. En cambio, NO es una funcionalidad de JMeter capturar tramas de red (esa función corresponde a analizadores como Wireshark).

Gatling es una herramienta de prueba de carga de código libre que se integra con soluciones existentes y ofrece integración con herramientas de CI/CD. Está construida sobre Scala, Akka y Netty; su marco distribuido permite la computación totalmente asíncrona, modelando los usuarios virtuales como mensajes ligeros en lugar de hilos, lo que le permite simular grandes cargas con pocos recursos.

Tsung es una herramienta de software libre que se especializa en pruebas de carga y estrés para aplicaciones basadas en protocolos de base de datos (además de HTTP, WebDAV, LDAP, XMPP, MQTT, etc.), destacando por su capacidad de generar cargas distribuidas de alta concurrencia.

Producto que NO es de pruebas — OneTrust

Conviene distinguir las herramientas de prueba de otros productos. OneTrust NO es un producto orientado a las pruebas de software: es una plataforma de gestión de privacidad, cumplimiento normativo y gobierno de datos (GRC), ajena al ámbito del testing.

Resumen comparativo de herramientas

Fuentes

• MÉTRICA Versión 3 — Ministerio (portal de Administración Electrónica / preparatic): https://www.preparatic.org/material/20100918/Metrica_v3.pdf

• MÉTRICA v3, Técnicas de Pruebas (Integración y Regresión) — manuel.cillero.es: https://manuel.cillero.es/doc/metodologia/metrica-3/tecnicas/pruebas/

• Apache JMeter — sitio oficial (protocolos soportados): https://jmeter.apache.org/

• Apache JMeter — Wikipedia (lista de protocolos): https://en.wikipedia.org/wiki/Apache_JMeter

• Gatling — documentación oficial (arquitectura asíncrona, CI/CD): https://docs.gatling.io/

• Gatling — repositorio oficial: https://github.com/gatling/gatling

• Appium — sitio oficial (automatización móvil vía WebDriver): https://appium.github.io/appium.io/index.html

• JUnit — sitio oficial: https://junit.org/

• Tsung — documentación oficial: http://tsung.erlang-projects.org/

TDD: desarrollo guiado por pruebas

El desarrollo guiado por pruebas (TDD, Test-Driven Development) es una técnica que guía el desarrollo escribiendo primero las pruebas. La desarrolló Kent Beck a finales de los años noventa como parte de Extreme Programming (XP).

El ciclo rojo-verde-refactorizar

TDD repite un ciclo corto de tres pasos, que se resume como rojo – verde – refactorizar (Red – Green – Refactor):

1. Rojo: se escribe una prueba para la siguiente funcionalidad que se quiere añadir. Como el código aún no existe, la prueba falla.

2. Verde: se escribe el código funcional imprescindible hasta que la prueba pasa.

3. Refactorizar: se reestructura el código, el nuevo y el anterior, para que quede bien organizado, manteniendo las pruebas en verde.

Saltarse la fase de refactorización es la forma más habitual de hacer mal TDD: el código pasa las pruebas, pero se va degradando.

TDD produce como efecto una batería de pruebas automatizadas que acompaña al código desde el principio y que se ejecuta en cada integración, por lo que encaja con la integración continua.

Fuentes de TDD

• Martin Fowler — Test-Driven Development (bliki): https://martinfowler.com/bliki/TestDrivenDevelopment.html