La prueba de software es el acto de comprobar si el software satisface las expectativas.
Las pruebas de software pueden proporcionar información objetiva e independiente sobre la calidad del software y el riesgo de que falle para un usuario o patrocinador. [1]
Las pruebas de software pueden determinar la corrección del software para escenarios específicos , pero no pueden determinar la corrección para todos los escenarios. [2] [3] No puede encontrar todos los errores .
Basado en los criterios para medir la corrección de un oráculo , las pruebas de software emplean principios y mecanismos que podrían reconocer un problema. Ejemplos de oráculos incluyen: especificaciones , contratos , [4] productos comparables, versiones anteriores del mismo producto, inferencias sobre el propósito previsto o esperado, expectativas del usuario o del cliente, estándares relevantes, leyes aplicables.
Las pruebas de software suelen ser de naturaleza dinámica; ejecutar el software para verificar que la salida real coincida con la esperada. También puede ser de naturaleza estática; Revisar el código y su documentación asociada .
Las pruebas de software se utilizan a menudo para responder a la pregunta: ¿El software hace lo que se supone que debe hacer y lo que debe hacer?
La información obtenida de las pruebas de software se puede utilizar para mejorar el proceso mediante el cual se desarrolla el software. [5] : 41–43
Las pruebas de software deben seguir un enfoque "piramidal" en el que la mayoría de las pruebas deben ser pruebas unitarias , seguidas de pruebas de integración y, finalmente, las pruebas de extremo a extremo (e2e) deben tener la proporción más baja. [6] [7] [8]
Un estudio realizado por el NIST en 2002 informa que los errores de software le cuestan a la economía estadounidense 59.500 millones de dólares al año. Más de un tercio de este costo podría evitarse si se realizaran mejores pruebas de software. [9] [ dudoso – discutir ]
La subcontratación de pruebas de software debido a los costos es muy común, siendo China, Filipinas y la India los destinos preferidos. [ cita necesaria ]
Glenford J. Myers introdujo inicialmente la separación entre la depuración y las pruebas en 1979. [10] Aunque su atención se centró en las pruebas de rotura ("Un caso de prueba exitoso es aquel que detecta un error aún no descubierto". [10] : 16 ), ilustró el deseo de la comunidad de ingeniería de software de separar las actividades fundamentales de desarrollo, como la depuración, de las de verificación.
Las pruebas de software suelen estar impulsadas por objetivos.
Las pruebas de software generalmente incluyen el manejo de errores de software: un defecto en el código que causa un resultado no deseado. [11] : 31 Los errores generalmente ralentizan el progreso de las pruebas e implican la asistencia del programador para depurarlos y corregirlos.
No todos los defectos causan una falla. Por ejemplo, un defecto en un código inactivo no se considerará una falla.
Un defecto que no causa falla en un momento determinado puede ocurrir más tarde debido a cambios ambientales. Ejemplos de cambios de entorno incluyen la ejecución en nuevo hardware informático , cambios en los datos e interacción con software diferente. [12]
Un solo defecto puede provocar múltiples síntomas de falla.
Las pruebas de software pueden implicar una brecha en los requisitos: omisión en el diseño de un requisito. [5] : 426 Las brechas en los requisitos a menudo pueden ser requisitos no funcionales, como la capacidad de prueba , la escalabilidad , la mantenibilidad , el rendimiento y la seguridad .
Una limitación fundamental de las pruebas de software es que las pruebas bajo todas las combinaciones de entradas y condiciones previas (estado inicial) no son factibles, incluso con un producto simple. [3] : 17–18 [13] Los defectos que se manifiestan en condiciones inusuales son difíciles de encontrar en las pruebas. Además, las dimensiones no funcionales de la calidad (cómo se supone que debe ser frente a lo que se supone que debe hacer ) ( usabilidad , escalabilidad , rendimiento , compatibilidad y confiabilidad ) pueden ser subjetivas; algo que constituye valor suficiente para una persona puede no serlo para otra.
Aunque no es factible realizar pruebas para todas las entradas posibles, las pruebas pueden utilizar la combinatoria para maximizar la cobertura y minimizar las pruebas. [14]
Las pruebas se pueden clasificar de muchas maneras. [15]
Las pruebas de software se pueden clasificar en niveles según la proporción del sistema de software en el que se centra la prueba. [18] [19] [20] [21]
Existen muchos enfoques para las pruebas de software. Las revisiones , recorridos o inspecciones se denominan pruebas estáticas, mientras que la ejecución de código programado con un conjunto determinado de casos de prueba se denomina pruebas dinámicas . [23] [24]
Las pruebas estáticas suelen ser implícitas, como la corrección de pruebas, además, cuando las herramientas de programación/editores de texto verifican la estructura del código fuente o los compiladores (precompiladores) verifican la sintaxis y el flujo de datos como análisis de programas estáticos . Las pruebas dinámicas se llevan a cabo cuando se ejecuta el programa en sí. Las pruebas dinámicas pueden comenzar antes de que el programa esté 100% completo para probar secciones particulares de código y se aplican a funciones o módulos discretos. [23] [24] Las técnicas típicas para estos son el uso de stubs /controladores o la ejecución desde un entorno de depuración . [24]
Las pruebas estáticas implican verificación , mientras que las pruebas dinámicas también implican validación . [24]
Las pruebas pasivas significan verificar el comportamiento del sistema sin ninguna interacción con el producto de software. A diferencia de las pruebas activas, los evaluadores no proporcionan ningún dato de prueba, sino que consultan los registros y seguimientos del sistema. Buscan patrones y comportamientos específicos para tomar algún tipo de decisiones. [25] Esto está relacionado con la verificación del tiempo de ejecución fuera de línea y el análisis de registros .
El tipo de estrategia de prueba a realizar depende de si las pruebas a aplicar a la IUT deben decidirse antes de que comience a ejecutarse el plan de pruebas (pruebas preestablecidas [28] ) o si cada entrada a aplicar a la IUT puede ser dinámicamente dependiendo de los resultados obtenidos durante la aplicación de las pruebas anteriores (pruebas adaptativas [29] [30] ).
Las pruebas de software a menudo se pueden dividir en caja blanca y caja negra. Estos dos enfoques se utilizan para describir el punto de vista que adopta el evaluador al diseñar casos de prueba. Un enfoque híbrido llamado caja gris que incluye aspectos de ambas cajas también se puede aplicar a la metodología de prueba de software. [31] [32]
Las pruebas de caja blanca (también conocidas como pruebas de caja transparente, pruebas de caja de vidrio, pruebas de caja transparente y pruebas estructurales) verifican las estructuras internas o el funcionamiento de un programa, a diferencia de la funcionalidad expuesta al usuario final. En las pruebas de caja blanca, se utiliza una perspectiva interna del sistema (el código fuente), así como habilidades de programación, para diseñar casos de prueba. El evaluador elige entradas para ejercitar rutas a través del código y determina las salidas apropiadas. [31] [32] Esto es análogo a probar nodos en un circuito, por ejemplo, pruebas en circuito (TIC).
Si bien las pruebas de caja blanca se pueden aplicar a nivel de unidad , integración y sistema del proceso de prueba de software, generalmente se realizan a nivel de unidad. [33] Puede probar rutas dentro de una unidad, rutas entre unidades durante la integración y entre subsistemas durante una prueba a nivel de sistema. Aunque este método de diseño de pruebas puede descubrir muchos errores o problemas, es posible que no detecte partes no implementadas de la especificación o requisitos faltantes.
Las técnicas utilizadas en las pruebas de caja blanca incluyen: [32] [34]
Las herramientas de cobertura de código pueden evaluar la integridad de un conjunto de pruebas creado con cualquier método, incluidas las pruebas de caja negra. Esto permite al equipo de software examinar partes de un sistema que rara vez se prueban y garantiza que se hayan probado los puntos de función más importantes. [35] La cobertura del código como métrica de software se puede informar como porcentaje para: [31] [35] [36]
La cobertura del 100% de la declaración garantiza que todas las rutas o ramas del código (en términos de flujo de control ) se ejecuten al menos una vez. Esto es útil para garantizar una funcionalidad correcta, pero no suficiente, ya que el mismo código puede procesar diferentes entradas de forma correcta o incorrecta. [37]
Las pruebas de caja negra (también conocidas como pruebas funcionales) describen el diseño de casos de prueba sin conocimiento de la implementación, sin leer el código fuente. Los evaluadores sólo saben lo que se supone que debe hacer el software, no cómo lo hace. [38] Los métodos de prueba de caja negra incluyen: partición de equivalencia , análisis de valores límite , pruebas de todos los pares , tablas de transición de estados , pruebas de tablas de decisiones , pruebas fuzz , pruebas basadas en modelos , pruebas de casos de uso , pruebas exploratorias y pruebas basadas en especificaciones. . [31] [32] [36]
Las pruebas basadas en especificaciones tienen como objetivo probar la funcionalidad del software de acuerdo con los requisitos aplicables. [39] Este nivel de prueba generalmente requiere que se proporcionen casos de prueba exhaustivos al evaluador, quien luego puede simplemente verificar que para una entrada determinada, el valor de salida (o comportamiento), "es" o "no es" el mismo que el valor esperado especificado en el caso de prueba. Los casos de prueba se construyen en torno a especificaciones y requisitos, es decir, lo que se supone que debe hacer la aplicación. Utiliza descripciones externas del software, incluidas especificaciones, requisitos y diseños para derivar casos de prueba. Estas pruebas pueden ser funcionales o no funcionales , aunque normalmente son funcionales. Puede que sean necesarias pruebas basadas en especificaciones para garantizar la funcionalidad correcta, pero son insuficientes para proteger contra situaciones complejas o de alto riesgo. [40]
Las pruebas de caja negra se pueden utilizar en cualquier nivel de prueba, aunque normalmente no en el nivel unitario. [33]
Prueba de interfaz de componentes
Las pruebas de interfaz de componentes son una variación de las pruebas de caja negra , que se centran en los valores de los datos más allá de las acciones relacionadas de un componente del subsistema. [41] La práctica de las pruebas de interfaz de componentes se puede utilizar para comprobar el manejo de los datos pasados entre varias unidades, o componentes del subsistema, más allá de las pruebas de integración total entre esas unidades. [42] [43] Los datos que se pasan se pueden considerar como "paquetes de mensajes" y se puede verificar el rango o los tipos de datos, para los datos generados desde una unidad, y probar su validez antes de pasarlos a otra unidad. Una opción para las pruebas de interfaz es mantener un archivo de registro separado de los elementos de datos que se pasan, a menudo con una marca de tiempo registrada para permitir el análisis de miles de casos de datos pasados entre unidades durante días o semanas. Las pruebas pueden incluir verificar el manejo de algunos valores de datos extremos mientras otras variables de interfaz se pasan como valores normales. [42] Los valores de datos inusuales en una interfaz pueden ayudar a explicar el rendimiento inesperado en la siguiente unidad.
El objetivo de las pruebas visuales es brindar a los desarrolladores la capacidad de examinar lo que estaba sucediendo en el punto de falla del software presentando los datos de tal manera que el desarrollador pueda encontrar fácilmente la información que necesita y que la información se exprese claramente. . [44] [45]
En el centro de las pruebas visuales está la idea de que mostrarle a alguien un problema (o una falla en la prueba), en lugar de simplemente describirlo, aumenta enormemente la claridad y la comprensión. Por lo tanto, las pruebas visuales requieren la grabación de todo el proceso de prueba, capturando todo lo que ocurre en el sistema de prueba en formato de video. Los vídeos de salida se complementan con entradas del probador en tiempo real a través de una cámara web de imagen en imagen y comentarios de audio de micrófonos.
Las pruebas visuales ofrecen una serie de ventajas. La calidad de la comunicación aumenta drásticamente porque los evaluadores pueden mostrar el problema (y los eventos que lo llevaron) al desarrollador en lugar de simplemente describirlo y la necesidad de replicar las fallas de las pruebas dejará de existir en muchos casos. El desarrollador tendrá toda la evidencia que necesita sobre una falla en la prueba y, en cambio, podrá concentrarse en la causa de la falla y cómo se debe solucionar.
Las pruebas ad hoc y las pruebas exploratorias son metodologías importantes para verificar la integridad del software, porque requieren menos tiempo de preparación para su implementación, mientras que los errores importantes se pueden encontrar rápidamente. [46] En las pruebas ad hoc, donde las pruebas se llevan a cabo de manera improvisada, la capacidad de los evaluadores para basar las pruebas en métodos documentados y luego improvisar variaciones de esas pruebas puede resultar en un examen más riguroso de las correcciones de defectos. [46] Sin embargo, a menos que se mantenga una documentación estricta de los procedimientos, uno de los límites de las pruebas ad hoc es la falta de repetibilidad. [46]
Las pruebas de caja gris (ortografía estadounidense: prueba de caja gris) implican el uso del conocimiento de algoritmos y estructuras de datos internos con el fin de diseñar pruebas mientras se ejecutan esas pruebas a nivel de usuario o de caja negra. El evaluador a menudo tendrá acceso tanto al "código fuente como al binario ejecutable". [47] Las pruebas de caja gris también pueden incluir ingeniería inversa (utilizando análisis de código dinámico) para determinar, por ejemplo, valores límite o mensajes de error. [47] La manipulación de datos de entrada y el formato de salida no califican como caja gris, ya que la entrada y la salida están claramente fuera de la "caja negra" que llamamos el sistema bajo prueba. Esta distinción es particularmente importante cuando se realizan pruebas de integración entre dos módulos de código escritos por dos desarrolladores diferentes, donde solo las interfaces están expuestas para la prueba.
Al conocer los conceptos subyacentes de cómo funciona el software, el evaluador toma decisiones de prueba mejor informadas mientras prueba el software desde fuera. Por lo general, a un evaluador de caja gris se le permitirá configurar un entorno de prueba aislado con actividades como inicializar una base de datos . El evaluador puede observar el estado del producto que se está probando después de realizar ciertas acciones, como ejecutar declaraciones SQL en la base de datos y luego ejecutar consultas para garantizar que se hayan reflejado los cambios esperados. Las pruebas de caja gris implementan escenarios de prueba inteligentes, basados en información limitada. Esto se aplicará particularmente al manejo de tipos de datos, manejo de excepciones , etc. [48]
Con el concepto de pruebas de caja gris, esta "distinción arbitraria" entre pruebas de caja blanca y negra se ha desvanecido un poco. [33]
La mayoría de los sistemas de software tienen procedimientos de instalación necesarios antes de poder utilizarlos para su propósito principal. Probar estos procedimientos para lograr un sistema de software instalado que pueda usarse se conoce como prueba de instalación . [49] : 139 Estos procedimientos pueden implicar actualizaciones totales o parciales y procesos de instalación/desinstalación.
Una causa común de falla del software (real o percibida) es la falta de compatibilidad con otras aplicaciones de software , sistemas operativos (o versiones de sistemas operativos , antiguos o nuevos) o entornos de destino que difieren mucho del original (como una terminal o La aplicación GUI destinada a ejecutarse en el escritorio ahora debe convertirse en una aplicación web , que debe representarse en un navegador web ). Por ejemplo, en el caso de una falta de compatibilidad con versiones anteriores , esto puede ocurrir porque los programadores desarrollan y prueban el software solo en la última versión del entorno de destino, que es posible que no todos los usuarios estén ejecutando. Esto tiene como consecuencia no deseada que el trabajo más reciente puede no funcionar en versiones anteriores del entorno de destino o en hardware más antiguo que las versiones anteriores del entorno de destino eran capaces de utilizar. A veces, estos problemas se pueden solucionar abstrayendo de forma proactiva la funcionalidad del sistema operativo en un módulo de programa o biblioteca independiente .
Las pruebas de cordura determinan si es razonable continuar con más pruebas.
Las pruebas de humo consisten en intentos mínimos de operar el software, diseñados para determinar si existen problemas básicos que impidan que funcione. Estas pruebas se pueden utilizar como prueba de verificación de compilación .
Las pruebas de regresión se centran en encontrar defectos después de que se haya producido un cambio importante en el código. Específicamente, busca descubrir regresiones de software , como características degradadas o perdidas, incluidos errores antiguos que han regresado. Estas regresiones ocurren cada vez que una funcionalidad del software que anteriormente funcionaba correctamente deja de funcionar según lo previsto. Normalmente, las regresiones ocurren como una consecuencia no deseada de cambios en el programa, cuando la parte recientemente desarrollada del software choca con el código previamente existente. Las pruebas de regresión suelen ser el esfuerzo de prueba más grande en el desarrollo de software comercial, [50] debido a la verificación de numerosos detalles en características de software anteriores, e incluso se puede desarrollar software nuevo mientras se utilizan algunos casos de prueba antiguos para probar partes del nuevo diseño y garantizar la funcionalidad anterior. todavía es compatible.
Los métodos comunes de pruebas de regresión incluyen volver a ejecutar conjuntos anteriores de casos de prueba y verificar si han vuelto a surgir fallas previamente solucionadas. La profundidad de las pruebas depende de la fase del proceso de lanzamiento y del riesgo de las funciones agregadas. Pueden ser completos, para cambios agregados tarde en la versión o considerados riesgosos, o ser muy superficiales y consistir en pruebas positivas en cada característica, si los cambios se realizan al principio de la versión o se consideran de bajo riesgo.
Las pruebas de aceptación son pruebas a nivel del sistema para garantizar que el software cumpla con las expectativas del cliente. [51] [52] [53] [54]
Las pruebas de aceptación se pueden realizar como parte del proceso de transferencia entre dos fases cualesquiera de desarrollo. [ cita necesaria ]
Las pruebas suelen agruparse en estos niveles según el lugar en el que se realizan en el proceso de desarrollo de software o el nivel de especificidad de la prueba. [54]
En ocasiones, la UAT la realiza el cliente, en su entorno y en su propio hardware.
OAT se utiliza para llevar a cabo la preparación operativa (prelanzamiento) de un producto, servicio o sistema como parte de un sistema de gestión de calidad . OAT es un tipo común de prueba de software no funcional, utilizado principalmente en proyectos de desarrollo y mantenimiento de software . Este tipo de prueba se centra en la preparación operativa del sistema que se va a admitir o que pasará a formar parte del entorno de producción. Por lo tanto, también se conoce como prueba de preparación operativa (ORT) o prueba de preparación y aseguramiento de operaciones (OR&A). Las pruebas funcionales dentro de OAT se limitan a aquellas pruebas que se requieren para verificar los aspectos no funcionales del sistema.
Además, las pruebas de software deben garantizar que la portabilidad del sistema, además de funcionar como se espera, no dañe o corrompa parcialmente su entorno operativo ni haga que otros procesos dentro de ese entorno dejen de funcionar. [55]
Las pruebas de aceptación contractual se realizan con base en los criterios de aceptación del contrato definidos durante la firma del contrato, mientras que las pruebas de aceptación regulatorias se realizan con base en las regulaciones relevantes para el producto de software. Ambas pruebas pueden ser realizadas por usuarios o evaluadores independientes. Las pruebas de aceptación de regulaciones a veces implican que las agencias reguladoras auditen los resultados de las pruebas. [54]
Las pruebas alfa son pruebas operativas simuladas o reales realizadas por usuarios/clientes potenciales o un equipo de pruebas independiente en el sitio de los desarrolladores. Las pruebas alfa se emplean a menudo para software comercial como una forma de prueba de aceptación interna antes de que el software pase a la prueba beta. [56]
Las pruebas beta vienen después de las pruebas alfa y pueden considerarse una forma de prueba de aceptación del usuario externo . Las versiones del software, conocidas como versiones beta , se lanzan a una audiencia limitada fuera del equipo de programación conocida como probadores beta. El software se lanza a grupos de personas para que pruebas adicionales puedan garantizar que el producto tenga pocas fallas o errores . Las versiones beta pueden ponerse a disposición del público abierto para aumentar el campo de comentarios a un número máximo de usuarios futuros y ofrecer valor antes, durante un período de tiempo prolongado o incluso indefinido ( beta perpetua ). [57]
Las pruebas funcionales se refieren a actividades que verifican una acción o función específica del código. Generalmente se encuentran en la documentación de requisitos del código, aunque algunas metodologías de desarrollo funcionan a partir de casos de uso o historias de usuarios. Las pruebas funcionales tienden a responder a la pregunta de "¿puede el usuario hacer esto?" o "¿funciona esta característica en particular?".
Las pruebas no funcionales se refieren a aspectos del software que pueden no estar relacionados con una función específica o acción del usuario, como la escalabilidad u otro rendimiento , el comportamiento bajo ciertas restricciones o la seguridad . Las pruebas determinarán el punto de ruptura, el punto en el que los extremos de escalabilidad o rendimiento conducen a una ejecución inestable. Los requisitos no funcionales tienden a ser aquellos que reflejan la calidad del producto, particularmente en el contexto de la perspectiva de idoneidad de sus usuarios.
Las pruebas continuas son el proceso de ejecutar pruebas automatizadas como parte del proceso de entrega de software para obtener comentarios inmediatos sobre los riesgos comerciales asociados con una versión candidata de software. [58] [59] Las pruebas continuas incluyen la validación tanto de requisitos funcionales como de requisitos no funcionales ; El alcance de las pruebas se extiende desde la validación de requisitos ascendentes o historias de usuarios hasta la evaluación de los requisitos del sistema asociados con los objetivos comerciales generales. [60] [61]
Las pruebas destructivas intentan provocar que falle el software o un subsistema. Verifica que el software funcione correctamente incluso cuando recibe entradas no válidas o inesperadas, estableciendo así la solidez de las rutinas de validación de entradas y gestión de errores. [ cita necesaria ] La inyección de fallas de software , en forma de fuzzing , es un ejemplo de prueba de fallas. Varias herramientas comerciales de prueba no funcionales están vinculadas desde la página de inyección de fallas de software ; También existen numerosas herramientas de software gratuitas y de código abierto disponibles que realizan pruebas destructivas.
Las pruebas de rendimiento generalmente se ejecutan para determinar cómo se desempeña un sistema o subsistema en términos de capacidad de respuesta y estabilidad bajo una carga de trabajo particular. También puede servir para investigar, medir, validar o verificar otros atributos de calidad del sistema, como la escalabilidad, la confiabilidad y el uso de recursos.
Las pruebas de carga se ocupan principalmente de comprobar que el sistema puede continuar funcionando bajo una carga específica, ya sean grandes cantidades de datos o una gran cantidad de usuarios . Esto generalmente se conoce como escalabilidad del software . La actividad de prueba de carga relacionada cuando se realiza como una actividad no funcional a menudo se denomina prueba de resistencia . Las pruebas de volumen son una forma de probar las funciones del software incluso cuando ciertos componentes (por ejemplo, un archivo o una base de datos) aumentan radicalmente de tamaño. Las pruebas de estrés son una forma de probar la confiabilidad bajo cargas de trabajo inesperadas o poco comunes. Las pruebas de estabilidad (a menudo denominadas pruebas de carga o resistencia) verifican si el software puede funcionar bien de forma continua durante un período aceptable o más.
Hay poco acuerdo sobre cuáles son los objetivos específicos de las pruebas de desempeño. Los términos prueba de carga, prueba de rendimiento, prueba de escalabilidad y prueba de volumen a menudo se usan indistintamente.
Los sistemas de software en tiempo real tienen estrictas limitaciones de tiempo. Para probar si se cumplen las restricciones de tiempo, se utilizan pruebas en tiempo real .
Las pruebas de usabilidad sirven para comprobar si la interfaz de usuario es fácil de usar y comprender. Se trata principalmente del uso de la aplicación. Este no es un tipo de prueba que pueda automatizarse; Se necesitan usuarios humanos reales, monitoreados por diseñadores de UI capacitados .
Se realizan pruebas de accesibilidad para garantizar que el software sea accesible para personas con discapacidades. Algunas de las pruebas comunes de accesibilidad web son
Estándares comunes para el cumplimiento
Las pruebas de seguridad son esenciales para el software que procesa datos confidenciales para evitar la intrusión de piratas informáticos en el sistema .
La Organización Internacional de Normalización (ISO) define esto como un "tipo de prueba realizada para evaluar el grado en que un elemento de prueba y los datos e información asociados están protegidos de modo que personas o sistemas no autorizados no puedan usarlos, leerlos o modificarlos, y A las personas o sistemas autorizados no se les niega el acceso a ellos." [62]
Las pruebas de internacionalización y localización validan que el software se puede utilizar con diferentes idiomas y regiones geográficas. El proceso de pseudolocalización se utiliza para probar la capacidad de una aplicación para traducirse a otro idioma y facilitar la identificación de cuándo el proceso de localización puede introducir nuevos errores en el producto.
Las pruebas de globalización verifican que el software esté adaptado a una nueva cultura (como diferentes monedas o zonas horarias). [63]
También se debe probar la traducción real a lenguajes humanos. Los posibles fallos de localización y globalización incluyen:
Las pruebas de desarrollo son un proceso de desarrollo de software que implica la aplicación sincronizada de un amplio espectro de estrategias de prevención y detección de defectos para reducir los riesgos, el tiempo y los costos del desarrollo de software. Lo realiza el desarrollador o ingeniero de software durante la fase de construcción del ciclo de vida de desarrollo de software. Las pruebas de desarrollo tienen como objetivo eliminar los errores de construcción antes de que el código se promueva a otras pruebas; Esta estrategia tiene como objetivo aumentar la calidad del software resultante, así como la eficiencia del proceso de desarrollo general.
Dependiendo de las expectativas de la organización para el desarrollo de software, las pruebas de desarrollo pueden incluir análisis de código estático , análisis de flujo de datos, análisis de métricas, revisiones de código por pares, pruebas unitarias, análisis de cobertura de código, trazabilidad y otras prácticas de prueba de software.
Las pruebas A/B son un método para ejecutar un experimento controlado para determinar si un cambio propuesto es más efectivo que el enfoque actual. Los clientes son dirigidos a una versión actual (control) de una función o a una versión modificada (tratamiento) y se recopilan datos para determinar qué versión es mejor para lograr el resultado deseado.
Las pruebas concurrentes o concurrentes evalúan el comportamiento y el rendimiento del software y los sistemas que utilizan computación concurrente , generalmente en condiciones de uso normales. Los problemas típicos que expondrá este tipo de pruebas son interbloqueos, condiciones de carrera y problemas con el manejo de recursos/memoria compartida.
En las pruebas de software, las pruebas de conformidad verifican que un producto funcione de acuerdo con sus estándares especificados. Los compiladores, por ejemplo, se someten a pruebas exhaustivas para determinar si cumplen con el estándar reconocido para ese idioma.
Crear una visualización del resultado esperado, ya sea como comparación de datos de texto o capturas de pantalla de la interfaz de usuario, [3] : 195 a veces se denomina prueba de instantáneas o prueba Golden Master, a diferencia de muchas otras formas de prueba, esto no puede detectar fallas automáticamente y, en cambio, requiere que un humano evaluar el resultado en busca de inconsistencias.
La prueba de propiedades es una técnica de prueba en la que, en lugar de afirmar que entradas específicas producen resultados esperados específicos, el profesional genera aleatoriamente muchas entradas, ejecuta el programa en todas ellas y afirma la verdad de alguna "propiedad" que debería ser cierta para cada par. de entrada y salida. Por ejemplo, cada salida de una función de serialización debe ser aceptada por la función de deserialización correspondiente, y cada salida de una función de clasificación debe ser una lista que aumenta monótonamente y que contiene exactamente los mismos elementos que su entrada.
Las bibliotecas de prueba de propiedades permiten al usuario controlar la estrategia mediante la cual se construyen las entradas aleatorias, para garantizar la cobertura de casos degenerados o entradas que presentan patrones específicos que se necesitan para ejercer plenamente aspectos de la implementación bajo prueba.
Las pruebas de propiedades también se conocen a veces como "pruebas generativas" o "pruebas QuickCheck", ya que fueron introducidas y popularizadas por la biblioteca QuickCheck de Haskell . [64]
Las pruebas metamórficas (MT) son una técnica de prueba de software basada en propiedades, que puede ser un enfoque eficaz para abordar el problema del oráculo de prueba y el problema de generación de casos de prueba. El problema del oráculo de prueba es la dificultad de determinar los resultados esperados de casos de prueba seleccionados o de determinar si los resultados reales concuerdan con los resultados esperados.
La prueba de VCR, también conocida como "prueba de reproducción" o prueba de "grabación/reproducción", es una técnica de prueba para aumentar la confiabilidad y velocidad de las pruebas de regresión que involucran un componente con el que la comunicación es lenta o poco confiable, a menudo una API de terceros. fuera del control del evaluador. Implica realizar una grabación ("casete") de las interacciones del sistema con el componente externo y luego reproducir las interacciones grabadas como sustituto de la comunicación con el sistema externo en ejecuciones posteriores de la prueba.
La técnica fue popularizada en el desarrollo web gracias a la biblioteca Ruby vcr.
En una organización, los evaluadores pueden estar en un equipo separado del resto del equipo de desarrollo de software o pueden estar integrados en un solo equipo. Las pruebas de software también pueden ser realizadas por probadores de software no dedicados.
En la década de 1980, el término probador de software comenzó a utilizarse para designar una profesión independiente.
Los roles y títulos de prueba de software notables incluyen: [65] administrador de pruebas , líder de pruebas , analista de pruebas , diseñador de pruebas , evaluador , desarrollador de automatización y administrador de pruebas . [66]
Las organizaciones que desarrollan software realizan pruebas de manera diferente, pero existen patrones comunes. [2]
En el desarrollo en cascada , las pruebas generalmente se realizan después de que se completa el código, pero antes de enviar el producto al cliente. [67] Esta práctica a menudo da como resultado que la fase de prueba se utilice como un amortiguador del proyecto para compensar los retrasos del proyecto, comprometiendo así el tiempo dedicado a las pruebas. [10] : 145-146
Algunos sostienen que el proceso en cascada permite que las pruebas comiencen cuando comienza el proyecto de desarrollo y que sean un proceso continuo hasta que finalice el proyecto. [68]
El desarrollo de software ágil comúnmente implica realizar pruebas mientras se escribe el código y organizar equipos con programadores y evaluadores y con miembros del equipo que realizan tanto la programación como las pruebas.
Una práctica ágil, el desarrollo de software basado en pruebas (TDD), es una forma de realizar pruebas unitarias de manera que las pruebas a nivel de unidad se realizan mientras se escribe el código del producto. [69] El código de prueba se actualiza a medida que se agregan nuevas características y se descubren condiciones de falla (errores corregidos). Por lo general, el código de prueba unitaria se mantiene con el código del proyecto, se integra en el proceso de compilación y se ejecuta en cada compilación y como parte de las pruebas de regresión. Los objetivos de esta integración continua son apoyar el desarrollo y reducir los defectos. [70] [69]
Incluso en organizaciones que separan los equipos por funciones de programación y prueba, muchas veces hacen que los programadores realicen pruebas unitarias . [71]
El siguiente ejemplo es común para el desarrollo en cascada. Las mismas actividades se encuentran comúnmente en otros modelos de desarrollo, pero podrían describirse de manera diferente.
Las pruebas de software se utilizan en asociación con la verificación y validación : [72]
Los términos verificación y validación se usan comúnmente indistintamente en la industria; También es común ver estos dos términos definidos con definiciones contradictorias. Según el Glosario estándar de terminología de ingeniería de software del IEEE : [11] : 80–81
Y, según la norma ISO 9000:
La contradicción se produce por el uso de los conceptos de requisitos y requisitos especificados pero con significados diferentes.
En el caso de los estándares IEEE, los requisitos especificados, mencionados en la definición de validación, son el conjunto de problemas, necesidades y deseos de las partes interesadas que el software debe resolver y satisfacer. Dichos requisitos están documentados en una Especificación de requisitos de software (SRS). Y los productos mencionados en la definición de verificación son los artefactos de salida de cada fase del proceso de desarrollo de software. Estos productos son, de hecho, especificaciones como la Especificación de diseño arquitectónico, la Especificación de diseño detallado, etc. El SRS también es una especificación, pero no se puede verificar (al menos no en el sentido utilizado aquí, más sobre este tema a continuación).
Pero, para la norma ISO 9000, los requisitos especificados son el conjunto de especificaciones, como se acaba de mencionar anteriormente, que deben verificarse. Una especificación, como se explicó anteriormente, es el producto de una fase del proceso de desarrollo de software que recibe otra especificación como entrada. Una especificación se verifica exitosamente cuando implementa correctamente su especificación de entrada. Todas las especificaciones se pueden verificar excepto el SRS porque es el primero (aunque se puede validar). Ejemplos: La Especificación de Diseño debe implementar el SRS; y, los artefactos de la fase de Construcción deben implementar la Especificación de Diseño.
Entonces, cuando estas palabras se definen en términos comunes, la aparente contradicción desaparece.
Tanto el SRS como el software deben estar validados. El SRS se puede validar estáticamente consultando con las partes interesadas. Sin embargo, ejecutar alguna implementación parcial del software o un prototipo de cualquier tipo (pruebas dinámicas) y obtener retroalimentación positiva de ellos, puede aumentar aún más la certeza de que el SRS está formulado correctamente. Por otro lado, el software, como producto final y en ejecución (no sus artefactos y documentos, incluido el código fuente), debe validarse dinámicamente con las partes interesadas ejecutando el software y pidiéndoles que lo prueben.
Algunos podrían argumentar que, para el SRS, el insumo son las palabras de las partes interesadas y, por lo tanto, la validación del SRS es lo mismo que la verificación del SRS. Pensar de esta manera no es aconsejable ya que sólo causa más confusión. Es mejor pensar en la verificación como un proceso que implica un documento de entrada formal y técnico.
En algunas organizaciones, las pruebas de software son parte de un proceso de garantía de calidad del software (SQA). [3] : 347 En SQA, los especialistas y auditores de procesos de software se preocupan por el proceso de desarrollo de software en lugar de solo por los artefactos como la documentación, el código y los sistemas. Examinan y modifican el proceso de ingeniería de software en sí para reducir la cantidad de fallas que terminan en el software entregado: la llamada tasa de defectos. Lo que constituye una tasa de defectos aceptable depende de la naturaleza del software; un videojuego de simulador de vuelo tendría una tolerancia a defectos mucho mayor que el software para un avión real. Aunque existen vínculos estrechos con SQA, los departamentos de pruebas a menudo existen de forma independiente y es posible que en algunas empresas no exista una función de SQA. [ cita necesaria ]
La prueba de software es una actividad para investigar el software bajo prueba con el fin de proporcionar información relacionada con la calidad a las partes interesadas. Por el contrario, QA ( garantía de calidad ) es la implementación de políticas y procedimientos destinados a evitar que los defectos lleguen a los clientes.
Las medidas de calidad incluyen temas como corrección , integridad, seguridad y requisitos ISO/IEC 9126 como capacidad, confiabilidad , eficiencia , portabilidad , mantenibilidad , compatibilidad y usabilidad .
Hay una serie de métricas o medidas de software de uso frecuente que se utilizan para ayudar a determinar el estado del software o la idoneidad de las pruebas.
Un proceso de prueba de software puede producir varios artefactos . Los artefactos reales producidos son un factor del modelo de desarrollo de software utilizado, las necesidades de las partes interesadas y de la organización.
Un plan de prueba es un documento que detalla el enfoque que se adoptará para las actividades de prueba previstas. El plan puede incluir aspectos tales como objetivos, alcance, procesos y procedimientos, requisitos de personal y planes de contingencia. [51] El plan de prueba podría presentarse en forma de un plan único que incluya todos los tipos de prueba (como un plan de prueba de sistema o de aceptación) y consideraciones de planificación, o puede emitirse como un plan de prueba maestro que proporcione una descripción general de más de un plan de prueba detallado (un plan de un plan). [51] Un plan de prueba puede ser, en algunos casos, parte de una " estrategia de prueba " amplia que documenta los enfoques de prueba generales, que puede ser en sí mismo un plan maestro de prueba o incluso un artefacto separado.
Un caso de prueba normalmente consta de un identificador único, referencias de requisitos de una especificación de diseño, condiciones previas, eventos, una serie de pasos (también conocidos como acciones) a seguir, entradas, salidas, resultados esperados y resultados reales. Clínicamente definido, un caso de prueba es una entrada y un resultado esperado. [74] Esto puede ser tan conciso como "para la condición x su resultado derivado es y", aunque normalmente los casos de prueba describen con más detalle el escenario de entrada y qué resultados podrían esperarse. Ocasionalmente puede ser una serie de pasos (pero a menudo los pasos están contenidos en un procedimiento de prueba separado que se puede aplicar contra múltiples casos de prueba, por una cuestión de economía) pero con un resultado esperado. Los campos opcionales son un ID de caso de prueba, un paso de prueba o un número de orden de ejecución, requisitos relacionados, profundidad, categoría de prueba, autor y casillas de verificación para determinar si la prueba es automatizable y si se ha automatizado. Los casos de prueba más grandes también pueden contener estados o pasos de requisitos previos y descripciones. Un caso de prueba también debe contener un lugar para el resultado real. Estos pasos se pueden almacenar en un documento de procesador de textos, hoja de cálculo, base de datos u otros repositorios comunes. En un sistema de base de datos, es posible que también pueda ver los resultados de pruebas anteriores, quién generó los resultados y qué configuración del sistema se utilizó para generar esos resultados. Estos resultados pasados normalmente se almacenarían en una tabla separada.
Un script de prueba es un procedimiento o código de programación que replica las acciones del usuario. Inicialmente, el término se derivó del producto del trabajo creado por herramientas de prueba de regresión automatizadas. Un caso de prueba será una base para crear scripts de prueba utilizando una herramienta o un programa.
En la mayoría de los casos, se utilizan varios conjuntos de valores o datos para probar la misma funcionalidad de una característica en particular. Todos los valores de prueba y los componentes ambientales modificables se recopilan en archivos separados y se almacenan como datos de prueba. También es útil proporcionar estos datos al cliente y con el producto o proyecto. Existen técnicas para generar datos de prueba.
El software, las herramientas, las muestras de entrada y salida de datos y las configuraciones se denominan colectivamente arnés de prueba .
Una ejecución de prueba es una colección de casos de prueba o conjuntos de pruebas que el usuario ejecuta y compara los resultados esperados con los reales. Una vez completado, se puede generar un informe o todas las pruebas ejecutadas.
Existen varios programas de certificación para respaldar las aspiraciones profesionales de los probadores de software y especialistas en control de calidad. Algunos profesionales argumentan que el campo de pruebas no está listo para la certificación, como se menciona en la sección de controversia.
Algunas de las principales controversias sobre las pruebas de software incluyen:
Se cree comúnmente que cuanto antes se detecte un defecto, más barato será solucionarlo. La siguiente tabla muestra el costo de reparación del defecto dependiendo de la etapa en la que se encontró. [84] Por ejemplo, si un problema en los requisitos se encuentra solo después de su lanzamiento, su solución costaría entre 10 y 100 veces más que si ya se hubiera encontrado mediante la revisión de los requisitos. Con la llegada de las prácticas modernas de implementación continua y los servicios basados en la nube, el costo de la reimplementación y el mantenimiento puede disminuir con el tiempo.
Los datos de los que se extrapola esta tabla son escasos. Laurent Bossavit dice en su análisis:
La curva de "proyectos más pequeños" resulta ser de sólo dos equipos de estudiantes de primer año, un tamaño de muestra tan pequeño que extrapolarlo a "proyectos más pequeños en general" es totalmente indefendible. El estudio de GTE no explica sus datos, salvo decir que provienen de dos proyectos, uno grande y otro pequeño. El artículo citado para el proyecto "Safeguard" de Bell Labs niega específicamente haber recopilado los datos detallados que sugieren los puntos de datos de Boehm. El estudio de IBM (el artículo de Fagan) contiene afirmaciones que parecen contradecir el gráfico de Boehm y ningún resultado numérico que corresponda claramente a sus datos.
Boehm ni siquiera cita un artículo sobre los datos de TRW, excepto cuando escribió para "Making Software" en 2010, y allí citó el artículo original de 1976. Existe un gran estudio realizado en TRW en el momento adecuado para que Boehm lo cite, pero ese documento no contiene el tipo de datos que respaldarían las afirmaciones de Boehm. [85]
int f(int x){return x*x-6*x+8;}
f(x)>=0
x=3