La prueba de software es el acto de examinar los artefactos y el comportamiento del software bajo prueba mediante verificación y validación . Las pruebas de software también pueden proporcionar una visión objetiva e independiente del software para permitir que la empresa aprecie y comprenda los riesgos de la implementación del software. Las técnicas de prueba incluyen, entre otras:
Las pruebas de software pueden proporcionar información objetiva e independiente sobre la calidad del software y el riesgo de que falle para los usuarios o patrocinadores. [1]
Las pruebas de software pueden determinar la corrección del software bajo el supuesto de algunas hipótesis específicas (consulte la jerarquía de dificultad de las pruebas a continuación), pero las pruebas no pueden identificar todas las fallas dentro del software. [2] En cambio, proporciona una crítica o comparación que compara el estado y el comportamiento del producto con oráculos de prueba : principios o mecanismos mediante los cuales alguien podría reconocer un problema. Estos oráculos pueden incluir (entre otros) especificaciones, contratos , [3] 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 u otros criterios.
Un objetivo principal de las pruebas es detectar fallas del software para poder descubrir y corregir los defectos. Las pruebas no pueden establecer que un producto funciona correctamente en todas las condiciones, sino sólo que no funciona correctamente en condiciones específicas. [4] El alcance de las pruebas de software puede incluir el examen del código, así como la ejecución de ese código en diversos entornos y condiciones, así como el examen de los aspectos del código: ¿hace lo que se supone que debe hacer y hace lo que necesita? hacer. En la cultura actual de desarrollo de software, una organización de pruebas puede estar separada del equipo de desarrollo. Hay varios roles para los miembros del equipo de pruebas. La información derivada de las pruebas de software se puede utilizar para corregir el proceso mediante el cual se desarrolla el software. [5] : 41–43
Cada producto de software tiene un público objetivo. Por ejemplo, el público del software de videojuegos es completamente diferente al del software bancario. Por lo tanto, cuando una organización desarrolla o invierte en un producto de software, puede evaluar si el producto de software será aceptable para sus usuarios finales , su público objetivo, sus compradores y otras partes interesadas. Las pruebas de software ayudan a realizar esta evaluación.
Las fallas de software ocurren a través del siguiente proceso: Un programador comete un error (error), lo que resulta en una falla (defecto, error) en el código fuente del software . Si se ejecuta este fallo, en determinadas situaciones el sistema producirá resultados erróneos provocando un fallo . [6] : 31
No todas las fallas necesariamente resultarán en fallas. Por ejemplo, las fallas en el código inactivo nunca resultarán en fallas. Una falla que no reveló fallas puede resultar en una falla cuando se cambia el entorno. Ejemplos de estos cambios en el entorno incluyen la ejecución del software en una nueva plataforma de hardware de computadora , alteraciones en los datos de origen o la interacción con software diferente. [7] Una sola falla puede resultar en una amplia gama de síntomas de falla.
No todas las fallas de software son causadas por errores de codificación. Una fuente común de defectos costosos son las lagunas en los requisitos, es decir, requisitos no reconocidos que resultan en errores de omisión por parte del diseñador del programa. [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 .
Un problema fundamental con 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. [4] : 17–18 [8] Esto significa que la cantidad de fallas en un producto de software puede ser muy grande y los defectos que ocurren con poca frecuencia son difíciles de encontrar durante las pruebas y la depuración. Más significativamente, 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 altamente subjetivas; algo que constituye valor suficiente para una persona puede resultar intolerable para otra.
Los desarrolladores de software no pueden probarlo todo, pero pueden utilizar el diseño de pruebas combinatorias para identificar la cantidad mínima de pruebas necesarias para obtener la cobertura que desean. El diseño de pruebas combinatorias permite a los usuarios obtener una mayor cobertura de pruebas con menos pruebas. Ya sea que busquen velocidad o profundidad de prueba, pueden utilizar métodos de diseño de pruebas combinatorias para generar variaciones estructuradas en sus casos de prueba. [9]
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. Se podría evitar más de un tercio de este coste si se realizaran mejores pruebas de software. [10] [ dudoso ]
La subcontratación de pruebas de software debido a los costos es muy común, siendo China, Filipinas y la India los destinos preferidos. [11]
Las pruebas de software pueden ser realizadas por probadores de software dedicados; Hasta la década de 1980, el término "probador de software" se utilizaba de forma generalizada, pero más tarde también se consideró una profesión independiente. En cuanto a los periodos y los diferentes objetivos en las pruebas de software, [12] se han establecido diferentes roles, como gerente de pruebas , líder de pruebas , analista de pruebas , diseñador de pruebas , tester , desarrollador de automatización y administrador de pruebas . Las pruebas de software también pueden ser realizadas por probadores de software no dedicados. [13]
Glenford J. Myers introdujo inicialmente la separación entre la depuración y las pruebas en 1979. [14] 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". [14] : 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.
Hay muchos enfoques disponibles en 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 . [15] [16]
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. [15] [16] Las técnicas típicas para estos son el uso de stubs /controladores o la ejecución desde un entorno de depuración . [dieciséis]
Las pruebas estáticas implican verificación , mientras que las pruebas dinámicas también implican validación . [dieciséis]
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. [17] 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 [20] ) 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 [21] [22] ).
Los métodos de prueba de software se dividen tradicionalmente en pruebas de caja blanca y de caja negra. Estos dos enfoques se utilizan para describir el punto de vista que adopta el evaluador al diseñar casos de prueba. También se puede aplicar un enfoque híbrido llamado prueba de caja gris a la metodología de prueba de software. [23] [24] Con el concepto de pruebas de caja gris, que desarrolla pruebas a partir de elementos de diseño específicos, ganando importancia, esta "distinción arbitraria" entre pruebas de caja blanca y negra se ha desvanecido un poco. [25]
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 explorar rutas a través del código y determinar las salidas apropiadas. [23] [24] 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. [25] 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: [24] [26]
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. [27] La cobertura del código como métrica de software se puede informar como porcentaje para: [23] [27] [28]
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. [29]
Las pruebas de caja negra (también conocidas como pruebas funcionales) tratan el software como una "caja negra", examinando la funcionalidad sin ningún conocimiento de la implementación interna, sin ver el código fuente. Los evaluadores sólo saben lo que se supone que debe hacer el software, no cómo lo hace. [30] 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 decisión , pruebas fuzz , pruebas basadas en modelos , pruebas de casos de uso , pruebas exploratorias y pruebas basadas en especificaciones. . [23] [24] [28]
Las pruebas basadas en especificaciones tienen como objetivo probar la funcionalidad del software de acuerdo con los requisitos aplicables. [31] 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. [32]
Una ventaja de la técnica de la caja negra es que no se requieren conocimientos de programación. Cualesquiera que sean los prejuicios que hayan tenido los programadores, es probable que el evaluador tenga un conjunto diferente y pueda enfatizar diferentes áreas de funcionalidad. Por otro lado, se ha dicho que las pruebas de caja negra son "como un paseo por un laberinto oscuro sin linterna". [33] Debido a que no examinan el código fuente, hay situaciones en las que un evaluador escribe muchos casos de prueba para verificar algo que podría haber sido probado por un solo caso de prueba o deja algunas partes del programa sin probar.
Este método de prueba se puede aplicar a todos los niveles de prueba de software: unitario , de integración , de sistema y de aceptación . [25] Por lo general, comprende la mayoría, si no todas, las pruebas en niveles superiores, pero también puede dominar las pruebas unitarias.
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. [34] 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. [35] [36] Los datos que se pasan pueden considerarse 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. [35] 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. . [37] [38]
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. [39] En las pruebas ad hoc, donde las pruebas se realizan de manera improvisada e 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. [39] 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. [39]
Las pruebas de caja gris (ortografía estadounidense: prueba de caja gris) implican tener conocimiento de las estructuras y algoritmos 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". [40] 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. [40] 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 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. [41]
En términos generales, existen al menos tres niveles de prueba: prueba unitaria, prueba de integración y prueba del sistema. [42] [43] [44] [45] Sin embargo, los desarrolladores pueden incluir un cuarto nivel, pruebas de aceptación. Esto puede ser en forma de pruebas de aceptación operativa o simples pruebas de usuario final (beta), pruebas para garantizar que el software cumpla con las expectativas funcionales. [46] [47] [48] Según el programa de estudios del nivel básico de pruebas certificadas de ISTQB, los niveles de prueba incluyen esos cuatro niveles, y el cuarto nivel se denomina prueba de aceptación. [49] Las pruebas se agrupan con frecuencia en uno de estos niveles según el lugar en el que se agregan en el proceso de desarrollo de software o el nivel de especificidad de la prueba.
Las pruebas unitarias se refieren a pruebas que verifican la funcionalidad de una sección específica de código, generalmente a nivel de función. En un entorno orientado a objetos, esto suele ser a nivel de clase, y las pruebas unitarias mínimas incluyen los constructores y destructores. [50]
Este tipo de pruebas generalmente las escriben los desarrolladores mientras trabajan en el código (estilo de caja blanca), para garantizar que la función específica funcione como se espera. Una función puede tener varias pruebas para detectar casos extremos u otras ramas del código. Las pruebas unitarias por sí solas no pueden verificar la funcionalidad de una pieza de software, sino que se utilizan para garantizar que los componentes básicos del software funcionen de forma independiente unos de otros.
Las pruebas unitarias son un proceso de desarrollo de software que implica una 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 unitarias tienen como objetivo eliminar errores de construcción antes de que el código pase a pruebas adicionales; 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 unitarias 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, análisis de cobertura de código y otras prácticas de prueba de software.
Las pruebas de integración son cualquier tipo de prueba de software que busca verificar las interfaces entre componentes con respecto a un diseño de software. Los componentes de software pueden integrarse de forma iterativa o todos juntos ("big bang"). Normalmente, la primera se considera una mejor práctica, ya que permite localizar y solucionar los problemas de interfaz más rápidamente.
Las pruebas de integración funcionan para exponer defectos en las interfaces y la interacción entre componentes integrados (módulos). Se integran y prueban grupos progresivamente mayores de componentes de software probados correspondientes a elementos del diseño arquitectónico hasta que el software funciona como un sistema. [51]
Las pruebas del sistema prueban un sistema completamente integrado para verificar que el sistema cumpla con sus requisitos. [6] : 74 Por ejemplo, una prueba del sistema podría implicar probar una interfaz de inicio de sesión, luego crear y editar una entrada, además de enviar o imprimir los resultados, seguido del procesamiento resumido o eliminación (o archivado) de las entradas, y luego cerrar sesión.
Las pruebas de aceptación comúnmente incluyen los siguientes cuatro tipos: [49]
La UAT y las pruebas alfa y beta se describen en la siguiente sección de tipos de pruebas.
La aceptación operativa 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. [52]
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. [49]
Diferentes etiquetas y formas de agrupar las pruebas pueden ser tipos de pruebas, tácticas o técnicas de prueba de software. [53]
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 . [54] : 139 Este procedimiento puede 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, [55] 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 pueden significar una de dos cosas:
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, [4] : 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 practicante 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.
Una práctica común en el desarrollo en cascada es que las pruebas las realiza un grupo independiente de evaluadores. Esto puede suceder:
Sin embargo, incluso en el modelo de desarrollo en cascada, las pruebas unitarias a menudo las realiza el equipo de desarrollo de software, incluso cuando las pruebas adicionales las realiza un equipo separado. [67]
Por el contrario, algunas disciplinas de software emergentes, como la programación extrema y el movimiento de desarrollo de software ágil , se adhieren a un modelo de " desarrollo de software basado en pruebas ". En este proceso, las pruebas unitarias las escriben primero los ingenieros de software (a menudo con programación en pares en la metodología de programación extrema). Se espera que las pruebas fallen inicialmente. A cada prueba fallida le sigue escribir el código suficiente para aprobarla. [68] Esto significa que los conjuntos de pruebas se actualizan continuamente a medida que se descubren nuevas condiciones de falla y casos extremos, y se integran con cualquier prueba de regresión que se desarrolle. Las pruebas unitarias se mantienen junto con el resto del código fuente del software y generalmente se integran en el proceso de compilación (con las pruebas inherentemente interactivas relegadas a un proceso de aceptación de compilación parcialmente manual).
Los objetivos finales de este proceso de prueba son respaldar la integración continua y reducir las tasas de defectos. [69] [68]
Esta metodología aumenta el esfuerzo de prueba realizado por el desarrollo, antes de llegar a cualquier equipo de prueba formal. En algunos otros modelos de desarrollo, la mayor parte de la ejecución de la prueba ocurre después de que se han definido los requisitos y se ha completado el proceso de codificación.
Aunque existen variaciones entre organizaciones, existe un ciclo típico de prueba. [2] El siguiente ejemplo es común entre las organizaciones que emplean el modelo de desarrollo en cascada . Las mismas prácticas se encuentran comúnmente en otros modelos de desarrollo, pero pueden no ser tan claras o explícitas.
Muchos grupos de programación [¿ como quién? ] confían cada vez más [ vago ] en pruebas automatizadas , especialmente grupos que utilizan desarrollo basado en pruebas . Hay muchos marcos [ especificar ] para escribir pruebas, y el software de integración continua ejecutará pruebas automáticamente cada vez que el código se registre en un sistema de control de versiones .
Si bien la automatización no puede reproducir todo lo que un ser humano puede hacer (y todas las formas en que piensa hacerlo), puede resultar muy útil para las pruebas de regresión. Sin embargo, requiere un conjunto de scripts de prueba bien desarrollado para que sea realmente útil.
Las pruebas de programas y la detección de fallos pueden mejorar significativamente mediante herramientas de prueba y depuradores . Las herramientas de prueba/depuración incluyen características como:
Algunas de estas características pueden incorporarse en una única herramienta compuesta o en un entorno de desarrollo integrado (IDE).
Las pruebas de captura y reproducción consisten en recopilar escenarios de uso de un extremo a otro mientras se interactúa con una aplicación y convertir estos escenarios en casos de prueba. Las posibles aplicaciones de captura y reproducción incluyen la generación de pruebas de regresión. La herramienta SCARPE [70] captura selectivamente un subconjunto de la aplicación en estudio mientras se ejecuta. JRapture captura la secuencia de interacciones entre un programa Java en ejecución y componentes en el sistema host, como archivos o eventos en interfaces gráficas de usuario. Estas secuencias luego se pueden reproducir para pruebas basadas en observaciones. [71] Saieva y otros. propone generar pruebas ad-hoc que reproduzcan los seguimientos de ejecución de usuarios registrados para probar parches candidatos en busca de errores de seguridad críticos. [72]
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. [46] 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). [46] 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 indicar si la prueba es automatizable y ha sido automatizada. 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 suele creer 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 del 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]
Las pruebas de software se utilizan en asociación con la verificación y validación : [86]
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 : [6] : 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.
Las pruebas de software pueden considerarse parte de un proceso de garantía de calidad del software (SQA). [4] : 347 En SQA, los especialistas y auditores de procesos de software se preocupan por el proceso de desarrollo de software y no 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.
int f(int x){return x*x-6*x+8;}f(x)>=0x=3{{cite book}}: CS1 maint: date and year (link)
